mb-verify

name	mb-verify
description	Verify one TASK-* against acceptance criteria and record reproducible evidence.

mb-verify — Verifier loop (acceptance → evidence → verdict)

• 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:

1. linked authoritative SDD specs for any tier, when present
2. explicit Verification Targets
3. explicit Normative Inputs
4. classic feature acceptance criteria and RTM
5. 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.