agentic-change-governance

Agentic 变更治理

确保 Agentic 编码始终处于用户、计划和现有系统授予的权限范围内。

编辑前对权限进行分类

对每项计划中的变更进行分类：

• 范围内：用户请求或已接受的计划直接要求的变更。
• 局部支持：为确保请求的行为正确而需要进行的小型邻近变更。
• 设计变更：改变架构、所有权边界、公共 API、惯例、存储结构、部署行为或跨模块职责的变更。
• 机会性变更：与请求的行为无关的清理、重组、抽象、重命名或风格调整。

实施范围内的变更和必要的局部支持变更。请求或计划中已明确批准的设计变更可以继续；只有在出现新的或实质性改变的设计决策时才需询问。除非明确提出，否则不要进行机会性变更。只有当邻近清理对于正确性或帮助理解变更路径确有必要，而不仅仅是让代码更好看时，才属于局部支持。

保持人类可辨识的结构

长期进行 Agentic 工作，不应把代码库变成只有 Agent 才能理解的系统。

引入新的模式、抽象、目录结构、命名方案、数据流或错误模型之前：

1. 找到最接近的现有示例。
2. 说明现有模式为何不足。
3. 尽可能将新模式限制在最小范围内。
4. 在计划或最终报告中将其标记为设计决策。

如果找不到现有模式，应优先采用直接实现，而非另行创建框架。

遵守系统规则

将项目文档、公共接口、模块边界、lint 规则、测试和既定惯例视为约束，而非建议。

不要为了让变更通过而放宽规则：

• 未经明确批准，不要禁用测试、lint 规则、类型检查或边界检查。
• 不要扩大类型范围、放宽验证或吞掉错误来掩盖不匹配。
• 不要通过导入内部实现绕过公共 API。
• 不要仅为避免决定正确行为而将行为设为可配置。

如果系统规则似乎有误，应报告冲突并提出单独的设计变更。

升级处理触发条件

如果某项尚未明确批准的操作会产生以下任一影响，请暂停并请求批准或修订计划：

• 在模块或所有权边界之间移动代码。
• 引入新的跨领域抽象。
• 改变公共契约、持久化数据结构、迁移行为或部署顺序。
• 移除或替换既有模式。
• 涉及许多无关文件。
• 将行为变更与大范围重构或格式调整混在一起。
• 需要放宽验证才能通过。

完成标准

变更始终处于已接受的授权范围内：每项编辑都对应请求或已接受的计划；不包含未经批准的设计变更或机会性变更；除非明确批准修改，否则系统规则保持不变；并且每项架构、契约、所有权或惯例变更都获得了明确批准，而非仅仅出现在最终报告中。