Make verification handoff own the path to a decision

.agents/skills/verification-handoff-prototype/SKILL.md

@@ -1,91 +1,87 @@
 ---
 name: verification-handoff-prototype
-description: Operates a local conversational handoff-to-decision replay with corrected goals and scoped evidence. Use when an owner explicitly requests the verification handoff prototype with a supplied change, context and local evidence packet; not for ordinary Behavior Diff trials.
+description: Carries an instruction change from owner-confirmed goals through review and authorized Behavior Diff verification to a decision-ready recommendation. Use when the owner wants to hand off verification of a change or PR without coordinating the agent's next steps.
 ---
 
 # Verification handoff prototype
 
-Answer whether the owner can hand off verification work and decide from credible
-evidence. This is a maintainer prototype, not the installed Behavior Diff skill.
-Use these same instructions on Claude Code and Codex; OMP may load this source
-path explicitly. Do not infer installed discovery or Spacedock adapter support.
+Own verification through a decision-ready result. Success means less owner
+coordination, not completion of a checklist. This maintainer skill orchestrates
+Behavior Diff; it does not replace its preparation, runner or evidence contracts.
+Use the same workflow on Claude Code and Codex. OMP may load this source explicitly.
+Resolve bundled files relative to this loaded skill, never the target repository.
 
-## Prerequisites and boundaries
+## Ownership and authority
 
-Use Python 3.10+ and the bundled `scripts/replay.py`; no dependencies or service.
-Read only the supplied change, discussion/documents and explicit case root.
-Do not search transcript stores, unrelated archives or the related reader study.
-Read private evidence only with permission; never send it to a new model/service,
-copy it into a tracked tree, launch a trial, change source evidence or publish it.
-Explain: fixed-evidence replay, not fresh verification, latency measurement or
-first-time intent inference. Disclose familiarity with the known case. Historical
-purpose remains frozen: corrected replay goals do not rewrite experimental intent.
-The production skill's automatic-launch and frozen-purpose contracts are unchanged.
+- Own discovery, planning, tool selection, preflight, execution, bounded recovery
+  and interpretation. Never ask the owner to select evidence IDs, design tests,
+  debug the harness or remind you to take the next agreed step.
+- Ask only for material goal corrections, unavailable domain facts, or missing
+  authority. Each interruption states the concrete decision, recommendation and
+  consequence. Continue useful independent work while awaiting that answer.
+- Before paid trials, obtain approval covering purpose, trial count, model/provider,
+  cost estimate or explicit budget, and outgoing data. Reuse approval within that
+  scope; changes to scope or budget need new approval. Editing this skill is not
+  run approval. Do not send private evidence to a new provider without consent.
+- No source edits, global configuration writes, publication, adoption or merge are
+  implied. Accepting findings or answering a study question records a decision
+  only. A separate explicit operational request must name the action and target;
+  clarify ambiguous replies in an evaluation context before external action.
+- Keep private inputs/results outside Git trees. Do not search transcript stores
+  or unrelated studies unless explicitly requested. Do not persist raw owner
+  responses by default. Familiarity and reused evidence must be disclosed.
 
-For an offline demonstration use `fixtures/synthetic.json`, explicitly invented.
-For the real walkthrough prepare the private packet yourself from permitted local
-sources, with source coordinates, reused labels, provenance and limits. If missing,
-report that prerequisite; never substitute synthetic findings for the real case.
+## Workflow
 
-## Conversation
+1. **Understand the change.** Inspect the selected diff, relevant unchanged rules
+   and available discussion. Pin revisions and source paths; prepare historical
+   inputs through Behavior Diff's supported provenance and isolation procedure.
+   Do not require the owner to assemble an evidence packet.
+2. **Confirm the question once.** Propose concise intended outcomes, preserved
+   requirements and bounded scope with explicit/inferred sources. Distinguish
+   added rule value from reliability in the owner's current environment. Reuse
+   prior confirmation; ask only about material uncertainty. Keep study questions
+   out of this gate. Goal corrections require reassessing affected evidence.
+3. **Review, then prepare verification.** Inspect instructions and saved evidence.
+   Review completion is not verification completion. For changed agent behavior,
+   proceed directly to preparing a Behavior Diff comparison; do not wait for
+   “now run Behavior Diff.” Existing evidence can satisfy the question only when
+   revisions, conditions and coverage match; explain that conclusion. Report a
+   material ambiguity without editing the source or silently testing a repaired
+   version. Preserve the agreed question unless the owner explicitly changes it.
+4. **Preflight before spending.** Load the available `behavior-diff` skill and
+   follow [execution handoff](references/execution.md). Own fixture preparation,
+   host compatibility, scenario reach and confound checks. Present any missing
+   run authorization as one concrete bounded proposal, not an open-ended menu.
+5. **Run and assess.** Once preflight and authorization are satisfied, launch and
+   follow through to raw actions, returns and artifacts. Separate setup failures,
+   missed cases and unavailable assessment from behavioral failures. Recover
+   within the approved boundary; never rerun merely to obtain a difference.
+6. **Return a decision-ready result.** Lead with retain/revise/hold and why. State
+   what changed versus Before, what stayed intact, what remains unknown, and
+   whether additional instructions showed added value. Link inspectable evidence
+   after the conclusion. Equal outcomes mean no observed added benefit under
+   these conditions, not proof that a rule is universally unnecessary. Simulated
+   behavior does not prove real-service reliability. Do not wait for the owner
+   to ask what the report means. Do not merge.
 
