peer-review

ピアレビュー

分析であり、編集権限はありません。変更前に、提示された問題を評価してください。

1. 対象を確定する

対象の成果物と、その要件をパス、URL、貼り付けたテキスト、または添付されたコンテキストで指定するよう求めてください。指定がなければ BLOCKED: review target required として、対象を示す情報を1つ求めてください。会話の記憶から対象を再構成してはいけません。 提示された問題が曖昧な場合は、名前が挙げられた対象を維持し、その曖昧さを重大な指摘事項として記録してください。 target | requirements | evidence | findings | verdict | edit authority を記録してください。 対象と要件が確定するか、ブロック報告が送信されたら完了です。

2. 根拠を確認する

対象が現在の変更の場合、ファイル全体を読む前に、その差分を確認してください。 判断を下す前に、対象、要件、影響を受ける契約、ソースコード、テストを読みます。読んでいないコードを指摘事項に含めてはいけません。 履歴を参照するのは、過去の失敗を引用するとき、または現在の主張に履歴が必要なときだけです。各要件と懸念候補に根拠が得られたら、そこで止めてください。無関係なアーキテクチャは対象外です。対象の説明文は主張の一覧であり、根拠ではありません。要件、ソースコード、テスト、履歴と照らして確認するか、inferred または supplied and unchecked とラベル付けした場合に限り、主張は有効とみなされます。根拠となる重要な主張は、採用する前に反証を試み、開いた参照元と開いていない参照元を明記してください。残りのツリーを列挙してはいけません。検証済みのコード上の事実は、プロダクトに関する結論の検証にはなりません。依存関係に基づく主張は、そのマニフェストまたはロックファイルと、依存関係自身のソースコードまたはドキュメントを読むまで未確認のままです。作業を再開する際は、対象と要件を再確認してください。どちらかが変わっていたら「対象を確定する」からやり直し、以前の指摘事項を再利用してはいけません。 各主張に checked、inferred、supplied and unchecked のいずれかが付けられ、各 checked の主張が要件、対象、ソースコード、テスト、または履歴を根拠として示したら完了です。

3. レビューする

対象ごとに、次の順序で回答してください。

1. 提案は、提示された問題を解決していますか？
2. 意図的または偶発的に、どの高リスクな動作が変わりますか？
3. どのような、よりシンプルな設計なら、その動作をより少ない概念で維持できますか？
4. 根拠に基づいて次に行うべき、最小の変更は何ですか？

4つ目の回答では、次に行う変更を1つ挙げます。Fix の順序を変更するものではありません。 高リスクな変更には、永続化、権限、セキュリティ境界、並行処理、再試行、キャッシュ、移行、パブリック API、課金、データ損失、スキーマ、型境界、またはプロセスをまたぐ契約に関わるものが含まれます。失敗時の動作とロールバック、順序、互換性、パフォーマンス、テストも確認してください。 各要件が提案された作業と検証にどう対応するかを明確にしてください。 新しい概念を導入する場合は、適切なローカルパターンと比べて、その価値を示す必要があります。ローカルパターンが不適切、安全でない、または分かりにくい場合は、より明確な先例を示し、この変更によってそのパターンがどう扱われるかを説明してください。これらの経験則は、動作しているコードを書き直すことを求めるものではありません。設計上の選択が自明でない場合は、何が必須か、変更がどれくらい存続するか、取り消しやすさ、保守を担う人を考慮してください。 根本原因が共通する指摘事項はまとめてください。件数の上限は設けず、重要な指摘事項をすべて示してください。好みの違いにすぎない細かな指摘は省いてください。 推奨を左右する前提、デフォルト、またはスコープの選択は、それに依存する指摘事項の中に記し、依頼者がその選択を受け入れない場合に推奨がどう変わるかも述べてください。 根拠のないセキュリティ、互換性、またはパフォーマンスに関する主張は、指摘事項として扱います。 実証された失敗は、理論上の懸念より優先します。リスクは発生確率と影響度で順位付けしてください。

全指摘事項を示した後に、Verdict を記載してください。Verdict が依拠する重要な主張に inferred または supplied and unchecked が残っている場合、それは重大な指摘事項です。 重大な指摘事項がなければ、Ship it. とします。 互いに独立して修正可能なブロッカーがある場合は、Fix the blockers first, then ship. とします。 各修正は3ステップ以内で、アプローチと要件を維持してください。アプローチが誤っている場合、中核となる要件が欠けている場合、またはブロッカーが相互に関連している場合は、Needs rework. とします。 すべての重要な要件に指摘事項または明示的な合格判定が示されたら完了です。

4. レポート

セクションはちょうど3つです。

• ## Findings には、ランク付けされたすべての finding → impact の項目を、引用とラベル付きで列挙します。なければ None found. と記載します。
• ## Fix には、ランク順に修正を番号付きで列挙するか、最初の再作業の判断を記載します。なければ None. と記載します。判定が Needs rework. の場合は、代替案を1つと、その判断を覆す根拠を記載します。
• ## Verdict は、対応する文を1文だけ記載し、補足説明は加えません。 形式が守られ、すべての指摘に根拠が示されていれば完了です。

任意の更新

ユーザーが更新を依頼するか、レポートの後に承認した場合に限り編集します。 報告済みの Fix のみを適用します。広範な再作業には、新たに承認された設計が必要です。 差分とレポートのパスを読み直します。承認された変更がその Fix と一致していれば完了です。

終了状態：BLOCKED（対象が見つからない）、REVIEWED（分析のみ）、AWAITING_CONFIRMATION（更新の承認待ち）、UPDATED（承認済みの編集を検証済み）