[KimGLee]

Summary

Closes #223.

• Terminal reads now join the existing evidence observation, after the original invalid-admission checks.
• Profile admission shares identical input rebinding only within an explicit read-only observation and freshly verifies inputs before successful exit. Nested new observations, independent composers, writers and resulting-state reads retain their own boundaries.
• CLI queries always use the target compiler's fresh full verification and common return-time input check. The unsafe checked-view cache, Runner decorators, public API declaration and cache-only assertions are retired together.
• The entrypoint owner now supplies source descriptors and parser capture as one complete compilation surface, with discovery/source read-back. Existing argument, policy and Receipt extraction owners are unchanged.
• The existing MCP stdio Host prepares checked-hash Python bytecode in a newly owned external directory. Every child still executes modules/defaults and performs full validation; only source compilation is shared. Automatic bytecode writes remain disabled, no adopter-local or previous-session cache is accepted, and stdio exit cleans the directory.

No Kernel/Profile rule, workflow, budget, runtime object, evidence kind or transport was added. No alternate writer, persistent cache or compatibility API is introduced.

Verification and cost

• Existing owner/Runner contract selection: 75 tests passed.
• Existing changed-scope, Terminal-consumer and Runner checkpoint selection: 44 tests passed.
• Final Terminal admission-boundary owner selection: 4 tests passed.
• Final direct-Gate checkpoint integrations: 4 tests passed. Selections overlap; these counts are not summed as unique coverage.
• MCP, compiler and entrypoint owner selection after Host preparation: 84 tests passed, including same-size/same-mtime source changes, external values re-evaluated on each execution, child isolation and exception cleanup.
• make check passed, including generated CLI/MCP/Host interfaces, metadata contract, Profile schema, Card provenance, links and both catalogs.
• Eight existing checkpoints were regenerated by their original producers. Their synthetic plan/receipt identities and dependency fingerprints change together; no test history is imported into a real runtime.
• Test catalog: 133 modules, 1,295 cases (previously 1,289), 49 fixtures and 8 bundles. No new test file, E2E, fixture bundle or explicit process/full-copy site. Six new owner cases cover Profile observation boundaries, dynamic CLI inputs, capture-source closure and private source-compilation lifetime.

Local same-input comparisons preserved complete result identities: Profile normative rebinding 6 -> 4; Terminal capability loads 28 -> 2 and entrypoint descriptions 728 -> 52. Old and new compiler algorithms over identical source inputs emitted identical full projections. These are structural/local observations, not a GitHub budget claim.

Retiring unsafe CLI reuse may increase full-check frequency. Correctness and total cost must both be measured using the unchanged protected Python 3.10/3.14 MCP lifecycle, including two batches, correction, content change, close and Terminal Proof. The required-chain target remains 300 seconds and maximum 360 seconds. No local full lifecycle is replayed just to duplicate that remote acceptance run.

Review boundaries

The source changes are confined to the existing evidence, Profile admission, compiler/entrypoint owners and their direct consumers. Most changed files are regenerated projections and existing checkpoint evidence. Independent producer admission, lock-time currentness/CAS, frozen evidence selection, rejection, per-item correction and write read-back are preserved.

First remote acceptance result

Run 34606345710, head d65fcf14eead9ed3a3539b277da37f488101ad2b: all contract/test jobs passed, including the unchanged full MCP lifecycle on Python 3.10 and 3.14. Natural MCP report times were 342.214 seconds and 379.872 seconds. Each kept 41 MCP tool calls and 36 explicit Runner child steps; these are not OS-process counts.

The required budget check measured 498.053 seconds and correctly failed the unchanged 360-second limit. This candidate is not ready to merge. Visible runner-start gaps do not explain the full overrun. The remaining work is to separate full CLI verification frequency from work inside each compilation, without restoring unsafe cached validation, dropping independent boundaries, or rerunning the same candidate to obtain a luckier timing. No workflow or test-scenario reduction is proposed.

The follow-up compares the actual source-only isolation environment with private checked-hash bytecode, not ordinary pre-existing local caches. Both modes execute a fresh full compiler every time. A local paired probe measured 1.094 vs 0.625 seconds per check, with 0.726 seconds of explicit initial preparation. This is not a remote budget result. The follow-up candidate retains the same protected acceptance run; no correctness or budget exception follows from these local numbers.

Final candidate acceptance

Run 34611055868, head a630e134626efd0957e81a69945e65509a6e1bc5, completed 24/24 jobs successfully in full verification mode. The unchanged complete MCP reports took 247.583 seconds on Python 3.10 and 214.573 seconds on Python 3.14. Both exercised the original two batches, independent correction, content revision, close and Terminal Proof; the test scenario was not shortened.

The protected gate measured 303.988 seconds. The existing budget owner then verified the completed attempt with --final: 305.000 seconds, passed, including setup, scheduling and cleanup. This is below the unchanged 360-second acceptance maximum and 5 seconds above the 300-second target. No jobs, versions, acceptance obligations or safeguards were removed. This is one measured successful attempt, not a guarantee about all future hosted-runner scheduling.