review-changes

変更のレビュー

変更されたコードを、重要度と確信度を明示してレビューします。

手順

徹底的かつ効率的なレビューを行うには、次の順序に従います。

1. 意図を把握します。 PR の説明、コミットメッセージ、関連する イシュー、既存のレビューフィードバックを読みます。評価する前に、変更が 何を実現しようとしているのか を把握します。
2. 必要に応じて、過去のフィードバックに関するガイダンスを読み込みます。 レビューに コメントやメモがすでにある場合は、差分をレビューする前に references/reviewer-feedback.md を読み、フィードバックが今も有効か、 どのように対応すべきかを確認します。ユーザーから既存の GitHub レビュー フィードバックへの対応を求められた場合は、まず有効なコメントを収集し、 現在も有効な懸念事項をそれぞれ該当する技術的な観点に対応付けて、 通常の指摘形式で提示してから、返信または解決の方法を決めます。GitHub の プルリクエストでは、スレッドの状態、返信、解決方法に関するガイダンスとして、 references/github-pr-reviews.md も読みます。
3. 対象範囲を確認します。 差分全体をざっと読み、対象となる領域（ファイル、 モジュール、レイヤー）を把握します。どの観点を読み込むべきかを判断します。
4. 観点を選択します。 下の表を使って、該当する技術的な観点を選びます。 該当するものだけを読み込み、残りは読み飛ばします。可読性は常に ベースラインとして扱います。
5. ファイルごとにレビューします。 差分をファイルごとに確認します。影響を 説明したり、問題が実在するかを検証したりするために必要な場合に限り、 変更されていない隣接コードを参照します。既存のレビューフィードバックを 繰り返したり支持したりする前に、最新のコードに照らして再確認します。
6. 統合します。 ファイルごとの確認後、まとめられる根本原因を探します。 複数のファイルに現れる症状が、共通の根本的な問題に由来する場合は、 別々の項目ではなく、まとめた指摘として提示します。
7. 以下のレポート構成に従ってレビューを作成します。 H1、短い 導入、## Overview、## Findings、## Verdict の順に記載します。
8. 最終セクションで判定を示します。

観点の選択

差分の対象に応じて、読み込む観点を次の表から判断します。 可読性は常にベースラインとして読み込む価値があります。

差分の対象…	読み込む観点
ユーザー入力、認証、ネットワーク、シークレット	セキュリティ
公開 API、モジュール境界	アーキテクチャ
CLI 出力、エラーメッセージ、デフォルト値	UX
ホットパス、ループ、クエリ、大規模データ	パフォーマンス
新機能、バグ修正、分岐ロジック	テスト
ドキュメント、README、ドックストリング、例	ドキュメント
その他すべて	可読性（常に有効）

対象範囲

変更されたコードと、差分によって導入された動作に注目します。影響を説明したり、 問題が実在するかを検証したりするために必要な場合に限り、変更されていない 隣接コードを参照します。

評価

影響度と確実性は別々に評価します。

重要度	絵文字	意味
P1	🔴	致命的：セキュリティ上の欠陥、データ損失、クラッシュ、リリースを妨げる問題
P2	🟠	重要：機能の破損、深刻なリグレッション、重大な正確性の欠如
P3	🟡	修正すべき：小規模なバグ、テスト範囲の不足、使い勝手の問題
P4	⚪	あれば望ましい：影響の小さい仕上げや一貫性の問題

確信度が 80 以上の指摘を報告します。60～79 の指摘は、末尾の 「確信度の低い所見」セクションに簡潔に記載し、不確実であることを明示します。 60 未満の指摘は記載しません。

レポートの構成

次の形式を使用します。

1. # Code Review
2. 背景を説明する1〜2文
3. ## Overview
4. ## Findings
5. ## Verdict
6. 任意で ## Lower-confidence observations

説明を長々と追加するより、以下の例を優先してください。

指摘の形式

各指摘には、次の内容を含めてください。

• File：行番号を含む場所
• Issue：問題を1文で説明
• Reasoning：その動作が誤りである、またはリスクがある理由
• Evidence：具体的なコード、型、または動作
• Suggestion：具体的な修正案または次のアクション

指摘が以前のレビューのフィードバックに基づく場合は、Source を追加してください。GitHub のレビューでは、レビューコメントに直接リンクしてください。

次の見出し形式を使用してください。

### 🟠 P2 · 🛡️ SEC-1 · Missing authorization check · 92%

次のプレフィックスを使用してください。

