bmad-loop-sweep

保留作業の一括トリアージ

目標： {implementation_artifacts}/deferred-work.md 内で選択されたすべての未完了項目を、 オーケストレーターが検証して実行できる、機械可読なトリアージ計画に分類します。

このワークフローは読み取り専用で、自動化を前提としています。bmad-loop の一括確認セッション内でのみ実行されます。台帳の編集、コードの編集、質問は一切行いません。唯一の出力は結果ファイルです。（例外は移行モードで、台帳ファイルを1つだけ編集します。）

起動時

ステップ 0：自動化チェックとモードの振り分け

次を実行します：echo "${BMAD_LOOP_MODE:-}"

出力が 1 でない場合、このスキルは bmad-loop の一括確認内でのみ実行されると伝え、ターンを終了します。それ以外の場合は ./automation-mode.md を最後まで読みます。そのルールと結果スキーマが、この実行全体を規定します。

呼び出しに --migrate <manifest-path> が含まれている場合、これはトリアージではなく移行セッションです。./migration-mode.md を読み、以下のステップ 1～4 の代わりに、その指示に従います。

ステップ 1：台帳の場所を特定する

次を実行します：echo "${BMAD_LOOP_LEDGER:-}"

表示されたパスが台帳です。オーケストレーターがプロジェクトの BMAD 設定（中央の _bmad/config.toml が従来の _bmad/bmm/config.yaml に重ねて適用されます）から解決済みのため、そのファイルを読み、場所を再導出しないでください。そのディレクトリが {implementation_artifacts} です。出力が空の場合に限り、{project-root}/_bmad/bmm/config.yaml を読み、implementation_artifacts を解決して {implementation_artifacts}/deferred-work.md を使用します。台帳を最初から最後まで読みます。未完了項目は、status: 行が open である ### DW-<n>: ブロックです。台帳が見つからない、または読み取れない場合は、automation-mode.md に従って CRITICAL（type: missing-ledger）としてエスカレーションし、ターンを終了します。

archived: 行がある項目は、ここにはスタブのみが残っています。その全文は同階層の deferred-work-archive.md にあり、同じ DW- ID で識別できます。その項目を分類する前に、アーカイブ内の全文を読んでください。archived-body: 行も同様に、アーカイブ後に再度オープンされた項目を示します。これは再び作業対象になっていますが、クローズ前に含まれていた本文は、該当行に記された日付のスタンプが付いたブロックとして、アーカイブファイルに残っています。

呼び出しに --only DW-1,DW-2,... が含まれている場合、それらの ID がこのセッションでトリアージする全項目です。台帳全体は読みますが、指定された未完了項目のみを検証して振り分けてください。ほかの未完了項目を open_ids やいずれかの結果カテゴリに追加してはいけません。オーケストレーターは、オペレーターが指定したサブセットまたは重大度しきい値のセレクターをすでに適用しており、この正確な対象範囲に対して結果を検証します。

呼び出しに --feedback <path> が含まれている場合、そのファイルを最初に読みます。そこには前回の試行で result.json が失敗した、決定論的な検証エラーが列挙されています。今回の出力では、その不備だけを修正してください。

ステップ 2：選択された各項目をコードと照合する

台帳のステータスは信頼できないことが知られています。後続の作業で解決されていても、完了としてマークされていない項目がよくあります。トリアージ対象の各項目について、次を行います。

1. 現在のツリーで location:（ファイル／コンポーネント）を確認します。
2. 説明されている問題がまだ存在するか確認します。コードを読み、症状を grep で検索し、その項目の origin: 日付以降に該当箇所を変更したコミットがないか git log を確認します。
3. どちらの場合も、具体的な証拠を記録します。「おそらく修正済み」は証拠ではありません。ファイルと行番号、またはコミットハッシュを示してください。

利用可能な場合は、並行検証にサブエージェントを使用します。許可を求めてはいけません。

ステップ 3：分類

トリアージ対象の各エントリーを、必ず次のいずれか 1 つのカテゴリに分類します。

