RS-TKT-0A-PATCH1 · 04 — L1 vs Phase-4 Execution Boundary Patch (P4)

Lane: RS-TKT-0A-PATCH1 · Date: 2026-06-21 Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 runtime mutations (KB writes only) Authority: NON_AUTHORITY · may_gate=false · decision_effect=NONE · design-only

Supersedes: the "clean-room rerun" wording in 03 §3 and 04 TKT-L1-PACKET, and clarifies the Phase 2/4 boundary in 07.

---

1. The defect (Codex P4, BLOCKER)

L1 said the packet "reconstructs … and reruns deterministically" while Phase 4 defers the verifier that executes the subject under test. The word "rerun" is ambiguous: read naively it could let a runtime execution verifier be smuggled into Base L0–L3. PATCH1 draws the line precisely.

2. Definitions

• inert packet fixture — a directory of files (manifests, hashes, recipe scripts, committed result anchors, documents) that contains no live system state and whose reconstruction does not require contacting any external runtime. The "subject" is the packet, not a running program.
• TKT reconstruction / verifier recipe — the TKT's own scripts (commands.sh/RERUN.sh-style) that recompute hashes, re-verify the tree pin, re-run the TKT probe harness, and re-emit the TKT verdict anchor. This is TKT verifying itself/its own packet, not invoking the candidate's behaviour.
• subject under test (SUT) — the candidate artifact/system the packet is about (a DOT, a handler, a registrar, a business function). Its runtime behaviour is the thing TKT must NOT trigger at L1.
• runtime execution — invoking the SUT's production/runtime behaviour, or any registrar/handler/validator/PG/Directus/external runtime call.
• Call Contract — the Phase-4 artifact that defines how to invoke the SUT safely (inputs, sandbox, deny-by-default, evidence capture). Required before any SUT execution.

3. The L1 boundary (binding for Base)

L1 MAY:
  - execute the TKT reconstruction/verifier recipe on INERT packet fixtures only;
  - recompute hashes, re-verify tree pin, re-run the TKT probe harness, re-emit the TKT verdict anchor.

L1 MUST NOT:
  - invoke the candidate's production/runtime behaviour;
  - call registrar, handler, validator, PG, Directus, external runtime, or any
    subject-under-test business function;
  - read or write live system state.

Any call into the subject under test REQUIRES the Phase-4 Call Contract + sandbox.

This keeps the execution verifier strictly in Phase 4. Base (L0–L3) is read/recompute over inert fixtures only.

4. New stop state

HOLD_RUNTIME_SURFACE_REQUIRED

If a package cannot be reconstructed/verified without invoking subject-under-test runtime, L1 must return HOLD (HOLD_RUNTIME_SURFACE_REQUIRED), never PASS. Reaching this HOLD means the work belongs to Phase 4 (Call Contract + sandbox), not Base. (Aligns with 07 Phase 2 HOLD_NO_EXEC_SURFACE and Phase 4 HOLD_NO_CALL_CONTRACT.)

5. Effect on the roadmap (07)

• Phase 2 (MVP Read/Report Inspector) runs L0–L3 on inert fixtures only; if it needs SUT runtime → HOLD_RUNTIME_SURFACE_REQUIRED / HOLD_NO_EXEC_SURFACE.
• Phase 4 (Controlled Execution Verifier) is the only phase that may execute the SUT, and only after an approved Call Contract + deny-by-default sandbox.
• This removes the smuggling path: a runtime execution verifier cannot appear inside Base because L1 fails closed to HOLD the moment SUT runtime is required.