verify

name	verify
description	Execute a task's oracle and, on pass, produce the hash-chained receipt and atomic commit. Use when an sddx task reaches VERIFY or the user asks to verify a task.

/sddx:verify

CLI: "${CLAUDE_PLUGIN_ROOT}/bin/sddx-run" "${CLAUDE_PLUGIN_ROOT}/dist/cli.mjs" (run from the repo root).

Run: ... verify <task-id> --model <your model id, if you know it>

• pass → the CLI has already written .sddx/receipts/<id>.json (immutable, chained to the previous receipt) and made one atomic commit containing code + spec + task file + receipt. Report the receipt path and commit SHA, then run ... next-actions (same cwd as the verify call, so it reflects this task's own branch/worktree) and relay its output verbatim as the completion message — don't compose your own summary of what's next. On the user's reply, run ... next-actions --select "<reply>" and relay that output too.
• fail → the oracle's exit code and the attempt count are printed; the task stays in VERIFY. Return to the loop (fix under GREEN/REFACTOR rules), then verify again. Respect the spec's stop_rules: if iterations exceed max_iterations (default 5), stop and escalate to the user.
• error: no failing-oracle evidence → the red-check was skipped. A task still in RED can run ... red-check <id>; a task already past RED cannot be red-checked retroactively — abandon and recreate it. Escalate to the user.

After a pass, cross-check the spec's success_criteria in prose: list each criterion and whether the oracle's observed run covers it. This review is non-binding — the receipt verdict derives solely from the oracle exit code, and a prose doubt can neither pass nor fail a task. If a criterion turns out not to be exercised by the oracle, report it to the user as a spec gap: the fix is a better oracle in a future spec, never a hand-judged verdict.

Never write or edit anything under .sddx/receipts/ yourself. Never re-run verify on a DONE task — receipts are write-once.