-1. Before showing results, use the supplied context to propose the modification
-   intent, preserved requirements, bounded evidence-review plan and limits. Label
-   each goal explicit or inferred with its source. Ask only about material
-   uncertainty: recommend a bounded option, allow none-of-the-above/free correction.
-   Do not ask the owner to select evidence IDs, design tests or repair mappings.
-2. Capture the owner's usual verification approach and remaining question in their
-   own words during this same walkthrough. Do not assume their bottleneck or invent
-   a response. Record observations privately only with consent; no raw transcript
-   persistence by default. The helper stores only goals, reviewed bindings and choice.
-3. Initialize the snapshot with your proposed goals. Apply exact owner corrections,
-   then confirm the current revision only after actual confirmation. Do not treat
-   a helper success as owner consent. Continue directly to evidence review/results
-   without requiring another “please continue”. A correction clears that goal's
-   support, confirmation and prior decision; unchanged goals retain their support.
-4. Review records against each *current exact requirement*. Bind supported or
-   contradicted observations only with scoped citations, a reason and scope.
-   Matching words do not establish semantic equivalence. Missing support stays
-   unverified with a concrete next verification step; do this mapping yourself.
-5. Request the confirmed result. Lead with findings, reasons, limits and decision
-   consequences, then offer exact read-only evidence entries. Distinguish
-   preservation, case reach, environmental blockers and recovery. Name reused versus
-   synthetic evidence; distinguish saved authors' interpretations from inspected
-   action/return/artifact slices. Do not claim whole-flow/service coverage from a slice.
-6. Let the owner inspect evidence, correct again, accept the stated limits, revise,
-   or request a bounded additional-verification proposal. Record only that choice;
-   “accept” never adopts, merges, changes files, runs models or contacts a service.
-7. With consent, privately record each actual takeover, trigger, work, observable
-   attention/wait burden, and necessary owner choice versus avoidable agent work.
-   Ask what decision is now possible, what still needs checking and which remaining
-   burden is most costly versus their baseline. Select the next experiment from
-   that answer. Negative/inconclusive value is valid; praise is not value evidence.
+## Completion and blockers
 
-## Helper protocol (host-operated, not owner homework)
+Finish with the bounded question answered, or an evidence-backed blocker naming
+what failed, what was tried, what remains unverified and the smallest recommended
+resolution. Missing capability is not permission to fake a worker or shrink scope.
+An intermediate review, helper result or successful process exit is not completion.
+Keep the exact run handle and private continuation context for interrupted work.
 
-Create a private directory outside **all** Git trees (mode 0700); snapshot files
-are mode 0600. Keep private packets there too. Run from the repository root:
+After delivery, optional feedback may ask what coordination the owner still had
+to do. Do not require an interview to finish. Distinguish necessary owner choices
+from avoidable reminders, debugging and interpretation. Never invent time saved.
 
-```sh
-python3 .agents/skills/verification-handoff-prototype/scripts/replay.py \
-  --state "$PRIVATE/session.json" --root "$CASE_ROOT" <<'JSON'
-{"action":"init","goals":[{"id":"review","text":"Stop for human review.","basis":"inferred","reference":"Supplied change","next":"Inspect the final stop and adoption actions."}]}
-JSON
-```
+## Explicit saved-evidence replay
 
-One JSON action on stdin per invocation, one JSON result on stdout; errors go to
-stderr with exit 1. Every action except `init` and read-only `show` requires `revision`.
-Use `show` to recover it; stale calls fail rather than silently rebase. Commands:
-
-- `correct`: `id`, exact `text`; `replace`: complete `goals` list, clears all support.
-- `bind`: `id`, `status` (`supported`/`contradicted`), `origin` (`reused`/`synthetic`),
-  nonblank `reason`, `scope`, and `citations` list of `{path,start,end}` objects.
-  Paths are relative to the supplied root; line ranges inclusive, at most 120.
-- `confirm`, then `result`: no extra fields. Changed/missing citations become gaps.
-- `evidence`: `citation` object; prints numbered source lines without execution.
-- `decide`: `choice` (`accept`/`revise`/`request-verification`); requires the current
-  result. Any correction returns to confirmation/review; never relabel old results.
-
-Keep the runnable private packet and a concise walkthrough handle for gate review,
-not a fabricated owner transcript. Helper smoke/tests establish mechanics only;
-AC-1/AC-2 need actual owner interaction and AC-3 remains owner-dependent.
+When the owner asks only for replay or forbids new runs, review the supplied
+evidence and identify gaps without launching trials. Use the optional
+[replay helper](references/replay.md) for revision-bound evidence mapping.
+Its fixed-evidence result describes that subset, not the whole verification
+journey. `fixtures/synthetic.json` is an invented helper demonstration, never
+real verification evidence. The helper is not a prerequisite for live comparison.

