機能・モード・一部ツールを破壊的に削除したあと、公開や外部ディレクトリ/ストアへの提出直前に行うドキュメント最終チェックは、利用者向けの公開ドキュメントだけを見ると不十分になりやすい。古い前提の記述は、検査者が見落としやすい場所に残る。

どこに古い記述が残るか

• 配布物（パッケージ同梱物）に含まれない内部の開発者向けドキュメント（貢献者ガイドや AI 向け指示ファイル等）。同梱対象から外れていても公開リポジトリ上には残り、審査者が閲覧しうる。
• 開発用の設定ファイル（ローカル接続定義など）。削除した起動方式や廃止した環境変数を指したまま壊れていることがある。
• メタデータ（バージョン、エントリポイント、起動スクリプト）とその説明文の食い違い。 公開ドキュメント本体は普通に確認されるので、むしろ上記の周辺ファイルを明示的に対象に含めるのが要点。

審査フォームがVCSブランチを指す場合の落とし穴

提出フォームに記載するドキュメントURLが、リポジトリの特定ブランチ（main 等）の生ファイルを指していることがある。この場合、ローカルの作業ツリーで修正済みでもコミット・push していなければ、審査者はそのURLで古い内容を見る。よって公開ドキュメントの修正をコミットして提出先ブランチへ反映することが、提出を実際に通すための前提工程になる。「修正済み」と「反映済み」を混同しない。

バージョンとタグの整合

機能やツールの削除は後方非互換なので、セマンティックバージョニングでは原則 MAJOR を上げる（新規追加だけなら MINOR）。さらに、すでに発行済みのタグや公開済みのパッケージバージョンは再利用できないため、据え置きのままだと公開・タグ付けが失敗する。提出前にバージョンを上げ、提出物の正本（公開版）とドキュメント内容を一致させる。

検証観点

削除した方式に固有のキーワード（廃止コマンド名、削除ツール名、廃止した環境変数、旧トランスポート名）を、公開docs・内部docs・設定ファイル・スクリプト説明まで横断検索して残存ゼロを確認する。提出フォームに載せる各URLを実際に開いて最新内容が返ることを確認する。実際に登録される機能一覧（ツール一覧など）とドキュメントの一覧を機械的に突き合わせ、過不足が無いか確認する。