KB-5403

T1 FIX7 Design Deep Verification Before Implementation - 00 Readme First

6 min read Revision 1
QT001FIX7T1design-verificationread-onlyDESIGN_BLOCKED_REQUIRES_CODEX_UPDATE

T1 FIX7 Design Deep Verification — 00 Readme First

Macro: PROGRAM_REVIEW_T1_FIX7_DESIGN_DEEP_VERIFICATION_BEFORE_IMPLEMENTATION Verifier: T1 (production Agent for Agent Data) Date: 2026-06-08 Execution mode: READ-ONLY design verification (Design-Only Macro Mode, per prompt-muc-tieu-mo-for-claude-code §4H). Live mutation: NONE except these KB report docs + checkpoint. No DDL/DML/role/owner/grant/manifest/writer/permit/apply. DB objects created: NONE. v_fix7_design_review_scope_summary was deliberately NOT created — DDL is forbidden in Design-Only mode; this verification is report-only.

FINAL STATUS: DESIGN_BLOCKED_REQUIRES_CODEX_UPDATE

T1 must NOT implement FIX7a yet. The corrected FIX7 design, as it exists in the KB, is a set of high-level property assertions, not an implementable specification. Implementing it now would require T1 to invent the concrete manifest schemas, the sealed gate denominator, the activation quorum parameters, the hash component list, the control-epoch lock mechanism, the analyzer trust model, the operator runbook and the rollback scripts — i.e. to "fix by assuming," which the macro explicitly forbids.

This does not mean the architecture is wrong. The architectural direction is sound and addresses every prior Codex failure class at the conceptual level. The block is about completeness and concreteness of the design package, plus four to five genuine open clarifications.

Headline findings (full detail in 01–14)

  • F1 — The per-dimension review docs the prompt told me to read do not exist. Final-review docs 0109 (hardcode, pg-native, control-plane, readiness, signoff, capability, hash, dependency, no-bypass) return not_found in both the agent-data KB and the Incomex KB. Only 00, 10, 11 + two checkpoints exist. The design index confirms the precedent: "detailed design docs 01..10 were never authored." The verdict PG_NATIVE_DRIVEN_READY_FOR_T1_IMPLEMENTATION therefore rests on review evidence that was never written.
  • F2 — Property-assertion-only. Every existing FIX7 doc is ~430–870 chars. There is no concrete artifact anywhere for: manifest table DDL/columns; sealed exact-set membership and the readiness denominator definition; activation quorum N and principal-independence criteria; hash component list / domain separation / extension dependency; capability measurement definitions and thresholds; the control_epoch lock primitive; the analyzer/static-analysis seal model; operator step sequences; rollback scripts.
  • F3 — Live control-plane is still Directus-owned (this is genuinely design-only). qt001_cp_owner does not exist; all four QT001 control tables are owned by directus (the app login role); directus holds INSERT and DELETE on qt001_independent_review_signoff and INSERT on qt001_capability_operational_evidence. FIX7's central premise (NOLOGIN owner + Directus read-only + REVOKE) is entirely future/operator-gated. FIX7a alone delivers zero control-plane immutability.
  • F4 — Current baseline is correctly fail-closed. qt001_signoff_plan_binding = 0, qt001_capability_operational_evidence = 0 → readiness BLOCKED, scale NOT_SAFE today. No false-green at present.
  • F5 — Hash extension availability is unaddressed. "Sealed SHA-256 manifests" is asserted, but whether pgcrypto/digest() is installed, or staged as an operator requirement if missing, is never specified (SUPERTRACK H.1).
  • F6 — Dependency-truth direction is correct but its trust model is unspecified. The design correctly does NOT pretend pg_depend sees PL/pgSQL body calls (FIX6 already proved func_to_func=0). It substitutes an "analyzer contract" + manifest-bounded dynamic SQL + runtime OID checks — but the analyzer's seal, quorum and staleness-binding are undefined.
  • F7 — TOCTOU/control-epoch is plausible but mechanism-undefined. Writer-shared / activation-exclusive epoch locking is the right shape, but the lock object, the writer's pre-commit staleness predicate, and the post-activation fresh-evidence binding are not concretely specified.

What Codex got right (confirmed at property level)

Generic typed policy/capability/hash interpreters with no metadata-ID CASE/list; sealed exact-set manifests; independent activation quorum; content-addressed evidence; zero direct runtime target DML; control-epoch serialization; Level-B DOT/migration pipeline for privileged changes; readiness stays BLOCKED and Stage 2.6B / permit / REAL_RUN / QT001 apply stay blocked. These are the correct answers to the FIX..FIX6 rejection history.

Document map

  • 01 design completeness (SUPERTRACK A)
  • 02 zero hardcode / disguised hardcode (B)
  • 03 PG-first / native / driven (C)
  • 04 control-plane immutability (D)
  • 05 readiness exact-set denominator (E)
  • 06 signoff / principal / evidence (F)
  • 07 capability verifier evidence (G)
  • 08 canonical hash (H)
  • 09 dependency truth / callgraph (I)
  • 10 TOCTOU / control_epoch (J)
  • 11 Level-B DOT / migration pipeline (K)
  • 12 T1 implementation boundary (L)
  • 13 risk register (M)
  • 14 final go / no-go (N)

Sources read (live, 2026-06-08)

Design-plan dir 00/02/09/11 (rev2); final-review dir 00/10/11 (rev1); both checkpoints; BIRTH_GATEWAY_DESIGN_INDEX.md (rev22); prompt-muc-tieu-mo-for-claude-code.md (v1.3). Final-review 01–09 confirmed absent. Live read-only PG: role/ownership/privilege/row-count checks (no mutation).

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-design-deep-verification-before-implementation-2026-06-07/00-readme-first.md