Coding checks

Every coding workspace receives the same task-directed validation guidance. The agent reads repository instructions, scripts and CI and chooses a bounded check relevant to the task. Where a trusted checkout binding, typed executor and durable ledger are available, run_check records execution. The default requires no repository-specific test command. Environment preparation and its ownership/recovery guards remain separate; the older startup smoke policy is compatibility behavior, not automatically a task baseline.

• Code: src/agents/registry.ts, src/core/dispatch/runLoop.ts, src/core/checkExecution.ts, src/core/checkExecutionSchema.ts, src/core/checkInspection.ts, src/execution/runCheck.ts, src/core/checkExecutionTypes.ts, src/tools/check.ts, src/tools/toolsets.ts, src/tools/runnableTool.ts, src/execution/executor.ts, src/execution/checkOperation.ts, src/execution/resident.ts, src/execution/tracingExecutor.ts, src/core/runLedger/workspaceDurability.ts, deploy/cloudflare-resident/checkOperation.ts
• Tests: src/core/checkInspection.test.ts, src/core/commands/runChecks.test.ts, src/execution/runCheck.test.ts, src/core/runLedger/checkInspection.test.ts, src/core/checkExecution.metadata.test.ts, src/core/harness/pi/relay.test.ts, src/agents/registry.test.ts, src/core/dispatch/runLoop.test.ts, src/core/checkExecution.test.ts, src/tools/check.test.ts, src/tools/toolsets.test.ts, deploy/cloudflare-resident/checkOperation.test.ts, deploy/cloudflare-resident/workspaceSettlement.test.ts, src/core/runLedger/workspaceDurability.test.ts
• Related: Coding agent, Execution, First coding baseline compatibility

Behavior

1. Select with context. Before intended code changes, the agent inspects the task, relevant AGENTS.md, package scripts and CI to identify the cheapest useful baseline. A monorepo task selects the relevant package or test, never a whole-suite default. The existing checks-by-cost rule and remaining run budget apply. Reusable repository instructions are useful input; they are not an additional central configuration requirement.

2. Prefer recorded execution when supported. run_check takes purpose: baseline | verification, command and optional timeoutMs. Commands can contain up to 16,000 characters, including multiline verification scripts. The complete dispatched command, including shell quoting and the checkout wrapper, stays within the 64,000-character receiver limit. Original operation hashes stay unchanged when the original encoding fits. The model-visible schema, execution admission and stored receipt use the same limit; oversized commands are refused before execution, never truncated to fit. The runner supplies the bound executor, run identity and workspace; model arguments cannot select another run or supply a result. The command uses the existing sandbox authority and execution budget. The tool does not grant publication, installation, network or external-write authority. Its command passes the shared shell-command restrictions as well as the current harness lifecycle gate; its own timeout is clipped by the existing command-budget policy.

3. Record facts. Before executing the check, the runner observes the checkout path, head and working-tree fingerprint; this is an observation, not an immutable snapshot. The existing run ledger records the tool-call identity and pending intent before execution, then the typed outcome before returning a receipt. If authorization, budget or a stop prevents dispatch after intent is saved, not_started records that fact; it is not an unknown execution or a completed command. Exit status, bounded/redacted output and available execution provenance come from the executor. Output is untrusted evidence. A successful process exit does not prove that assertions ran, that the selected check was relevant, or that the repository is healthy. A nonzero process exit likewise does not distinguish a failing assertion from missing setup by itself.

