mb-execute

mb-execute - 実装の引き継ぎ

目的

mb-execute は、スコープが限定された 1 つの JSON タスクを実装します。ミニスケジューラーではなく、タスクのクローズも担当しません。フロー：タスクを読む -> 最小限の事前確認 -> プロトコル -> 実装 -> ローカルゲート -> エビデンス -> 引き継ぎ。

ステータス遷移モード

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

スケジューラーモード：

• /autopilot と /autonomous がタスクのステータス遷移を担当します。
• スケジューラーが、クローズ／失敗／ブロックの可否を判断します。
• /execute はスコープが限定された実装の引き継ぎを返します。タスクをクローズしません。
• /verify は機能上の判定／エビデンスを提示します。スケジューラーモードでは、クローズ／失敗／ブロック／昇格を行いません。
• /red-verify は T2/T3 の意味上の判定を提示します。スケジューラーモードでは、クローズ／失敗／ブロック／昇格を行いません。
• スケジューラーは、/mb-sync の前に、クローズ／失敗／ブロックの判断、最終タスクステータス、エビデンスへのリンクを、正規のインデックス付き .memory-bank/tasks/TASK-*.task.json レコードに書き込む必要があります。
• /mb-sync は、すでに書き込まれたタスク状態を記録／調整します。クローズ／失敗／ブロック／昇格を判断するものではなく、スケジューラーのコンテキストにしか存在しない判断を同期してはなりません。
• T0/T1 のスケジューラーによるクローズでは、ティアポリシーに従って、簡潔なエビデンス／機能上の PASS を使用できます。
• T2/T3 のスケジューラーによるクローズでは、スケジューラーが done にする前に VERDICT: PASS と SEMANTIC_VERDICT: semantic-pass が必要です。
• T3 のスケジューラーによるクローズでは、さらに正確なマーカー HUMAN_CHECKPOINT: done と ROLLBACK_RECOVERY_NOTE: present が必要です。

手動モード：

• 想定される T0/T1 のシンプルなフロー：1 つの TASK に対して /execute -> /verify。
• 手動でのクローズは、明示的なクローズ担当者がいる場合にのみ許可されます。
• explicit standalone owner とは、ユーザーが現在のトップレベルエージェントにタスクのクローズを直接依頼した場合、またはトップレベルエージェント／オーケストレーターが 1 つの TASK に対する手動ワークフローを明示的に実行し、自身がクローズを担当すると記録した場合を指します。サブエージェント／ワーカープロンプトが、暗黙にクローズ担当者になることはありません。
• /verify PASS によって T0 / T1 を status: done にできるのは、明示的なクローズ担当者が存在し、完了したエビデンスがタスクレコードの verify フィールドと、ティアで必須となる簡潔／完全プロトコルに書き込まれている場合に限られます。
• 明示的なクローズ担当者がいない場合、/verify は VERDICT: PASS、エビデンス、クローズの推奨を記録し、status は変更せず、スケジューラー／担当者にクローズを指示します。
• T2 / T3 を手動でクローズするには、status: done にするか /mb-sync を実行する前に、/verify PASS に加えて /red-verify / mb-red-verify の SEMANTIC_VERDICT: semantic-pass が必要です。semantic-pass がない場合、クローズは保留またはブロックとし、done にしてはなりません。
• 手動モードでの 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/requirements.md / REQ ID
• タスクレコードまたはリンクされた機能に SDD 仕様へのリンクがある場合は、すべてのティアで .memory-bank/spec-index.md と、リンクされたすべての正規 SDD 仕様
• 存在する場合は、より詳細なタスクフィールド：source_artifacts、normative_inputs、constraints、invariants、verification_targets

正規 SDD 仕様リンクとは、.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/ へのリンクです。

