issue-verify

Autonomy contract. This step is agent-handled, not founder-gated. Verify automatically once required_checks have all exited 0. Record the verified receipt without founder confirmation. The receipt itself is the audit signal: the founder reads it after the fact, not before. Founder-gated steps are still: /issue-approve, /prd-approve, /prd-split commit, and any scope amendment mid-issue. This step is not one of them.

Verify the active DSSE issue. Execute in order:

1. Run python3 "${CLAUDE_PLUGIN_ROOT}/scripts/issue_runner.py" status. Confirm an issue is loaded. If issue_id is null, stop and tell the founder to run /issue-start <issue-id> first.

2. Commit the issue's work first. The size class (ASK-1749 tier) reads committed HEAD, so uncommitted code verifies, reviews and closes at L. Then run python3 "${CLAUDE_PLUGIN_ROOT}/scripts/issue_runner.py" verify.

   This ONE command is the whole step. It runs every check in the spec snapshot itself, records each check's exit code and an output hash as evidence, and writes the verified receipt only if all of them exit 0.

   Do NOT run the checks by hand first. verify runs them from the snapshot taken at /issue-start, which is the thing the receipt attests to; a check you ran yourself from the live spec can differ from that snapshot, and the receipt would then describe a run nobody made. There is no way to record this receipt without running the checks -- mark verified refuses by design (ASK-402).

   An issue loaded after ASK-1810 (its state carries "verify_contract": 2) gets more from the same command, all computed by verify and sealed into the receipt, never typed:

   • a check that runs the full suite (verify.sh --full, bare pytest, kipi check) is refused before anything runs; CI runs it once per PR;
   • real_path: which of the issue's non-test .py files each check ran at its tracked path, seen by real_path_observer/sitecustomize.py; a check that only runs a copy is refused;
   • defined_vs_ran: test functions in each named Python test file, from the AST, against the runner's own count; hidden tests are refused;
   • repeats: the checks rerun inside a 20-minute budget as many times as the diff's size class earns (S: 2, refused below 2; M and L: up to 10, refused below 5), and refused on any red run.
   • mutants (ASK-2768): each mutant run recorded for this issue, judged against verify's own clean run. caught names the tests that failed only under the mutant; a test failing in both runs is not counted. A silent mutant (the runner's output shows no new failure) is refused by name. No caught mutant is recorded as gap, not refused. A typed tally is never read: verify reads only <state_dir>/mutants/<issue_id>/*.json, and only the mutant verb writes there.

   To record a mutant (founder budget: one per new decision point): apply a one-line break to the tracked file, run python3 "${CLAUDE_PLUGIN_ROOT}/scripts/issue_runner.py" mutant <name> (lowercase letters, digits, dashes), put the code back, then run verify. The mutant verb runs the snapshot's checks and stores their raw output; it never judges. Only verify turns that output into a count.

3. If verify exits 0:

   • Report: "verified receipt recorded at ."
   • Read checks from its JSON output and list them, one per line (checks_run is the count).
   • Under contract 2, also paste real_path, defined_vs_ran, mutants and repeats from the same JSON. These are the closeout numbers; do not restate them from memory. A mutant count that is not in mutants is a claim, not a closeout number.

4. If verify exits 2:

   • It already printed which check failed and its exit code. Report that.
   • The evidence is stored even on a red run; the receipt is withheld.
   • An empty required_checks list also exits 2. That is not a passing issue, it is a spec with nothing to attest to: tell the founder to add a check or amend the spec.
   • Stop. Do not attempt to fix silently. Tell the founder.