verify

/verify - Verify one TASK outcome

<input_contract> Expected $ARGUMENTS: one TASK-NNN-TN-FT-NNN-WN.

Require:

• exactly one matching indexed task record plus .memory-bank/workflows/tier-policy.md#tier-obligations and #closure-authority;
• #task-claim-and-dependency-ownership;
• #tier-classification-and-escalation when scope may be under-tiered, #hard-write-boundary when a boundary/alias is non-empty, #task-scoped-acceptance-evidence when its fields are populated, and #claim-linked-red--green-for-t2t3 only for T2/T3;
• task-linked feature/REQ material needed for this outcome;
• direct task-linked applicable canonical SDD specs;
• current accepted graph row and exact contract heading for every task-scoped inter-module interaction;
• tier-selected execution protocol and /exe handoff/evidence:
  • T0/T1 -> .protocols/<TASK_ID>/run.md plus .tasks/<TASK_ID>/ when present;
  • T2/T3 -> context.md, plan.md, progress.md, handoff.md, existing verification.md, and substantive .tasks/<TASK_ID>/ artifacts.

Normal scheduler input is in_progress. Manual re-verification of another state requires tier-appropriate execution evidence or an explicit request. Never verify a merely planned|ready task as executed or silently reinterpret blocked|failed|done.

Point-of-use preflight confirms index/file/ID and ID-segment consistency, valid tier, string-array reqs/depends_on, valid gate shapes, valid verify array, and tier-selected execution evidence. This is not another full schema/review gate. Missing required input returns NEEDS-CLARIFICATION; do not reconstruct it from protocol prose.

An execute receipt is optional evidence, not required /exe input. Its absence or ineligibility routes to a rerun or replacement probe, not by itself to NEEDS-CLARIFICATION. Missing tier-required protocol, /exe handoff/evidence, or normative evidence remains a required-input blocker under the rule above. </input_contract>

<hard_invariants>

• Before the verdict, load and apply this installed skill's references/finding-adjudication.md semantic pack.
• Before the verdict, attempt one fresh best-effort co-review on model Codex Luna with reasoning effort xhigh, using this installed skill's agents/review-code.md; give it the task target, governing evidence, scope, and actual change surface. Do not retry or block verification if it cannot launch. Treat its output only as candidate findings.
• Route only by task.tier; lifecycle/status ownership is canonical in .memory-bank/workflows/tier-policy.md#closure-authority.
• Verify this task's outcome and mapped AC/REQ subset, not the whole feature or acceptance assigned to other tasks.
• Treat done and done_for_prod dependency outcomes as prerequisites, not claims to prove. Applicable regression checks support the current task outcome and do not transfer ownership.
• Direct task-linked canonical specs outrank secondary task prose for their concerns. For T2/T3, feature links or spec-index.md alone are insufficient.
• Apply only spec families demanded by actual scope. Missing/conflicting/wrong canonical coverage is a planning/design blocker, not an implementation FAIL.
• Evidence requirements and verification targets state what must be proved; they are not proof. /exe local PASS is input, not automatic PASS.
• Executor claim-path evidence linked by the current attempt is supporting, not an independent observation or replacement for this command's functional proof. Never demand fabricated RED from historical done|done_for_prod|failed tasks.
• An execute receipt is self-attested supporting evidence. It does not prove that its declared snapshot preceded the command or that the reported result occurred, and it is never an independent observation by /verify.
• Advisory touched_files deviation is not material expansion by itself; hard allowed/forbidden scopes and semantic task boundaries remain strict.
• When direct task links define architecture boundaries, PASS requires both the functional outcome and the allowed architectural path. Limit this to the actual change surface; do not run a repository-wide architecture audit.
• Do not edit implementation, specs, AC, dependencies, tier/wave, task scope, BUG records, or follow-up tasks.
• /verify never invokes /debug. It may recommend a separate fresh /debug <TASK_ID> for an observed failure whose root cause or minimum correction is not evidence-backed; the functional verdict still follows this command's evidence-adequacy rules.
• Scheduler mode: never close/fail/block/promote tasks or dependents. </hard_invariants>