Codex Checkpoint Packet (rev2) — Gap-only Spec + FIX7 Read/Report Pilot

Nature: compact re-review request after the Codex block BLOCKED_BY_AUTHORITY_OR_ARTICLE14_RISK. It does not re-argue; it states what changed (the 12 fixes) and asks Codex to seal or return blockers. Date: 2026-06-09 · Supersedes: reviews/codex-checkpoint-packet-gap-only-spec-and-fix7-pilot-2026-06-09.md (rev1, which received RETURN_BLOCKERS). Production mutation: NO. writes_performed: KB design docs only. Review target docs: the rev2 spec .{md,json}, FIX7 pilot rev2, MVP plan rev2, acceptance matrix rev2, fix ledger. Decision sought: seal the rev2 read/report-only surface, or return blockers. MVP greenlight remains gated on a fresh seal.

1. Context (one paragraph — do not re-investigate)

rev1 was blocked for Article-14 structural fake-green (a resolving reference treated as sufficient ⇒ READ_REPORT_PASS possible while an executable claim stayed unproven — the Recheck-8 class), plus hardcoded counts, a >=2 denominators invariant, literal 41/4 & 219/102 checks, exit-0-for-FLAG, module-name (not capability) enforcement, complete-claim-extraction assumption, a READY_FOR_GPT_REVIEW contract treated as binding, and PROGRAM_MACRO_READY over-claim. rev2 repairs all 12 (ledger: 12/12 = YES). The sealed B/C/D/G/H are untouched.

2. What changed since the block (the deltas Codex must verify)

1. READ_REPORT_PASS removed. New final verdicts READ_LEVEL_ACCEPTABLE / READ_LEVEL_FAIL / BLOCKED / UNVERIFIED + separate mandatory article14_status; any execution claim forces ARTICLE14_NOT_PROVEN_EXECUTION_UNVERIFIED and makes ACCEPTABLE unavailable. (fix 1)
2. Article-14 adequacy chain (claim→type→required class→artifact→capability→adequacy→verdict) with structural binding fields; a resolving reference yields only ARTIFACT_EXISTENCE_EVIDENCE, never a positive. (fix 2)
3. 12-class evidence model + 13-type claim matrix define what each evidence kind can/cannot prove and the max verdict per claim type. (fix 2)
4. Claim extractor demoted to best-effort; UNPARSED_REGION[] + claim_inventory_completeness=UNVERIFIED block ACCEPTABLE; manual review required. (fix 3)
5. FIX7 pilot scope narrowed + Fixture C (resolvable-but-insufficient/contradictory evidence) ⇒ READ_LEVEL_FAIL + NOT_PROVEN, never EVIDENCE_PRESENT. Full Recheck-8 run-proof explicitly deferred to the Call Contract. (fix 4)
6. Literal counts removed from normative positions; survive only as dated fixture examples; denominator_source_record model; >=2 replaced by "all relevant denominators distinct + provenanced"; 41/4 & 219/102 checks replaced by role/key/population/provenance/separation. (fixes 5/6/7)
7. Fake-green removed: exit map 0/1/2/3/4; FLAG/FAIL/BLOCKED/UNVERIFIED never exit 0; G8 gate. (fix 8)
8. Capability boundary made structural: allowed/prohibited action enums per module; static + runtime guard (read-only PG role, no write credential, no shell, KB-path allowlist); negative capability tests. (fix 9)
9. Dead-link/coverage = ADVISORY_UNVERIFIED; no resolver completeness / canonical-id coverage claim. (fix 10)
10. Authority Contract status normalized: sealed B/C/D/G/H binding; the contract itself READY_FOR_GPT_REVIEW, not binding as a whole; PROGRAM_MACRO_READY removed. (fix 11)
11. writes_performed[] output field discloses the KB report-only writes so "Production mutation: NO" cannot hide them. (fix 12)

3. The questions for Codex (each YES/NO + note)

1. Does rev2 make a positive PASS structurally unavailable when an executable claim is unresolved/inadequate (Article-14)?
2. Does the adequacy chain prevent "a reference resolves" from ever producing a positive claim verdict?
3. Is the claim extractor limitation (completeness=UNVERIFIED, no governed declaration contract yet) honest enough to block over-confident acceptance?
4. Are all literal counts removed from normative logic (counts only dated fixtures; checks are role/key/provenance)?
5. Is fake-green eliminated (no exit 0 for FLAG/FAIL/BLOCKED/UNVERIFIED)?
6. Is the no-run/no-write boundary now enforced by capability (static+runtime guard + negative tests), not module names?
7. Does Fixture C demonstrate the decisive resolvable-but-insufficient Recheck-8 catch, and is the pilot's scope (adequacy half only; run-proof deferred) correctly stated?
8. Is MVP implementation allowed after this rev2 seal, or still blocked?

4. Hard limits / fail-closed checklist (unchanged intent)

No runner/dispatcher; no FS-DOT/IU-command/detector invocation; no PG/Directus/registry/filesystem/system_issues mutation; no TAC↔IU bridge; no new resolver/registry/logger/graph/corpus authority; no proof-of-run; no collapsed counts; no build before a fresh seal; no FIX7 resume; sealed B/C/D/G/H not reopened.

5. Out of scope for this review

The execution surface (Call Contract, proof-of-run, manifest, write contracts, bridge, CI gating) — all deferred behind named future contracts (B1/B2/B3 + queue). Do not seal those here.

6. Requested disposition

• GAP_ONLY_SPEC_REV2_SEALED → read/report-only MVP build may start (no execution capability; capability guards + negative tests are build acceptance gates). or
• RETURN_BLOCKERS → list the minimal residual modifications; nothing builds until re-sealed.

Cross-references

• rev2 spec / pilot / plan / matrix / ledger (see those docs).
• Source block: reviews/codex-review-gap-only-spec-fix7-pilot-mvp-readiness-2026-06-09.md.
• Superseded rev1 packet: reviews/codex-checkpoint-packet-gap-only-spec-and-fix7-pilot-2026-06-09.md.