deduplicate

重複の解消

目的はひとつです。 正規の実装をひとつ配置し、すべての利用側がそれを使うようにして、知識の重複をなくします。

一般的なクリーンアップ、名前変更、レイアウトの書き換え、コードの臭い探しに範囲を広げないでください。重複ではないもの（または正しく重複を解消するために必要なもの）には手を加えないでください。

基本ルール

• ユーザーが変更を許可しない限り、動作、公開 API、データ形式を維持します。
• 偶然の構造的な類似ではなく、変更によってずれが生じる知識の重複を解消します。
• 誤った抽象化をするより、意図的な重複を少し残すほうを優先します。複数の箇所が、安定した同一の概念、名前、変更理由を共有する場合にのみ切り出します。
• その概念の既存の配置先がある場合は、そこを再利用します。競合する utils／helpers／shared の寄せ集めを新たに作らないでください。
• レビューしやすい変更を維持します。範囲が広い場合は、1 回につき重複のまとまりを 1 つ（または密接に関連するまとまり）扱います。
• 無関係なユーザーの変更を維持します。

対象範囲の設定

• 対象を限定する場合： 指定されたファイル、ディレクトリ、モジュール、機能、または重複のまとまりのみを対象にします。理解のために対象外の参照先も確認し、共有元をつなぐために必要な場合にのみ変更します。
• コードベース全体を対象とする場合： まず自プロジェクトのコードで、重複が集中している箇所を検索します。生成ファイル、ベンダーコード、ビルド出力、キャッシュ、ロックファイル、スナップショット、マイグレーションは、問題として指定されていない限り除外します。

境界が曖昧で、編集対象が変わる可能性がある場合は、焦点を絞った確認質問をひとつします。それ以外の場合は、推定した境界を示して作業を進めます。

ワークフロー

1. 候補を洗い出す

次の重複を検索します。

• ロジック／アルゴリズム／バリデーション／マッピング
• 型、インターフェース、スキーマ、定数、列挙型、設定
• 同じプロダクト概念を表現する UI の断片
• 同じドメインのフィクスチャを定義するテストのセットアップ

各まとまりについて、場所、重複している知識、確信度、正規の配置先案を記録します。

意味が異なるのに形だけ似ているまとまりや、正当な理由で異なる方向へ変化するまとまりは対象外にします。詳細はこちら：when-not-to.md。

2. 信頼できる唯一の情報源を選ぶ

対象として採用したまとまりごとに、ssot-placement.md を参考に、ひとつの配置先を選びます。

判断の順序：

1. 既存のモジュールがすでにこの概念を担っていますか？ そのモジュールを優先します。
2. そうでない場合は、すべての利用側が共有する最も狭い範囲の所有者（機能 → パッケージ → ワークスペースパッケージ）に配置します。
3. 「共有ヘルパー」ではなく、概念を表す名前を付けます。
4. 寄せ集めのファイルより、明確なエクスポートをひとつ設けることを優先します。

切り出す前、または切り出しと同時に、選んだパスとその理由を示します。

3. 切り出して参照先をつなぎ直す

1. 選んだ配置先に正規の実装を移動するか、新たに作成します。
2. すべての重複箇所を、その実装のインポートまたは合成に置き換えます。
3. 不要になったコピーを削除します。
4. テストを更新します。共有元を通じて検証し、利用側固有のテストのみローカルに残します。
5. 意味を加えずに再エクスポートするだけの「薄いラッパー」は残しません。ただし、公開境界に安定したファサードが必要な場合を除きます。

4. 検証する

変更した箇所に対して、既存のフォーマット、Lint、型チェック、テストのうち、最も対象を絞ったものを実行します。共有モジュールが複数の領域にまたがる境界にある場合にのみ、検証範囲を広げます。

チェックを実行できない場合は、実行しなかった内容と理由を伝えます。

完了報告

簡潔にまとめます。

• 調査した範囲
• 重複を解消したまとまり：概念 → 正規のパス → 以前の場所
• 変更しなかったまとまり（理由：意図的な差異、見かけ上の類似、対象範囲外、確信度が低い）
• 実行した検証と結果