在审查 Pull Request 时使用此清单。并非每个条目都适用于每次变更，但审查者应明确考虑相关部分。
通用 PR 审查清单#
- 变更是否正确解决了所述问题？
- 范围是否聚焦？
- 行为变更时是否更新了文档和测试？
- 当不需要测试时，纯文档变更的理由是否清晰？
- 除非 PR 明确声明，否则变更是否保持了当前的默认行为？
- 失败模式是否清晰且可操作？
- PR 是否披露了它是否直接支持某个公司或客户用例？
Runtime/Core PR 清单#
- 这个功能是否应该放在 core 而非可选扩展中？
- 是否保持了稳定的运行时契约？
- 是否避免了特定产品的工作流？
- 是否保持了诊断信息的明确性？
- 是否保持了取消、流式传输、会话、记忆和工具执行的语义？
- 是否避免了增加 core 的依赖权重？
Gateway PR 清单#
- 是否保持了本地优先和自托管的默认设置？
- 是否保持了公开绑定的安全加固？
- 是否保持了认证、密钥处理、通道签名和不安全工具的防护？
- 配置不安全时是否故障关闭（fail closed）？
- health、admin、OpenAI 兼容、MCP、websocket 或诊断接口变更时是否有文档记录？
- 面向运维者的错误信息是否可操作？
扩展 PR 清单#
- 这个功能是否应该放在扩展而非 core 中？
- 扩展边界是否明确？
- 是否避免了隐藏的 Provider 或供应商默认值？
- 不支持时是否快速失败（fail fast）？
- 是否避免了在 AOT 通道中加载动态或仅 JIT 行为？
- 设置和兼容性文档是否已更新？
行业/工业 PR 清单#
- 这是可复用的基础设施、适配器工作、文档还是示例代码？
- 是否避免了客户特定的工厂逻辑？
- 是否避免了专有的数字员工工作流？
- 是否避免了供应商专属的默认配置？
- 是否有公司或客户驱动的贡献已做披露？
- 是否保持了供应商中立性？
- 是否符合 ../ARCHITECTURE_BOUNDARIES.md 中描述的行业边界？
文档 PR 清单#
- 文档是否在正确的位置？
- 相对链接是否正确？
- 文档是否区分了受支持行为与提案或实验？
- 是否避免了过度承诺路线图计划？
- 设置步骤是否保持最新且具体？
- 是否链接到权威文档而非重复冗长的操作说明？
安全敏感 PR 清单#
- 此变更是否涉及认证、授权、密钥、公开绑定行为、审批、工具执行、插件加载或网络访问？
- 是否故障关闭？
- 不安全操作是否有审批门槛？
- 密钥是否在日志、诊断、追踪和导出中脱敏？
- 用户控制的路径、URL、头部和负载是否经过验证？
- 新的信任假设是否有文档记录？
- 是否需要核心维护者审查？
AOT 兼容性清单#
- 是否在核心路径中保持了 NativeAOT 兼容性？
- 是否引入了反射、动态加载、运行时代码生成或隐藏的 JIT 依赖？
- 是否在需要时使用了源生成 JSON 序列化？
- 仅 JIT 的接口是否已隔离并有文档记录？
- AOT 是否在加载不支持的动态行为之前快速失败？
- 是否增加了裁剪风险？
赞助/商业贡献者清单#
- PR 是否披露了它直接支持某个公司或客户用例？
- 变更是否保持了供应商中立性？
- 是否避免了授予路线图控制权、发布权、维护者身份、独占权或生态方向所有权？
- 是否将商业或客户特定逻辑排除在 core 之外？
- 贡献是否明确按项目许可证提交？