T1 FIX7 Design Verification - 01 Design Completeness (SUPERTRACK A)
01 — Design Completeness Review (SUPERTRACK A)
A.1 Did Codex correct the original FIX7 design, or only review it?
Both — by its own account. The design-plan directory is rev2 and the readme/recommendation/corrections docs state the original FIX7 was "directionally correct but insufficient" and that ten disguised-hardcode/authority ambiguities plus writer/activation TOCTOU were corrected. The final-review 10-design-corrections-if-any.md enumerates the corrections and asserts "No unresolved design choice is delegated to T1." So Codex claims to have corrected then re-reviewed.
Caveat (decisive): the corrections are recorded only as property bullet-lists. The artifact that would let T1 implement without guessing — concrete schemas, parameters, mechanisms — was not produced. So the correction is real at the intent level and unverifiable at the implementation level.
A.2 Which design docs were changed?
Changed/authored (rev2 in design-plan dir): 00-readme-first, 02-control-plane-immutability-design, 09-implementation-staging-plan, 11-final-recommendation. Final-review dir (rev1): 00-readme-first, 10-design-corrections-if-any, 11-final-verdict-and-t1-go-no-go. Two checkpoints (control-plane-immutability rev2; final-hardcode-review rev1).
Not authored: final-review 01–09 (the nine per-dimension review docs the macro instructed me to read). Confirmed not_found in agent-data KB and Incomex KB. Also absent: design-plan 01, 03–08, 10 (only 00/02/09/11 exist).
A.3 Which prior failure classes are now addressed (at design-intent level)?
| Prior failure (FIX..FIX6 / Codex audits) | FIX7 design answer | Addressed at intent? |
|---|---|---|
| Tier CASE / metadata-ID hardcode | generic typed interpreter, no metadata-ID CASE/list | Yes (intent) |
| Authority callers reach legacy objects | deterministic authority-scope closure; analyzer contract | Yes (intent) |
| Directus owns/ can mutate control plane (262 objs) | NOLOGIN qt001_cp_owner; Directus read-only; REVOKE |
Yes (intent) — but operator-gated, not done |
| Signoff spoofable / not plan-bound | manifest/FK principal contracts; content-addressed evidence; no self-sign | Yes (intent) |
| Capability = function-exists / free-text | behavioral + operational evidence, verifier identity | Yes (intent) |
| MD5 / delimiter hash; signoff stales plan hash | SHA-256 exact-set; control-state vs plan-content hash | Yes (intent) — extension dependency open |
| pg_depend can't see body calls (func_to_func=0) | does NOT pretend; analyzer + OID-checked dynamic SQL | Yes (intent) — seal model open |
| Writer/activation TOCTOU | hash-bound control_epoch serialization |
Yes (intent) — mechanism open |
| no-bypass tautology / bool_and NULL-ignore | manifest-driven no-bypass vectors; no caller PASS | Yes (intent) |
A.4 Which risks remain intentionally operator-gated?
All live privileged actions: role creation, ownership cutover, ACL/REVOKE, extension install, manifest activation (quorum), scheduler, writer repoint, FIX7b, FIX7c. Plus Stage 2.6B, permits, REAL_RUN, QT001 apply. The design keeps authority_cutover_complete=false and readiness BLOCKED until these complete. This deferral is correct and is not the basis of the block.
A.5 Is any instruction ambiguous enough that T1 could implement differently from Codex's intent?
Yes — pervasively. Because no concrete spec exists, T1 implementing FIX7a today would have to independently decide, among others:
- Manifest table set, column names, types, PK/FK, and what bytes the SHA-256 seal covers.
- The exact-set membership of each manifest and the readiness denominator definition (how "missing/extra/NULL gate fails" is computed).
- Activation quorum N, what makes a principal "independent," and the activation-envelope schema.
- The hash component list, domain-separation scheme, canonical ordering, and the hashing primitive/extension.
- The capability measurement definitions, thresholds, and what counts as "fresh post-activation evidence."
- The
control_epochlock object and the writer's pre-commit staleness check. - The analyzer trust/seal model and how its output binds to live function bodies.
- Operator step sequence and rollback scripts.
Each is a semantic/governance decision (per muc-tieu-mo §4G these are stop-without-asking items, not surgical drift). Different reasonable choices yield materially different security properties — exactly the divergence the macro warns against.
Completeness verdict
INCOMPLETE. Architecture direction = sound. Design package = not implementation-ready: nine claimed per-dimension review docs missing; zero concrete specification; ≥8 unresolved implementation decisions that are not T1's to make. → feeds DESIGN_BLOCKED_REQUIRES_CODEX_UPDATE.