tenzir-review-changes

変更のレビュー

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

プロセス

徹底的かつ効率的にレビューするため、次の手順に従ってください。

1. 意図を把握します。 PR の説明、コミットメッセージ、関連する イシュー、既存のレビュー担当者からのフィードバックを読みます。評価する前に、変更が 何を目指しているのか を把握してください。
2. 必要に応じて、過去のフィードバックに関するガイダンスを読みます。 レビューにすでに コメントやメモがある場合は、差分をレビューする前に references/reviewer-feedback.md を読み、そのフィードバックが今も有効か、どのように 対応するかを確認してください。変更が GitHub のプルリクエストにある場合、 指摘への対応依頼、PR のフィードバック、レビューコメント、変更依頼、またはエンドツーエンドの レビューのフォローアップは、既存の GitHub レビューフィードバックへの対応依頼として扱います。 まず有効なコメントを集め、未解決の各スレッドを追跡し、今も有効な懸念事項を 関連する技術的な観点に対応付け、その一覧を実装、返信、最終的なスレッド状態まで 引き継いでください。GitHub のプルリクエストでは、スレッドの状態、返信、解決に関する ガイダンスとして references/github-pr-reviews.md も読んでください。
3. 対象範囲を確認します。 差分全体に目を通し、変更が及ぶ範囲（ファイル、モジュール、 レイヤー）を把握します。これに基づいて、読み込む観点を決めます。
4. 観点を選択します。 該当する技術的な観点を選ぶには、以下の表を使ってください。 該当するものだけを読み込み、それ以外は省略します。読みやすさは常に基本となる観点です。
5. ファイルごとにレビューします。 ファイルごとに差分を確認します。影響を説明したり、 問題が実在するかを検証したりするために必要な場合に限り、変更されていない周辺コードも 確認してください。過去のレビュー担当者からのフィードバックを繰り返したり支持したりする前に、 最新のコードに照らして再確認します。
6. 内容を統合します。 ファイルごとの確認を終えたら、まとめられる根本原因がないかを調べます。 異なるファイルに現れた複数の症状が、同じ根本的な問題に起因する場合があります。 そのような場合は、個別の指摘ではなく、まとめた指摘として提示してください。
7. 依頼されたレビューへの対応を完了します。 タスクにレビュー指摘、PR コメント、変更依頼、 または PR フィードバックへの対応が含まれる場合は、受け入れた変更を実装し、関連する チェックを実行してから、未解決スレッドの一覧を再確認します。懸念事項が修正済み、または 完全に回答済みのスレッドは、それぞれ解決してください。解決を別途許可が必要な手順とせず、 タスクの一環として実施します。背景の説明が役立つ場合は、解決する前に簡潔な返信を投稿します。 レビュアーの判断がまだ必要な場合、意見の相違が解消されていない場合、内容が曖昧な場合、 または利用可能な GitHub 権限では解決できない場合に限り、スレッドを未解決のままにします。 その場合は、明確な質問またはトレードオフの説明を追加してください。
8. 以下のレポート構成を使ってレビューをまとめます。H1、短い導入、 ## 概要、## 指摘事項、## 判定 の順に記載します。
9. 判定を出します。 最終セクションで判定を提示します。

観点の選択

差分の変更箇所に応じて、読み込む観点を判断するには以下の表を使ってください。 読みやすさは常に読み込む基本の観点です。

差分が次の内容に触れている場合…	読み込む観点
ユーザー入力、認証、ネットワーク、シークレット	セキュリティ
パブリック API、モジュール境界	アーキテクチャ
CLI の出力、エラーメッセージ、デフォルト値	UX
ホットパス、ループ、クエリー、大量データ	パフォーマンス
新機能、バグ修正、分岐ロジック	テスト
ドキュメント、README、docstring、例	ドキュメント
その他すべて	読みやすさ（常に適用）

対象範囲

差分によって導入された変更コードと動作に焦点を当てます。影響を説明したり、 問題が実在するかを検証したりするために必要な場合に限り、変更されていない周辺コードも 確認してください。

