global-coding-governance/vibe-coding-governance/references/01-分级与门禁.md

影响分级与确认门禁

按最高影响分级

评估业务行为、工程数量、接口契约、数据、架构、权限与安全、回归范围、发布协同和可回滚性。最高风险维度决定最终等级。

维度	L0	L1	L2
业务行为	不改变运行行为	小范围行为变化	核心流程或多模块变化
工程	单个极小位置	单工程或少量模块	多工程或跨服务
接口	不涉及	少量兼容性变化	大量或破坏性变化
数据	不涉及	小范围兼容调整	迁移、重构或跨存储变化
架构	不涉及	核心架构不变	架构或依赖方向变化
安全	不涉及	低风险局部逻辑	核心权限、隔离或敏感数据
回归	极小	清晰且可控	广泛、复杂或不确定
发布	简单	可控且容易回滚	多方协同、高风险或难回滚

注释、拼写、静态文案和非行为性文档只有在不改变配置、契约、合规含义或运行行为时才属于 L0。

典型 L1 包括范围明确的 CRUD、兼容性接口调整或影响已知的小型缺陷修复。

典型 L2 包括跨服务改造、核心流程重构、破坏性接口、复杂迁移、大范围权限调整、广泛回归、多工程协同发布或影响明显不确定。

提出分级建议

修改代码前输出：

## 变更影响等级评估
- 建议等级：
- 判断依据：
- 涉及业务：
- 涉及工程：
- 接口影响：
- 数据影响：
- 架构影响：
- 回归范围：
- 主要风险：
- 建议执行流程：

最终等级由用户确认。确认前允许只读调查。

门禁

L0

一次性确认具体改动、位置、影响和最小验证方式，然后实施并验证。

L1

完成 01.精简变更日志.md 的计划部分，包括需求、范围、方案、影响与回归、冒烟用例。编码前确认一次，然后实施、Review、验证并补全同一份日志。

L2

执行三次门禁：

1. **G1 需求门禁：**确认大需求 技术侧需求分析.md、业务子任务拆分、全部 01.需求分析.md、范围、矛盾和待决事项。
2. **G2 方案门禁：**确认 02.技术实现方案.md 和 03.冒烟与逻辑验证.md 第 1–4 节，包括接口与数据设计、影响、回归和验证计划。
3. **G3 开发交付门禁：**提交完成执行结果的 03.冒烟与逻辑验证.md、04.技术实现记录.md 和 05.代码Review报告.md，确认可以交给测试人员。

代码 Review 和验证是实现后的强制质量动作，不得在其执行前人为增加确认门禁。

在 STATUS.md 记录门禁状态：

G1 需求门禁：待确认 / 已通过
G2 方案门禁：待确认 / 已通过
G3 开发交付门禁：待确认 / 已通过

每次门禁必须绑定：

• 当前原始需求版本；
• 本门禁确认的文档及文档版本；
• 相关代码分支、Commit 或等价版本标识；
• 确认时间、确认来源和确认范围。

门禁通过后，确认对象发生实质修改时，将门禁改为“需要重新确认”，记录失效原因并停止进入下一阶段。仅修正错别字、链接等不改变语义的编辑可以保留门禁，但要写入状态历史。

重开与升级

出现以下情况时，暂停受影响工作并退回失效阶段：

• 出现需求矛盾；
• 必须改变已确认的业务规则；
• 影响扩大到其他工程或核心功能；
• 接口兼容、数据设计或架构发生实质变化；
• 原方案不可行；
• 需要破坏性或不可逆操作。

新证据触发更高等级时必须升级，并在继续前补齐产物。只有用户明确确认后才能降级。

不改变已确认行为、契约、数据、架构和影响范围的私有实现调整无需重开门禁，但要写入实现记录。