4. Keep history. A completed baseline records the pre-command workspace observation and subsequent process result. This is not a stable-tree or effective-command-directory attestation: another operation may change the checkout between observations, and the command itself can change directories or files. Later edits do not invalidate or erase that historical observation, and an exact duplicate call returns its saved result instead of executing again. A new verification uses a new call identity. Reusing an identity with different submitted arguments is refused, including switching between an omitted timeout and an explicit default timeout. A known not_started operation can be attempted under a new call identity after the refusal is resolved. A pending or unknown operation is not automatically replayed, and a new call identity cannot retry the same unknown command. New Resident checks persist distinct metadata and selected-command request identities before each dispatch. A retained preflight result is saved before parsing its workspace observation; unresolved preflight identity cannot start the selected command or certify scratch custody closure. A read-only lookup can recover the original saved result immediately after transport loss or when the same check identity is inspected later within its current owner and run budget. A retained metadata result can be inspected but cannot start the selected command: its saved head/fingerprint does not prove the current checkout at that path. Terminal runs can use runs.check to inspect retained canonical check evidence without resuming. runs.settlecheck can retire exactly one unresolved alias only from an existing original native-ended proof; it never dispatches or signals native work. The lookup requires the original owner, thread, command and workspace incarnation; it never dispatches the command. Missing, pending, interrupted and legacy evidence stays held. This does not grant a stopped run permission to resume, cancel native work or recover a historical check without its saved identity. This rule is not a semantic detector for differently spelled commands.

5. State the limits. The agent is instructed to establish the baseline before intended edits. This is a workflow expectation, not a read-only phase or a structural guarantee: arbitrary commands can write, and neither the purpose label nor a shell parser proves command semantics. A verification receipt is not a publication-gate receipt, approval, or permission to publish.

6. Report capability limits honestly. The universal prompt does not imply universal receipt support. A cold path cloned by the model may lack a trusted checkout binding, and an executor without typed execResult cannot produce this receipt. An initially absent or untracked ledger refuses before metadata or command execution and explicitly reports that the command did not start. A later durable-write failure remains a persistence failure. Existing pending or unknown operations take precedence over missing capabilities after resume and remain unresolved. If a non-mutating capability refusal establishes that the requested command did not start, the agent may use ordinary permitted shell tools and report their actual output without claiming a typed check receipt. Policy refusal, an unknown outcome or persistence failure never licenses that fallback or an automatic replay. If the evidence does not establish that the command did not start, preserve the uncertainty.

7. Use judgment when a baseline is unavailable. For a documentation-only change, select a relevant documentation check when one exists. If no useful bounded baseline exists, report that fact and its reason; do not run an unrelated command merely to fill a receipt. Missing dependencies or tools remain environment limitations, not passing tests. The final validation states what actually ran, what failed, and what remains unverified.

8. Refresh the phase notes. A verification may include a complete checkpoint with the current phase, goal, decisions, rejected approaches, reported completed work, unproven work and next step. The model-visible schema permits checkpoints only with purpose: verification; both purposes remain valid without a checkpoint. Invalid, oversized or baseline checkpoints also refuse at runtime before execution. Only a new recorded verification with a known zero exit replaces the existing notepad through its owner-fenced, source-preserving write. Reported work remains explicitly model-reported; the saved check identity, head, working-tree fingerprint and command hash record process evidence separately. The checkout observation precedes the command and cannot attest an unchanged tree or assertion coverage. A check replay never replaces newer notes. Failed, unknown, stopped or fenced paths keep the preceding notes. Lost note-write acknowledgement is reported as unknown without re-executing the recorded check; the agent must reconcile notes before refreshing them. Ordinary notes writes remain compatible. Both harnesses use this shared tool capability.

9. Reserve recorded checks for execution evidence. Each run retains at most 32 check receipts and 4,000 characters per output stream. A full receipt ledger refuses before metadata or command dispatch. Each refusal publishes a bounded, redacted harness_error run note under its original call ID before it returns. The tool reports that the command did not start and permits other tools and saved-result replay to continue; existing unknown operations and persistence failures still stop recovery. A completed result with truncated output explicitly states that its evidence is partial. Source reading uses review_read or read. When a request requires shell-based source collection, save the large read-only output once under $TMPDIR and page it with read, rather than spending check receipts on small shell slices. A missing or incomplete read never supplies review coverage.

Validation criteria

