Action-Ready Blockers (rev3) — after Gap-only Spec PG-first repair

Nature: the live blocker list after the rev3 repair. It does NOT claim "no engineering omissions remain" — that wording stays withdrawn (Codex fix 11/H6). rev3 carries authority/owner blockers, build-time guarantee blockers, and a new taxonomy-authority blocker that bounds (does not block) the read/report MVP. Date: 2026-06-09 · Supersedes: checkpoints/action-ready-blockers-after-gap-only-spec-rev2-2026-06-09.md (rev2). Production mutation: NO. Read-only verification disclosed. writes_performed: KB design docs only.

1. Status of "engineering omissions"

NOT claimed clean. rev3's position: the read/report design is repaired against the four Codex re-seal blockers (B-1 taxonomy authority, B-2 guard feasibility, B-3 discoverability, B-4 negative tests), with the no-run/no-write guard now feasible and grounded in a verified read-only substrate. But MVP acceptance still depends on build-time guarantees that cannot be asserted at design time. Those are tracked as real blockers, not "done."

2. Blockers gating the read/report-only MVP

• B0″ — Codex RE-seal of the rev3 layer (gates the read/report MVP). rev3 spec/pilot/plan/matrix/ledger are ..._REV3_READY_FOR_CODEX but not yet re-sealed. Next action: route reviews/codex-checkpoint-packet-gap-only-spec-and-fix7-pilot-rev3-2026-06-09.md to Codex (optionally GPT first). Blocks MVP? Yes — the read/report-only MVP.
• B4 — Capability guards not yet implemented (gates MVP acceptance, not seal). The 10-layer static+runtime guard (import/capability denylist; endpoint allowlist; context_pack_readonly read-only role; read-only transaction; SQL statement classifier; KB-report-only writer) and the expanded negative tests (#21–#37) are specified + grounded but unbuilt (v0.1 builds nothing). Blocks MVP? Yes — MVP cannot be accepted until they exist and the negative tests pass.
• B5 — Governed claim-declaration contract does not exist (bounds, does not block). Without it claim_inventory_completeness is normally UNVERIFIED, capping dossiers at UNVERIFIED. Accepted as honest, not a defect.
• B6 — Governed claim/evidence/verdict taxonomy authority does not exist (bounds, does not block) — NEW, rev3. Because no governed source exists, v0.1 is negative/triage-only: it has no positive/green verdict and no exit 0. This bounds usefulness (it surfaces gaps; it never certifies acceptance) but does not block the read/report MVP. Next action: a future, separately-sealed taxonomy authority contract would re-enable a positive verdict + exit 0. Until then, triage-only.

3. Blockers gating the execution surface (carried, owner/authority — expected carve-outs)

• B1 — Call / Proof-of-run Contract not sealed. Gates the command-runner + the run/pass half of the binder and the global-absence proof (proving an executable does not exist anywhere — the FIX7 run-half). Blocks the read/report MVP? No. Blocks the runnable verifier? Yes.
• B2 — iu_core ↔ cutter_governance lineage owner decision. Gates the generic package_manifest schema. Blocks the read/report MVP? No.
• B3 — TAC ↔ IU corpus authority unresolved (by design, Domain H). Gates any corpus-canonical/bridge work. Blocks the read/report MVP? No (dual-report).

4. Net statement

The read/report-only MVP is blocked on B0″ (fresh Codex re-seal of rev3) and, for acceptance, on B4 (capability guards built + negative tests passing). B5 and B6 bound (do not block) the inspector: B5 caps inventory completeness; B6 keeps v0.1 negative/triage-only (no green). The execution surface stays blocked on B1/B2/B3 — expected owner/authority carve-outs. No "no engineering omissions remain" claim is made.

Cross-references

• rev3 spec / pilot / plan / matrix / fix ledger / checkpoint packet (see those docs).
• Codex re-seal: reviews/codex-reseal-gap-only-spec-rev2-2026-06-09.md.
• Future contracts: planning/future-contracts-queue-after-v0-1-2026-06-09.md.
• Superseded rev2: checkpoints/action-ready-blockers-after-gap-only-spec-rev2-2026-06-09.md.