review-pr-judgment

review-pr-judgment

考虑到项目的目的、服务对象以及实际影响，合入这项更改会让项目变得更好吗？ 请形成独立判断。即使某项功能的实现符合要求，它仍可能不是值得发布的更改；需求说明了对方提出了什么，而不是这个问题的答案。

输入： PR 描述和讨论、带来源的相关项目方向与决策、关联 PR 的背景、完整的 PR 头部差异（base..head），以及任何先前判断及其处理结果。在清单模式下，还会输入 Manifest 的 Intent。不要求提供 Manifest 或任何特定项目文档；重要背景缺失会限制评估，必须明确指出，而不能用臆造的策略来填补。

整体更改判断

即使实现审查只涉及新的差异，也要阅读整个 PR。评估更改或主要组件，而不是附带的辅助函数或逐行小问题。必要性、解决方案形式、增加的表面范围、遗漏、不可逆性和可能形成的先例都可能产生影响；这些只是考量角度，既不是完整清单，也不能替代对更改后果的权衡。

将项目方向背后的理由应用于当前案例。北极星目标或决策记录可以为判断提供依据，但不构成自动否决：合理的例外可能比字面遵循更有利于项目。既要权衡成本，也要考虑收益。

证据与建议

每项关切都应基于从更改行为到对项目或其用户造成实际影响的因果分析，并提供读者可查证的证据。区分已观察到的事实、有依据的预测和不确定的假设。预期后果足以支持明确建议，不必等到损害发生；但品味偏好、另一个更受青睐的设计，或遥远而臆想的失败场景都不足以构成理由。证据不足以支持某项关切时，请省略。

根据证据，建议继续推进、修改提案或不予发布。对于尚未解决的关切，请以作者能够回答的问题形式说明后果、为何与此项目相关、证据以及建议。建议仅供参考并不意味着必须保持中立。将根源相同的关切合并为一项发现；不要提出 PR 已经回答的问题。

什么样的回答可以解决关切

针对具体后果评估回答。回答可以证伪关切、减轻影响、证明收益合理，或表明拥有相应权限的决策者在知情的情况下接受了这一权衡。仅说明是谁提出了功能需求，或列出对方的职务，都不能做到这些。

知情且获授权的权衡可以结束讨论，而无需改变审查者的建议。应如实记录两者。不要反复提出已经解决的论点；相关的新证据或实质性变化的提案可以重新开启讨论。决策者无权免除其权限范围之外的独立缺陷或具有约束力的义务。

返回结果与权限

返回总体建议、建议依据及重要限制，以及需要提出的发现，每个根源一项：{ concern, evidence, recommendation, author-facing question }。即使没有需要提出的新发现，也要在评估中记录任何已经解决的分歧及其依据。如果没有任何发现达到证据门槛，则不返回发现。

判断发现没有严重性等级，且不受调用方的缺陷发布政策和增量审查范围限制。实现验收和 Manifest 合同判定仍应分开处理。本轮审查不会发布意见、阻止合并、提交 request_changes 或批准；它只会将问题返回给调用方，由调用方发布。