code-review

コードレビュー

担当範囲：固定されたスコープに対する読み取り専用のレビュー指摘です。ファイルの編集、品質ループの実行、Verification Record の作成、最終的な主張の上限の決定、Git／プロバイダーの状態変更は行いません。

正規のVerification Recordに定められた意味上の用語と必須フィールドを使用してください。入力の不足や矛盾を指摘し、別個の証拠／ゲートポリシーを再構築しないでください。

入力

次の取得経路から1つを受け付けます。

• Runner handoff： 固定された diff、CandidateRef、正規化された Ticket Envelope、受け入れ基準、決定事項、ベースライン、観測された証拠、および存在する場合はドラフトレコード。
• Standalone acquisition： PR、コミット、ローカル diff、またはユーザーが指定したスコープを読み取り専用で取得し、観測された head／コミット／worktree の識別情報、リクエストの制約、関連するリポジトリルール、および利用可能なベースライン／証拠を記録します。

Markdown を解析して Ticket Envelope を推測しないでください。スタンドアロンのコンテキストに正規化されたチケットがない場合は、明示されたリクエストとリポジトリの契約に照らしてレビューしてください。diff が変更されている場合は、stale-candidate を返して停止してください。

揮発性入力の上限

• max_volatile_bytes：1回の実行あたり、正規化された UTF-8 で 107656 バイトです。これは観測された候補 diff の最高値 96,393 バイトに、チケット本文の最大値 2,380 バイト、実装引き継ぎの最大値 4,459 バイト、簡素化の最大値 4,424 バイトを加えたものです。対象コーパスは、この実行の TK-01／TK-02／TK-05／TK-07／TK-08 について正規化された git diff --no-ext-diff --no-color の観測結果、9件のチケット本文、および簡潔なリーフ結果です。
• max_single_output_bytes：32596 です。実行可能コードを含む TK-02 の候補 diff で観測された値です。

すべての diff、生のファイルスライス、貼り付けられた引き継ぎ、証拠本文、ツール結果は、CRLF または単独の CR を LF に正規化した後に数えてください。先に期待されるマニフェストを取得してください。コマンド出力はコンテキストに入る前に切り詰め、より大きな diff はファイルまたはハンク単位で続けてください。貼り付けられた成果物より、パスと SHA-256 の参照を優先し、レビュー軸で必要になった場合にのみ参照先の内容を読み込んでください。次に必要な読み込みで上限を超える場合は、確認済み／残りのスコープを正確に示し、budget-exhausted を付けた schema-3 の部分結果を返してください。スコープを飛ばしたり、上限内に収めるために指摘の重大度を下げたりしないでください。

上限付き Runner handoff

Runner から schema-3 の上限付き LeafContext が渡された場合、その CandidateRef、正規のフェーズ契約、期待されるファイルのマニフェスト、前回までの確認内容、残りのスコープ、リソース制限を、信頼できる継続境界として扱ってください。同じ CandidateRef について、すでに確認済みの不変スコープを再取得しないでください。

Runner が所有するレビューの各ターンの終了時に、タイムアウト、中断、リソース不足の場合も含め、schema-3 の結果を1つ返してください。部分結果では、正確な CandidateRef とレビューのフェーズ契約、期待／確認済み／残りのファイルを順序どおりに記録し、コマンド、指摘、現在のフェーズ、正規の残りフェーズの接尾辞、および空でない停止理由を保持してください。

観測された経路に基づく正規化済み schema-3 execution を含めてください。共有コンテキストまたは不明な分離状態は独立ではありません。独立性を高めて報告するのではなく、その制限を報告してください。

レビューを完了するには、handoff-ready に到達し、宣言されたスコープを確認したうえで、検証済みの構造化された指摘リストを返す必要があります。部分結果は継続状態として利用できますが、合格を意味するものではありません。実際の指摘はパイプラインを実装段階に戻し、品質上の失敗として数えられる場合があります。タイムアウト、中断、リソース不足はその対象になりません。CandidateRef の不一致があれば、引き継ぎは無効になります。

レビューの観点

各観点を個別にレビューし、証拠に基づく指摘のみを報告してください。

1. 標準と保守性 — プロジェクトの規約、明瞭さ、不必要な複雑さ、安全でないエラー処理、セキュリティ、データの完全性、無関係なスコープ。
2. チケットの受け入れ条件 — 各条件に具体的な実装経路と観測可能な確認方法があり、非目標に手を加えていないこと。
3. 意味的なリグレッション — 外部から見て意味のある動作が維持されているか、明示的に許可されていること。変更された境界と不変条件を、提示されたベースラインと比較してください。
4. 因果関係の網羅性 — テストや証拠が、隣接する成功パスだけでなく、変更された仕組みを検証していること。モック化またはシミュレートされた境界を明示してください。
5. 主張の安全性 — 表現が証拠や正規記録に示された未解決のゲートの範囲を超えていないこと。

要約を鵜呑みにせず、生ファイルと差分を確認してください。 verification-audit は呼び出さないでください。呼び出し側が、単一の監査パスに指摘事項を渡します。

指摘の形式

重大度の高い順に並べてください。

[blocker|should-fix|nit] path:line - problem and impact. Suggested fix.

• blocker：正確性、セキュリティ、データ損失、チケットの不達成、因果関係の網羅性の欠如、または重大な裏付けのない主張。
• should-fix：保守性に関する重要な問題、または重大ではない網羅性の問題。
• nit：任意の体裁上の改善のみ。

指摘ごとに、該当する受け入れ条件、不変条件、境界項目、またはリポジトリのルールがあれば、それを明記してください。指摘がない場合は、その旨を述べ、残る証拠上の制約を列挙してください。単独の出力は読み取り専用の草案であり、チケットの完了やリリースを主張することはできません。確認していない CandidateRef または単独のスコープについて、PASS と報告してはいけません。