针对工单审查 Pull Request
Pull Request 之前的最后一道关卡。它回答一个问题——此差异是否在架构约束范围内交付了工单？——并依据两个比审查者品味更优先的来源来回答：验收标准和参考架构。
此审查是阅读和报告。它不进行编辑：一个自行修复所发现问题的审查会破坏错误的证据，并且没有人能学到模式。
三个阶段中的最后一个阶段，位于 TICKET-ANALYSIS.md 和 IMPLEMENTATION-PHASE.md 之后。WORKFLOW.md 说明了它们如何组合在一起以及如何安装它们。
目录
1. 确定差异
将分支与仓库的实际基础分支进行差异比较，而不是基于假设。审查每一个更改过的文件；一个因为看起来无聊而被跳过的文件，正是配置更改隐藏的地方。
记录差异中涉及但工单未提及的内容。该列表是第 §2 节和第 §5 节的输入，尚不构成一个发现项。
2. 验收标准优先
逐一处理验收标准，并为每个标准指明满足它的代码和证明它的测试。两者缺一不可，否则视为未满足。
- 有代码但无测试的标准是未经证明的。
- 有测试但无代码的标准是测试框架本身的断言。
- 根本无法定位到的标准是审查中最关键的发现项，其优先级高于审查中的任何风格观察。
然后是另一个方向：没有对应标准的变更。 其中一些是合理的——在已更改代码内部进行的修复（IMPLEMENTATION-PHASE.md §2）。其余的是范围蔓延，在此处指出的成本比在发布后解释要低。
3. 架构审查环节
针对差异涉及的层次，逐项检查合规性检查清单。最有价值的发现项是那些通过构建无法展示的：
- P2 — 任何领域相关的内容添加到共享内核：实体、DTO、枚举、种子数据集、定价常量、面向用户的字符串。
- P3 — 跨上下文的读取或写入；第二个服务访问所属服务的数据库。
- P4 — 未经迁移就更改了模式，或者一个迁移不具有提供程序可移植性。
- P5 — 秘密、密钥或连接字符串出现在源代码、配置文件或注释中；从非环境变量位置读取配置。
- P8 — 一个新的依赖项在启动时失败而不是降级，或者该依赖项在健康检查端点和启动横幅中缺失。
- P9 / P10 — 将连线内联在
Program.cs中；新增扩展点作为基类而不是通过 DI 注册的接口。 - P11 — 外部形态未经转换就到达领域层。
- P15 — 新增路径没有追踪、指标或日志。
SERVICE-API-PATTERNS.md— 端点位于信任组之外、未限定的列表、非统一的错误体、没有显式超时的出站调用、重试的非确定性写入。- 安全性 — 任何新暴露给公众的内容，在发布前必须通过
SECURITY-REVIEW.md审查环节，而不是之后。
如果 Pull Request 中记录了偏离决策及其原因，则不算作一个发现项。相同的偏离行为，如果保持沉默，则构成一个发现项——这正是 P14 原则发挥作用的地方。
4. 测试审查环节
阅读测试主体。测试数量、文件数量和文件夹结构证明不了什么；对一个包含 447 个测试的套件在 2026-08-14 进行的审计发现，其中大约 45% 是占位符或通过守卫条件阻止了任何断言，而这些从外部完全不可见（P13）。
- 每个新测试是否处于持有逻辑的适当层次，还是说浏览器被用来替代验证器？
- 它会断言一个结果，还是断言一个按钮被点击过？
- 差异涉及的每个现有路径是否存在回归测试，还是只为新分支编写了测试？
- 测试是否满足每条用例的基准——独立性、使用
data-testid、没有睡眠等待、没有生产凭据（TESTING-STRATEGY.md§6）？ - 是否有任何新的测试入口点在 CI 上下文中被执行（§9）？
5. 严重性等级与裁决
对每个发现项进行排名，根据其后果而非描述难度来排名：
| 等级 | 含义 |
|---|---|
| 阻塞 | 验收标准未满足或未经证明；原则被违反且无记录决策；秘密暴露；测试被削弱或删除以通过构建 |
| 应修复 | 功能正确但模式不符：错误的测试层次、缺少回归覆盖、未记录的假设、文档因变更而过时 |
| 考虑 | 真正的可选问题。保持此部分简短——过长会掩盖前两个等级 |
以协议图中关卡需要的裁决作为结尾，并明确说明：此 Pull Request 是否交付了工单，并且是否在架构约束范围内？ 可能的三个答案之一——已验证通过；已验证通过，带有上述非阻塞性发现项；或未验证通过，并列出阻塞性发现项。"看起来不错，有些评论"不是一种裁决。
6. 失败模式
| 症状 | 原因 |
|---|---|
| 审查批准了一个遗漏需求的差异 | 审查环节从代码开始而不是从验收标准开始 |
| 审查结果是一堆风格意见 | 由于构建通过了，架构和测试审查环节被跳过——而这正是它们要检查的内容 |
| 将通过的测试套件视为证据 | 从未阅读过测试主体；而是相信了数量和结构 |
| 所有发现项都以相同权重报告 | 没有严重性排名，导致阻塞性发现项被埋没在命名小问题之下 |
| 相同违规行为跨 Pull Request 重复出现 | 发现项由审查者修复而非报告，因此模式从未被学习 |
| 报告了一个作者已经证实的偏离项 | 审查前未阅读 Pull Request 的记录决策 |
7. 检查清单
- 已与仓库的实际基础分支进行差异比较；已阅读每个更改过的文件
- 每个验收标准已映射到满足它的代码以及证明它的测试
- 已识别并分类了没有对应标准的变更
- 已针对差异涉及的每一层检查合规性清单
- 已提前阅读记录决策，因此已证实的偏离项不会被报告为发现项
- 任何新公开的内容已通过安全审查环节
- 已阅读测试主体而非计数；已检查测试层次、结果断言、回归覆盖率和每条用例的基准
- 发现项已按阻塞/应修复/考虑进行排名
- 已针对工单给出明确的裁决
- 审查期间未编辑任何内容
从 docs/delivery/PR-REVIEW.md 由 scripts/build-marketplace.mjs 生成。请勿编辑此文件：修改源文档或其条目（位于 catalog/marketplace.catalog.json），然后重新运行生成器。