Criterion	Proof
Receipt exhaustion records each original-call refusal in the run stream, leaves recorded results intact and permits saved-result replay through the shared native relay. Unknown operations still stop recovery.	[unit] src/core/harness/pi/relay.test.ts::hosted %s check lifecycle::reports a full receipt ledger as not started and preserves recorded replay, ::retains the original check failure before recovery stops native result delivery*
A completed command with clipped output returns an explicit partial-evidence notice and retains the bounded receipt.	[unit] src/tools/check.test.ts::run_check phase checkpoints::reports partial output with source-reading guidance instead of silently clipping a check
Multiline commands above the former 2,000-character limit retain complete recorded receipts and can be read after restart without execution. Commands up to 16,000 characters pass the same tool and execution limit; larger commands refuse before dispatch.	[unit] src/tools/check.test.ts::run_check command size::*; src/core/checkExecution.test.ts::recorded coding checks::executes %s checks in their recorded checkout
A maximum-size quote-heavy command dispatches within the receiver bound at ordinary and long checkout paths. Compact encoding preserves literal shell input, execution results and retained-result replay.	[unit] src/core/checkExecution.test.ts::recorded coding checks::keeps a quoted check within the receiver limit*, ::executes %s checks in their recorded checkout
The model-visible check schema rejects baseline checkpoints, accepts baselines without checkpoints, and accepts verification with or without a checkpoint. The pi extension restores this rule after the pinned non-strict Anthropic converter drops it, only for an already-offered tool. The runtime still refuses invalid calls before execution.	[unit] src/tools/check.test.ts::run_check phase checkpoints::rejects baseline checkpoints in the model-visible schema while accepting valid check intents, ::keeps previous notes for failed and unknown checks and refuses baseline checkpoints; src/core/harness/pi/extensionSource.test.ts::run_check provider schema::retains the checkpoint rule in the serialized Anthropic payload for %s without restoring removed tools
A verified phase refresh preserves the goal, decisions, rejected approaches, reported work, remaining gaps and next step with actual command evidence. Invalid, oversized and baseline payloads cannot start execution; failed, unknown, fenced and replayed calls cannot overwrite previous notes, and uncertain note writes do not replay the check.	[unit] src/tools/check.test.ts::run_check phase checkpoints::*, ::run_check phase note recovery::*
A recorded command receives the harness-owned temporary directory as $TMPDIR; it retains the recorded checkout and command result.	[unit] src/core/checkExecution.test.ts::recorded coding checks::executes %s checks in their recorded checkout
The cold, resident and seeded coding prompts share task-directed baseline selection and run_check; other agents gain neither the coding instruction nor authority through that instruction.	[unit] src/agents/registry.test.ts::coding prompts: adaptive task baseline before edits::*; src/core/dispatch/runLoop.test.ts::runLoop adaptive coding checks::binds typed checks…
A check records intent before executor dispatch and result before success is returned; the model cannot supply exit status or another run's context.	[unit] src/core/checkExecution.test.ts::recorded coding checks::persists intent before dispatch and records typed exit without interpreting output; src/tools/check.test.ts::run_check tool::*
Successful and nonzero results retain typed exit codes and bounded output without claiming assertion coverage; malformed or lost results cannot become success by matching output text.	[unit] src/core/checkExecution.test.ts::recorded coding checks::persists intent before dispatch and records typed exit without interpreting output, ::records %s as unknown without inventing successful completion, ::retains exit %s as unknown and suppresses another call id for the same command
Exact call replay returns completed history after ordinary edits without a second execution; a changed payload under the same identity refuses; a pending or unknown identity is never replayed.	[unit] src/core/checkExecution.test.ts::recorded coding checks::returns historical completion after edits and restart without rerunning or probing the new tree, ::serializes simultaneous duplicate calls and refuses a changed payload under the same call id, ::refuses timeout omission changing from %s to %s under the same call id, ::retains exit %s as unknown and suppresses another call id for the same command
Missing persistence, unavailable typed execution, invalid timeout and exhausted run budget cannot produce a successful check receipt. Existing owner, branch and publication guards remain in force.	[unit] src/core/checkExecution.test.ts::recorded coding checks::does not return an accepted receipt when %s persistence fails, ::refuses absent capabilities, malformed metadata, exhausted budget and stopped runs before dispatch; src/tools/check.test.ts::run_check tool::rejects model-supplied receipt facts and target overrides before execution
A missing typed executor or trusted checkout does not imply missing baseline guidance; ordinary permitted execution can provide observational evidence only after a known pre-execution capability refusal, never as a replay after uncertainty or a way around policy.	[unit] src/agents/registry.test.ts::coding prompts: adaptive task baseline before edits::records failures honestly and permits unrecorded checks only before dispatch, never after uncertain execution; src/core/checkExecution.test.ts::recorded coding checks::refuses absent capabilities, malformed metadata, exhausted budget and stopped runs before dispatch; [agent] Follow step 5 below.
An initially absent or untracked ledger establishes that a new command did not start; saved pending or unknown operations still prohibit replay after capabilities disappear. Actual write failures remain fail-closed.	[unit] src/core/dispatch/runLoop.test.ts::runLoop adaptive coding checks::refuses recording before execution when the ledger is %s; src/core/checkExecution.test.ts::recorded coding checks::preserves %s uncertainty when recording and the checkout are unavailable after resume, ::does not return an accepted receipt when %s persistence fails; src/tools/check.test.ts::run_check tool::reports missing durable capability and unknown execution without a success claim
The trusted tool session can only narrow the original run deadline and signal; a session abort prevents queued work from starting and interrupts in-flight check observation without fabricating completion.	[unit] src/core/checkExecution.test.ts::recorded coding checks::honors the tool session's narrower deadline and abort independently of the owning run, ::never dispatches a queued check after its tool session ends
The selected command passes the shared shell policy before metadata collection and is checked again immediately before dispatch; a changed refusal cannot execute the command.	[unit] src/core/checkExecution.test.ts::recorded coding checks::uses the existing command policy before metadata or intent and rechecks it before dispatch
Existing explicit startup-smoke policies and saved legacy receipts retain their original behavior independently of task-directed checks.	[unit] src/core/firstTest.test.ts::first coding test::*; src/core/dispatch/runLoop.test.ts::runLoop first coding test::*
A task in one package of a monorepo selects a relevant bounded baseline; a docs-only task selects a useful documentation check or clearly names the absence of one; a normal failing test is reported separately from a missing tool or dependency.	[agent] Follow the evaluation procedure below against an authorized test installation.
Command receipts bind to an actual run owner and optionally a real coordinator unit. Missing or empty required identity, an empty/explicitly undefined unit, foreign optional-unit presence/value or ambiguous legacy owner refuses before metadata, persistence or execution; historical bytes remain unchanged. Legacy standalone coding receipts with unit: "" remain held even when original canonical metadata matches; normalization and resume parity are not supplied.	[unit] src/core/checkExecution.test.ts::recorded command owner binding::*
New tracked, actually bound read-profile Review exposes the direct existing run_check only when its canonical current owner and typed executor are ready. Its original read-command policy, checkout, executor, timeout, signal and fenced pending/result acknowledgements remain in force; no unit, workspace or generation is minted. Native shell is removed from launch definitions and independently denied at the bot gate.	[unit] src/core/dispatch/runLoop.test.ts::tracked Review command receipt binding::* Launch/source and local ledger proofs do not establish native or served-store acceptance.
Hosted Review omits pi native bash, removes OpenCode native shell with the pinned editor and denies shell last while retaining direct relays and existing CodeMode/subagent/egress denies. Coding and ordinary read policies retain their own behavior.	[unit] src/core/harness/pi/process.test.ts::hosted Review launch policy::*; src/core/harness/pi/relay.test.ts::hosted Review native admission::*; src/core/harness/opencode/process.test.ts::hosted Review permission policy::*; src/core/harness/opencode/pluginSource.test.ts::hosted Review plugin table::*; src/core/harness/opencode/bridge.test.ts::hosted Review native permission admission::*
Cached sessions do not acquire a verified command policy from current launch configuration, a prompt or definitions-only tool discovery. Hosted Review resume remains held before producer effects until a separate original-session verification capability exists.	[unit] src/core/harness/contract.test.ts::hosted Review retained session policy::*

