# 影响分级与确认门禁

## 按最高影响分级

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

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

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

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

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

## 提出分级建议

修改代码前输出：

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

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

## 门禁

### 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` 记录门禁状态：

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

每次门禁必须绑定：

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

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

## 重开与升级

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

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

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

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