mb-red-verify — Adversarial semantic verification

• What it does: pressure-tests one completed TASK-* for semantic correctness, hidden failure modes, and systemic harm.
• Use it when: a task may be locally correct yet still wrong in product/domain/architectural/operational reality.
• Input: TASK_ID, task intent, actual change surface, tests/evidence, and only then relevant spec reconciliation.
• Output: red-verification.md, a concise semantic-risk report, and follow-up bugs/tasks when concerns are serious.

Goal

Catch changes that are "disciplined but wrong":

• pass acceptance criteria but solve the wrong problem
• work locally but damage system integrity
• overfit to the task record and ignore neighboring constraints
• introduce architectural drift, state inconsistency, or hidden maintenance cost
• create false confidence because the evidence surface is too narrow

This is intentionally different from existing commands

• mb-verify checks acceptance criteria and evidence-backed task completion.
• mb-review reviews Memory Bank quality, planning, and discipline in fresh context.
• mb-red-verify asks: "Is this solution actually right in substance?"