| A lost pending or result state acknowledgement grants neither command dispatch nor completion credit. The existing original-generation write-through reconciles only exact canonical state; an absent or different state stays held. Later reconciliation does not silently revive the failed capability or replay the command. | [unit] src/core/checkExecution.test.ts::recorded checks with uncertain canonical ACK::* |

| Checkout metadata uses its own existing preflight allowance, clipped by the remaining run and originating call budget. A short command timeout cannot alone cut off metadata; the business command still uses its requested timeout. | [unit] src/core/checkExecution.test.ts::recorded coding checks::records a short command after metadata takes longer than the command timeout; src/core/checkExecution.test.ts::recorded coding checks::distinguishes metadata deadline* | | A selected process timeout does not cut off its remote response at the same instant. The existing executor response margin stays clipped to the original run and call allowance; process timeouts, run stops and call stops still record an unknown interrupted outcome. | [unit] src/core/checkExecution.test.ts::recorded coding checks::keeps the process timeout while awaiting its* |

| A new Resident check saves its request identity before dispatch. After a lost reply or a later inspection of that same receipt, only an owner-, thread-, request- and incarnation-matched saved terminal result settles it. Inspection never dispatches a command; missing, pending, stale or legacy evidence remains held. | [unit] src/core/checkExecution.test.ts::recorded coding checks::recovers a saved Resident command result after a lost reply without repeating execution, ::inspects a retained unknown check on the same identity without redispatch and holds mismatches, ::holds unreadable or mismatched result inspection and a failed recovery receipt write; deploy/cloudflare-resident/checkOperation.test.ts::recorded Resident check operations::*; deploy/cloudflare-resident/workspaceSettlement.test.ts::Resident recorded check result lookup::* |

