What it does: checks a completed task against acceptance criteria and records the result with evidence.
Use it when: implementation is done and you want an explicit PASS, FAIL, or partial verdict.
Input: TASK_ID, acceptance criteria sources, and the task protocol files.
Output: verification.md, evidence artifacts, verification verdict, and recommended next status/follow-up bugs when criteria fail.

Goal

Independent-ish verification so we don’t “trust without verify”.

This is not the adversarial semantic pass. If a task may satisfy AC/REQ while still being wrong in substance, follow with /red-verify / mb-red-verify.

Status Transition Modes

Status transitions have two modes.

Scheduler mode:

/autopilot and /autonomous own task status transitions.
Scheduler decides closure/failure/blocking eligibility.
/execute returns scoped implementation handoff; it does not close tasks.
/verify gives functional verdict/evidence; in scheduler mode it does not close/fail/block/promote.
/red-verify gives semantic verdict for T2/T3; in scheduler mode it does not close/fail/block/promote.
/mb-sync records/reconciles state after the scheduler-provided closure/failure/blocking decision. It does not decide closure itself.
T0/T1 scheduler closure may use compact evidence / functional PASS according to tier policy.
T2/T3 scheduler closure requires VERDICT: PASS plus SEMANTIC_VERDICT: semantic-pass before scheduler marks done.
T3 scheduler closure also requires exact markers HUMAN_CHECKPOINT: done and ROLLBACK_RECOVERY_NOTE: present.

Manual mode:

Expected T0/T1 simple flow: /execute -> /verify.
Manual closure is allowed only when an explicit closure owner exists.
T0/T1 may be marked done after functional VERDICT: PASS and completed evidence.
T2/T3 must not treat /verify PASS alone as final done; run /red-verify and require SEMANTIC_VERDICT: semantic-pass before final closure//mb-sync.
If required T2/T3 /red-verify returns anything other than semantic-pass, leave closure pending or blocked, not done; optional T0/T1 red-verify does not make their normal verify-based closure stricter.
semantic-concern in manual mode means do not trust the existing done state without human review / follow-up.
Do not mix scheduler mode and manual mode inside one task run.
No persisted mode field is used.

Inputs

TASK_ID (e.g. TASK-123)
Authoritative task record via .memory-bank/tasks/index.json and .memory-bank/tasks/<TASK_ID>.task.json
Mandatory tier: T0|T1|T2|T3 in that task record
Links to acceptance criteria:
- .memory-bank/features/FT-* and/or
- .memory-bank/requirements.md (REQ IDs)
Link to protocol plan: .protocols/<TASK_ID>/plan.md

If present, also use:

linked authoritative SDD specs for any tier
verification_targets
normative_inputs
constraints
invariants
task record references to source artifacts

Authoritative SDD spec links are links in task richer fields or linked feature spec_design_links that point to .memory-bank/spec-index.md, .memory-bank/tech-specs/, .memory-bank/architecture/, .memory-bank/contracts/, .memory-bank/domains/, .memory-bank/states/, .memory-bank/adrs/, .memory-bank/testing/, or .memory-bank/runbooks/.

Preconditions

Implementation is done and gates were run (or failures recorded).
.memory-bank/tasks/index.json lists the target task record, and the indexed .task.json validates the requested TASK_ID.
Authoritative verification routing is only task.tier; the old risk / risk.level model is invalid.

Required outputs

T0 / T1: verification may be recorded in compact .protocols/<TASK_ID>/run.md.
T2 / T3: update (or create) .protocols/<TASK_ID>/verification.md using:
- ./references/shared-protocols-verification-template.md
Store evidence in .tasks/<TASK_ID>/:
- logs, screenshots, videos, reproduction steps
Add completed evidence entries to the task record verify field; evidence_required and verification_targets remain requirements/targets, not proof by themselves.
Before any command sets status: done, the task record verify field must contain completed verification/evidence entries.

Status ownership

mb-verify owns verification evidence and VERDICT: PASS|FAIL|NEEDS-CLARIFICATION.
When invoked by /autopilot or /autonomous, it must not close the task, set status: done, set status: failed, block dependents, or promote dependents. It reports a recommended next status to the scheduler.
In standalone/manual mode, it may mark a T0 / T1 task done after functional VERDICT: PASS only with explicit closure ownership.
For T2 / T3, mb-verify records functional evidence and closure recommendation, but final closure requires mb-red-verify semantic-pass first.

Process

1) Prime only what you need

Read:

.memory-bank/tasks/index.json
indexed .memory-bank/tasks/<TASK_ID>.task.json
.protocols/<TASK_ID>/context.md
.protocols/<TASK_ID>/plan.md
.protocols/<TASK_ID>/progress.md
acceptance criteria source docs
.memory-bank/spec-index.md and all linked authoritative SDD specs when the task record or linked feature contains SDD spec links, for any tier

Before verifying, validate the authoritative task record:

the task is present in .memory-bank/tasks/index.json
the indexed record id matches TASK_ID
required fields for verification are present (status, feature, reqs, depends_on, gates, verify)
tier is present; if missing, stop
for T2 / T3, linked SDD specs are present in task richer fields, feature spec_design_links, or spec-index.md; if absent, stop and route back to /spec-improve or /spec-auto

Do not block T0 / T1 only because SDD spec links are absent. If the authoritative task record is missing or invalid, stop and report the issue instead of verifying from protocol docs alone.

Priority:

linked authoritative SDD specs for any tier, when present
explicit Verification Targets
explicit Normative Inputs
classic feature acceptance criteria and RTM
evidence in .tasks/<TASK_ID>/

Missing richer fields or absent SDD spec links must not block verification of a classic T0 / T1 task.

2) Verify acceptance criteria

For each AC / REQ:

run the smallest meaningful check
prefer deterministic checks (tests/CLI) over “looks OK”
record what you did and link the evidence

If the task changes UI or browser behavior:

prefer Playwright / agent-browser / CDP-driven verification
capture screenshots/videos/traces when useful
store artifacts in .tasks/<TASK_ID>/
do not use “I clicked around manually” as the main evidence when browser automation is available

3) Verdict

If anything fails:

set VERDICT: FAIL
create a bug doc in .memory-bank/bugs/BUG-<short>.md
add a follow-up .task.json and update .memory-bank/tasks/index.json (if needed)
recommend current task status: failed
in scheduler mode, do not block downstream dependents directly; return that recommendation to the scheduler

If all pass:

VERDICT: PASS
add completed verification/evidence entries in verify
apply status by tier:
- scheduler mode: recommend the scheduler decision; do not close/fail/block/promote
- manual mode: may set T0 / T1 status: done after functional VERDICT: PASS with explicit closure ownership; for T2 / T3, leave closure pending /red-verify SEMANTIC_VERDICT: semantic-pass
in scheduler mode, final T2 / T3 closure is eligible only after /red-verify / mb-red-verify returns semantic-pass

4) Sync recommendations

Record RTM/feature lifecycle recommendations for /mb-sync
Do not independently perform scheduler closure or dependent block/promotion

Definition of done

Verification output exists and is evidence-backed: compact run.md for eligible T0 / T1, full verification.md for T2 / T3.
PASS verification has updated RTM/task evidence; T2 / T3 tasks are not closed until /red-verify / mb-red-verify produces semantic-pass.
FAIL tasks have a bug doc and next steps.