• SEC：セキュリティ
• ARC：アーキテクチャ
• TST：テスト
• UXD：ユーザー体験
• RDY：可読性
• DOC：ドキュメント
• PRF：パフォーマンス

次のカテゴリのアイコンを使用してください。

Prefix	Emoji	Category
SEC	🛡️	セキュリティ
ARC	🏗️	アーキテクチャ
TST	🧪	テスト
UXD	🎨	ユーザー体験
RDY	👁️	可読性
DOC	📖	ドキュメント
PRF	🚀	パフォーマンス
GRP	📦	グループ化された指摘

レビューの提示方法

## Overview では、次のように指摘を列挙してください。

- {severity_emoji} {severity} · {category_emoji} {id} · {title} ({confidence}%) · {file}:{line}

まず深刻度の高い順に、その後、確信度の高い順に並べてください。根本原因が共通する場合に限り、指摘をまとめてください。

対応のしやすさ

現在の変更で対応できる、具体的で再現可能な指摘を優先してください。通常の規模の差分では、出力する指摘はおよそ8件までにしてください。

次のような指摘は避けてください。

• 具体的な根拠のない推測的な懸念
• ツールで既に強制されているスタイル上の細かな指摘
• 明確なリスクを伴わない書き換えの提案
• 差分の対象外にある既存の問題
• 無関係な範囲への拡大

レイアウト例

# Code Review

I reviewed the BITZ parser changes with a focus on payload validation and test
coverage. I found one P2 issue and one P3 gap.

## Overview

- 🟠 P2 · 🛡️ SEC-1 · Corrupted BITZ frames are accepted if garbage follows a valid Arrow stream (96%) · libtenzir/builtins/formats/bitz.cpp:209
- 🟡 P3 · 🧪 TST-1 · The new tests miss payload-corruption and compatibility coverage (93%) · test/tests/operators/bitz/round_trip.tql:1

## Findings

### 🟠 P2 · 🛡️ SEC-1 · Corrupted BITZ frames are accepted if garbage follows a valid Arrow stream · 96%

- File: libtenzir/builtins/formats/bitz.cpp:209-247
- Issue: ...
- Reasoning: ...
- Evidence: ...
- Suggestion: ...

### 🟡 P3 · 🧪 TST-1 · The new tests miss payload-corruption and compatibility coverage · 93%

- File: test/tests/operators/bitz/round_trip.tql:1-6
- Issue: ...
- Reasoning: ...
- Evidence: ...
- Suggestion: ...

## Verdict

**Needs changes**

| 🔴 P1 | 🟠 P2 | 🟡 P3 | ⚪ P4 |
| :---: | :---: | :---: | :---: |
|   0   |   1   |   1   |   0   |

- Reject BITZ frames that contain unread tail bytes after the embedded Feather stream.
- Add a regression test for malformed message payloads and a mixed legacy/new compatibility fixture.
- Merge after the parser validation bug is fixed.

判定ラベルには、次のいずれかを使用してください。

• Ship it：指摘がない、またはP4の軽微な指摘のみ。
• Ship with fixes：P3以下の指摘があり、ブロッカーはない。
• Needs changes：マージ前に解決すべきP2の指摘が1件以上ある。
• Blocked：P1の指摘が1件以上ある。マージしないでください。

判定の箇条書きには、具体的な次のアクションを記載してください。

技術的な観点

現在の差分に関係する観点のみ読み込んでください。

• architecture
• documentation
• performance
• readability
• security
• tests
• user experience

以前のレビュアーからのフィードバック

変更に既存のレビューコメントがある場合、またはユーザーがその返答方法を尋ねている場合は、レビュアーからのフィードバックを読んでください。その内容を使って指摘を明確にし、コメントがまだ該当するか確認してから、技術レビューの完了後に簡潔な返答を作成してください。以前のフィードバックにある有効な懸念事項は、それぞれ適切な技術的指摘に反映してください。

GitHub のプルリクエスト

GitHub のプルリクエストをレビューするときは、既存のレビューコメントと未解決のスレッドを最初に確認してください。該当するものがある場合は、差分をレビューする前にレビュアーからのフィードバックとGitHub プルリクエストのレビューを読んでください。まだ有効な懸念事項は、それぞれ適切な技術的指摘として提示し、GitHub のコメントに直接リンクする Source 行を追加してください。返信するか、解決するか、さらに議論するか、スレッドを開いたままにするかは、GitHub 固有のリファレンスに従って判断してください。