| Resident result storage holds at most 64 phase aliases per thread with bounded, redacted output: at most 32 complete metadata-plus-command checks for one owner, fewer while older pending aliases remain. Eviction strips completed output while retaining no-repeat tombstones and pending evidence. Only a strictly newer current owner fence removes settled old-owner aliases. Capacity refusal records that the command did not start. | [unit] deploy/cloudflare-resident/checkOperation.test.ts::recorded check retention::*; src/core/checkExecution.test.ts::recorded coding checks::records a definite Resident capacity refusal as not started, ::reports metadata capacity before start and preserves other held command identities |

| Result-write uncertainty, unavailable Worker completion and refused/unavailable result reads report closed failure codes with bounded trusted thread/run/fence/check identity. Diagnostics contain no raw errors, commands, outputs or response payloads; logging never changes settlement. | [unit] deploy/cloudflare-resident/checkOperation.test.ts::recorded Resident check operations::reports result-write uncertainty with bounded identity and no raw failure data; deploy/cloudflare-resident/workspaceSettlement.test.ts::Resident recorded check result lookup::reports the held check identity when substituting an unavailable result; src/core/checkExecution.test.ts::recorded coding checks::reports an unavailable result read without exposing response or error text |

| Metadata and the selected command have separate durable identities. A lost metadata reply is read without repeating that preflight; only a persisted valid observation permits the selected command. Pending metadata holds other identities, missing result or write acknowledgement, foreign owners and scratch custody closure. | [unit] src/core/checkExecution.test.ts::recorded coding checks::recovers the original metadata reply before starting the selected command, ::holds metadata admission or result persistence failure before the selected command starts, ::inspects retained metadata without dispatch while inputs and foreign owners stay held; src/core/runLedger/workspaceDurability.test.ts::canonical scratch custody disposition::keeps retained preflight evidence from certifying scratch custody closure |

