機能撤去や大規模削除の完了ゲートとして「旧名のリポジトリ全体検索がゼロ」を置く方法は、撤去対象の語がシステム内で他の生きた概念にも使われていると成立しない。撤去する機能名が、別ドメインの列挙値、外部仕様の予約語、メタデータのプロパティ名、テストの生文字列などと同じ綴りで存在する場合、ゼロにはできないし、ゼロを目指すと残すべきものを壊す。

いつ起きるか

• 撤去する機能名が、残す別機能のカテゴリー値・種別値として使われている（機能としては消すが、分類ラベルとしては生きている）
• 撤去する語が外部仕様側の予約語と同じ（例: 購読・追跡系の機能名が、検索エンジン向けメタデータのプロパティ名と一致する）
• 撤去する種別の定数を消しても、テスト fixture や mapper テストが同じ値を生文字列で持っており、定数名の検索をすり抜ける

最後の型が特に危険で、シンボル名だけを検索する完了ゲートは通ってしまう。生文字列を別の検索として必ず併走させる。

判断基準

• ゲートの条件を「ヒットゼロ」ではなく「allowlist に載っていないヒットがゼロ」に変える。
• allowlist はファイル単位ではなく (パス, 行の正規表現) 単位にする。ファイル単位にすると、削除すべき記述と残すべき記述が同居するファイルで、片方を見逃すか片方を壊すかの二択になる。この同居は実際に起きる（モックデータ定義や国際化リソースが典型）。
• allowlist は会話やレビュー本文ではなく機械可読ファイルとして版管理し、判定をスクリプト化する。「たぶん無関係だから残す」という実装者の都度判断を挟ませない。判断を挟ませると、網羅性の根拠が人の注意力に戻る。
• 実装中の allowlist 追加は禁止せず、「残すべき理由を1行添えて責任者の承認を得る」運用にする。禁止すると実装が止まり、自由にすると閉包が骨抜きになる。

列挙からの切り替え時期

計画時に触るファイルを人手で列挙する方法は、参照が数十ディレクトリに広がると網羅を保証できない。計画レビューで「列挙漏れ」型の指摘が2巡以上続いたら、列挙を足し続けるのをやめ、対象シンボル一覧を正本にした閉包へ方式ごと切り替える。このときファイル列挙は捨てず「着手点であって網羅の根拠ではない」と位置づけ直す。過去に漏れた箇所は起点リストとして残すと、同じ場所を再び見落とさない。

検証方法

判定スクリプトの出力に、ヒット総数・許可数・不許可数と不許可の一覧を出させ、証跡として残す。不許可ゼロだけを見て許可数を見ないと、allowlist が広がりすぎて実質無検査になっていることに気づけない。allowlist の各行が今も必要かは、撤去完了時に一度読み返して、恒久的に残る行と移行期間だけの行を分ける。