Verify

Verify that a change actually satisfies an acceptance criterion using runnable checks plus an explicit judgment over outputs. This is for "prove it works", not for implementing new features.

Use when

• User asks to validate a change against acceptance criteria.
• You need evidence from test/lint/type-check/build outputs.
• A plain "looks good" answer is insufficient without execution proof.

Do not use when

• No acceptance criterion is provided and cannot be inferred.
• The task is to implement/fix code (use implementation/debug skills first).
• Required checks cannot run in the current environment and no fallback exists.

Input contract

• acceptance_criterion (required): plain-English success condition.
• candidate_commands (optional): preferred checks in priority order.
• max_rounds (optional): default 2, clamp to [1, 4].
• judge_mode (optional): strict (default) or balanced.
• fail_fast (optional): default true (stop on decisive failure).

Parsing rules (priority order)

1. If structured args exist, use them directly.
2. Else infer from user text:
   • requirement sentence -> acceptance_criterion
   • explicit commands -> candidate_commands
   • "run twice/max 3 rounds" -> max_rounds
3. Command selection fallback:
   • explicit commands first
   • then acceptance-based inference (test, lint, type-check, build)
   • then repo defaults (Phase 75-style autodetect: e.g., cargo test, cargo check)
4. If acceptance_criterion is still missing, ask for one concrete criterion.

Canonical workflow

1. Normalize criterion
   • Rewrite criterion into objective pass/fail checkpoints.
2. Build verification plan
   • Select minimal command set that can falsify the criterion quickly.
3. Execute bounded rounds (1..max_rounds)
   • Run commands in priority order.
   • Capture per-command: exit code, key output lines, duration.
   • If fail_fast=true and decisive failure appears, stop early.
4. LLM judge over evidence
   • Evaluate whether collected evidence satisfies each checkpoint.
   • Mark unknowns explicitly instead of guessing.
5. Stop when:
   • criterion satisfied with evidence (status=pass), or
   • criterion disproven (status=fail), or
   • environment blocks decisive evaluation (status=inconclusive), or
   • missing criterion/context (status=needs_user_input).

Guardrails

• Never claim success without command-backed evidence.
• Never run destructive or scope-expanding commands during verification.
• Keep logs concise: only relevant lines proving pass/fail.
• Separate "command passed" from "criterion satisfied" (they are not identical).
• If checks are flaky, report flakiness explicitly and avoid false certainty.

Output format

Always return:

• status: pass | fail | inconclusive | needs_user_input
• rounds_run: rounds executed
• acceptance_criterion: normalized criterion used
• commands_run: ordered list with exit codes
• evidence: criterion checkpoints mapped to concrete outputs
• judge_decision: explicit rationale for pass/fail/inconclusive
• gaps: what could not be proven
• next_action: required unless status=pass

Examples

• acceptance_criterion="all core tests pass and no clippy warnings" candidate_commands=["cargo test -p nexo-core","cargo clippy -p nexo-core -- -D warnings"]
• acceptance_criterion="feature builds and type-checks" (autodetect may pick cargo check/cargo test)
• acceptance_criterion="endpoint returns 200 and response includes health=ok" candidate_commands=["cargo test -p api health_check"]