在人工审查下，向开源框架提交AI编写的拉取请求

## 标明AI生成的内容，只推送到智能体自己创建的分支 将外部写入、议题归属、分支和署名视为受控操作。 - 明确标注由AI生成的拉取请求说明、评审评论和议题评论，并在项目要求时注明人类操作者。 - 通过经过身份验证的信息源确定操作者或作者。绝不猜测身份；若查询失败，则省略姓名。 - 在AI辅助的提交中加入规定的共同作者尾注。 - 如果项目采用该上限，每名操作者每天不得创建超过10个拉取请求；应优先完成少量完整且经过充分测试的变更。 - 只处理符合条件且尚未分配的议题。在实施前将议题分配给操作者，并转为进行中状态。 - 只向代理自己创建的分支推送。未经明确许可，不得向贡献者的分支推送。 - 优先使用个人分叉仓库，避免上游仓库堆积未清理的分支；分支名应包含有意义的主题和议题标识，并在合并或拒绝后清理该分支。 保持拉取请求元数据为最新状态。每次推送后都要更新标题和说明，使其仍能准确描述完整的变更集。 ## 修改代码前，先读代码历史和过去的工单 不要因为代码看起来不正确就认定它存在缺陷。长期维护的系统经常在代码中承载当前实现无法直接体现的历史约束。 1. 复现并验证所报告的问题，质疑不完整或错误的前提。 2. 检查文件历史和blame信息，再阅读相关提交消息和关联议题，以理解代码为何如此编写。 3. 搜索相关议题，了解曾被否决的方法、以往讨论和有意作出的决定。 4. 阅读受影响领域的设计文档，尤其关注安全、遥测、日志上下文和公开命名契约。 5. 如果一个模块替代了另一个模块，应区分有意变更和意外遗漏。 6. 如果拟议修复会撤销先前有意作出的变更，应停止并重新考虑。若仍有充分理由撤销，应说明即使存在原始理由也必须这样做的原因。 实施前向操作者说明调查结果、风险、歧义以及问题可能无效的情况。评审拉取请求时采用同样严格的调查方法。 通过权威来源核实外部依赖项的当前版本、发布状态和行为。绝不能只根据模型训练知识，对不断变化的外部项目作出权威断言。 ## 把测试中的固定休眠换成有时间上限的等待 测试中绝不能使用固定时长的休眠。它会使测试缓慢、不稳定且不具确定性。 - 如果组件提供原生的限时断言，应将其用于该组件已经能够表达的条件。 - 对其他条件使用异步等待工具，例如在执行下一步操作前等待中间计数达到要求。 - 不要用轮询工具包裹原生阻塞断言；这会在现有锁存器外增加多余的轮询。 - 使用等待工具时，始终设置明确的最大超时时间。 - 使用带断言的条件或清晰的谓词，绝不能使用忙等待循环。 - 修改含有固定休眠的现有测试时，应迁移到原生限时断言或通用等待工具。 例如，`MockEndpoint.assertIsSatisfied()`内部已经会等待，而Awaitility适合处理`MockEndpoint`无法表达的条件。新测试不得引入`Thread.sleep()`。 ## 确定谁可信，并通过非公开渠道报告漏洞 依据项目的权威威胁模型，判断信任哪些主体、信任边界位于何处，以及哪些责任属于框架。 - 当代码作者和部署操作者有意配置可执行路由、表达式、机密信息、网络暴露范围及运行时设置时，将他们视为受信任主体。 - 将外部消息发送者以及流经受信任路由的所有数据视为不可信。 - 框架自身不得将不可信数据转化为代码执行、文件读取、请求伪造或授权绕过。 - 受信任作者有意执行代码、操作者配置错误以及通过明确选择加入而启用的危险行为，本身并不构成框架漏洞。 有效的安全问题必须证明，在默认配置或合理预期的配置下发生了信任边界突破。典型类型包括不安全的反序列化、XXE、表达式注入、路径遍历、SSRF、标头分派滥用、身份验证或授权绕过、机密信息泄露、不安全的默认值，以及对框架所构建查询的注入。 缺少必要控制时的资源耗尽、被有意公开的管理界面、无法经由框架代码路径触达的传递依赖问题，以及没有信任边界突破证据的扫描器输出，通常不属于框架漏洞范围。 绝不能通过公开议题、拉取请求、邮件列表或其他公开渠道披露疑似漏洞。应遵循私密报告流程，并停止公开处理。 ## 拦截不可信的传入数据，危险的安全默认值保持关闭 针对具体滥用途径，评审每个消费者、解析器、数据格式、类型转换器、聚合存储和安全相关选项。 - 在分派前，使用严格且不区分大小写的策略，从不可信入站消息中过滤框架内部标头。 - 没有适当的输入过滤器时，不得反序列化不可信对象。 - 将机密信息标记为机密元数据，并按照风险类别对不安全的配置开关进行分类。 - 安全敏感的默认值应保持拒绝状态，除非被明确启用。放宽默认值需要升级说明和维护者的明确批准。 - 验证身份认证和授权选项确实会检查签发者、受众、签名，以及它们声称保护的每条子路径。 部署时，使用生产安全配置文件，通过批准的保管库解析机密信息，配置经过验证的TLS，在处理不可信输入的消费者中禁用不安全序列化，并将管理控制台和运行时管理功能限制在受信任网络内。 安全评审必须区分受信任路由的行为与框架行为，同时仍要阻止不可信数据跨越边界。 ## 每次改动都补上测试和用户文档，并提交生成文件 每项功能或错误修复都必须包含适当的测试和面向用户的文档。在相关指南中记录默认值变更、发现行为、重命名或移除的选项、标头变更、API或SPI变更、弃用和迁移。 - 针对变更范围，运行仓库规定的格式化、导入排序、样式、单元测试、集成测试和源代码检查。 - 重新生成并提交生成的构件；不要把生成变更留给CI首次发现。 - 即使本地验证任务没有运行所有分析器，也要避免引入新的静态分析问题、可维护性退化、常见弱点模式和已弃用API。 - 导入类并使用简单名称，不要使用完全限定类名；仅当两个类具有相同简单名称时例外。保留对生成代码的明确排除规则。 - 为每个新的公开API类型和方法添加规定的引入版本标签，使用即将发布的版本，并将该标签放在其他文档标签之后。 - 更新用于发现嵌套扩展的所有元数据注册表；只有源目录并不一定能让构建、目录或生成文档发现扩展。 - 对集成测试容器，验证每个受支持的体系结构。如果不存在相应镜像，则使用批准的注册表镜像或明确的体系结构专用跳过设置。 - 内部页面应使用内部文档引用，并针对已发布目标而不只是开发分支验证跨版本锚点。 弃用功能时，应同时更新构建元数据、API注解、文档标题和升级指南。 ## 合并前请两位审查者审查，并获得一次人工批准 仅当拉取请求已准备好评审时才请求评审，处于草稿状态时绝不能请求。 - 根据近期文件历史和blame数据确定相关的活跃维护者，然后邀请至少2名合适的评审者。 - 处理完所有评论并使检查重新通过后，再次请求现有评审者进行评审。 - 只要仍有任何未解决的评审对话，就绝不能合并。 - 必须获得至少1项人类批准，并且代理绝不能批准自己的拉取请求。 - 从目标分支推导发布里程碑，并在关闭议题前同时设置里程碑和议题修复版本。 - 通过程序确定拉取请求作者，正确分配拉取请求和议题，并应用由议题和变更内容支持的类别标签。 - 将公开发布和合并置于一条由格式化、类型检查、lint、测试和安全检查全部成功组成的链之后。 - 在最终合并提交中保留规定的AI共同作者信息。 - 合并后，使用修复版本和拉取请求链接解决议题，然后清理分支。 总结用户可见行为、有意义的验证、文档影响、未解决风险以及任何无法运行的检查。本地测试不能证明CI成功，证据不完整也不足以证明已做好发布准备。