評価

影響度と確信度を分けて評価してください。

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

確信度が 80 以上の指摘を報告してください。確信度が 60〜79 の指摘は、末尾の「確信度の低い所見」セクションで、不確実であることを明記して簡潔に述べてください。60 未満の指摘は完全に除外してください。

レポートの構成

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

1. # コードレビュー
2. 背景を説明する文を 1〜2 文
3. ## 概要
4. ## 指摘事項
5. ## 判定
6. 任意の ## 確信度の低い所見

説明を増やすより、以下の例を優先してください。

指摘事項の形式

各指摘には次の項目を含めてください。

• ファイル：行番号を含む場所
• 問題：問題点を述べる 1 文
• 理由：その挙動が誤っている、または危険な理由
• 根拠：具体的なコード、型、または挙動
• 提案：具体的な修正方法または次の対応

指摘が過去のレビューコメントに由来する場合は、出典を追加してください。GitHub のレビューでは、レビューコメントに直接リンクしてください。

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

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

次の接頭辞を使用してください。

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

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

接頭辞	絵文字	カテゴリ
SEC	🛡️	セキュリティ
ARC	🏗️	アーキテクチャ
TST	🧪	テスト
UXD	🎨	ユーザー体験
RDY	👁️	可読性
DOC	📖	ドキュメント
PRF	🚀	パフォーマンス
GRP	📦	グループ化した指摘

レビューの提示方法

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

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

重大度の高い順、次に確信度の高い順で並べてください。根本原因が共通する場合に限り、指摘をまとめてください。

実行可能性

具体的で再現可能であり、現在の変更に対して対応コストが低い指摘を優先してください。通常規模の差分では、出力をおよそ 8 件までにしてください。質の高い指摘には、具体的な根拠があり、変更によって生じる挙動に直接関係し、リスクを説明し、PR の範囲内で実行可能な修正案が含まれます。プロジェクトですでに自動チェックされている場合、スタイル、書式、機械的な一貫性の問題はツールで対処するものとして扱ってください。

レイアウト例

# 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.

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

• そのままマージ可：指摘がない、または P4 の軽微な指摘のみ。
• 修正後にマージ可：P3 以下の指摘のみで、マージを妨げるものがない。
• 要修正：マージ前に解決すべき P2 の指摘が 1 件以上ある。
• ブロック：P1 の指摘が 1 件以上ある。ブロッカーが解決するまでマージを保留する。

判定の箇条書きは、具体的な次の対応として記述してください。

技術的な観点

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

• アーキテクチャ
• ドキュメント
• パフォーマンス
• 可読性
• セキュリティ
• テスト
• ユーザー体験

過去のレビュアーからのフィードバック

変更にすでにレビューコメントがある場合、ユーザーが対応方法を尋ねている場合、またはユーザーがレビュー指摘への対応を求めている場合は、レビュアーのフィードバックを読んでください。その情報を使って指摘を明確にし、コメントが現在も該当するか確認し、技術レビューの完了後に簡潔な回答を作成してください。現在も有効な懸念は、それぞれ適切な技術的指摘に反映してください。

GitHub のプルリクエスト

GitHub のプルリクエストをレビューする際は、まず既存のレビューコメントと未解決のスレッドを確認してください。存在する場合は、差分をレビューする前に レビュー担当者からのフィードバックと GitHub のプルリクエストレビューを読んでください。現在も有効な懸念事項はそれぞれ適切な技術的指摘として取り上げ、GitHub のコメントに直接リンクする Source 行を追加してください。ユーザーからコメントへの対応を求められた場合は、実装した修正または回答、実行した GitHub の操作、レビュー担当者の入力待ちとして残したスレッドを記録した、スレッドごとの要約で締めくくってください。ユーザーがレビュー指摘、PR のフィードバック、変更依頼への対応、またはレビュー全体への対応を求めた場合も、同じ方法で締めくくってください。修正済み、または十分に回答済みのスレッドに対する GitHub の操作は、通常 replied ではなく resolved にしてください。