指摘（finding）を報告する場合は、次の規則に従ってください。

- 問題は1件ずつ分け、異なる原因や契約を1件にまとめないでください。
- 各指摘には、その状態で必要な項目を含めてください。`new` では重大度、根拠、違反している要件・契約・不変条件、具体的な影響と失敗条件、修正案を含め、場所は原則として `file:line` で示してください。`persists` では同じ `finding_id`、前回根拠、今回根拠、問題、修正案を、`resolved` では同じ `finding_id` と解消根拠を示し、`new` 専用の項目を他の状態へ一律に要求しないでください。
- 必須の実装または配線が存在せず、全経路を確認した結果として場所を1行に特定できない場合は、架空・推測の場所を付けず、確認した範囲を根拠として示してください。
- `finding_id` を使うレポートでは、各指摘に指定された形式の ID を付けてください。
- 既存指摘を継続報告する場合は同じ `finding_id` を再利用し、別の ID を採番しないでください。
- `new` / `persists` / `resolved` を使うレポートでは、各指摘に該当する状態を付けてください。
- `persists` では元の ID を維持し、`resolved` では解消を確認した具体的な根拠を示してください。
- 最終 ID や lifecycle 状態をまだ割り当てない raw finding では、それらを先に作らないでください。
- 根拠を確認できない問題を指摘として作り出さないでください。

レビューを行う場合は、次の範囲規則にも従ってください。この範囲規則はレビュー作業だけに適用し、実装・計画・修正のステップでは各ステップ固有の作業境界を維持してください。

- 次の変更対象スコープを正として扱い、自前の `git diff` が空であっても、そこに列挙されたすべてのファイルを確認してください。
{review_scope}
- スコープ欄が範囲の限定・不足・算出不能を明記している場合だけ、自前の調査で不足分を補ってください。
- 継続レビューを承認する直前に、提示された変更対象一覧を回帰確認し、修正が変更契約を壊していないことを確認してください。確認範囲と根拠はレポートの該当欄へ記録してください。
- PR Context がある場合は base から head までの累積差分を一次証拠とし、`review-target.md` と過去レポートは snapshot として扱ってください。解消判定は元要件、受入条件、現在差分に基づき、同一 PR 内の schema 変更は最終形で評価してください。