KB-25E8

Codex Checkpoint Packet — Gap-only Spec + FIX7 Pilot rev4 (compact re-review request; 6 guard/authority blockers only; disposition GAP_ONLY_SPEC_REV4_SEALED or RETURN_BLOCKERS; 2026-06-09)

8 min read Revision 1
tool-kiem-thucodex-checkpoint-packetrev4re-review-requestoffline-packetnon-gatingdeny-by-default-sandboxdesign-only2026-06-09

Codex Checkpoint Packet — Gap-only Spec + FIX7 Pilot (rev4)

Ask: narrow adversarial re-seal of the six guard/authority blockers Codex returned on rev3 — not a re-review of history, the baseline, sealed B/C/D/G/H, or the Article-14 chain (Gate 2 PASS in rev2, Gate 5 PASS in rev3, both preserved). Date: 2026-06-09 · Requested disposition: GAP_ONLY_SPEC_REV4_SEALED or RETURN_BLOCKERS. Production mutation: NO. No build, no install, no tool/schema/runner, no live read re-run, no mutation. writes_performed: KB design docs only. Self-declared status: GAP_ONLY_SCOPE_SPEC_v0_1_REV4_READY_FOR_CODEX. MVP implementation allowed: NO (it becomes adjudicable, not granted).

1. What changed since rev3 (the one decision + six repairs)

Decision: the MVP is re-scoped to an offline, packet-derived, non-gating inspector. It performs no live read (no live PG query, no live KB read), holds no network / DB driver / credential / secret / arbitrary local-FS, and does not write KB. It reads a governed-provenance export packet (KB/PG-derived, per-item provenance) and writes a local report. This removes the live attack surface Codex found ungrounded, rather than asserting a sandbox we cannot prove.