.agents/skills/verification-handoff-prototype/references/execution.md

@@ -0,0 +1,96 @@
+# Execution handoff
+
+The host owns this work. Do not expose helper setup as owner homework. Load the
+available Behavior Diff skill once and retain its exact base and version. In a
+Behavior Diff development checkout, use its canonical `plugin/skills/behavior-diff`
+source; elsewhere use the discovered installed skill. Never silently mix versions.
+Missing tooling is a concrete prerequisite to resolve or report, not permission
+to invent a substitute runner.
+
+## Prepare a meaningful comparison
+
+- Follow Behavior Diff's historical source isolation, purpose derivation, scenario
+  preparation, freeze and launch contracts. Keep this conversation's review
+  conclusions and prior results out of a fresh historical scenario preparer's
+  context. Current review goals never rewrite historical experimental intent.
+- For a PR, prepare supported Before/After file inputs or isolated replay fixtures
+  from pinned revisions. Preserve companion-file mappings and disclose the tested
+  scope. Never flatten a multi-file change into an unsupported whole-PR claim.
+- State privately what observation would distinguish added value, preservation,
+  regression and insufficient evidence. Inspect existing requirements first;
+  Before may already require the desired behavior. Do not weaken Before.
+- Use neutral tasks and sufficient shared data. Do not supply the new instruction
+  as a task hint. Verify that each planned case can reach its decision point;
+  an earlier approval stop can make a later case unreachable. Do not bypass a
+  preserved approval gate to force coverage.
+
+## Route by the behavior that must execute
+
+Distinguish an application's runbook decisions from actual workflow-engine state
+or inter-agent handoffs. A mention of a worker or gate is not evidence that a Go
+source project is needed. When Behavior Diff directs you to its Spacedock
+reference, inspect the rule and fixture prerequisites before invoking its builder.
+Do not apply a source-repository fixture to an unrelated application repository.
+
+If the loaded skill requires a fixture that cannot represent the requested
+behavior, report that specific contract/capability mismatch with a recommended
+resolution. Do not silently ignore the downstream contract or replace a real
+worker handoff with a scripted reply. A general decision scenario is valid only
+when it answers the agreed question; narrowing away a real handoff requires owner
+approval. Do not ask the owner to diagnose the mismatch.
+
+## Check compatibility and confounds before launch
+
+Inspect effective subprocess settings, not just the interactive session's model.
+Check host/model compatibility, available tool semantics, authentication and
+output locations without printing secrets. Use documented process-local settings
+and disposable locations; do not change the owner's global configuration,
+permissions, trust entries or memory. Check automatic host writes too. If the host
+cannot respect that boundary, stop before launching and explain the prerequisite.
+
+For incremental rule value, isolate unrelated memory and instruction injection
+and prevent direct tool reads of those sources. For current-environment reliability,
+keep the intended environment equal across variants and disclose shared guidance.
+Prefer the isolated comparison for a question about whether added rules help;
+do not make the owner discover this distinction after seeing results. Record the
+boundary and verify it with harmless probes. Disabling injection alone is not
+filesystem isolation. Any model-backed probe belongs in the approved run budget.
+Do not claim complete isolation if a relevant channel cannot be checked.
+
+Follow Behavior Diff's preflight and frozen-handoff helpers rather than rebuilding
+their validators. Simulation checks prove the fixture's mechanics, not that a
+real website or workflow engine works. Run a real-service check only with its
+specific authorization; do not replace the agreed question with a simulation.
+
+## Authorization, execution and recovery
+
+This handoff requires the bounded live-run approval in SKILL.md before entering
+Behavior Diff's automatic-launch step. Do not treat its normal no-extra-prompt
+rule as overriding this boundary. Once approved, carry execution through without
+another stage-by-stage permission loop. A study answer or “accept limitations”
+is never run or merge authorization.
+
+Keep the printed run handle, frozen inputs, exact host/model settings and failed
+attempts. Diagnose tooling failures from their outputs. Repair routine local
+setup within the authorization, without editing the target change or global
+settings. Retry only when the approved budget includes it and the cause is
+understood; otherwise propose one bounded recovery. Do not retune after a null
+result. A changed scenario or isolation condition is a new comparison, not a
+replacement result. Stop repeated unsuccessful recovery with a concrete blocker.
+
+## Interpretation and return
+
+Audit raw actions, returns and artifacts for each case, including minority results.
+If automated assessment is rejected, retain the report and distinguish a documented
+raw-evidence assessment from the unavailable automated result. Never re-label it
+as an automatic pass. Distinguish rule effects from pre-existing instructions,
+shared memory, task hints and environment failures.
+
+Deliver the recommendation without requiring “what does the report mean?”:
+what question was tested; added benefit observed or not demonstrated; regressions
+and preserved behavior; decisive evidence; unresolved scope and its decision impact.
+A process change without an outcome change is not automatically an improvement.
+Recommend retain/revise/hold at the tested scope. Do not infer universal redundancy
+from a few equal trials or promise the next real run will succeed. Finish the
+verification handoff before offering optional process feedback; never operate the
+PR in response to that feedback.