mb-verify

mb-verify — 验证器循环（验收 → 证据 → 判定）

• **作用：**根据验收标准检查已完成的任务，并记录结果及证据。
• **适用时机：**实现已完成，且你需要明确的 PASS、FAIL 或部分通过判定时。
• 输入：TASK_ID、验收标准来源和任务协议文件。
• 输出：verification.md、证据文件、验证判定，以及标准未通过时建议的后续状态／跟进缺陷。

目标

进行相对独立的验证，避免“未经验证就轻信”。

这不是对抗式语义审查。 如果任务可能满足 AC/REQ，但实质上仍有错误，请继续运行 /red-verify / mb-red-verify。

状态转换模式

状态转换有两种模式。

调度器模式：

• /autopilot 和 /autonomous 负责任务状态转换。
• 调度器决定是否符合关闭、失败或阻塞条件。
• /execute 返回范围明确的实现交接；不会关闭任务。
• /verify 提供功能判定／证据；在调度器模式下，不会关闭、标记失败、阻塞或提升任务。
• /red-verify 为 T2/T3 提供语义判定；在调度器模式下，不会关闭、标记失败、阻塞或提升任务。
• /mb-sync 在调度器提供关闭／失败／阻塞决定后记录／协调状态。它本身不决定是否关闭。
• 根据层级策略，调度器可依据精简证据／功能 PASS 关闭 T0/T1 任务。
• 调度器关闭 T2/T3 任务前，要求 VERDICT: PASS，且 SEMANTIC_VERDICT: semantic-pass。
• 调度器关闭 T3 任务还要求精确标记 HUMAN_CHECKPOINT: done 和 ROLLBACK_RECOVERY_NOTE: present。

手动模式：

• 预期的 T0/T1 简单流程：/execute -> /verify。
• 只有明确指定了关闭负责人时，才允许手动关闭。
• 功能 VERDICT: PASS 且证据已齐全后，可将 T0/T1 标记为 done。
• T2/T3 不得仅凭 /verify PASS 就视为最终 done；应运行 /red-verify，并要求 SEMANTIC_VERDICT: semantic-pass，然后才能最终关闭／运行 /mb-sync。
• 如果必需的 T2/T3 /red-verify 返回的结果不是 semantic-pass，则应将关闭状态留为待处理或阻塞，而不是标记为 done；可选的 T0/T1 red-verify 不会提高其常规的基于验证结果的关闭要求。
• 手动模式下的 semantic-concern 意味着：未经人工审查／跟进，不要信任现有的 done 状态。
• 不要在同一次任务运行中混用调度器模式和手动模式。
• 不使用持久化的 mode 字段。

输入

• TASK_ID（例如 TASK-123）
• 通过 .memory-bank/tasks/index.json 和 .memory-bank/tasks/<TASK_ID>.task.json 获取的权威任务记录
• 该任务记录中必需的 tier: T0|T1|T2|T3
• 验收标准链接：
  • .memory-bank/features/FT-* 和／或
  • .memory-bank/requirements.md（REQ ID）
• 协议计划链接：.protocols/<TASK_ID>/plan.md

如果存在，还应使用：

• 任意层级关联的权威 SDD 规范
• verification_targets
• normative_inputs
• constraints
• invariants
• 任务记录中对源文件的引用

权威 SDD 规范链接是指任务的扩展字段或关联功能中的 spec_design_links，且链接指向 .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/ 或 .memory-bank/runbooks/。

前置条件

• 实现已完成，并已运行门禁（或已记录失败）。
• .memory-bank/tasks/index.json 中列有目标任务记录，且索引中的 .task.json 与请求的 TASK_ID 相符。
• 验证路由仅以 task.tier 为准；旧的 risk / risk.level 模型无效。

必需输出

• T0 / T1：验证记录可以简明地保存在 .protocols/<TASK_ID>/run.md 中。
• T2 / T3：使用以下模板更新（或创建）.protocols/<TASK_ID>/verification.md：
  • ./references/shared-protocols-verification-template.md
• 将证据保存在 .tasks/<TASK_ID>/ 中：
  • 日志、截图、视频、复现步骤
• 在任务记录的 verify 字段中添加已完成的证据条目；evidence_required 和 verification_targets 是要求/目标，本身不能作为证明。
• 在任何命令将 status: done 之前，任务记录的 verify 字段必须包含已完成的验证/证据条目。