# rev3 blocker rev4 repair (one line) Where
1 negative verdicts → shadow denial authority non-gating non-global denial contract: decision_effect=NONE, may_gate=false, 5 bounded scoped verdicts, scope_of_denial, non-global disclaimer, READ_LEVEL_FAIL="not acceptable for PASS" not "false" spec §4.0
2 DB allowlist ≠ process egress allowlist offline: no network namespace; nothing to allowlist; egress denied at the environment, tested as a process-level denial (#27) spec §12.1; matrix #27
3 no sandbox for secret/local/network deny-by-default sandbox named (no network ns; RO input mount; WO output mount; no secret mounts; scrubbed env; seccomp execve/socket/connect/ptrace) spec §12.1–§12.3
4 no bounded KB writer MVP does not write KB; writes only a local output mount; KB upload is a separate governed step; no writer claimed spec §10/§13
5 SELECT-only ≠ side-effect-fn safe MVP issues no SQL; deferred export step = named query IDs only, pre-approved side-effect-free, no raw/dynamic/multi/CALL/DML/DDL spec §12.6
6 tests not tied to enforcement every negative test bound to an enforcement layer (L1–L5) + block point + proof-of-block evidence matrix rev4 §3–§6

2. The exact points to adjudicate (and only these)

  1. No shadow denial authority — is decision_effect=NONE + may_gate=false + bounded scoped verdicts + scope_of_denial + non-global disclaimer + deferring all gate use to a sealed consumer contract (B7) sufficient to prevent the inspector from becoming a negative/denial authority? (spec §4.0; F21/F22/F24; tests #18/#20/#21/#22/#23)
  2. No arbitrary SQL / no side-effect SELECT — does "MVP issues no SQL; the deferred export step uses named query IDs only from a sealed side-effect-free catalog" remove the side-effect-function risk for the MVP, with the residual correctly deferred to the export-step contract (B7)? (spec §12.6; matrix #31/#32→D9)
  3. No direct PG driver — is the MVP's "no driver / no connection / no credential, live read confined to the deferred governed export step" acceptable, with any direct-driver/live-read capability gated behind a sealed driver contract (B7)? (spec §12; matrix #30/#35)
  4. Sandbox/network/secret/local guard feasibility — is the deny-by-default sandbox (§12.1) a concrete, namable enforcement substrate (vs rev3's bypassable in-process guards)? Is it acceptable that it is specified, not deployed, with provisioning + negative tests as B4′ acceptance scope? (spec §12.1–§12.4; matrix #25/#27/#28/#29/#33/#37)
  5. KB writer / report persistence boundary — is "the MVP writes only a local artifact; KB upload is a separate governed step; no bounded KB writer is claimed" the honest resolution of blocker 4, with a path-scoped writer deferred to B7? (spec §10/§13)
  6. Negative tests tied to enforcement — does each capability/bypass test now map to a real enforcement layer + block point + proof-of-block evidence (Codex blocker 6)? Is #27's correction to a process-level egress denial (not a gateway DB allowlist) correct? (matrix §4)
  7. MVP readiness — is the recommendation Option C (offline packet-only) gated on the A discipline (guard harness in build scope), hard fallback to B the right honest outcome? Should MVP build start now, or only after B4′? (spec §21)

3. Questions for Codex

  • Q1. Is the offline-packet re-scope (Option B) the correct response to the Gate-3 FAIL, or do you require Option A (network-minimized live read) to be specified instead/also?
  • Q2. Is decision_effect=NONE + may_gate=false enough, or must the authoritative-looking verdict names (READ_LEVEL_FAIL/BLOCKED) be renamed to triage-finding labels before any seal?
  • Q3. Is deferring the live governed export step + named-query catalog + bounded KB writer + gate-consumer all to a single B7 contract acceptable, or must they be separate sealed contracts?
  • Q4. Is "the sandbox is specified, not deployed; B4′ gates acceptance" an acceptable seal basis, or must a real sandbox be demonstrated before any seal?
  • Q5. Are the proof-of-block evidences (seccomp EPERM, mount table, env keyset, build-time rejection) the right acceptance evidence for the capability tests, or do you want a specific harness named?
  • Q6. Does the manual-governed-packet bootstrap (run the MVP against a hand-assembled governed packet until the export step exists) preserve KB-first/PG-first honesty, or is it a local-first violation?
  • Q7. Is anything in rev4 still an assertion masquerading as a guarantee (the class you flagged on rev3)?

4. What rev4 explicitly does NOT do

  • Does not claim the sandbox host exists; does not claim a bounded KB writer exists; does not claim the export step is built.
  • Does not authorize MVP implementation; does not start a build; does not create a tool/schema/runner.
  • Does not reopen sealed B/C/D/G/H; does not reopen the Article-14 chain; does not redo the baseline/history.
  • Does not perform any production mutation; did not re-run live reads (the MVP performs none).

5. Packet contents (for re-review)

  • Spec rev4: designs/implementation-package-dot-v0-1-gap-only-scope-spec-rev4-2026-06-09.{md,json}
  • FIX7 pilot rev4: designs/fix7-read-report-pilot-design-rev4-for-implementation-package-dot-v0-1-2026-06-09.md
  • MVP plan rev4: planning/mvp-read-report-inspector-implementation-plan-no-code-rev4-2026-06-09.md
  • Acceptance matrix rev4: designs/acceptance-test-matrix-implementation-package-dot-v0-1-rev4-2026-06-09.md
  • Fix ledger rev4: reports/codex-fix-ledger-gap-only-spec-rev4-2026-06-09.md
  • Action-ready blockers rev4: checkpoints/action-ready-blockers-after-gap-only-spec-rev4-2026-06-09.md
  • Source block: reviews/codex-reseal-gap-only-spec-rev3-2026-06-09.md
Back to Knowledge Hub knowledge/dev/laws/tool-kiem-thu/reviews/codex-checkpoint-packet-gap-only-spec-and-fix7-pilot-rev4-2026-06-09.md