KB-9745

T1 FIX7 Impl-Spec Full Adversarial Review - 00 Readme First

6 min read Revision 1
QT001FIX7T1adversarial-reviewread-onlyDESIGN_NEEDS_CODEX_CORRECTION_BEFORE_IMPLEMENTATION

T1 FIX7 Implementation-Spec — Full Adversarial Review — 00 Readme First

Macro: PROGRAM_REVIEW_T1_FIX7_IMPLEMENTATION_SPEC_FULL_ADVERSARIAL_REVIEW_BEFORE_ANY_IMPLEMENTATION Verifier: T1 (production Agent for Agent Data) · Date: 2026-06-08 Execution mode: READ-ONLY production. Live mutation: NONE except these KB review docs + checkpoint. No DB object created; no SQL applied; no role/owner/ACL/manifest/permit/apply.

FINAL: DESIGN_NEEDS_CODEX_CORRECTION_BEFORE_IMPLEMENTATION

IMPLEMENTATION_FEASIBILITY_VERDICT: IMPLEMENTABLE_WITH_OPERATOR_GATED_STEPS

The two verdicts are different on purpose. The technical design is feasible and scale-safe (verified live against the real PG16 environment), but the byte-level build artifacts T1 needs to implement without guessing are summarized, not published for review. T1 must not implement yet. This is a narrow, near-final correction — the hard design decisions are done and accepted; what remains is publishing the exact artifacts. It is one short publish-and-review cycle from CONFIRMED, not a re-design.

What changed since the prior round (big, real progress)

The prior T1 verdict was DESIGN_BLOCKED_REQUIRES_CODEX_UPDATE — the design existed only as property assertions. This round Codex supplied concrete decisions for every prior blocker:

  • PG16 + pgcrypto SHA-256, NO-GO/operator-install if absent (resolves the prior hash-extension gap). Verified live: PG 16.13, pgcrypto 1.3 installed → feasible today.
  • Exact quorum: Q_CRITICAL_3 = OPERATOR_MIGRATION + CODEX_REVIEWER + T2_HUMAN_REVIEWER; Q_STANDARD_2 = OPERATOR_MIGRATION + CODEX_REVIEWER; approvals ≤24h, invalidate on hash/epoch/scope/principal/evidence drift; post-activation verifier ≤15 min.
  • 14 named readiness gates; 14 bypass vectors; exact-set both-EXCEPT; NULL/missing/extra/stale fail; bool_and-alone forbidden; Directus-no-write gate.
  • Capability: exact workload QT001_REPRESENTATIVE_1M_V1 (1,000,000 rows / 100,000 collision candidates), KEYSET ≥3 monotonic pages/no-OFFSET, RESUME ≥2 checkpoints + new session, PERF ≤600000 ms / ≤1 GiB / zero timeout-deadlock-error; freshness 7d/7d/24h.
  • Signoff: LOGIN session_user principals (no SET ROLE/proxy/shared role), content-hashed evidence + independent read-back, append-only revoke/supersede, valid ≤24h, exact target/plan/scope/tier/action/epoch binding.
  • 7 domain-separated SHA-256 contracts; canonical explicit-key JSONB, ordered arrays, JSON-null ≠ NULL, no floats/delimiter/MD5.
  • control_epoch: single owner-held row, enumerated increment events, writer FOR SHARE + reread-before-commit, activation FOR UPDATE + atomic + increment, rollback never decrements.
  • Level-B: exact CI path .github/workflows/fix7-level-b.ymlscripts/fix7/level-b/run.shsql/fix7/level-b; packet ID regex ^FIX7-[ABC]-[0-9]{8}-[0-9]{3}$; FIX7_BLOCKED_LEVEL_B_PIPELINE_UNAVAILABLE if absent; no manual psql/SSH/Directus fallback.
  • Rollback: layer-specific, owner-gated, evidence-bound, epoch-incrementing, fail-closed; never deletes history / never restores unsafe writer.
  • T1 boundary: author/test only; any missing-spec point → FIX7_IMPLEMENTATION_BLOCKED_SPEC_CONFLICT (stop, do not improvise).

The remaining gap (why not CONFIRMED)

The KB docs are decision-complete but artifact-incomplete. Three classes of byte-level build artifact are asserted to be "specified" / "in the full spec" but are not present in the KB and no fuller artifact exists (KB search + directory listing confirm only 14 summary docs):

  1. Exact manifest DDLmanifest_set column types/PK/FK/CHECK (only the column-name list is given) and the 27 named child contracts' actual schemas (named, not shown).
  2. The 14 readiness gate adapter rule sets — gates are named; doc 03 says each adapter name/rule set/freshness is "in the full spec," which is not in the KB. These rule sets ARE the enforcement logic.
  3. The 7 hash payload key-maps / ordering — contracts named + method given; doc 06 says the exact key maps "are specified," not shown.

As the independent adversarial gate, I cannot confirm artifacts I cannot see; Codex's "they are specified" + self-eval 20/20 are evidence, not authority (doc 12 itself states it is a self-check, not verification). The macro forbids "assuming resolved" and lists "schema columns" and "hash inputs" as guess-rejection triggers. Confirming now would risk re-running the FIX..FIX6 divergence loop (T1 authors 14 adapters / 27 child schemas / 7 key-maps that diverge from Codex's unseen intent, and plausibly fills gaps instead of stopping).

Required correction (narrow)

Publish the three artifact classes as independently reviewable docs/files (exact DDL with types/FK/CHECK for manifest_set + all 27 child contracts; the 14 gate adapter rule sets with freshness; the 7 hash key-maps with ordering) — or point this review to the already-authored full-spec files if they exist outside the KB — or explicitly authorize T1 to author them mechanically under the SPEC_CONFLICT-stop discipline with a Codex re-audit of the authored artifacts before any live step. Then a short re-review → CONFIRMED.

Document map

01 prior-blocker resolution (A) · 02 manifest/engine (B) · 03 readiness (C) · 04 quorum (D) · 05 signoff (E) · 06 capability (F) · 07 hash (G) · 08 dependency (H) · 09 control_epoch (I) · 10 Level-B (J) · 11 T1 boundary (K) · 12 zero-hardcode (L) · 13 PG-native-driven (M) · 14 risk/rollback (N) · 15 feasibility/scale (O) · 16 disguised-hardcode (P) · 17 final go/no-go (Q).

Sources read

All 14 Codex spec docs (00–13) + completion checkpoint; the three prior FIX7 checkpoints; my prior T1 design-verification checkpoint; BIRTH_GATEWAY_DESIGN_INDEX (rev22); prompt-muc-tieu-mo (v1.3). Live read-only PG: version, pgcrypto, role/ownership/privilege (no mutation).

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-implementation-spec-full-adversarial-review-2026-06-07/00-readme-first.md