在不越权的前提下，修改含生成代码的多模块仓库

## 编辑前先阅读根目录和各文件夹的说明 首先找到对可修改文件具有约束力的仓库指南。应将项目文档和目录内的分层指令文件视为本地规范的权威依据，而不是依赖通用的技术生态假设。 - 阅读根目录指南，以及目标目录中更具体的适用指令。 - 查看与任务相关的仓库概览、贡献指南、开发环境设置、测试指南和发布文档。 - 当仓库级指南与模块专用指南不一致时，遵循距离目标最近且适用的指令。 - 从持续维护的项目文件中核实被引用的规则，不要依赖记忆中的命令。 - 找到所有权文件，并确定负责受影响区域的评审者。 - 编辑前明确受支持的工作流程、必要审批和验证要求。 - 只有在权威依据互相冲突，或影响重大的决定仍未解决时才提问。 ## 找出负责此修改的模块和审查人 在选择实现位置前，先理解代码库的划分方式。在多模块仓库中，构建边界、依赖清单、生成区域、示例、测试和发布单元可能因目录而异。 - 找到负责公开行为的模块，以及它所依赖的底层组件。 - 区分手写实现与生成代码、模板、规范、测试数据和示例。 - 检查模块清单，理解直接依赖与间接依赖的边界。 - 根据所有权规则确定代码、服务和共享基础设施的维护者。 - 追踪变更会影响单个软件包、一组模块还是共享的兼容性范围。 - 遵循既有目录布局和命名模式，不要另造一套平行结构。 - 除非经验证的依赖关系要求协同修改，否则不要把无关模块纳入变更。 ## 使用项目指定的工具版本和任务命令 使用仓库和目标模块声明的工具链。受支持版本、任务运行器、生成器和环境准备方式由项目决定，不能根据本机安装的最新版本自行推断。 - 从持续维护的规则或配置中确认当前受支持的语言和工具版本。 - 如果仓库管理的任务还会执行额外设置，应优先使用它，而不是直接调用语言命令。 - 在文档工作流程所要求的模块或工作区目录中运行命令。 - 保留权威任务执行的环境选择、兼容性选项、生成资源和其他设置。 - 只有文档工作流程明确要求时，才全局安装前置工具。 - 使生成器和编译器版本与项目固定或支持的版本保持一致。 - 缺少前置条件时，应将其报告为具体阻碍，不要悄悄改变工作流程。 ## 发布、修改CI或使用凭据前先获得许可 智能代理可以读取代码、解释行为、提出变更、实施已授权的编辑、添加测试、改进文档，并协助分析问题或评审。影响更大的操作仍须获得人员的明确授权。 - 未经批准，不要触发发布、批准发布阶段或公开软件包。 - 不要把修改持续集成、部署流水线或工作流程控制作为其他变更的附带操作。 - 未经明确授权，不要更改许可证、法律声明或合规政策。 - 不要超出已授权任务使用认证信息、访问外部服务或更改远程状态。 - 除非状态变更已获授权，否则问题分类、标签建议和重复项判断都应停留在建议层面。 - 在执行破坏性操作或更改受保护环境前停止，并请求必要的决定。 - 对范围内的常规实现和验证继续自主推进，不要要求多余的确认。 ## 不直接改生成文件，而是修改规范后重新生成 生成的软件包需要采用不同于手写代码的变更路径。手动编辑生成结果通常会被覆盖，还可能使实现偏离作为权威依据的规范。 - 通过仓库标记、清单、位置文件或文档化的目录规则识别生成文件。 - 当项目要求依据规范重新生成时，不要手动修改生成结果。 - 如果规范、模板或生成器输入是文档规定的权威来源，就修改该来源。 - 使用项目规定的生成命令和所需工具版本。 - 检查生成后的差异，查找意外文件、纯格式变动或无关的API变更。 - 按仓库模式将手动扩展点与生成区域分开。 - 如果无法执行或未获准执行重新生成，应说明限制，不要把临时编辑伪装成持久修复。 ## 做保持向后兼容的小修改 优先进行遵循现有代码规范并保持兼容性的聚焦变更。如果两种方式都能满足要求，小而易于评审的修补比大范围重构更安全。 - 先阅读附近实现，再选择辅助函数、名称、错误模式和文件位置。 - 除非破坏性变更已获明确批准并完成文档记录，否则保持向后兼容。 - 遵循本地关于公开名称、缩写、注释和公开API文档的规范。 - 使用保留有效上下文且不会暴露机密信息的描述性错误。 - 保留所有必要的版权和许可证声明。 - 遵循模块依赖政策，不要为了本地已有的功能新增外部依赖。 - 将无关清理与请求的变更分开，让评审者能够清楚判断意图。 ## 先构建并测试目标模块，必要时再扩大范围 先运行能够覆盖受影响模块的最小命令，只有共享行为或仓库政策确有要求时才扩大验证范围。命令成功只有在覆盖变更路径时才有意义。 - 使用模块文档规定的任务或语言命令构建目标模块。 - 先运行直接相关的单元测试，再运行更广的软件包或工作区测试套件。 - 按模块要求加入类型检查、静态分析、格式检查和生成文件验证。 - 确认测试选择范围确实包含预期的软件包和测试用例。 - 尝试集成测试或真实环境测试前，先检查必要的环境变量。 - 如果命令跳过了目标，或结果依赖不可用的外部状态，不要声称已经完成验证。 - 记录运行过的命令、观察到的结果和无法完成的检查。 ## 编写不依赖网络和执行顺序的测试，以及能运行的示例 测试应证明行为变更，并能在不同机器上可靠运行。示例应遵循仓库的可执行示例规范，展示受支持的用法。 - 复用模块中已经确立的断言库和测试结构。 - 修复缺陷时，在应用修复前确认新测试会因预期原因失败。 - 单元测试不得依赖网络、认证信息、随时间变化的状态或执行顺序。 - 将测试数据存放在指定位置，并保持最小规模。 - 把真实环境测试设置隔离在获准使用的环境文件中，绝不要提交机密值。 - 当断言说明能实质改善诊断时添加说明。 - 按预期的命名和软件包结构放置示例，并确认它们能在文档化的测试流程中编译或运行。 ## 行为改变时更新模块说明和变更记录 文档也是实现范围的一部分。如果不更新会让用户、维护者或发布工具获得不完整或误导性信息，就应进行更新。 - 当设置、受支持行为或公开用法发生变化时，更新模块概览。 - 按项目的文档风格添加或修订API注释。 - 在规定的变更历史中记录用户可见的变化。 - 仓库政策有要求时，为新的公开API提供示例。 - 使设置、生成、迁移和发布指引与实际命令保持同步。 - 确认引用仍然有效，且不会把读者引向私有或过时的位置。 - 行为和工作流程未变化时，避免无意义的文档改动。 ## 从指定分支提交审查请求，提交前检查全部差异 使用仓库批准的贡献路径，并让完整变更便于检查。贡献应将实现、测试、文档和理由联系起来，同时不得更改受保护的共享历史。 - 从获准的基础分支开始工作，并通过经授权的派生仓库或远程仓库发布。 - 打开变更请求前，检查分支的完整差异。 - 使用描述清楚的标题，并在有相关工作时加以引用。 - 包含能够防止今后回归的测试，以及政策要求的文档。 - 除非维护者要求采用其他历史策略，否则通过可追踪的后续变更处理评审意见。 - 确认所有必需的自动检查，并调查失败原因，不要绕过检查。 - 未经明确授权，不要更改受保护分支、发布分支或共享历史。 ## 审查是否有破坏兼容的修改和生成文件的错误 代码评审应优先关注正确性、兼容性、生成完整性、测试质量、安全性和可维护性。应使用项目专用指南，而不是通用的样式检查清单。 - 确认变更属于所选模块并遵循其架构。 - 查找会破坏API或行为兼容性的变更，包括细微的默认行为变化。 - 在相关情况下，确认测试覆盖成功、失败、边界和可重复性。 - 确认生成文件来自获准的来源和生成流程。 - 检查依赖和清单变更中是否存在违反政策或不必要的新增项。 - 检查文档和变更记录是否完整准确。 - 将发现项交给相应负责人，并区分阻断性缺陷与可选改进。 ## 私下报告安全问题，并附上测试结果进行交接 安全问题报告、发布、流水线审批、许可证和认证信息需要专门处理。用基于证据的交接完成常规工作，并把受保护的操作留给有权限的人员。 - 通过项目规定的非公开渠道报告安全问题，不要发到公开的问题区或讨论区。 - 绝不要在公开产物中包含机密值、非公开联系方式或敏感的复现信息。 - 将发布触发、部署审批和许可证决定留给获得明确授权的维护者。 - 说明重要的实现选择，并将其与适用的项目指南关联起来。 - 汇总变更路径、执行过的测试、观察到的结果和仍然存在的限制。 - 需要进一步评审时，指出适当的代码或服务负责人。 - 如果外部访问、不可用工具或审批边界妨碍了完整验证，应明确说明。