Action-Ready Blockers — after Internal Proof (rev4 Phase-2 Readiness)

Date: 2026-06-09 · Source: reports/internal-evidence-proof-rev4-phase2-readiness-2026-06-09.{md,json}. Decision: D — TRUE_BLOCKER (owner/operator + resource). Final status: INTERNAL_PROOF_PARTIAL. Production mutation: NO. Codex consulted: NO. One-line: everything internally provable is closed; the build cannot start because the deny-by-default sandbox host is not provisioned (an owner/operator resource action) and the corpus records B0‴ (Codex re-seal) as a precondition to any build (an owner authority decision to honor or waive). No "no engineering omissions" claim is made.

Blocker B-EXT-1 — Sandbox host not provisioned (LOAD-BEARING)

• Blocker: the offline MVP's primary enforcement boundary is L1 = a deny-by-default sandbox host (no network namespace; read-only input mount; write-only output mount; no secret mounts; scrubbed env; seccomp execve/socket/connect/ptrace deny). It is specified, not deployed (rev4 spec §2 honesty bound, §20 caveat; fix ledger §4; plan M5).
• Evidence: rev4 spec §12.1–§12.4; plan G5 (primary) + M5; matrix L1 + tests #25/#27/#28/#29/#33/#34/#35/#37; fix ledger blockers 2/3 "MVP still blocked = Yes."
• Why it blocks: without L1, (a) ~11 of the 45 acceptance tests cannot pass — their proof-of-block (seccomp EPERM, mount table, env keyset) only a real sandbox produces; (b) by the design's own P1 self-check, an un-sandboxed run fails closed to BLOCKED/exit 3 before any read (§12.4 / F23 / G5 / G12) — a no-sandbox prototype refuses to function; (c) per spec §21, absent a provisionable sandbox host the readiness "hard fallback to B" (stay blocked) applies.
• Safe next action: owner/operator provisions the §12.1 deny-by-default sandbox host and attests the invariants (plan M5). This is a resource action; it is not something Claude can perform or prove internally, and the macro forbids creating a sandbox.
• Who: Owner / operator (resource).
• Blocks build or only future phases: Blocks build acceptance (B4′). Gating.

Blocker B-EXT-2 — B0‴ (rev4 Codex re-seal) open

• Blocker: the rev4 corpus records B0‴ — Codex seals rev4 — as a precondition to ANY build (spec §1/§22; plan §5/M1; JSON becomes_allowable_when; index minimal-next-step). The offline-packet architecture is a new response to Codex's Gate-3 FAIL and has not been reviewed by any independent authority; the rev4 Codex checkpoint packet (authored) was never sent/answered.
• Evidence: the unanswered packet reviews/codex-checkpoint-packet-gap-only-spec-and-fix7-pilot-rev4-2026-06-09.md (7 open questions Q1–Q7); index lineage showing rev2 ("all-PASS") and rev3 ("10/10 PASS") self-audits were each overturned by Codex — i.e. T1 self-audit PASS has not been a reliable build-readiness proxy.
• Why it blocks: it is an authority judgment (is the offline re-scope the right answer to Gate-3? is "specified-not-deployed" an acceptable seal basis? is the manual-packet bootstrap KB-first-honest? is anything still an assertion-as-guarantee?). The internal proof can frame these but cannot settle them.
• Safe next action (owner choice):
  • (i) Honor B0‴ → route the rev4 packet to Codex for the re-seal (this is the corpus's recorded path; → Decision C); or
  • (ii) Owner-waive B0‴ → owner records a decision to proceed without a Codex round, explicitly accepting the documented risk (unreviewed architecture; self-audit-overturned history). Waiving is a legitimate owner authority act consistent with the stated goal of reducing Codex dependency — but it is the owner's call, not an internal proof.
• Who: Owner (authority) → Codex only if (i).
• Blocks build or only future phases: Blocks build start per the corpus; owner-waivable.

Deferred blockers (future phases only — do NOT block the MVP)

ID	Blocker	Unblocking contract	Who	Scope
B-DEF-1	Live governed export step + named-query-catalog/driver/network-policy	B7	Owner + Codex	MVP uses a manually-produced governed packet meanwhile (spec §12.6)
B-DEF-2	Path-scoped server-enforced KB report writer	B7	Owner + Codex	MVP writes local only; KB upload is a separate governed step
B-DEF-3	Downstream consumer/authority contract (any gate use)	B7	Owner + Codex	MVP output is decision_effect=NONE/may_gate=false
B-DEF-4	Command run + exit capture / proof-of-run / global-absence	Call / Proof-of-run (B1/B2/B3)	Owner + Codex	Execution surface; MVP runs nothing
B-DEF-5	--selftest N/N + module_sha256; generic package_manifest schema	post-reseal build / lineage review	Owner + Codex	Build-time, after seal
B-DEF-6	Positive/green verdict + exit 0	sealed governed taxonomy authority (B6)	Owner + Codex	MVP has no green / no exit 0 by design

Engineering / design blocker classification (completeness — Track 8 of the macro)

• No unclassified engineering/design blocker remains. rev4 is internally coherent (spec ↔ JSON ↔ plan ↔ matrix ↔ fix ledger ↔ pilot all align; verdict model, L1–L5, G1–G12, N1–N32/#1–#45 consistent). No rev5 design repair is required (Decision ≠ B). The remaining items are resource (B-EXT-1) and authority (B-EXT-2), plus named deferrals (B-DEF-*) — none is an open design defect.

Minimal safe next step

Owner decision + provisioning, in this order:

1. Owner/operator provisions the §12.1 deny-by-default sandbox host (B-EXT-1 / M5). (Load-bearing; nothing else unblocks the build without it.)
2. Owner disposes of B0‴ (B-EXT-2): honor (→ Codex) or waive (with the risk recorded).
3. Only then author the offline MVP prototype build macro (the build prompt is intentionally not written yet — see proof Track 10).

Do NOT implement, invoke, install, mutate, provision-by-Claude, or create a tool/schema/runner/sandbox in the interim.

Cross-references

• Internal proof: reports/internal-evidence-proof-rev4-phase2-readiness-2026-06-09.{md,json}
• rev4 spec §2/§12/§20/§21/§22; plan M1–M5 + G1–G12; matrix L1–L5 + #1–#45 + D1–D11
• Prior rev4 action-ready blockers (design layer): checkpoints/action-ready-blockers-after-gap-only-spec-rev4-2026-06-09.md
• Unanswered Codex packet: reviews/codex-checkpoint-packet-gap-only-spec-and-fix7-pilot-rev4-2026-06-09.md