System Path Simulation

Use this when you need to know whether a change will work in the real system, a path has not been walked by a real actor, or a possible blocker remains unresolved. This is not tied to launch or to failure. Take the smallest real slice around the question: start where the change takes effect when that directly answers it, or one or two production transitions before it when the joins are part of what must work. A fresh unused project on a familiar unchanged path does not need it.

Revamp log

This skill is being rebuilt from observed simulations, one dated entry per run. Read the entries before choosing a case. When a few simulated runs stand behind them, overhaul the skill around what they show and delete the settled entries.

• 2026-09-15, gate overhaul (PR #683). A seeded round starts from a copied campaign that has already passed the fresh-project path, so it cannot measure what the overhaul changed: time to the first preview, the rows each refusal shows, adoption. There the real run is the condition; cases/real-run-watch.md is the new case. A steward subagent per condition shares the account's session limit: one 429 (session limit, resets 14:20) ended the audit subagent and the run's Builder in the same minute; a fresh token on the same account died the same way at 13:49. The launcher now runs one minimal Builder-slot turn before the gate and refuses with the provider's reset clause (main 69ed55b5b). Stewards went; the launching session ran its own conditions. Seeded rounds default the Built slot to scripted, so the Builder → Built Harness handover stays unexercised until a real battery; when the question is the measure stage, run --built live.
• 2026-09-29, stewards return on an account of their own. The 2026-09-15 death was one account carrying the steward's condition, the run's Builder and the parent at once. The operator's numbered accounts in .accounts/ separate them: a steward's condition spends an account no live run and no parent is spending, so its 429 ends only itself. The rule is below.
• 2026-09-30, three truss and esp32 stewards spent their first minutes on hand steps: a seed refused 3,466 tool-tree references, and a second five-minute --relocate run left them naming the main checkout's tree; Built pins unlike the record turned a rebuild into a measure; CLAUDE* variables were unset by hand; a transcript copy was lost to the CLI's close stub. Helpers own each step now.
• 2026-10-01, the limit-line arm of PR #122 from esp32 campaign -20 at its partial battery i14. Two seeds and two captures, no model turn. Neither first prompt carried the line: the selector measures a republished product before it builds, so with --built no-solve the newest row is a refused claim (DISCRIMINATION_ACCEPT_REJECTED, 19 invalid control receipts) and a line that speaks for the latest battery alone cannot fire; and the readout set every carried battery aside, since products recorded before experiment-authoring/v2 (2026-09-29) are not resumable, by design. A condition on how a Builder answers a battery needs a position recorded after that cut whose seed measure is reproduced (a scripted solver over the recorded artifacts) or solved live; every esp32 campaign after the cut is an Opus full pass, so the arm's trigger has not yet existed for Opus 5.5 there. pick-run.mts should say the cut. The same evening, three live segments from that position (run-segment.mts, Opus 5.5 medium, 12 turns, 30-minute turn wall, the readout rendered from the recorded counts and labelled authored): the arm's limit line, the control without it, and B′ with i14 authored as a full pass. The arm and the control did the same thing: kept the failed task byte for byte, named its stand-in check wrong and widened it (probe.ts), and added 14 tasks to reach the 25 the task-count line asks; the control read the fail from the families line (esp32-oled 0/1) and the traces. B′ removed all 11 tasks and authored 25 new ones over a new host stand-in. So at this position the line changes nothing: the Builder's branch follows the readout's reading of the record, and the arm adds no second reading. The seed's cost: run-segment.mts copies no .toolchain, so each Builder rebuilt a 10 GB arduino tree and lost its first 30-minute turn to the wall, two of three a second; a segment whose actor compiles needs a cloned tree or a wall above the install.

Standing triggers

These change classes warrant a simulation; each earned its place in a recorded session (2026-09-01: four stewards, two changed a conclusion).

The change looks like	Steward and question
An interface where the tests use doubles — backend signal contracts, vendor/pi-claude-bridge, transports	One layer-walk over the real sources: does each field/signal the change reads actually arrive there? Both recorded production defects (the one-hour settle fallback and Claude's MCP-prefixed tool names; earlier, the acceptance-close false warranty) were green-tested wrong joins of this class.
A removed default, backstop or widened guard	One steward asking "what fires now that this doesn't?" Removing the six-hour session cap uncovered a hidden one-hour DEFAULT_TURN_SETTLE_MS that fired two hours before the new wall could start.
A fix that claims to repair a specific past run, before the next paid run	One past-run-replay over that run's actual recorded bytes (claims, packets, terminals), plus the nearest hostile mutation in a scratch copy. Minutes of replay against run36/run39/run40 bytes beat another dead run discovering the miss live.
A recorded position whose next controller round is the question	One seeded-condition: seed with seed-campaign.mts, capture the first prompt, run one round through run-condition.mts with the slot under test live, probe with host-panel.mts. The 10 September Astra condition answered handover, admission and scope binding in one 354-second native turn; its helper is now the runner.
A changed Judge or Epoch Reviewer prompt, schema or orientation	One review-replay: the live Judge over recorded cases with judge-replay.mts, then the live reviewer over the resulting contested rows with review-settle.mts. On 2026-09-15 the first replay refuted the chosen position in six minutes (both recorded disputes were the Judge's arithmetic) and the second settled a genuine veto against the harness.
An unlanded stack before a paid run	One triage, no model: list every decision change in the stack with no live exercise, give each one condition, and order them so the cheap condition can cancel the dear one — one fact, then layer walk, then deterministic replay, then the eight-task one-iteration rehearsal, then a live segment. On 2026-09-01 two of four listed conditions settled without a model: a writer/reader join (below) and a revert proved byte-identical to the tree that had created claims.

The opening rule still wins: a change fully bound by a focused test on the real code path, and a question only a recorded live run can answer, get no steward — mark the second unobservable rather than manufacturing a finding.

A cleared deterministic condition is not finished until its owning test file carries it: the gate must bind the join the condition proved, or the next change reopens the question. The recurring shape is two tests that each hand-roll the same record — the watchdog readiness file on 2026-09-01 — so neither runs the real writer against the real reader. cases/layer-walk.md names the method.

A steward runs its condition on an account of its own. A steward subagent may own one condition again (operator decision 2026-09-29), but only when that condition's model calls go through a numbered account that no live run and not the launching session is spending. Without such an account, the launching session runs its own conditions, as it did from 2026-09-15.

• Choose from .accounts/usage. Run it from the main checkout. It prints each numbered account's 5-hour and weekly windows and prints no token. It marks the account behind the plain CLAUDE_CODE_OAUTH_TOKEN, which is the one launch-run hands to live Claude runs by default. Pick an account that is:

  • not the plain one, and not the one a live run was launched on with .accounts/launch claudeN (scripts/credential-use.mts names the credential file each open run's launch receipt holds);
  • not the one the launching session runs on;
  • showing neither rejected nor a window near full.

  The reading on 2026-09-29: claude1 at 3 % (5-hour) and 6 % (week), claude2 as the plain token at 88 % of its week, claude4 rejected.

• Pass the account as an env file. Run every model-calling script as bun --env-file=.accounts/claudeN.env .claude/skills/system-path-simulation/scripts/<script>.mts …. Every slot resolves its credential through loadRepoEnv(repoRoot, Bun.env), and there the process environment wins over the checkout's .env. So this one flag moves the Builder, Built, Judge and review slots together. A shell that already exports CLAUDE_CODE_OAUTH_TOKEN beats the file, so check that it is unset. run-condition.mts records it and names open runs sharing it.

• The runners drop the launching session's variables. run-condition, run-segment, review-settle and judge-replay strip and print each CLAUDE* name the product does not read (CLAUDE_EFFORT, CLAUDECODE, …; session-env.mts), which it would hand on to the Builder's CLI. A paid launch starts under env -i and never has them.

• Treat the files as secrets. .accounts/ is local and untracked (.git/info/exclude). Each claudeN.env holds that account's token under CLAUDE_CODE_OAUTH_TOKEN, the one name the launcher reads, and is written by .accounts/launch claudeN.

  • Never print, copy or cat these files, and never put a token on a command line.
  • If a file is missing, report it. Do not rebuild it from .env by hand or look for another.

• The steward's own session still spends the parent's account. Only the condition moves, so keep the steward's reasoning short and let the condition's calls carry the spend.

• The steward's shape. One steward per condition, at most four in parallel, and none spawns further agents. Each writes its trail to the report path it was given, so a dead steward loses nothing the parent cannot read. The steward briefs the parent with the account it used and that account's .accounts/usage line before and after.

The actor under test keeps the run's own condition — for the standard Opus run that is claude-opus-5-5 at medium on the Builder, Built and review slots, launch-run's opus preset, which run-condition.mts --preset opus pins — and neither the session nor a steward ever stands in for it (operator decision 2026-09-01). The unpinned Claude default in src/backends/resolve.ts is still claude-opus-5, so a runner that takes --backend claude without a preset serves a different actor.

Rules that hold for every case

If a gate or test already binds the thing you are about to check, you are finished before you start.

Spend alone is not the criterion (operator decision 2026-08-16, restated 2026-08-17: "we do not care about the money, only indirectly by checking if the model is doing sensible things; time is more important"). Use a live behavioural condition when it can change the decision and the host already has action authority. Keep the epistemic discipline: one stubbed thing, one variable, and stop at the decisive fact because work past that point confounds the answer.

Prefer a new discriminator to an idle continuation. A condition asks a new question; a further turn often repeats an answered one. Of four conditions run on 2026-08-17, the control changed the conclusion. This is evidence for good experimental judgement, not a required condition count.

Keep independent live-model conditions independent. Give each one exact head, one evidence packet, one question, one scratch directory and one report path, as its own background command, and keep every other model-visible byte identical. Check each load-bearing claim against the named bytes before routing it.

Seed as late as the question allows. The segment starts at the last stage whose output the question does not depend on; everything earlier is paid for and confounds nothing. Copy the required recorded source bytes into an owned fixture before invoking a mutating production helper. Inspect linked runtime and tool trees too: a copied workspace can still write through .toolchain into the original run, outside its fingerprint. Use owned tool fixtures for startup and resume probes; keep real recorded trees read-only. A republish opens a fresh epoch, so the source epoch's MEMORY.md and SCRATCHPAD.md do not follow it (production carries notes only when an epoch supersedes one); the seed names their sizes, and the stated delta must too.

Optional: give the condition an active tool tree. Do this when the actor will compile, run or rehearse through the product's tools. Without a tree it spends its wall reinstalling, and the condition ends up measuring installation instead of the question. Skip it when the question is prose or planning, or when a reinstall is cheap. On 2026-09-30 a truss Builder with no recorded tree reinstalled OpenSeesPy from the uv cache in 6 seconds; an esp32 tree is 12 GB of arduino cores.

• Seeding already clones the tree. seed-campaign.mts republish clones the selected product's tool tree into the owned seed with APFS clonefile and rewrites the references inside it to the seed's own tree by rule, under every spelling of the source; --relocate now answers only references outside the tool tree.
• Check the tree exists before relying on it. scripts/tool-tree.mts --campaign <dir> says whether the selected product's recorded toolTree still resolves and lists the family's other trees; every epoch tree of the truss campaign …-3fd52f9e-29 was swept on 2026-09-30. The seed and run-condition.mts both warn of a gone tree, --tool-tree <tree> seeds a family tree instead, or let the actor reinstall and record that it did.
• Clone anything the actor may write; do not link it. A symlink into a recorded run lets the condition write through to that run, and the audit refuses it as an escape. Link only to a host file that no recorded run owns and the condition cannot change, such as ~/.bun/bin/bun.
• Give each parallel condition its own seed. A campaign holds one .controller.lock, so two conditions or live arms from one position each need a seed; --as-slug a,b,c seeds them in one call. The esp32 ablation arms of 2026-09-30 were three seeds of one campaign.
• Write it in the trail. seed.json records the tree's source (toolTreeSource); add its size and whether the actor reinstalled anyway, which is a finding about the seed, not the product.

Choose the production owner before the helper. A session measures authoring, a Builder campaign also measures continuation and admission, and a full run adds measurement and routing. Read the actual exports and helper flags at the measured revision; a familiar script name does not prove that it still mounts production tools or supplies the current read grant and system prompt. For admission or semantic comparisons, read authoring-comparison.

Fifteen turns is the maximum budget (operator decision 2026-08-19, replacing the ten-turn limit from 2026-08-17). This is the whole segment's model-turn ceiling, not a tool-call limit: one turn may contain many tool calls. A condition may request fewer turns but never more. A segment that cannot answer inside about fifteen turns is badly staged, not under-funded: seed later and ask something narrower. turn-budget-reached is a result to read, not a failure to retry. Keep any smaller authorised bound. Turns, tool calls, submissions and elapsed time are separate: one native turn can contain six submissions and hours of real compiler work. Record progress and settlement at their own boundaries; do not add turns, nudges or a new source revision to an active condition. An explicit wall limit is a separate part of the condition.

A settled actor ends the step. A continuation that calls no tool closes the step as step-settled. On 2026-08-17, 15 of 22 turns across four conditions were continuations that called nothing and answered "already complete", each still re-reading a transcript that had grown all segment — the idle turn sent 49% more input than the working turn before it. A stage with more to do needs a continuation carrying a reason (--continue-file), not an empty nudge. Spend reads as a signal here rather than a limit: a condition whose turns cost a lot while its trail shows no tool calls says the actor stopped working.

Read the results before starting anything else. The recorded failure of this script is an unread answer rather than a wrong one: four conditions finished while their pre-registered predictions sat unresolved. The script closes with an UNRESOLVED line naming each P<n>. Resolve them against the trail and the workspace, and append each resolution with scripts/predictions.mts --resolve; --unresolved lists what is still open.

Scout every prediction to its bytes before the actor starts. For each P<n>, name three things: the surface the chosen runner mounts that can produce the observable, the recorded file where it lands, and a reader already shown to see it on one known positive. If any is missing, the condition cannot prove the prediction however long it runs. On 2026-09-15 a census condition went through run-segment.mts, which mounts no gate, and a status probe counted a process name the suite never started. It ran 78 minutes and 70 authoring calls, then resolved all three predictions untriggered. run-segment.mts now refuses predictions naming a gate, census, F2, adoption or battery before any backend opens (--accept-unreachable "<reason>" keeps a deliberate absence question); route those questions to run-condition.mts. A monitor's first tick should find a positive, not only zeros.

Pick your case, then read it

Classify the question against the table, read the case file (or files) under cases/, and follow it. One question usually needs one case; a batch of conditions may need several, read in the order the table lists them, because the cheaper case often cancels the dearer one. Every case uses the position rules below.

The question looks like	Case file
One fact: which branch, value, identity, which version the wrapper runs	cases/check-one-fact.md
Will an actor follow this instruction — and can the stack under it carry it?	cases/layer-walk.md (always before a live condition)
Does this path hold end to end with one stubbed step?	cases/scenario-stub.md
What does the real model do from this position, in a few turns?	cases/live-segment.md
Can the Builder reach admission, repair a semantic gap, or improve under another model condition?	cases/authoring-comparison.md
Seed a recorded campaign and run one real controller round with one slot live, the rest scripted or off	cases/seeded-condition.md
Does the whole runtime hold: controller, wall, verifier, record?	cases/seeded-project.md
Compare two trees or conditions on whole runs; rehearse a prompt on a full run	cases/fullrun-conditions.md
Does a fresh project on this head reach its first preview, adoption and the Built Harness?	cases/real-run-watch.md
Two or three past runs are named: which to analyse, and how to re-run it here	cases/past-run-replay.md
What the live Judge or Epoch Reviewer now decides from a recorded case	cases/review-replay.md
"The brittle angles", "what would break", across several runs	cases/brittle-angles.md
A final test of a large PR stack: which single PR carries each error	cases/stacked-prefix-groups.md

A past run beats an authored position. Before writing a situation by hand, run scripts/pick-run.mts over notes/runs/ and take the nearest recorded one; the position section below says how to derive the rest from its recorded bytes.

Derive the position, and keep your hands off the outcome

Every shape needs a position: where the actor stands, which bytes it holds, what already happened. The same hand writes the position, the conditions and the verdict, so this is where a simulation stops measuring the product and starts measuring its own prose.

How much of the position is real

A position is four separable facts, each derived or authored on its own:

• the tree — campaigns/<name>/epoch-*/workspace/, straight into --seed-dir;
• the model-visible text — the contract and framingDigest in epoch-*/builder-session.json, so a seeded kickoff is proved byte-equal rather than asserted;
• the controller state that put the actor here — controller/<fullrun-*>/opening.json and terminal.json, plus the recorded case rows for that checkpoint;
• the history the actor is told it lived — the misleading part. A Claude slot's own transcript lives in $TMPDIR/ana-claude-cli-*/projects/<cwd-slug>/*.jsonl only while its session is open; scripts/condition-evidence.mts keeps each state of it during a live condition, and a past run's epoch-*/builder-prose*.jsonl keeps only the words. scripts/position-packet.mts copies a transcript's last three to five exchanges verbatim — tool calls and results — under a summary labelled as authored, so only the summary is yours. Ten exchanges drown the situation (operator decision 2026-08-23). A Codex slot leaves a rollout under ~/.codex/sessions in another shape; there the history stays authored and labelled.

Deriving three and labelling the fourth beats a whole position hand-built for coherence. Label them where the predictions are written: a finding is as strong as the weakest part the behaviour depended on.

Usually no run stood exactly here, and then the quantity is the delta to the nearest real position: one battery earlier, eight tasks instead of 25, a rebuild advice packet the real run had settled. A delta you cannot state in one line means the position was decorated rather than derived. The condition is part of it — four conditions on 2026-08-17 ran at --effort medium and low against a run that pins higher, which is a different actor rather than a cheaper one.

Two traps run the other way. Real bytes are not automatically the right bytes: seeding from a run that predates the change under test measures the old product. And a position no completed run has reached raises reachability before behaviour — one recorded pair spent 910 and 431 seconds landing twice on the same verifier-required terminal, answering reachability by accident.

When the block and the bytes disagree, the behaviour is a response to the story. The climb condition of 2026-08-17 declared a frozen adopted climb round over a seed its own predictions file records as the w28 workspace "standing in as" one, shared with three other conditions.

Whether the position hands over the answer

Production puts an actor in a situation. A seeded position tends to hand it an assignment instead, and the recorded uses show four ways that happened:

• An imperative production never sends. "Decide and take your next action now" closed all four Builder positions of 2026-08-17; "then stop: report what you set up" closed the toolchain condition of 2026-08-16.
• A named target, which turns a propensity question into a capability one. One condition asked whether the Builder can reach the network from its walled workspace, and its position told it to install PlatformIO. "Can, when told" and "does, unprompted" are different findings, and a run usually depends on the second.
• The falsifier stated in the subject's own prompt. "One more byte-identical submit ends this session" stood in the position of the condition predicting the session would stop resubmitting.
• A prediction whose caught is compliance. P1 and P7 that day both resolve caught when the session does what the steering text quoted in the same prompt asked; neither condition could fail. P2 is the shape that pays — it asked whether the edit landed on the surface the finding named, which the prompt did not say.

The line that holds: production constrains scope, it does not assign the next action. A position may name the files writable this round, because production does. It may not say what to do with them, in which order, or when to stop.

Steer by transition, not destination

The useful behavioural shape is A → B → {C, D}:

• A is the actor's settled past, derived from recorded bytes: what it built, what was measured and what decision boundary it reached.
• B is the new controller-owned situation: the selector moved, a scope opened, or a public fact became available. Append B at the boundary where production would deliver it, normally through the real handover rather than by putting future history in the first kickoff.
• C and D are plausible outcomes. They belong in the campaign-owned frozen prediction/event ledger and its advisory simulation projection, never in model-visible text. The expected or "right" answer must not appear as a named target, suggested mechanism, falsifier or stopping instruction.

Write the transition as ordinary continuity: "You were in A. The controller has now selected B. The workspace is exactly as that completed stage left it, and this round has scope S." This gives the actor enough orientation to proceed without assigning the action it should take. Use the real controller's reason and contract where they exist; an authored transition is labelled as such.

For an authored A or B, pre-register and run three conditions when the question is important enough to change production prose:

1. Natural transition: A followed by B, with neither C nor D named.
2. Context-minus control: the same bytes and contract without the authored transition sentence.
3. Counterfactual transition: the smallest legitimate B′ that should change the correct branch.

The first pair measures whether the transition steered behaviour. The counterfactual measures whether the actor read its meaning rather than merely following its vocabulary. If B and B′ lead to the same branch, do not claim contextual reasoning. Keep all other model-visible text, model pins and tool contracts identical, and record each prompt digest separately.

Re-reading your own position for this does not work, since you wrote the sentence. Two checks instead: every imperative in the position must be quotable from a production surface, and one condition runs with the sentence removed — a behaviour that survives removal belongs to the product.

Say what you did not run

Pre-register the prediction rows before the first condition. Condition selection, dropped conditions and reruns belong to the campaign-owned frozen prediction/event ledger; this simulation note is only an advisory projection of those rows. predictions.mts --hash writes a local integrity checksum for the projection and refuses to replace it after the note changes. It does not create campaign authority, consume an allowance, choose an experiment or promote a result. A rerun or newly justified condition gets a new campaign prediction/event, not a silent edit to this projection. State the expected outcome and what would refute it. Include an expected-failure condition when the evidence supports one; a demonstration with no discriminator is not an experiment.

Scripts

All under .claude/skills/system-path-simulation/scripts/; each takes absolute paths and refuses a relative path or an unknown option.

Script	Duty
pick-run.mts	list recorded runs from notes/runs/ with ancestry, denominator and component facts for comparison
position-packet.mts	the last 1–5 exchanges of the actor's own SDK transcript, verbatim under a labelled authored summary, with the source digest
difficulty-watch.mts	the authoring sequence and submit rows from recorded builder-execution records, codes only
predictions.mts	--hash, --verify, --resolve, --unresolved on the prediction note
run-segment.mts, seed-kickoff.mts	a seeded live segment over the production backend
workspace-changes.mts	a workspace's changed paths and diffSha, counted from its seeding commit, since checkpoint commits move HEAD (--since HEAD for the view since the last one)
seed-campaign.mts	clone a recorded campaign into a fresh tree, or republish its selected product here under one or more new slugs (--as-slug a,b); symlink and absolute-path audit, the owned tool tree relocated by rule, seed.json; names what it could not carry (a swept tree, the epoch's notes), and --tool-tree stages another tree
tool-tree.mts	whether the selected product's recorded tool tree still resolves, its size, and the family's existing trees; --digest says which match the recorded digest
run-condition.mts	one real controller round over a seeded slug with each slot live, a scripted module, no-solve or capture; --preset as launch-run pins it; --capture compares a first prompt with an earlier capture; preflight of session variables, Built pin, tool tree and credential; wall, sampled process census, preregistration digest, report.json
condition-evidence.mts	a condition's live CLI transcripts and durable Builder records, kept under content names that never overwrite (--follow while live), a per-session tool tally and --grep over the prose
credential-use.mts	the credential file each open launched run holds, from its launch receipt; names only
judge-replay.mts	the live Main Judge over recorded battery cases under the current prompt; verdicts and every contested row
review-settle.mts	the live Epoch Reviewer over a scratch copy of a recorded battery and its Judge disagreements; the evidence and its public projection
host-panel.mts	valid, equivalent and hostile artifacts for one task through the real verifier host; fingerprint before and after
show-prompt-surfaces.mts	the exact model-visible surfaces and their digests

The build stage has one interface, HarnessBuildOptions.builderRuntime (src/run/harness-build.ts). Production binds the live transport; a scripted session bound there still runs the real submit, census, solvability and adoption path. test/full-run-scripted-loop.test.ts runs the whole controller loop through it with no provider, and test/helpers/scripted-builder-runtime.ts is the one scripted session both that warranty and run-condition.mts use. Do not hand-build a session, a seed clone, a product pointer, a wall, a process census or a host panel again: each has an owner above, and the recorded setup faults of 8 to 10 September all lived in hand-written copies of them.

Separate your script's faults from the product's

A simulation produces different kinds of refusal that can look identical on stdout. Classify the owner before attributing behaviour; repair setup faults and verify the repaired path within the existing authority before making a product claim. Recorded artifacts, all from simulations that were otherwise sound: a scratch tree with no node_modules above it failing as Cannot find module '@ana/agent-bundle'; a helper typed level: number | null = TARGET_LEVEL, so the "level omitted" scenario passed undefined and triggered the default it claimed to omit; a script that never passed expectedTasks, making its own silence read as a battery shortfall; a scratch copy that symlinked node_modules, which fullrun refused before any provider work; a probe that called the wrong export and failed before reaching the product fact at all; a seed exported with git archive and therefore without .git, which initWorkspace overlaid with the starter skeleton so both conditions rebuilt from placeholders while the note declared an adopted-product position (2026-09-13; run-segment.mts now commits such a seed as the root and verifies the bytes).

For every refusal you intend to report, name the production caller and confirm it passes the same arguments your script passed, from a tree set up the way production sets one up. If the real caller passes more, your scenario is not yet the production scenario. Preserve the failed attempt and classify its owner: simulation setup, shared product code, generated candidate, or provider/host environment. A repaired setup gets a new labelled attempt; do not fold it into a model's failure count. Reproduce a shared defect against unchanged candidate bytes when possible, then add the positive and nearest hostile case to its existing owning test.

Test the helpers without model spend

Run a changed script's owning suites through the prepared-worktree runner; none calls a model:

bun run test -- test/sps-*.test.ts test/system-path-simulation-*.test.ts test/full-run-scripted-loop.test.ts

One test/sps-<helper>.test.ts owns each helper, and test/sps-refusals.test.ts holds one row per declared option refusal: select only the ones owning the change. Bun never descends into this hidden directory, so test/test-discovery-completeness.test.ts refuses a suite written beside its helper. Zero discovered tests is not a pass. A prose-only skill edit needs frontmatter/link validation and diff review, not this runtime matrix or a paid model replay. A passing matrix is mechanism evidence for the helpers, not for the model behaviour a later condition measures.

Result

Return one evidence path and one result:

• blocking: the command would use the wrong branch or condition;
• cleared: the check proves the intended path;
• accepted-risk: only a paid run can decide it.

Return this result to the invoking agent. cleared preserves any existing authority but does not exercise it, schedule a command or choose the next experiment. The improvement loop or standalone host owns that decision and launch boundary.

A deterministic check never predicts provider behaviour, output quality or later runtime branches; for those, accept the risk or run the rehearsal in cases/fullrun-conditions.md, whose result is the prediction note with its resolution section, not one of the three words. For live conditions also report operational closure, semantic verdicts and prediction resolution separately. Preserve verified, unaccepted and non-result denominators; list unexecuted probes. A host-blocked condition can leave a prediction unresolved. Admission, a compiler exit and a passing generated control set each prove their own condition, not complete domain correctness.