| A restored preflight snapshot cannot dispatch the selected command at a potentially replaced checkout. The original result remains saved, and metadata_revalidation_required holds dispatch until a separate freshness proof exists. | [unit] src/core/checkExecution.test.ts::recorded coding checks::holds a restored preflight when the checkout head or fingerprint may have changed at the same path |

| Recorded checks reserve room for the command, checkout identity and worst-case escaped output before metadata or command execution. Their aggregate state stays within 256 KiB, leaving room in the 512 KiB ledger request. Capacity refuses before effects and preserves earlier receipt identities and replay suppression. | [unit] src/core/checkExecution.test.ts::recorded coding checks::refuses %s receipt capacity before dispatch without losing saved identities |

Evaluation procedure

Use an authorized test installation and disposable fixtures, with normal coding requests rather than an explicitly supplied test command. Keep run identifiers, deployed version, fixture heads, commands and results in the operator's evidence store, not this spec. Do not create production events solely to fill a receipt.

1. Submit a small change in one package of a fixture monorepo with two independently testable packages. Inspect its transcript and receipts: the agent read local instructions/scripts, selected the relevant package's bounded test, and observed its baseline before the first intended source edit. A test in the unrelated package or a whole-suite default fails this selection criterion. The transcript proves this observed ordering only; it does not establish a universal pre-edit security boundary.
2. Submit a documentation-only change in a fixture with a documented documentation check, then in one without a useful bounded check. The first should use the documented check. The second should name the unavailable baseline and still report appropriate validation for its actual change, without fabricating a passing test.
3. In separate fixtures, use a runnable test with a failing assertion and a missing required tool or dependency. Inspect the actual command evidence and the agent's explanation. Neither condition may be described as clean; a generic nonzero exit alone must not be called an assertion failure.
4. Confirm a later verification has a distinct call identity and names its own result. The earlier baseline remains history. Publication still requires the existing ownership, exact-tree checks and review rules.
5. On a supported installation, confirm typed receipts; on a path without a trusted checkout or typed executor, confirm the agent describes ordinary shell evidence without inventing a receipt. A command-policy refusal or ambiguous earlier operation must not trigger a shell fallback.
6. Exercise duplicate delivery and an interrupted response in the test harness. Confirm exact completed replay executes once and pending/unknown replay executes zero additional commands. Authoritative operation reconciliation is not implemented by this tool; retain the unresolved operation, and never substitute a model-written file.

| Metadata execution, result and framing failures retain a bounded structural diagnostic on the existing unavailable tool result. Typed infrastructure reasons require the actual typed cause; prose, private streams, paths, stacks and names are never emitted or classified. A typed aborted execution may retain only a closed abort source and its effective metadata timeout. The existing deadline and trusted run/call control signals supply that observation; conflicting or later control aborts remain ambiguous and an unobserved source remains unknown. No raw reason text is read for classification. These fields prove neither metadata ending nor retry authority and change no deadline, reserve or replay rule. No business command or intent/result write begins on metadata failure. | [unit] src/core/checkExecution.metadata.test.ts::recorded check structural metadata diagnostics::*; src/core/checkExecution.test.ts::recorded coding checks::distinguishes metadata deadline*; src/core/checkExecution.test.ts::recorded coding checks::keeps an unobserved typed abort unknown and leaves arbitrary error diagnostics unchanged |

| Known pre-execution input or policy refusals allow a corrected command; a known missing capability retains the existing permitted fallback. Neither grants policy bypass or effect replay. Repeated unresolved refusals stop, and uncertain execution or persistence blocks the next model call immediately. | [unit] src/core/harness/toolRecovery.test.ts::run-owned tool recovery::allows correction after a definitive %s check refusal; ::allows permitted fallback after a known missing check capability but stops repeated refusals; ::blocks model admission after %s check uncertainty |

