KB-318B

T1 FIX7 Design Verification - 01 Design Completeness (SUPERTRACK A)

5 min read Revision 1
QT001FIX7T1design-completenesssupertrack-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 0109 (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, 0308, 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:

  1. Manifest table set, column names, types, PK/FK, and what bytes the SHA-256 seal covers.
  2. The exact-set membership of each manifest and the readiness denominator definition (how "missing/extra/NULL gate fails" is computed).
  3. Activation quorum N, what makes a principal "independent," and the activation-envelope schema.
  4. The hash component list, domain-separation scheme, canonical ordering, and the hashing primitive/extension.
  5. The capability measurement definitions, thresholds, and what counts as "fresh post-activation evidence."
  6. The control_epoch lock object and the writer's pre-commit staleness check.
  7. The analyzer trust/seal model and how its output binds to live function bodies.
  8. 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.

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-design-deep-verification-before-implementation-2026-06-07/01-design-completeness-review.md