# 既存システム尊重ポリシー

リリース済みまたは運用中の既存システムでは、要求達成に必要な最小差分だけを行い、既存契約を不用意に変えない。

## 原則

| 原則 | 基準 |
|------|------|
| 既存契約優先 | 既存利用者、テスト、運用が依存する契約を保持する |
| 最小差分 | 要求達成に必要な変更だけを残す |
| 近接性より必要性 | 変更箇所に近いことを変更理由にしない |
| 既存構造尊重 | ファイル配置、型名、公開API、責務境界を明示要求なしに変えない |
| コメント保全 | 意図、制約、算出根拠を示すコメントを削除しない |
| テストの契約性 | 既存テストが検証する挙動を軽微扱いしない |
| 改善の分離 | 作法改善や整理は要求と直接関係する場合に限定する |
| 保守制約優先 | 一般的な品質改善より、既存挙動と既存構造の保持を優先する |

## 変更境界

| 基準 | 判定 |
|------|------|
| 要求を満たすために不可欠な変更 | OK |
| 不可欠な変更を接続するための呼び出し元更新 | OK |
| 不可欠な変更の副作用を止めるための局所修正 | OK |
| 変更ファイル内という理由だけの整理 | REJECT |
| 明示要求のないファイル移動、型名変更、公開API変更 | REJECT |
| フレームワーク作法の改善を混ぜる | REJECT |
| 別PRで扱える改善を同時に入れる | REJECT |

## 他ポリシーとの優先順位

既存システムの保守では、coding、frontend、design-fidelity、testing などの一般的な品質基準を、要求達成に必要な範囲へ制限して適用する。

| 衝突 | 判定 |
|------|------|
| 一般品質基準は改善を推奨するが、要求には不要 | 変更しない |
| 既存構造は理想的でないが、今回の要求を満たせる | 既存構造を維持する |
| 品質基準を満たすには既存契約変更が必要 | ユーザーの明示要求または計画上の根拠が必要 |
| 不具合修正に必要な最小の構造変更 | 理由と影響範囲を明記して実施する |

## 観測可能契約

UI、アクセシビリティ、テスト、ログ、API、型、ファイル配置、コメントは、外部利用者または開発者が観測する契約になりうる。

| 契約 | 変更条件 |
|------|----------|
| UI文言、アクセシビリティ名、role/state | 要求に直接含まれる場合のみ変更する |
| hook の戻り値、Props 型名、公開関数名 | 呼び出し元更新が要求達成に不可欠な場合のみ変更する |
| テスト期待値 | 仕様変更が要求されている場合のみ変更する |
| コメント | 誤りを直す場合、またはコードで完全に不要になった場合のみ変更する |
| ファイル配置 | 既存構造では要求を満たせない場合のみ変更する |

## テスト変更

テストは実装へ追随させるものではなく、既存契約と新要求を区別するために使う。

| パターン | 判定 |
|---------|------|
| 新要求を検証するテスト追加 | OK |
| 既存契約を守るための回帰テスト追加 | OK |
| 実装変更に合わせて既存期待値を緩和するだけ | REJECT |
| テスト対象の既存挙動を削除してテストを通す | REJECT |
| テストが邪魔という理由で削除する | REJECT |

## 完了前確認

完了前に、全差分を「必須変更」「関連変更」「不要変更」に分類する。不要変更が残っている場合は完了してはならない。

| 分類 | 基準 |
|------|------|
| 必須変更 | これがないと要求を満たせない |
| 関連変更 | 必須変更を接続、検証、整合させるために必要 |
| 不要変更 | 読みやすさ、作法、ついで整理、将来拡張だけが理由 |