| A definitive pre-dispatch budget or stop refusal remains a no-start fact and retains the run's normal ending. It is neither unknown execution nor a task failure; genuine failed checkpoints and uncertain effects retain their holds. | [unit] src/core/harness/toolRecovery.test.ts::run-owned tool recovery::keeps definitive command-budget refusals out of task failure recovery |

| An uncertain recorded check publishes its bounded, redacted failure evidence under the original call id before tool recovery can stop the harness. The original call ID, command hash, outcome kind, unknown reason and typed infrastructure reason precede long command or output excerpts. The full receipt remains canonical; its note excerpt can be truncated. The closed execution diagnostic remains ahead of the excerpt. Metadata refusal retains its structural evidence without inventing a command receipt. A late or absent native result cannot erase this note. The original hold still blocks new dispatch; arbitrary exception prose never becomes a diagnostic. | [unit] src/core/harness/pi/relay.test.ts::hosted %s check lifecycle::retains the original check failure before recovery stops native result delivery*; src/core/harness/pi/relay.test.ts::hosted %s check lifecycle::retains a closed metadata refusal before recovery without inventing a command receipt; src/core/checkExecution.test.ts::recorded coding checks::retains a typed command failure on durable replay without dispatch or prose classification |

| Retained check notes redact each receipt text field before JSON serialization and cap the assembled note without another whole-line redaction. Cookie headers in the command or captured streams cannot erase the receipt identity, unknown outcome or typed reason. Cookie values remain hidden and the recovery hold remains in force. | [unit] src/core/harness/pi/relay.test.ts::hosted %s check lifecycle::retains structural failure evidence when %s contains a cookie header |

Criterion	Proof
Canonical readers reuse the producer's strict schemas, verify the stored phase key and reject malformed, duplicate, foreign or forged receipts without reconstructing absent identity.	[unit] src/core/checkInspection.test.ts::canonical check selection::*; src/core/checkInspection.test.ts::check archive refusal::*
runs.check and runs.settlecheck select the original run/call/phase through ordinary visibility, compare the full frozen resource and thread before authorization, keep private workers hidden, and wrap saved output as untrusted. A completed canonical result remains displayable after Resident evidence is pruned.	[unit] src/core/commands/runChecks.test.ts::recorded check commands::*
Runtime requests contain only the selector. The final receiver observation is bound to the one authorized source through a response identity hash; changed identity, missing binding or malformed output refuses without a retry.	[unit] src/execution/runCheck.test.ts::run check runtime adapter::*; deploy/cloudflare-resident/checkOperation.test.ts::recorded check receiver::*
Retained terminal check inspection and proof-backed retirement work on the containing deployed release.	[gap] Source tests do not establish deployment or authorized live original-operation acceptance.

| A claim or promotion under the same run ID preserves the full original authorization resource of current live or archived checks. Changed channel/visibility refuses before mutating phase, metadata or source bytes; identical resource remains supported. | [unit] src/core/runLedger/inMemory.test.ts::archived check claim authority*::*; src/core/runLedger/inMemory.test.ts::live check claim authority::*; deploy/cloudflare-memory/runLedger.test.ts::archived check claim authority*::*; deploy/cloudflare-memory/runLedger.test.ts::live check claim authority in real SQLite::* | | A restart without resume context hydrates the check producer from canonical restored state before tools run. Completed receipts permit new checks and replay only their saved result; unknown receipts still block execution. Unreadable tracked history stops tool recovery without fallback authority. | [unit] src/core/dispatch/runLoop.test.ts::tracked Review command receipt binding::hydrates %s checks from canonical state on a same-ID request-only restart; src/core/dispatch/runLoop.test.ts::tracked Review command receipt binding::holds unreadable tracked check history at the tool boundary without fallback authority |