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. 撰写审查报告，并使用以下结构：一级标题、简短介绍、## 概述、## 发现 和 ## 结论。
9. 给出结论。 在最后一节中给出结论。

视角选择

根据差异涉及的内容，使用下表决定要加载哪些视角。 可读性始终值得作为基线视角加载。

如果差异涉及……	加载以下视角
用户输入、身份验证、网络、机密信息	安全
公共 API、模块边界	架构
CLI 输出、错误消息、默认值	用户体验
热路径、循环、查询、大型数据集	性能
新功能、错误修复、分支逻辑	测试
文档、README、文档字符串、示例	文档
其他内容	可读性（始终加载）

范围

重点关注更改的代码以及差异引入的行为。只有在解释影响或确认问题是否属实时，才查看相邻的未更改代码。

评分

分别评估影响程度和确定性。

严重程度	表情符号	含义
P1	🔴	严重：安全漏洞、数据丢失、崩溃或阻碍发布的问题
P2	🟠	重要：功能失效、严重回归或重大正确性缺陷
P3	🟡	应修复：较小的错误、覆盖率缺口或可用性问题
P4	⚪	有则更好：影响较小的润色或一致性问题

仅报告置信度 ≥ 80 的问题。对于置信度为 60–79 的问题，在末尾的“低置信度观察”部分简要提及，并明确标注为不确定。低于 60 的问题则完全省略。

报告结构

采用以下结构：

1. # Code Review
2. 一到两句背景说明
3. ## Overview
4. ## Findings
5. ## Verdict
6. 可选的 ## Lower-confidence observations

优先采用以下示例，不要添加多余的叙述。

问题格式

每个问题必须包含：

• File：带行号的位置
• Issue：用一句话描述问题
• Reasoning：说明该行为为何不正确或存在风险
• Evidence：具体代码、类型或行为
• Suggestion：具体修复方案或后续行动

如果问题来自之前的评审反馈，请添加 Source。对于 GitHub 评审，请直接链接到评审评论。

使用以下标题格式：

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

使用以下前缀：

• SEC：安全
• ARC：架构
• TST：测试
• UXD：用户体验
• RDY：可读性
• DOC：文档
• PRF：性能

使用以下类别图标：

前缀	表情符号	类别
SEC	🛡️	安全
ARC	🏗️	架构
TST	🧪	测试
UXD	🎨	用户体验
RDY	👁️	可读性
DOC	📖	文档
PRF	🚀	性能
GRP	📦	分组问题

评审呈现方式

在 ## Overview 中按以下格式列出问题：

- {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 问题。
• 阻止发布：至少有一个 P1 问题；解决阻塞项之前不要合并。

结论中的项目应写成具体的后续步骤。

技术视角

仅加载与当前差异相关的视角：

• 架构
• 文档
• 性能
• 可读性
• 安全
• 测试
• 用户体验

之前的评审反馈

如果改动已有评审评论、用户询问如何回复，或用户要求处理评审发现，请阅读评审反馈。利用这些反馈完善问题描述、核实评论是否仍然适用，并在技术评审完成后起草简洁的回复。将之前的反馈纳入评审：把每个仍然有效的问题转化为相应的技术问题。

GitHub 拉取请求

审核 GitHub 拉取请求时，先检查是否已有审核评论和未解决的讨论串。如果有，请先阅读审核者反馈和GitHub 拉取请求审核，然后再审核差异。将每项仍然成立的问题作为相应的技术发现提出，并添加一行 Source，直接链接到 GitHub 评论。当用户要求处理评论时，最后按讨论串逐一总结已实施的修复或回复、已采取的 GitHub 操作，以及任何仍待审核者提供意见的讨论串。当用户表示要处理审核发现、PR 反馈、要求的更改，或要端到端处理审核时，也采用同样的收尾方式。已修复或已充分答复的讨论串通常应执行 GitHub 操作 resolved，而不应仅仅 replied。