reroute-plan

Reroute Plan

承認済みプランを覆す発見があった場合に、進行中の作業を巻き戻すかどうかを判断します。これは薄いルーターです。どの成果物が無効になったのか、どこまで巻き戻すのかを判断し、その後は以下の「薄いルーターの終了条件」に従って処理を委譲します。build-in-waves は、「プラン自体が間違っている」場合、または根本原因が現在のタスクより上位にあるサーキットブレーカーに達した場合、ここに引き継ぎます。何かおかしいと感じた時点で、ユーザーが直接呼び出すこともできます。

順に、診断、分類、ルーティングの3つのフェーズがあります。ハードストップは2つあり、自動書き換えは行いません。

変更を見つけた人が開始地点を決めます。 あなたまたはワーカーが見つけた場合 → フェーズ1。ユーザー自身のメッセージで、追加・変更・削除する内容が示されている場合 → 以下の「ユーザーによる修正」。

ユーザーによる修正 — ユーザーのメッセージが2つの承認を兼ねます

「ステータスを削除して」と伝えたユーザーは、すでに実行を承認し、変更内容も決定しています。フェーズ1とフェーズ2で再度停止する必要はありません。ベースライン実行12回では、ユーザーが4時まで会議中にこのようなメッセージを受け取り、1回はフェーズ1で停止して午後いっぱい何もせず、3回はこのスキルを読んで独自の判断で停止を飛ばしました。

1. フェーズ2に従って、無効になった最も低いレベルの成果物を分類し、台帳の行を追記します（以下の「冪等性」を参照）。レベルによって変更される成果物が決まるため、確認を求める必要はありません。
2. 成果物と、その下位にあるすべてのものを、所有するスキルに従って編集します。ただし、そのスキルにあるファイル承認のための停止は行いません。
3. ユーザーの指示どおりにビルドを続行します。
4. 報告の最後に、必須のこの表現を確認してくださいブロックを付けます。ここには、記述または削除したすべての要件、設計、タスクの行を、ファイル名とともに一字一句そのまま記載します。このブロックで、飛ばした承認を行います。ベースラインでの修正12件のうち、11件でApproved仕様を書き換えていましたが、書き換えた内容を引用したケースはありませんでした。

フェーズ1 — 診断（ユーザーのためのハードストップ）

発見事項がある場合です。ユーザーによる修正ではありません。

次の5つのラベル付き項目を含む、構造化された診断通知を作成します。

• 何が間違っているか、または変更されたか
• どこで差異が表面化したか
• なぜ現在のプランが有効でなくなったのか
• どのように残りの実行に影響するか
• 判断に必要なその他のコンテキスト

通知を提示して停止します。分類せず、成果物に触れず、ユーザーが明示的に判断するまで先に進まないでください。

完了条件： ユーザーが実行するか、実行しないかを判断したときです。

ユーザーが実行しないと判断した場合は、仕様やコードを変更せず、巻き戻しを行わずに制御を返します。これは何も行わない正常な処理であり、部分的な巻き戻しではありません。ディスク上のものは何も変更されません。

フェーズ 2 — 無効になった最も下位の成果物を分類する

診断の続行許可を得た後にのみ行います。連鎖の中で実際に無効になった最も下位のレベルを特定し、その根拠を示してください。

レベル	発見によって否定されたもの…	再開先（フェーズ 3）
タスク単位	現在のタスクのアプローチのみ。仕様は引き続き有効	build-in-waves/test-first に戻る
計画	タスクの分解／順序付け／網羅性。設計は有効	plan-tasks
設計	アーキテクチャ／設計上の判断。要件は有効	design-solution → plan-tasks
要件	約束した内容 — 基準に誤りがある、または不足している	specify-behavior → 設計 → 計画
ビジョン	機能の前提が製品の対象範囲と矛盾している	出荷済みのコード／仕様と新しい前提が衝突する場合は /assess-pivot-impact を指定します。それ以外の場合はビジョンレイヤー（/define-project）に戻るか、担当者にエスカレーションします

分類の原則： 根拠がある中で最も下位のレベルを選んでください。より高いレベルの根拠がないのに、「念のため」上位のレベルまで戻ることは禁止です。現在のタスクのアプローチだけに影響する発見は、後戻りの方が安全に感じるというだけで specify-behavior に戻る理由にはなりません。

変更提案（選択したレベル、その根拠、提案する再開先）を提示し、ユーザーの承認を得るまで停止してください。

完了条件： ユーザーが提案を承認していること。

提案は一時的なものです。実行可否の確認のために会話内に留め、ディスク上に独立した成果物として書き込むことはありません。docs/specs/ 以下に「変更が提案された」ことを記録するものはありません。痕跡を残すのは、最終的に再開するスキルによる編集と、以下のログのみです。

冪等性 — 根拠ログ

後戻りはすべて、同じ事実を再検討した結果ではなく、新たに発見された根拠に基づく必要があります。分類の前に .skills/<CODE>/corrections.md（一時的な、Git で無視される作業用ファイルであり、進行中の計画を対象とする .skills/<CODE>/progress.md と並行するもの）を読みます。このファイルには、対応済みの修正ごとに、根拠のフィンガープリント、選択したレベル、結果を 1 行で記録します。

現在の差異が、新しい根拠がないまま、対応済みの同じ根拠を、無効になった最も下位の成果物と同じレベルに再分類することになる場合、そのレベルには再度戻らないでください。代わりにユーザーへエスカレーションしてください。これにより、build-in-waves → reroute-plan → write-* → realign-spec → build-in-waves のループが回り続けるのを防ぎます。これによって、真に新しい発見が妨げられることはありません。そのフィンガープリント、レベル、結果を新しいログ行として記録し、通常どおり分類してください。

