KB-25CA

T1 FIX7 Blueprint Patch After Codex Recheck 2 - Readme First

6 min read Revision 1

00 - Readme First

Date: 2026-06-08 Author: T1 (production Agent for Agent Data) Macro: PROGRAM_PATCH_T1_FIX7_BLUEPRINT_AFTER_CODEX_RECHECK_2_PG_AUTHORITY_CONTRACT_FAIL Mode: READ-ONLY production; blueprint KB-doc direct-revision; NO production mutation.

Final status

FIX7_REFACTOR_BLUEPRINT_PATCH_AFTER_RECHECK_2_REQUIRES_DESIGN_AMENDMENT

One-paragraph summary

Codex recheck 2 failed the owner-semantics-patched FIX7 refactor blueprint (..._CODEX_RECHECK_2_FAIL_HARDCODE_OR_PG_NATIVE_GAP) with 8 remaining blockers. T1 analysed every blocker against the approved byte-level DDL (the 27 child contracts + registries + activation) and a fresh read-only pg_roles read. 6.5 of 8 blockers are resolvable in-blueprint by binding to already-approved surfaces and were patched directly (A owner-unreachable, B independent root denominator, D typed operator authorization, E forward-only rollback source, F superuser break-glass, G forward-only history, H author/rehearse/seal order). One blocker — C, the legacy-disposition contract — genuinely has no approved home and cannot be authored by T1 without repeating the two failure modes Codex has already rejected: typed columns (recheck 1 = DDL drift) or computed/open-text/external-artifact policy (recheck 2 = disguised hardcode). Per law §4G (governance/design change is a T1 HARD-STOP) and Codex's own decision tree ("declare design amendment required"), blocker C is routed to the design owner with two concrete options. The honest, loop-breaking verdict is therefore REQUIRES_DESIGN_AMENDMENT.

Why not push to `READY_FOR_CODEX_RECHECK_3`

The primary objective was READY_FOR_RECHECK_3, and 6.5/8 blockers are fixed. But declaring READY while blocker C is unresolved would require T1 to either (a) re-add columns/catalog vocabulary the sealed approved DDL forbids, or (b) re-encode the disposition as computed/open-text/external policy — both already rejected. It would also require T1 to unilaterally decide whether to eliminate the disposition model (Option β below), which removes a construct the design owner has been formalising across rechecks — a §4G governance decision T1 may not make alone. The asymmetry is decisive: an extra amendment round-trip is far cheaper than a §4G violation or a third rejected retrofit.

The decisive gap (blocker C) and the two amendment options

The approved 27-surface design protects targets, proves non-reachability, repoints writers, and runs a forward-only sealed manifest lifecycle. It has no typed home for: legacy routines/views as managed authority objects; a 5-value disposition enum (REVOKE_ONLY/STUB_FAIL_CLOSED/FREEZE_NO_CHANGE/DEPRECATE_READONLY/DO_NOT_TOUCH); or a sealed rule/truth-table that emits it. Concretely: the bootstrap catalog families are a sealed exact set (CP-03, not extensible → no disposition family); authority_scope_manifest #20 has no disposition/root_kind column and §2.7 scopes it to TABLE/CONSTRAINT/INDEX/runtime-evidence (so LEGACY_FUNCTION/PROCEDURE/VIEW rows are semantic drift); item_payload is forbidden (§2.7).

Option α — add a typed contract (byte-DDL/catalog amendment). A typed legacy-disposition surface (or a new sealed catalog family) carrying the 5-value enum + a sealed disposition rule set (bound to policy_rule_manifest #01 semantics) + a priority/conflict rule + a CASE/code-only-rejecting guard.
Option β — bless the collapse (no DDL change, but a design-owner confirmation). Eliminate the disposition enum and STUB_FAIL_CLOSED; express legacy neutralization entirely through approved primitives — owner-transfer to qt001_cp_owner + sealed #21 privilege_set_manifest grants (or absence) + #20 protected_target TABLE rows + #11 reverse-closure + structural relkind/prokind — verified by a guard over the live catalog. T1 recommends β (PG-native, approved-design-faithful, and live-proven sufficient because directus is non-superuser), but β removes an agreed construct and is therefore itself a §4G design-owner confirmation, not a unilateral T1 change.

Boundaries (unchanged)

Official FIX7 design remains approved. Implementation, Stage 2.6B, qt001_backfill_permit, REAL_RUN, QT001 apply, manifest activation, repoint, and owner/ACL cutover all remain BLOCKED. Production was READ-ONLY throughout. The only writes are the blueprint-doc revisions, this report, and the checkpoints. Do NOT claim implementation approval.

Document map

doc	content
00	this readme
01	Codex recheck-2 failure matrix (8 blockers → disposition)
02	BLOCKER A — owner-unreachable fix (in-blueprint)
03	BLOCKER B — `U_legacy` independent root denominator fix (in-blueprint)
04	BLOCKER C — disposition rule contract → DESIGN_AMENDMENT_REQUIRED (Options α/β)
05	BLOCKER D — operator-authorization typed-PG contract fix (in-blueprint)
06	BLOCKER E — rollback evidence-binding fix (forward-only; in-blueprint)
07	BLOCKER F — superuser/`bypassrls` break-glass control fix (in-blueprint)
08	BLOCKER G — forward-only activation-history fix (in-blueprint)
09	BLOCKER H — author/rehearse/seal order fix (in-blueprint)
10	hardcode / PG-native self-review
11	cross-layer boundary self-review
12	direct blueprint revisions applied (doc-by-doc)
13	final verdict + self-review against the recheck-2 checks