mb-verify

mb-verify — 検証ループ（受け入れ基準 → エビデンス → 判定）

• 内容： 完了したタスクを受け入れ基準と照合して確認し、エビデンスとともに結果を記録します。
• 使用する場面： 実装が完了し、明示的な PASS、FAIL、または部分的な判定が必要なとき。
• 入力： TASK_ID、受け入れ基準の参照元、タスクのプロトコルファイル。
• 出力： verification.md、エビデンスの成果物、検証判定、および基準を満たさない場合に推奨される次のステータス／フォローアップバグ。

目標

「検証せずに信頼する」ことを避けるための、ある程度独立した検証です。

これは敵対的な意味検証ではありません。 タスクが AC／REQ を満たしていても、実質的には間違っている可能性がある場合は、続けて /red-verify ／ mb-red-verify を実行してください。

ステータス遷移モード

ステータス遷移には2つのモードがあります。

スケジューラーモード：

• /autopilot と /autonomous がタスクのステータス遷移を管理します。
• スケジューラーが、クローズ／失敗／ブロックの可否を判断します。
• /execute は対象範囲を限定した実装の引き継ぎを返します。タスクをクローズしません。
• /verify は機能判定／エビデンスを提示します。スケジューラーモードでは、クローズ／失敗／ブロック／昇格を行いません。
• /red-verify は T2／T3 の意味判定を提示します。スケジューラーモードでは、クローズ／失敗／ブロック／昇格を行いません。
• /mb-sync はスケジューラーが提示したクローズ／失敗／ブロックの判断後に、状態を記録／調整します。クローズ自体は判断しません。
• T0／T1 のスケジューラーによるクローズでは、ティアポリシーに従い、簡潔なエビデンス／機能的な PASS を使用できます。
• T2／T3 のスケジューラーによるクローズでは、スケジューラーが done にする前に、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 として扱ってはいけません。最終クローズ／/mb-sync の前に /red-verify を実行し、SEMANTIC_VERDICT: semantic-pass を必須としてください。
• 必須の T2／T3 /red-verify の結果が semantic-pass 以外の場合は、クローズを保留またはブロック状態にし、done にしないでください。任意の T0／T1 の red-verify によって、通常の verify に基づくクローズ条件が厳しくなることはありません。
• 手動モードで semantic-concern が示された場合は、人間によるレビュー／フォローアップを行わずに、既存の done 状態を信頼してはいけません。
• 1つのタスク実行内で、スケジューラーモードと手動モードを混在させないでください。
• 永続化される 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 の場合、リンクされた SDD 仕様がタスクの詳細フィールド、機能の spec_design_links、または spec-index.md に含まれている。存在しない場合は中止し、/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) 同期に関する推奨事項

• /mb-sync 用に RTM／機能ライフサイクルの推奨事項を記録します
• スケジューラーのクローズや依存タスクのブロック／昇格は独自に行いません

完了の定義

• 検証結果が存在し、証拠に裏付けられていること：対象となる T0／T1 には簡潔な run.md、T2／T3 には完全な verification.md を用意します。
• PASS の検証により RTM／タスクの証拠が更新されていること。/red-verify／mb-red-verify が semantic-pass を生成するまで、T2／T3 のタスクはクローズしません。
• FAIL のタスクにはバグドキュメントと次のステップが用意されていること。