シンボルやファイルの削除・改名で「呼び出し元・ドキュメントに旧名が残る」事故は、一箇所のチェックでは繰り返し漏れる。人手のレビューや実装者の自己申告だけに頼らず、三層に分けて機械的に担保すると再発が止まる。

三層の役割分担

• 計画段階: 変更対象シンボルの呼び出し元を検索で全列挙し、変更マップに落とす(どこを直すかを事前に確定させる)
• 実装完了ゲート: 旧名のリポジトリ全体検索(ドキュメント含む)がゼロであることを完了条件の機械ゲートにし、検索結果の証跡を添付させる
• レビュー段階: レビュアーもリポジトリ全体走査を明示的な観点として持つ

効くポイント・落とし穴

• 「ゼロ件の検索出力を証跡として残す」ことが鍵。実装者に自己申告させるのではなく、コマンド出力を貼らせると未検証を排除できる
• docs / コメント / 設定ファイルまで検索範囲に含めないと、コード内だけ直して文書に旧名が残る典型漏れが起きる
• 複数の定義ファイルに同文の条項を新設する場合、コピー間の同期ズレ自体が次の事故源になるため、条項の対応表を別途持って全コピーが揃っているか検査する