Sandbox Feasibility + Phase-2 Build-Go Decision (tool-kiem-thu)
Sandbox Feasibility + Phase-2 Build-Go Decision — Implementation Package DOT v0.1
Program Macro:
PROGRAM_MACRO_SANDBOX_FEASIBILITY_AND_PHASE2_BUILD_GO_DECISION_4RO_2026_06_09Date: 2026-06-09 · Mode: READ-ONLY (no mutation, no build, no install, no sandbox creation, no Codex) Final status:SANDBOX_DECISION_READYBuild-go decision:B — BUILD_PROMPT_READY_BUT_OPERATOR_SANDBOX_ACTION_REQUIREDProduction mutation: NO · Codex consulted: NO · Owner/operator decision faked: NO
This report closes the sandbox feasibility + Phase-2 build-go decision layer end-to-end. It reclassifies the prior INTERNAL_PROOF_PARTIAL / TRUE_BLOCKER determination using one new piece of governed-native evidence (a read-only Docker listing of the host) and a clean separation between authoring a gated build prompt (safe now) and accepting a built MVP (needs an operator-attested sandbox + B0‴ disposition).
The headline correction: the sandbox is not a true blocker and not "automatically owner/operator." The deny-by-default sandbox is realizable on the container runtime that is already deployed and operational on the governed host; the guard harness (profile + in-process guards + negative tests) is build-scope code that can be authored now. What remains before a build can be accepted is (1) an operator action to run the harness in a deny-by-default container and attest the negative tests pass (B4′), and (2) the owner's disposition of B0‴ (Codex re-seal or documented waiver). Both are real, both are action-ready and narrow — neither makes this a true blocker, and neither prevents authoring the build prompt now.
Track 1 — KB readback / SSOT confirmation
All six required documents were read in full from KB (mcp__agent-data__batch_read, full=true; 175,292 chars), not from local copies. The index was read for-rewrite (revision 74).
| KB path | Exists | Version / status | Key constraints found | Contradiction vs index? | Local copy needed? | Result |
|---|---|---|---|---|---|---|
00-index.md |
Yes | rev 74 · GAP_ONLY_SCOPE_SPEC_v0_1_REV4_READY_FOR_CODEX; records INTERNAL_PROOF_PARTIAL / Decision D — TRUE_BLOCKER |
Minimal-next-step = "owner provisions §12.1 sandbox host + disposes B0‴" | No | No | PASS — authoritative SSOT |
designs/…gap-only-scope-spec-rev4-2026-06-09.md |
Yes | GAP_ONLY_SCOPE_SPEC_v0_1_REV4_READY_FOR_CODEX ("spec's own readiness for re-review — not ready-to-build") |
§2 offline decision; §3 Article-14 chain; §4.0 non-gating non-global denial; §12.1 sandbox = primary, §12.2 in-process = secondary; §22 blockers B0‴/B4′/B7/B1-3/B6; §0.5 "do not fake KB/PG-first by granting unrestricted access" | No | No | PASS |
planning/mvp-…-implementation-plan-no-code-rev4-2026-06-09.md |
Yes | MVP_PLAN_REV4_DESIGN_ONLY; build BLOCKED until B0‴ + (acceptance) B4′ |
13 modules, allowed_actions ⊆ {READ_PACKET_ITEM, WRITE_LOCAL_REPORT}; gates G1–G12; manual gates M1–M5 (M5 = sandbox provisioning); negatives N1–N32 |
No | No | PASS |
designs/acceptance-test-matrix-…-rev4-2026-06-09.md |
Yes | ACCEPTANCE_MATRIX_v0_1_REV4_READY_FOR_CODEX; "design only; no test executed" |
45 in-scope tests each bound to L1–L5 + block point + proof-of-block; 11 deferred (D1–D11); ~11 tests L1-dependent | No | No | PASS |
reports/internal-evidence-proof-rev4-phase2-readiness-2026-06-09.md |
Yes | INTERNAL_PROOF_PARTIAL; decision "D — TRUE_BLOCKER (owner/operator + resource)" |
Scope 12/12; guards 14/14; negatives 16/16; Article 13+14 PASS; A/B/C rejections; build prompt deliberately NOT written | No | No | PASS |
checkpoints/action-ready-blockers-after-internal-proof-rev4-2026-06-09.md |
Yes | INTERNAL_PROOF_PARTIAL · B-EXT-1 (load-bearing), B-EXT-2 (B0‴), B-DEF-1..6 |
"~11 of 45 tests cannot pass without L1"; "no rev5 design defect found" | No | No | PASS |
Track-1 verdict: PASS. No document is missing; none contradicts the index. KB is SSOT; this report adds no competing authority and writes only governed KB design/report/checkpoint docs.
Track 2 — Blocker classification (re-classified)
| Blocker | Current classification (rev4 corpus) | Evidence basis (KB / native) | Agent can resolve? | Owner/operator? | Codex? | Move into build scope? | Re-classified decision | Safe next action |
|---|---|---|---|---|---|---|---|---|
| B-EXT-1 sandbox host not provisioned | "TRUE_BLOCKER, load-bearing, owner/operator + resource" | spec §2/§12.1/§20; plan M5; proof Track 5/9; checkpoint B-EXT-1 — plus new evidence: list_docker shows Docker runtime + 11 live containers incl. ephemeral pg-restore-test-… on the governed host |
Partly — Agent authors the harness (profile + guards + tests) = build-scope; cannot run/attest it | Yes — for acceptance attestation only (run container, confirm seccomp/mount/env negatives) | No | Yes (harness = build-scope); only the attestation is operator | Operator action for acceptance (B); harness authorable now. NOT a true blocker — runtime exists | Author guard harness in the build prompt; issue operator attestation packet |
| B0‴ / B-EXT-2 Codex re-seal open | "Parallel, owner-waivable authority gate; precondition to ANY build" | spec §1/§22; plan §5/M1; JSON becomes_allowable_when; checkpoint B-EXT-2 |
No (authority, not engineering) | Yes — owner disposition (honor → Codex, or waive w/ risk) | Only if owner honors | No (it gates build start/consumption, not harness authoring) | Owner authority disposition before build execution; does not block authoring a gated build prompt | Record as a hard precondition at the top of the build prompt; owner decides honor-vs-waive |
| B4′ guard harness built + negative tests pass | "Gates MVP acceptance" | spec §22; plan M5; matrix L1; proof Track 5 | Author: yes (build-scope). Prove against real sandbox: needs host | Yes — operator runs/attests | No | Yes — the harness build IS the first build deliverable | Build-scope deliverable; acceptance gated on operator attestation | Make harness + L1-bound negatives the gating first phase of the build |
| B7 export step / KB writer / gate consumer | "Deferred online surface" | spec §22/§12.6; matrix L5 deferred; proof | N/A now | Future contracts | Future (Codex-mandatory per queue) | No — explicitly out of MVP | Correctly deferred; not in scope for this decision | Leave deferred; do not reopen |
| B1/B2/B3 execution surface | "Deferred (Call Contract / proof-of-run / global-absence)" | spec §22; future-contracts queue | N/A now | Future | Future | No | Correctly deferred | Leave deferred |
| B6 (carried) no governed taxonomy authority | "triage-only, no green, no exit 0" | spec §4.0 | Already enforced in design | No | No | Already in scope as a constraint | Closed in design (non-gating/no-green) | Preserve in build prompt invariants |
Re-classification summary. The only two blockers standing between now and a built+accepted MVP are B-EXT-1/B4′ (engineering provisioning, testable, runtime already present) and B0‴ (owner authority disposition, owner-waivable). Neither is a true blocker. B7/B1/B2/B3/B6 are correctly deferred or already closed.
Track-2 verdict: PASS — every current blocker is classified with evidence; none left unclassified.
Track 3 — Sandbox option matrix (A–F)
Columns: Feas = feasibility on this estate · Net = blocks network · Shell = blocks subprocess/shell · Sec = blocks secret/env · FS = blocks arbitrary local read · WO = enforces output-only writes · NegTest = negative tests can prove enforcement · Prohib = violates current macro prohibitions · BScope = can be build-scope · Op = operator action required.
| Option | Feas | Net | Shell | Sec | FS | WO | NegTest | Prohib | BScope | Op | Recommendation |
|---|---|---|---|---|---|---|---|---|---|---|---|
| A — Offline local process, in-process guards only | High to write | ✗ (cannot truly deny at OS) | ✗ | partial | ✗ | partial | ✗ — guards are bypassable (Codex's exact objection) | Would be the "fake sandbox" Codex rejected if used as primary | Yes | No | REJECT as primary. Keep only as L2/L3 secondary defense-in-depth |
B — Docker/Podman container (--network none, --read-only, RO input -v …:ro, WO output mount, --security-opt seccomp=profile.json, --security-opt no-new-privileges, --cap-drop ALL, scrubbed env) |
High — runtime already deployed on host (governed list_docker evidence) |
✓ --network none |
✓ seccomp execve/execveat deny |
✓ scrubbed env + minimal image, no secret mounts | ✓ mount namespace; only RO input visible | ✓ single rw mount | ✓ seccomp EPERM, mount-table RO, env keyset are real, observable artifacts |
No (authoring config ≠ prohibited; running = operator) | Profile/harness: yes. Host runtime: already present | Attestation only | RECOMMENDED (primary). Realizes §12.1 1:1 on the existing runtime. Podman-rootless preferred for least privilege where available |
C — OS-level sandbox / bubblewrap / firejail / seccomp (bwrap --unshare-net --ro-bind input --bind output --clearenv --seccomp …) |
High on Linux; bwrap is rootless/unprivileged-friendly | ✓ --unshare-net |
✓ seccomp + no --share exec path |
✓ --clearenv |
✓ --ro-bind only |
✓ single --bind |
✓ same OS-level proofs | No (config authoring fine; needs bwrap/firejail present) | Profile: yes. Needs bwrap/firejail installed (install prohibited here) | Attestation (+ possible install) | RECOMMENDED (co-equal alternative). Best where no container daemon/privilege; bwrap needs no daemon. Slightly higher operator burden if bwrap absent |
| D — CI sandbox later, no local sandbox now (GH Actions / GitLab CI ephemeral container runner) | High | ✓ (restricted runners) | ✓ | ✓ (ephemeral, no secrets injected) | ✓ | ✓ | ✓ in CI logs | No | Yes — as an acceptance venue | CI provides runtime | VIABLE complement. Good acceptance/regression venue; reduces local-host burden. Does not by itself unblock local-dev acceptance |
| E — Manual operator-provisioned sandbox host | High | depends on chosen tech | — | — | — | — | ✓ | No | This is the provisioning action, pairs with B/C | Yes — by definition | PAIR with B or C. Not a distinct sandbox technology — it is the operator attestation step (B4′) for whichever of B/C is chosen |
| F — No-sandbox dry prototype | Trivial | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ — nothing to prove | Acceptable only as a design walkthrough; explicitly non-acceptable for MVP acceptance (matrix: ~11 tests can't pass; P1 self-check fails closed to BLOCKED/exit 3) | n/a | n/a | REJECT for acceptance. Permitted only as a no-enforcement design rehearsal, never as the accepted MVP |
Recommended option: B (Docker/Podman deny-by-default container), with C (bubblewrap) as a co-equal fallback and D (CI) as a complementary regression venue. The decisive factor is the governed-native evidence that the container runtime is already deployed and in active use on the host (incl. an ephemeral test container), so Option B requires no new runtime install — only the profile/harness (build-scope) plus an operator run+attest.
Track-3 verdict: PASS.
Track 4 — Minimum acceptable sandbox for Phase-2 MVP
The minimum acceptable sandbox is exactly the rev4 §12.1 profile, realized by Option B or C, with every boundary backed by an enforcement-bound negative test (matrix L1) producing an OS-level proof-of-block:
| # | Requirement | Realization (Option B / C) | Proof-of-block (negative test artifact) |
|---|---|---|---|
| 1 | No network | --network none / bwrap --unshare-net |
socket()/connect() → EPERM/EAFNOSUPPORT; no route table |
| 2 | No PG driver reachable | (1) + no driver in image/env; named-query export deferred (B7) | connect attempt to any DB endpoint fails at syscall |
| 3 | No live KB/PG | (1)+(2); MVP issues no SQL, holds no driver/credential | no egress; no driver import (L2 denylist) |
| 4 | No KB writer | no KB credential/capability in env; output is local only | KB write attempt → no credential, capability-guard reject (L2/L3) |
| 5 | No env secret | scrubbed env / --clearenv; minimal image; no secret mounts |
env keyset snapshot contains no token/conn-string |
| 6 | No arbitrary local read | mount namespace; only RO input dir bind-mounted | open() outside input/output → ENOENT/EACCES; mount table shows only 2 mounts |
| 7 | Input packet read-only | -v input:/in:ro / --ro-bind |
write to input → EROFS |
| 8 | Report output write-only | single writable mount = output dir | write outside output → EROFS/EACCES |
| 9 | Subprocess/shell blocked | seccomp execve/execveat deny; no-new-privileges; --cap-drop ALL |
execve() → EPERM |
| 10 | Dynamic import/plugin controlled | L2 static import/capability denylist (build-time) + no network to fetch | import of denied module → build-time rejection / runtime guard |
| 11 | Output path escape blocked | output path canonicalized; only output mount writable | ../ / symlink escape write → EROFS/rejected |
| 12 | Each boundary negative-tested | matrix rev4 #24–#37 bound to L1 + block point + proof | seccomp EPERM / mount table / env keyset captured per test |
| 13 | Fail-closed if sandbox absent | L3 runtime-self-check (P1) attests sandbox invariants before any read | no-sandbox run → BLOCKED / exit 3, before any packet read |
Minimum bar: a run that (a) presents exactly two mounts (RO input, WO output), (b) has an empty network namespace, (c) has a scrubbed env, (d) denies execve/socket/connect/ptrace via seccomp with no-new-privileges, and (e) makes the MVP's P1 self-check pass — and against which negatives 1–13 above each produce the named OS-level proof-of-block. Anything weaker (Option A or F) is not acceptable.
Track-4 verdict: PASS.
Track 5 — Guard harness build-scope decision
Decision: PARTIAL — "the build prompt can include the guard harness, but acceptance remains blocked until the operator runs the harness in a deny-by-default container and attests the L1-bound negative tests pass."
Justification (evidence-backed):
- The harness is code + config: a Dockerfile/Podman invocation (or bwrap wrapper), a
seccomp.json, the L2 static import/capability denylist, the L3 P1 runtime-self-check, and the L1-bound negative-test suite. Authoring these is pure design/code authoring — no install, no host, no run required to write them. → build-scope. - The rev4 spec already says so: "Provisioning the sandbox and passing the Track-7 negative tests against it is part of MVP build scope (B4′)." The harness build is the first build deliverable.
- What is not build-scope is the attestation that the harness actually enforces on a real host — that requires executing the container and observing seccomp
EPERM, the mount table, and the env keyset. That is an operator/resource action (B4′ acceptance), which this macro forbids Claude from performing. - Therefore: YES to authoring the harness in the build prompt; acceptance gated on operator attestation. That is exactly the PARTIAL option, not YES (which would imply acceptance needs no external action) and not NO/BLOCKED (the runtime exists; a feasible path is proven).
Track-5 verdict: PASS.
Track 6 — Codex dependency decision
Decision: Codex is NOT required now. Defer Codex until after test evidence exists; B0‴ disposition is the owner's call.
Applying the Track-6 rule:
- The remaining load-bearing issue is engineering/provisioning (author harness → run deny-by-default container → attest negatives). It is testable. The rule says: testable engineering ⇒ do NOT use Codex now.
- B0‴ (Codex re-seal of rev4) is an authority/risk gate, but it is owner-waivable and recorded as the owner's disposition — it is not something this macro triggers, and the macro forbids calling Codex. The owner may (a) route the existing rev4 checkpoint packet to Codex, or (b) waive with the unreviewed-architecture risk recorded.
- Because the next safe step is an offline build authoring (the gated build prompt) followed by operator-attested negative tests, Codex is best deferred until that test evidence exists — at which point a Codex re-seal (if the owner honors B0‴) reviews a tested harness rather than a paper design. This avoids spending a Codex round on something still unproven.
Track-6 verdict: PASS — Codex deferred on the engineering/testable ground; B0‴ left as the owner's authority disposition.
Track 7 — Build-go decision
Selected: B — BUILD_PROMPT_READY_BUT_OPERATOR_SANDBOX_ACTION_REQUIRED.
Why B is correct:
- The guard harness is build-scope code authorable now (Track 5), so a complete build prompt can be prepared — the first decision-clause of B.
- But before that build can be accepted/executed, two real, narrow actions stand: (i) operator runs the harness in a deny-by-default container and attests the L1 negatives pass (B4′); (ii) owner disposes of B0‴ (honor → Codex, or waive). That satisfies the second decision-clause of B ("sandbox provisioning must happen first").
- B is the honest middle that advances the work (writes the next artifact) without faking authorization.
Why not the other five:
- Not A (
BUILD_OFFLINE_MVP_WITH_GUARD_HARNESS_NEXT): A requires "no owner/operator action required before build." False — B0‴ is recorded as a precondition to any build (owner disposition needed), and B4′ acceptance needs an operator attestation on a real sandbox. At least one owner/operator action stands before an accepted build. A overclaims. - Not C (
OPERATOR_ACTION_PACKET_REQUIREDalone): C understates what is safely possible now. Agent can author the gated build prompt (a KB design artifact — no mutation, no build, no run). The operator action is a precondition to acceptance, not to the next safe Agent step. B captures both truths; C alone discards "build prompt ready now." - Not D (
CODEX_REQUIRED_NOW): the load-bearing remaining blocker is engineering/provisioning and testable (Track 6). B0‴ is owner-waivable authority, the owner's call, not a forced Codex round now. - Not E (
REV5_DESIGN_REPAIR_REQUIRED): the internal proof found no rev4 design defect, and this macro found none — the §12.1 profile is directly specifiable into a harness. No design repair needed. - Not F (
TRUE_BLOCKER): a safe engineering path demonstrably exists — author harness (build-scope) → run a deny-by-default container on the already-deployed Docker runtime (governedlist_dockerevidence) → attest negatives. The prior "TRUE_BLOCKER" framing conflated "author the build prompt" with "accept the build," and predated the runtime-presence evidence. F is now disproven.
This is the substantive advance over the prior INTERNAL_PROOF_PARTIAL / TRUE_BLOCKER: the sandbox blocker is reclassified from true/impossible/owner-resource to build-scope harness (authorable now) + operator attestation (narrow, on existing runtime) + owner B0‴ disposition → Decision B.
Track-7 verdict: PASS.
Track 8 — Build prompt packet (created, because B)
Authored as a gated Program Macro build prompt:
knowledge/dev/laws/tool-kiem-thu/planning/build-offline-packet-mvp-with-guard-harness-program-macro-prompt-2026-06-09.md
It carries hard preconditions at the top (DO NOT EXECUTE until B0‴ disposed + sandbox host attested per the operator packet) and specifies: offline packet MVP prototype, guard harness (sandbox profile + L2/L3 guards), sandbox provisioning precondition, packet reader, provenance validator, evidence-adequacy classifier (Article-14 chain), non-global verdict reporter, local report writer, fixtures, the 45 acceptance/negative tests (L1–L5-bound), the FIX7 packet fixture, Article-13 and Article-14 self-audits, and the full prohibition wall (no network, no PG driver, no KB write, no command execution, no mutation, no fake-green, no local-first).
Track 9 — Operator action packet (created, because B)
Authored: knowledge/dev/laws/tool-kiem-thu/checkpoints/operator-action-packet-sandbox-host-for-phase2-mvp-2026-06-09.md
It states the exact sandbox requirement, the recommended implementation (Option B Docker/Podman; Option C bwrap fallback), what the operator must provide, how Agent will verify it later (read-only attestation evidence), the expected proofs (seccomp EPERM, mount table, env keyset), the risk if waived, and the fallback if unavailable (Option C / Option D CI). No destructive commands; no assumed owner approval.
Tracks 10–12 — Not applicable
- Track 10 (Codex packet): NOT produced — decision is B, not D.
- Track 11 (rev5 repair packet): NOT produced — decision is B, not E; no design defect found.
- Track 12 (true blocker packet): NOT produced — decision is B, not F; a safe engineering path exists.
Track 13 — Final self-audit
| Item | Verdict | Evidence |
|---|---|---|
| Article 13 PG-first / native / driven | PASS | All project facts read from KB SSOT (Track 1); the one feasibility-critical environment fact (runtime presence) read from a governed-native source (list_docker, read-only), not asserted; local files are not authority here |
| Article 14 evidence-backed / no fake-green | PASS | No prose-only PASS; the build-go decision is gated (B), not declared "authorized"; the harness is "authorable" not "proven enforcing"; runtime-presence is cited from a real read, and explicitly does not prove the deny-by-default profile passes (that needs B4′ attestation) |
| KB-first / local-last | PASS | Source docs read from KB; deliverables written to KB; no local-first evidence used; local report is not made an authority |
| No unsupported build-go | PASS | B selected, not A; build is not authorized — build prompt is prepared, gated on B0‴ + B4′ |
| No fake owner/operator/Codex decision | PASS | B0‴ left to owner; attestation left to operator; Codex not called; no approval fabricated |
| No hidden production mutation | PASS | Only reads (batch_read, get_for_rewrite, list_docker) + KB writes of governed design/report/checkpoint docs; no PG/Directus/registry/system_issues mutation; no install; no sandbox created |
| Sandbox decision evidence-backed | PASS | Option matrix grounded in §12.1 + standard OS/container capabilities + governed runtime-presence evidence |
| Next step unambiguous | PASS | Exactly two action-ready items: owner disposes B0‴; operator attests the deny-by-default sandbox per the operator packet — then author/execute the build |
No critical item failed → Final status SANDBOX_DECISION_READY.
Final summary
- Build-go: B — BUILD_PROMPT_READY_BUT_OPERATOR_SANDBOX_ACTION_REQUIRED.
- Recommended sandbox: Option B (Docker/Podman deny-by-default container) on the already-deployed host runtime; Option C (bubblewrap) co-equal fallback; Option D (CI) complementary regression venue. Reject A (in-process only) and F (no-sandbox) for acceptance.
- Guard harness: PARTIAL — build-scope to author now; acceptance gated on operator attestation.
- Codex: not now — engineering/testable; B0‴ is the owner's owner-waivable disposition.
- Remaining blockers (both action-ready, neither a true blocker): (1) operator attests the deny-by-default sandbox (B4′) before build acceptance; (2) owner disposes B0‴ before build execution.
- Minimal safe next step: owner disposes B0‴ (honor→Codex or waive-with-risk) and operator provisions+attests the §12.1 sandbox per the operator packet; the gated build prompt is ready to execute once both clear. No build, install, mutation, sandbox creation, or Codex call was performed.