{{include:policies/finding-validity}}

{{include:policies/evidence-based-judgment}}

**修正計画の有効性:**
- 各指摘のIDと、正本に裏付けられた問題、受入条件、修正境界を維持し、指摘の根拠は現在のコードへ再照合してください。レビュアーが示した修正方法は候補として扱い、要求、仕様、schema、公開契約より優先しないでください
- 同じ原因、破られる観測可能な条件、受入条件を持つ指摘は、報告場所ごとに分断せず1つの修正として計画してください。名前、型、ファイル上の近さだけを統合の根拠にせず、原因または受入条件が異なる問題は分けてください
- 定義元から生成、変換、検証、保存、復元、利用箇所、外部から観測できる結果まで、受入条件の成立に必要な実在経路をコードとデータフローから確認してください。代表箇所だけで完了とせず、関係のない隣接契約へ範囲を広げないでください
- enum、状態遷移、入力形式、候補順序、件数上限などが問題に関係する場合は、仕様または現在のコードで適用を確認できる値と境界だけを具体化してください。根拠のない値や組み合わせを網羅項目として追加しないでください
- 各経路について、変更、移行または削除、確認のみのどれを行うかを明確にしてください。共有箇所の変更だけで条件を満たす利用側は、対称性のために編集せず確認対象としてください
- 言語、runtime、標準ライブラリ、依存ライブラリの挙動を原因または検証根拠に使う場合は、対象コード、型・API仕様、または提供された記録済み結果から実際の入力と結果を確かめてください
- テストを簡単にすることや命名を整えることだけを理由に、非公開の定義を公開したり、公開schemaやfield名を変更したり、本番用の列挙APIを追加したりしないでください
- 修正方法、検証方法、完了条件を、要求、現在のコード、公開契約へ照合してください。タスクに関係する判断基準や参考資料が示されていれば反映し、完了条件は外部から観測可能にしてください
- 検証は対象の契約経路を通り、問題が残っていれば失敗できる観測点を持たせてください。静的な条件は、現在のコード、型、schema の照合で確認してください
- 修正計画の見直しが必要なのは、原因、修正境界、必要な影響経路、修正方法、受入条件、検証方法の不足または矛盾を計画の変更で解消できる場合です。計画どおりの実装や証拠が不足しているだけの場合と区別してください