Fix rehearsal capability checks and Codex preparation evidence

docs/architecture.md

@@ -470,13 +470,28 @@ digests cannot prove that a probe ran or succeeded.
 
 Optional private `preparation_evidence` binds native preparer records and the
 reviewed input file to this inventory. `preparation_evidence.py` checks the
-supported Codex native export for one complete, non-inherited legacy-history
-turn with matching plain-text user input. Changed or missing files fail verify.
+supported Codex native export for one complete, non-inherited turn with matching
+plain-text user input. Legacy exports carry full turns directly; paginated
+exports retain metadata plus every unfiltered full-item turn-page request and
+response through the terminal cursor. Incomplete chains, summary-only items and
+additional turns fail validation. Changed or missing files fail verify.
 Unsupported or absent records remain unavailable/unverified. The native thread's
 model field is not per-turn execution telemetry: neither a resolved model nor the
 entire historical context is claimed verified. These private records never become
 trial inputs or assessment content; validation does not authenticate a fabricated
 export.
+Ordinary historical rehearsal requires a fresh supplied history and reviewed
+contemporary inputs, not attestation of every hidden context surface. Verified
+input/completion facets support that bounded route despite the overall unverified
+label; unavailable model/ambient-context facets remain disclosed. Invalid input,
+inherited history or failed completion still blocks preparation. A stronger
+isolation or model-attestation claim requires the owner's explicit goal and its
+separate capabilities, rather than being inferred from a PR request.
+Codex preparation explicitly disables memory, hooks, plugins, apps, multi-agent
+features, web search and each configured MCP server for that process, verifying
+effective configuration before a model turn. An empty MCP table is not a reset.
+The private record keeps only sanitized control facts, not credential-bearing
+configuration; these controls do not attest every hidden context surface.
 
 Optional `context_requirements_file` freezes a declared native filesystem
 restriction separately from preparation provenance. The existing runner prepares
@@ -611,6 +626,11 @@ The modules below live in the skill's [`scripts/`](../plugin/skills/behavior-dif
   rewritten definitions still invalidate the whole target; `decisions.target_rejection`
   is reserved for that global failure. Extraction keeps the untouched raw response
   and reports `target_partially_rejected` or `target_rejected` as appropriate.
+  The extraction schema emits the decision chain before criteria reference it.
+  Criteria use final chain indexes and trial-local citations; action checks leave
+  output excerpts empty rather than quoting narrative as evidence of a call.
+  Output/source-consistency checks still require exact excerpts and the same
+  provenance validation. No invalid citation is repaired or silently accepted.
   With a scenario record, the complete frozen check set is mandatory. The report
   loader binds it to configuration, not model output; a conflicting persisted
   record or purpose invalidates the assessment without dropping observations.
@@ -1073,6 +1093,10 @@ Behavior Diff owns the distinction between supported-environment findings and
 stronger isolation claims, including historical preparation in a fresh context
 without prior discussion or outcomes. Required safety or evidence boundaries
 cannot be waived merely to complete a journey.
+If a sandboxed command tool cannot start a nested native sandbox, the host's
+authorized command-approval mechanism owns execution access to the unchanged
+preparation or runner command. Child sandboxes remain enabled. The skill does not
+enable automatic approval or grant OS permission from model-run consent.
 
 The handoff reuses existing authorization and requests only missing terms.
 When the goal is ambiguous, it first inspects the change, then offers 2–4
@@ -1087,12 +1111,21 @@ independent review. Behavior Diff supplies the capability gap and supported
 recovery; the handoff carries it through within authority or explains the
 remaining decision. It does not build a replacement launcher.
 
-The agreed question determines whether a simulation is sufficient or a live
-service is required. The first final answer leads with what to do with the
-change and why, followed by decision-changing risk and remaining required
-evidence gaps. Non-decision-changing methodology and detailed evidence stay in
-private links. A useful null result can complete the journey; missing required
-evidence or failed execution cannot.
+Behavior Diff maps the owner's question to claims before requiring capabilities.
+Ordinary instruction rehearsals test agent decisions using controlled modeled
+external services, disclosed in the initial proposal. Production instructions
+requiring an artifact or upload do not alone require real generation or a live
+service in the test. Real output quality, visual recognition and live integration
+claims still require their corresponding capabilities; they cannot be replaced
+by recorded simulated decisions. Missing capabilities block dependent claims,
+not independent authorized behavioral work. An approved real-output scope needs
+an explicit revised proposal before substitution.
+
+The first final answer leads with what to do with the change and why, followed
+by decision-changing risk and remaining required evidence gaps.
+Non-decision-changing methodology and detailed evidence stay in private links.
+A useful null result can complete the journey; missing required evidence or
+failed execution cannot.
 
 Explicit replay-only requests use saved evidence without new trials. Optional
 `replay.py` owns private snapshots, correction invalidation, confirmed revisions

e2e/README.md

@@ -59,6 +59,32 @@ An actual owner conversation must still exercise correction, evidence inspection
 and a gap, and record real takeover points versus their baseline privately.
 Helper checks alone do not establish acceptance, handoff value or live latency.
 
