KB-30DB

T1 FIX7 Corrected-Spec Short Review — Readme First

6 min read Revision 1
fix7architecturet1-reviewcorrected-specshort-review

00 - T1 FIX7 Corrected-Spec Short Review — Readme First

Date: 2026-06-08 Author: T1 (production Agent, Agent Data) Mode: READ-ONLY production. Execution mode AUTHOR_MODE_ONLY. Live mutation: NO. Reviewed package: codex-fix7-spec-artifact-correction-from-t1-proposals-2026-06-07 (docs 00..12), which claims to resolve T1 CP-01..CP-07 and address CP-08..CP-09.

Boundary held

No production DB / role / grant / trigger / function / scheduler / UI / REAL_RUN / permit / ledger / QT001-apply mutated. No DB object created. No SQL applied. No manifest activated. No ownership/ACL change. No permit opened. Stage 2.6B not advanced. No Codex doc edited. T1 wrote only this KB review package. Read path OPEN — all 13 corrected artifacts (00..12), Codex self-review (11) and final verdict (12), the correction checkpoint, the superseded finalization checkpoint, my prior T1 proposal package (13) and prior checkpoint, and the governing law prompt-muc-tieu-mo-for-claude-code v1.3 were read in full.

One-line verdict

DESIGN_NEEDS_TARGETED_CODEX_CORRECTION_WITH_PROPOSALS. The 9 prior proposals CP-01..CP-09 are resolved to a high standard — a genuine, substantial advance — but cross-impact analysis surfaces a short, precise set of residual corrections (RP-01..RP-08; 4 blocking, 4 advisory) that must close before Codex final approval. This is NOT a hardcode / PG-native / scale / read-path FAIL.

Why NEEDS_CORRECTION even though all 9 CPs are met

The 9 CP responses are individually verified. The block is NEW and is a direct consequence of the corrections themselves — precisely the "changing one detail affects another layer" risk the operator warned about:

  • RP-01 (BLOCKING — completeness): the now-published hash key-maps H04/H05/H06 (doc 07) and the partition targets named in doc 09 reference runtime instance/evidence tables — the signoff/binding instance rows, capability run/measurements/artifacts, gate/bypass fact-result evidence, quorum votes, denied-attempt evidence, dashboard exports, Level-B packet executions — whose byte-level CREATE TABLE DDL is NOT published. Those hash contracts and the partition strategy are therefore not yet byte-implementable, reopening the FIX..FIX6 divergence risk (prose graded in isolation while the authoritative artifact drifts).
  • RP-02 (BLOCKING — anti-hardcode coherence): doc 09 + self-review item 8 introduce an "ACTIVE sealed retention policy" carrying numeric interval/capacity authority that is NOT one of the exactly-27 contracts, directly in tension with CP-05/doc-06 + self-review item 3 ("no uncounted 28th authority surface").
  • RP-03 (BLOCKING — integrity completeness): no single consolidated object-creation + deferred-ALTER order / exact constraint-set verification spans docs 02/03/04/09/10, despite several cross-table FK cycles (evidence↔principal↔human_identity; manifest_set↔manifest_activation; envelope→evidence). A forgotten ALTER FK is a SILENT (not fail-closed) loss of referential integrity.
  • RP-04 (BLOCKING — anti-hardcode coverage): the catalog-family enforcement contracts (reference_contract, operand_column_contract, SA15 structural-literal catalog) need explicit enumeration as sealed surfaces + exact-set coverage so no catalog-typed column can silently lose family/type enforcement.

Verdict map

  • CP-01 byte-level 27 DDL: CP01_VERIFIED
  • CP-02 inter-manifest FK targets: CP02_VERIFIED
  • CP-03 code_catalog bootstrap/seal/ownership: CP03_VERIFIED
  • CP-04 typed operand columns/checks: CP04_VERIFIED
  • CP-05 sealed thresholds: CP05_VERIFIED
  • CP-06 canonical hash: CP06_VERIFIED (encoding/canonicalization fully pinned; full byte-implementability of H04/H05/H06 gated on RP-01)
  • CP-07 Directus read path: CP07_VERIFIED
  • CP-08 registry/evidence placement/retention: CP08_ADVISORY_REMAINING (original advisory met; RP-01/RP-02 in this domain are now blocking)
  • CP-09 Level-B identity: CP09_VERIFIED
  • Supertrack J zero-hardcode: DISGUISED_HARDCODE_RISK (not FAIL)
  • Supertrack K PG-native/driven: PG_NATIVE_DRIVEN_NEEDS_CORRECTION
  • Supertrack L feasibility/scale: FEASIBILITY_SCALE_VERIFIED (design level; runtime scale evidence remains operator-gated/pending — Codex's own SCALE_SAFETY_PASS_DESIGN_EVIDENCE_PENDING)
  • Correction proposal count: 8 (RP-01..RP-08)
  • Final: DESIGN_NEEDS_TARGETED_CODEX_CORRECTION_WITH_PROPOSALS

What is genuinely strong (so Codex does not over-correct)

Exactly 27 byte-level child contracts with proper PK / envelope-FK / UNIQUE / typed domains; NO policy-shaped CHECK and NO DEFAULT false hidden policy (booleans are NOT NULL, caller-supplied, generic-guard-evaluated); typed-operand num_nonnulls(...)=1 + jsonb/schema pairing; sealed code-catalog root (owner-only, one-active index, jsonb item_payload restricted to object); every threshold mapped to an existing sealed field with NO threshold table; canonical hash fully pinned (encode(...,'hex') lowercase, trim_scale numeric, UTC timestamp, COLLATE "C", total array ORDER BY, JSON-null vs string-NULL, no MD5/delimiter); Directus path A with real-query both-EXCEPT preflight + smoke + rollback; load-bearing evidence_registry/principal_registry/human_identity_registry/analyzer_run now defined byte-level with FK cycles correctly broken by ALTER. Do NOT undo these.

Hard block (unchanged)

No Stage 2.6B, no permit, no REAL_RUN, no QT001 apply. Readiness BLOCKED. No implementation until RP-01..RP-04 close → republish → short T1 re-review → DESIGN_READY_FOR_CODEX_FINAL_APPROVAL → Codex final approval → only then operator-gated author/rehearsal work.

Document map

01 CP-01 review · 02 CP-02 · 03 CP-03 · 04 CP-04 · 05 CP-05 · 06 CP-06 · 07 CP-07 · 08 CP-08 · 09 CP-09 · 10 zero-hardcode final scan · 11 PG-native/driven final scan · 12 feasibility/scale final scan · 13 correction proposal package (RP-01..RP-08) · 14 final verdict.

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-corrected-spec-short-review-proposals-2026-06-07/00-readme-first.md