完了条件： 分類の前にログを読み、同じ根拠の再発（新しい根拠なし）でエスカレーションされたか、真に新しい根拠について新しい行が記録されていること。

このログは一時的な作業用ファイルであり、永続的な仕様成果物ではありません。ログへの記録は、上記の一時的な提案のルールと矛盾しません。このルールが対象とするのは変更提案であり、この修正ログではありません。

フェーズ 3 — ルーティングして再開する

提案が承認されたら、該当する再開先にルーティングします。それぞれを必須のサブスキルとして直接呼び出してください。ユーザーに実行を提案するだけで済ませてはいけません。また、そのスキル自身の承認ゲートを実行させてください。

• タスク内 → build-in-waves／test-first に戻ります。上流の成果物は巻き戻しません。
• 計画 → 必須のサブスキル：plan-tasks を使用します。
• 設計 → 必須のサブスキル：design-solution を使用します。そこから plan-tasks に進みます。
• 要件 → 必須のサブスキル：specify-behavior を使用します。そこから設計、計画へと進みます。
• ビジョン → 新しい前提と出荷済みコードまたは仕様が衝突する場合は、ユーザーに /assess-pivot-impact を明示します（ユーザーが呼び出すものです。こちらから呼び出してはいけません）。衝突がドキュメントのみで、docs/product/vision.md が存在する場合は、更新用に /define-project を明示します。どちらのレイヤーも存在しない場合は、ユーザーにエスカレーションし、その前提に本当に疑問があることにユーザーが同意した場合に限り、必須のサブスキルとして frame-change を使用して再開します。

完了条件： 該当するサブスキルが直接呼び出され、そのスキル自身の承認ゲートが実行中であること。reroute-plan がその上に二重の承認手順を作り出してはいけません。

シンルーターの終了処理 — 委任、整合、記録、再開

reroute-plan 自身が要件、設計、計画、タスク、監査トレースのメタデータを書き換えることはありません。仕様内容の生成はすべて write-* スキルに委任し、トライアドの整合はすべて realign-spec に委任します。

再開先のスキルの承認ゲートを通過した後：

1. 整合する。 再開によって承認済みの成果物またはそのトレースリンクが変更された場合、必須のサブスキルとして realign-spec を使用し、Status と監査トレースを整合させます。理由付きの取り消し線による廃止と INDEX の更新は realign-spec が担います。reroute-plan はその処理を再実装しません。
2. 記録する。 最終的に承認された変更にアーキテクチャ上の影響がある場合は、必須のサブスキルとして define-domain を使用し、ADR として記録します。設計レベルの巻き戻しは通常該当しますが、要件またはビジョンの巻き戻しは、アーキテクチャ上の重要性が高い場合に限ります。タスク内および計画レベルでは、ADR を作成しません。 ユーザーが承認していない提案について、ADR を決して永続化してはいけません。
3. 再開する。 制御を build-in-waves に戻します。build-in-waves は自身の台帳に基づき、修正済みの計画から自動的に再開します。手動で再起動する必要はありません。タスク内の巻き戻しでは、.skills/<CODE>/progress.md は変更しません。tasks.md が書き換えられる計画／設計／要件の巻き戻しでは、まず台帳を再ベースライン化します。書き換え後も完了済み作業が有効な項目は残し、書き換えによって置き換えられた項目は削除します。これにより、build-in-waves は古いタスク番号ではなく、依然として有効な最後の完了済みタスクの次から再開できます。台帳は Git で無視される一時ファイルなので、仕様成果物には影響しません。

完了条件： 成果物が変更された場合は整合処理が実行され、ADR は必要かつ承認済みの場合に限って存在し、build-in-waves が（書き換えられた可能性のある）tasks.md と一致する台帳に基づいて再開していること。

警告 — スキルの誤用

• 出荷後に行う、スコープ内の調整（出荷済み機能の色の変更、文言の編集、小規模な追加対応）→ これは reroute-plan ではなく amend-feature です。ここでは「承認後に無効になった」ものは何もありません。機能はすでに出荷済みです。
• 有効な仕様に対するコードの不具合 → これは reroute-plan ではなく root-cause です。仕様は今も正しく、実装だけが間違っています。
• realign-spec は終了処理であり、意思決定者ではありません。 巻き戻しの判断後に実行され、Status とトレースを再整合する機械的な調整処理です。どの成果物が誤っているかを判断するのは reroute-plan です。reroute-plan は realign-spec の記録処理を行わず、realign-spec も巻き戻しを判断しません。
• build-in-waves 内の事前フライト計画レビュー（ディスパッチ前の整合性スキャン）は実行前の処理であり、進行中に判明した問題ではありません。そのため、このスキルの発動条件には該当しません。

考え方	実際のところ
「この発見は大きな問題のようだから、念のため要件まで巻き戻そう」	証拠に基づいて、無効になった最も下位の成果物を分類してください。上位レベルに根拠がないまま過剰に巻き戻すことは禁止されています。発見によって正当化されていない承認まで無効にしてしまいます。
「ユーザーはすでに問題があることに同意しているから、そのままルーティングしてよい」	診断の実行可否判断と変更提案の承認は、それぞれ別の段階です。問題があることへの同意は、特定の再開プロセスの承認と同じではありません。
「計画ファイルを直接修正すればよい。そちらのほうが早い」	reroute-plan に編集機能はありません。plan-tasks／design-solution／specify-behavior にルーティングしてください。内容の管理と、それぞれの承認ゲートは各スキルが担います。
「同じバグがまた出たから、もう一度巻き戻そう」	まず .skills/<CODE>/corrections.md を読んでください。同じ証拠、同じレベルで、新たな発見もない場合は、繰り返すのではなくユーザーにエスカレーションしてください。