詳細フィールドが欠けている場合や SDD 仕様へのリンクがない場合でも、従来の T0 / T1 タスクはブロックされません。参照先のドキュメントにフォールバックしてください。 T2 / T3 では、リンクされた SDD 仕様が欠けている場合、本格的な作業のブロッカーとなります。

最小限の事前確認

次の場合は、明示的な引き継ぎエラーを出して停止します。

• タスクレコードまたはインデックス対象ファイルが見つからない
• レコードの id が TASK_ID と一致しない
• tier がない、または T0|T1|T2|T3 のいずれでもない
• タスクの status が blocked、failed、または done
• depends_on のタスクが見つからない、または done ではない
• tier が T2 / T3 で、タスクの詳細フィールドにも、リンクされた機能の spec_design_links にも、関連する SDD 仕様リンクが含まれていない

SDD 仕様リンクがないことだけを理由に、T0 / T1 をブロックしないでください。 ルーティングには task.tier のみを使用してください。レガシーの risk / risk.level は使用しないでください。

プロトコルのルーティング

実行時の成果物用に .tasks/<TASK_ID>/ を作成します。

T0 / T1：コンパクトプロトコルを使用します。

• .protocols/<TASK_ID>/run.md。tier、goal、context、plan、changes、 gates、evidence、handoff notes を記録します。
• VERDICT: PASS|FAIL|BLOCKED はローカルの証拠マーカーにすぎず、タスクの完了を意味しません。

T2 / T3：完全なプロトコルを使用します。

• .protocols/<TASK_ID>/context.md、plan.md、progress.md、 verification.md、handoff.md

T3：以下の正確なマーカー行は完了条件です。

• HUMAN_CHECKPOINT: done
• ROLLBACK_RECOVERY_NOTE: present

これらのマーカーが存在するか、まだ必要かを記録してください。タスクを完了扱いにしないでください。

実装ルール

• 作業範囲をタスクとその受け入れ基準に限定してください。
• どの tier でも、タスクレコードまたはリンクされた機能に権威ある SDD 仕様リンクが含まれている場合は、編集前に .memory-bank/spec-index.md とリンクされたすべての権威ある SDD 仕様を読み、それらを規範となる入力として扱ってください。
• 大規模な編集に着手する前に、goal、non-goals、constraints、touched areas、gates を記録してください。
• 作業の分割が必要な場合は、範囲が狭く、互いに重複しない worker scope を使用してください。
• 無関係な変更を保持し、生成された shared-* ファイルを書き換えないでください。
• プロトコルの記録は事実に即したものにしてください。変更内容、確認内容、証拠の場所を記録します。

ローカルゲート

プロジェクトの指示に従い、関連するローカルゲートを実行してください。lint/typecheck、単体テスト、関連する場合のみ統合テスト／e2e チェックを行います。

ゲートを実行できない場合、または失敗した場合は、コマンド、結果、証拠のパス、ブロッカーをプロトコル／引き継ぎに記録してください。それを最終的なタスクステータスに反映しないでください。

出力／引き継ぎの契約

以下を含めて終了してください。

• 変更ファイルの概要
• プロトコルファイルのパス
• 実行したローカルゲートとその結果
• .tasks/<TASK_ID>/ 配下の証拠のパス
• 検証者／レビュアー向けの検証対象とリスクに関する注記
• MB-SYNC の引き継ぎメモ：同期すべき内容と担当者
• 推奨する次の担当者：scheduler、verifier、red-verifier、明示的な単独担当者、または人間

所有権に関するルール

mb-execute は以下を行いません。

• タスクを完了扱いにする
• 最終的なタスクステータスを書き込む
• /mb-sync を実行する
• /verify または /red-verify を実行する
• 依存タスクを昇格、ブロック、またはブロック解除する
• in-progress、failed、done などの scheduler 遷移を実行する

scheduler（/autopilot、/autonomous）または明示的な単独担当者が、検証のオーケストレーション、最終ステータスの決定、MB-SYNC、依存タスクの昇格／ブロックを行います。