+### Capability-scope regression walkthrough
+
+After approval for model cost and data use, exercise these goal variants with
+synthetic instruction changes on each supported plugin host. These are manual
+acceptance checks, not CI or proof supplied by the replay helper:
+
+- **Ordinary behavioral rehearsal:** a change requires preparing an archive,
+  inspecting checksum results and waiting for human approval. The host lacks the
+  production archive service. Expect a proposal that names controlled simulation,
+  then preparation and trials of the decisions through recorded local tools;
+  do not require the production service merely because the source mentions it.
+- **Explicit real-output goal:** ask whether a real archive can be downloaded
+  intact from that service. If access is unavailable, expect a precise blocker
+  for that claim, not a simulated-download pass.
+- **Mixed goal:** test approval decisions and real service reliability. Continue
+  independent authorized decision checks while retaining the reliability gap;
+  never describe partial coverage as full completion.
+- **Previously approved real-output scope:** an unavailable capability may lead
+  to a concrete alternative proposal. No silent simulation substitution, new
+  model call or external effect outside the existing authorization.
+
+Check the proposal and recorded actions, not just the final answer. Record
+owner intervention and whether required real capabilities were correctly
+distinguished from modeled external services. Keep private evidence outside Git.
+
+
 ## Optional Jev manual verification
 
 Run `python3 tests/jev-test.py` first. Its injected transport and subprocess

plugin/skills/behavior-diff-live/SKILL.md

@@ -63,6 +63,14 @@ the sibling skill's bundled `scripts/` directory.
    Validate it with `python3 <behavior-diff scripts>/purpose.py <purpose file>`.
    Keep its canonical JSON for assessment; never include purpose, its path,
    or raw session context in either trial prompt. Do not revise it after results.
+   Before capability checks, follow the canonical reference's
+   [claim derivation](../behavior-diff/references/scenario-and-test-data.md#prepare-from-intent)
+   and [controlled behavior simulation](../behavior-diff/references/scenario-and-test-data.md#controlled-behavior-simulation)
+   rules. Disclose simulated external tools in the initial proposal for ordinary
+   decision goals. A production-tool requirement in the tested instruction alone
+   does not require a real-output trial; explicitly real goals keep their actual
+   dependencies and claim-level stops. Never turn simulated results into real
+   inspection evidence or real owner approval.
 
 2. **Build the variants** in a scratch dir, never in the user's repo:
 

plugin/skills/behavior-diff/SKILL.md

@@ -123,13 +123,22 @@ the single-role or two-agent path. Create the fixtures with
    **Historical context boundary.** Before deriving historical purpose, read
    the source-isolation rule in `references/scenario-and-test-data.md`. If this
    session already knows later history or previous trial outcomes, purpose
-   derivation and preparation must use the fresh context described there.
-   If that isolation is unavailable, stop; disclosure alone is not a substitute.
+   derivation and preparation must use the fresh supplied-history context defined
+   there. An unavailable fresh-session mechanism blocks preparation; unavailable
+   complete ambient-context or per-turn model attestation does not block an ordinary
+   supported-environment rehearsal. Preserve those limits rather than silently
+   upgrading a historical PR request into a stronger isolation claim.
 
    **Freeze the purpose before drafting or running trials.** Derive concise,
    distinct goals from the current conversation and the selected diff without
    asking the owner to restate their reason. Use one or two sentences per goal;
    keep separate goals separate, including behavior meant to survive a cleanup.
+   Distinguish the owner's comparison question from production obligations in
+   the instruction being tested. Do not infer a real-output goal merely because
+   that instruction requires a production tool. Before capability checks, apply
+   the reference's claim derivation: ordinary decision goals default to
+   controlled external-tool simulation, disclosed in the initial proposal;
+   explicit real-output goals retain their real dependencies.
    On both Claude Code and Codex, use the conversation already available in the
    current context, including supplied summaries; do not open host transcript
    stores, resume other sessions, or infer access to missing turns. The same
@@ -226,9 +235,14 @@ the single-role or two-agent path. Create the fixtures with
 
 2. **Prepare the scenario and data.** Before drafting anything, read
    `references/scenario-and-test-data.md` inside this skill's base directory
-   and follow its preparation recipe once. From the frozen goals, author a
-   neutral task, sufficient shared data, private per-case criteria, and the
-   sanitized scenario with frozen checks and required recorded sources.
+   and follow its preparation recipe once. From the frozen goals, derive
+   decision, execution-quality, and integration claims before tool dependencies.
+   Author a neutral task, sufficient shared data, private per-case criteria,
+   and the sanitized scenario with frozen checks and required recorded sources.
+   Follow [Controlled behavior simulation](references/scenario-and-test-data.md#controlled-behavior-simulation)
+   for equal, recorded interfaces that expose material outcomes without
+   enforcing correct decisions or supplying assessment answers. Choosing to
+   inspect through a simulated tool is not evidence of actual pixel detection.
    Keep private context outside every trial input. The helper validates and
    inventories your reviewed files; it never authors their meaning or proves
    that a required capability works.
@@ -243,11 +257,16 @@ the single-role or two-agent path. Create the fixtures with
    user to confirm the file, task, cost, or run mode. Do not mention trial
    counts, cost, or full versus fast modes during normal execution.
    First satisfy the privacy and sensitive-content approval boundary above;
-   automatic execution never overrides it. If the planned environment cannot
-   support a required capability or premise, stop and report it; do not silently
-   substitute a narrower test or fabricate approvals. Stop preparation workers
-   before launch, and keep the first result: no retuning or reruns to manufacture
-   a finding after seeing outcomes.
+   automatic execution never overrides it or a surrounding journey's approval
+   gate. Apply the reference's claim-level capability checks: missing required
+   premises stop dependent claims, while an unavailable production tool alone
+   does not block a decision claim already scoped to simulation. Report blocked
+   claims; do not silently narrow an approved real-output goal or fabricate
+   approvals. If changed scope needs approval, offer the reference's concrete
+   bounded proposal; do not re-ask an unchanged approved budget. Security and
+   historical-freshness gates remain mandatory. Stop preparation workers before
+   launch, and keep the first result: no retuning or reruns to manufacture a
+   finding after seeing outcomes.
 
    Use the reference's complete private handoff for both hosts:
    `prepare_shared.py prepare --handoff` for staged data or exclusions;