• already_resolved — コード内にその問題が存在しなくなっています。具体的な evidence（現在その問題に対処しているファイルと行番号、または修正したコミット）が必要です。オーケストレーターが台帳のエントリーを確定的にクローズします。
• bundles — 今すぐビルド可能です。修正に必要なすべてのファイルがすでに存在し、先に完了すべき将来のストーリーもありません。同じタッチポイント（同じファイル、同じサブシステム、同じバリデーターパターン）を共有するエントリーを、1 回の開発セッションで完了できる規模の、まとまりのある単一目標のバンドルにまとめます。単独で完結するエントリーは、1 件のエントリーからなるバンドルにします。name は ^[a-z0-9][a-z0-9-]{1,39}\Z に一致する必要があります（ケバブケース、最大 40 文字。例：unicode-string-hardening）。intent は、まとまりのある単一目標を説明する 2〜6 文にします。
• blocked — 名前を挙げた将来のストーリー／エピックが完了した後でなければ、修正に意味がない（または大幅に容易にならない）状態です。ブロッカーの名前をそのまま記載します。
• skip — より新しい内容に置き換えられている、該当しなくなっている、またはプロジェクトが明示的に対象外としているシナリオに関係しています。その理由を記載します。
• decisions — 人間による選択が必要です。必ず decision とし、bundle にはしません。仕様の <frozen-after-approval> ブロック内の内容の再交渉、人間が承認した意図的なスコープ決定の撤回、未構築のコンシューマーに波及する API 形状の変更、および理由が「auto-mode: needs human decision」で延期されたエントリーが該当します。各 decision には、具体的な選択肢を 2〜4 個記載し、それぞれに effect（build と実装の意図、close と任意の解決内容、または keep-open）と recommendation を含めます。唯一の例外として、凍結ブロックの再交渉が明らかに全体として有益で、非破壊的かつ動作を厳密化する場合は、バンドルにできます。迷った場合は decision にします。

トリアージ対象の各エントリーは、必ずいずれか 1 つのカテゴリに含めてください。オーケストレーターはこれを確定的に検証します。エントリーの記載漏れや重複があると、結果全体が失敗となり、再試行が 1 回消費されます。

バンドルの成果物が、コードリポジトリ内に厳密に置かれた、設定済みの implementation_artifacts ディレクトリ内の無視対象コンテンツに限られる場合は、既存の intent フィールドに、その成果物と保存場所を記載してください。トリアージの受領確認フィールドを追加したり、実行セッションの代わりに受領確認を宣言したりしないでください。そのセッションは、実際の成果物が条件を満たす場合に限り、自身の最後の真正な ## Auto Run Result 内で、Status: の横の独立した行に Artifact only: true と記載できます。true はラベルと同じ行に置き、後ろに説明を付けません。古い成果物だけを根拠にしてはいけません。このマーカーは、オーケストレーターによる修正注記を含まず、フェンス付きブロックの外にある現在のセッションで記述する必要があります。フロントマターでは宣言できず、値は厳密なブール値 true でなければなりません。通常の作業証明プローブで変更がないことをまず肯定的に確認し、受領確認ゲートでは、そのディレクトリに限定した無視対象ファイル一覧の取得が肯定的に成功する必要があります。その他すべての検証と台帳クローズの確認も引き続き適用されます。隔離されたワークツリーでは、統合に成功すると、破棄前に承認済みのバンドル仕様が公開されます。追加の無視対象通常ファイルは、implementation_artifacts からの正確な相対パスを使って、承認済み仕様の artifact_deliverables フロントマターリストに記載する必要があります。これらの出力予定をバンドルの intent に記載し、実行セッションがそれらを宣言できるようにしてください。ディレクトリ、グロブ、絶対パス、パストラバーサル、シンボリックリンク、およびオーケストレーターが所有する台帳とスプリントボードは禁止されています。宣言されていないファイルはコピーされません。公開時には、実行前に取得したコピー先のベースラインを確認します。メインチェックアウトで変更が競合した場合は公開を一時停止し、復旧用にソース成果物を保持します。受領確認だけではファイルは公開されません。

ステップ 4：結果を記述してターンを終了する

./automation-mode.md に従って result.json を記述し、各カテゴリに振り分けたエントリー数を 1 行で示します。ターンを終了してください。結果ファイル以外のファイルは編集しないでください。