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 設定から解決したものです（v6 では {implementation_artifacts}、v7 ではアクティブなイニシアチブのフォルダー）。そのファイルを読み、パスを再解決してはいけません。そのディレクトリーが {implementation_artifacts} です。台帳全体を読みます。未完了エントリーは、status: 行が open である ### DW-<n>: ブロックです。出力が空の場合、または台帳が存在しない、もしくは読み取れない場合は、automation-mode.md に従って CRITICAL （type: missing-ledger）としてエスカレーションし、ターンを終了します。

archived: 行を持つエントリーは、ここにはスタブのみが残されています。本文全体は同じ DW- ID をキーとして、同階層の deferred-work-archive.md に保存されています。そのエントリーを分類する前に、そちらを読みます。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 行で示します。ターンを終了してください。結果ファイル以外のファイルは編集しないでください。