状态归属

• mb-verify 负责验证证据和 VERDICT: PASS|FAIL|NEEDS-CLARIFICATION。
• 由 /autopilot 或 /autonomous 调用时，不得关闭任务、设置 status: done、设置 status: failed、阻止依赖任务或提升依赖任务。它应向调度器报告建议的下一状态。
• 在独立/手动模式下，只有明确拥有关闭权限时，才能在功能性 VERDICT: PASS 后将 T0 / T1 任务标记为 done。
• 对于 T2 / T3，mb-verify 会记录功能性证据和关闭建议，但必须先由 mb-red-verify 判定语义检查通过，才能最终关闭。

流程

1) 仅预备所需内容

阅读：

• .memory-bank/tasks/index.json
• 索引指向的 .memory-bank/tasks/<TASK_ID>.task.json
• .protocols/<TASK_ID>/context.md
• .protocols/<TASK_ID>/plan.md
• .protocols/<TASK_ID>/progress.md
• 验收标准来源文档
• 当任务记录或关联功能包含 SDD 规范链接时，阅读 .memory-bank/spec-index.md 和所有链接的权威 SDD 规范；任何等级的任务均适用

验证前，检查权威任务记录：

• 任务存在于 .memory-bank/tasks/index.json
• 索引记录中的 id 与 TASK_ID 一致
• 验证所需字段齐全（status、feature、reqs、depends_on、gates、verify）
• 存在 tier；若缺失，则停止
• 对于 T2 / T3，任务扩展字段、功能的 spec_design_links 或 spec-index.md 中必须包含关联的 SDD 规范；若缺失，则停止并转交 /spec-improve 或 /spec-auto

不得仅因缺少 SDD 规范链接而阻止 T0 / T1。 如果权威任务记录缺失或无效，应停止并报告问题，不要仅依据协议文档进行验证。

优先级：

1. 存在时，适用于任何等级任务的关联权威 SDD 规范
2. 明确的 Verification Targets
3. 明确的 Normative Inputs
4. 传统功能验收标准和 RTM
5. .tasks/<TASK_ID>/ 中的证据

扩展字段缺失或没有 SDD 规范链接，不得阻止对传统 T0 / T1 任务的验证。

2) 验证验收标准

对于每项 AC / REQ：

• 执行最小但有意义的检查
• 优先采用确定性检查（测试/CLI），而非仅凭“看起来没问题”
• 记录所做的检查并链接证据

如果任务会更改 UI 或浏览器行为：

• 优先使用 Playwright / agent-browser / CDP 驱动的验证
• 在有用时捕获截图/视频/跟踪记录
• 将产物保存在 .tasks/<TASK_ID>/ 中
• 若可使用浏览器自动化，不要将“我手动点击查看了一下”作为主要证据

3) 判定

如果有任何项失败：

• 设置 VERDICT: FAIL
• 在 .memory-bank/bugs/BUG-<short>.md 中创建缺陷文档
• 添加后续 .task.json，并在需要时更新 .memory-bank/tasks/index.json
• 建议当前任务的 status: failed
• 在调度器模式下，不要直接阻塞下游依赖项；将该建议返回给调度器

如果全部通过：

• VERDICT: PASS
• 在 verify 中添加已完成的验证／证据条目
• 按层级应用状态：
  • 调度器模式：建议调度器作出决策；不要关闭／标记失败／阻塞／提升任务
  • 手动模式：在功能性 VERDICT: PASS 且明确指定关闭责任方后，可将 T0 / T1 的 status 设为 done；对于 T2 / T3，将关闭状态保留为待 /red-verify 返回 SEMANTIC_VERDICT: semantic-pass
• 在调度器模式下，只有 /red-verify / mb-red-verify 返回 semantic-pass 后，才可以最终关闭 T2 / T3

4) 同步建议

• 记录 RTM／功能生命周期建议，供 /mb-sync 使用
• 不要自行执行调度器关闭操作，也不要阻塞／提升依赖项

完成定义

• 验证输出已生成且有证据支持：符合条件的 T0 / T1 使用精简版 run.md，T2 / T3 使用完整的 verification.md。
• PASS 验证已更新 RTM／任务证据；在 /red-verify / mb-red-verify 生成 semantic-pass 之前，不得关闭 T2 / T3 任务。
• FAIL 任务已有缺陷文档和后续步骤。