機能・商品・ページを削除したとき、コードと内部リンクを消すだけでは不十分。その機能を「やるべきこと」として記述している正本ドキュメントが残っていると、次に作業する人がそれを読んで再実装する。

失敗の型

事業計画・ロードマップ・データソース一覧・常騐の指示ファイルなど、「正本」と定めてある文書は、削除した機能を未実装の項目として描いたままになりやすい。削除の理由は会話やコミットメッセージにしか残らないので、次のセッションは「これはまだ作られていないのだな」と読む。

特に AI エージェントに作業を任せる構成では危険。常騐の指示ファイルが正本文書を名指ししていると、エージェントはそれを根拠に実装を提案・着手する。人間なら「そういえばやめたはず」と思い出せるが、セッションをまたぐとその記憶は残らない。

やること

削除のコミットに含める。別バッチにしない（忘れる）。

• 正本文書の冒頭に失効注記を置く。本文を全部書き直さなくても、「以下のうち○○を前提とする部分は失効している」と日付付きで先頭に書けば足りる
• 常騐の指示ファイルに現在の位置づけと禁止事項を書く。「新規の○○には着手しない」のような肯定形の指示は、失効注記より強く働く
• 削除の根拠となった事実を一行残す。「やめた」だけだと後で判断を検証できず、同じ調査をやり直すことになる

検知方法

削除後に、消した機能名・商品名をリポジトリ全体で grep する。コードだけでなく docs・計画書・設定ファイル・コメントを含めて見る。ヒットした箇所を、「失効を明示している」か「まだやることになっている」かで仕分ける。