実装計画の探索中に周辺の不具合や品質課題が見つかると、それぞれに修正理由があるため、同じ計画へ次々に取り込みやすい。変更マップがあっても、「対応するテストや翻訳」のような省略があると、合意時に認識した規模と実際の差分が大きく乖離する。

スコープは一つの中心成果を先に固定し、各項目を次の基準で分類する。

• 中心成果: 利用者へ直接届ける一つの状態変化。
• 必須前提: 除外すると中心成果が動かない、既存契約を破る、または今回の変更が新しい安全性・整合性問題を生むもの。
• follow-up: その項目を除いても中心成果が成立し、別日・別リリースで単独出荷できるもの。

探索で見つけたこと、同じ画面やリポジトリにあること、同じ担当者が直せることは同梱理由にしない。必須前提を追加するときは、中心成果との因果と増える変更量を提示して再合意する。

合意前には、重複を除いた変更候補を本体、テスト、翻訳、設定・ツール、文書などへ分類し、区分別件数と総数を示す。規則的なファイル群を省略表記する場合も展開件数を数える。一定規模を超えたら自動的に失敗とするのではなく、分割案を提示して明示承認を求める停止ゲートにする。閾値は過去の実測で調整するが、件数未満でも独立出荷できる成果は分ける。

実装中に変更マップ外のファイルが必要になった場合も、必須波及と周辺発見を再分類する。必須波及なら計画と総量を更新し、停止ゲートを跨ぐなら再合意する。周辺発見なら同じ差分へ善意で追加せずfollow-upへ送る。

検証では、計画時と完了時の区分別ファイル数、変更マップ外の追加数、規模ゲートの発火回数、単独出荷可能な成果が同梱されていないかを確認する。計画を詳細化することではなく、削る判断と総量の可視化が目的である。