# L0 与 L1 轻量流程

## L0

仅对影响极小且不改变运行行为的变更使用 L0。

```text
理解并定位
→ 说明具体改动和影响
→ 用户确认
→ 修改
→ 检查差异
→ 执行最小必要验证
→ 报告结果
```

确认内容可以很精简：

```markdown
变更等级：L0

计划修改：
- ...

影响范围：
- ...

验证方式：
- ...
```

L0 不创建完整的 L2 PM 文档集，但仍必须保留用户已有改动、遵循项目规则、检查最终差异，并说明实际执行了哪些验证。

如果看似简单的修改会改变配置、运行行为、对外含义、契约或业务规则，必须升级。

## L1

维护一份持续更新的文档：

```text
01.精简变更日志.md
```

落地位置分两种情况：

- 独立需求：放在该需求的 `management/PM-<编号>-<名称>/` 大需求根目录下。
- 大需求下的子任务：放在对应 `tasks/ST-<编号>-<名称>/` 子任务目录内。

PM 编号尚未确定时使用 `PM-待确认-<需求名称>`，在本次 L1 编码前确认中由用户决定后再改为正式目录。Agent 不得自行生成永久编号。

编码前完成第 1–6 节并取得一次确认；编码后补充第 7–12 节。

```markdown
# 精简变更日志

## 1. 基本信息
- 需求编号：
- 需求名称：
- 影响等级：L1
- 当前状态：

## 2. 需求说明

## 3. 变更范围
- 涉及工程：
- 涉及功能：
- 涉及接口：
- 非本次范围：

## 4. 影响及回归范围

## 5. 技术实现计划
- 现有逻辑：
- 复用内容：
- 计划改动：
- 数据变化：
- 风险与待确认项：

## 6. 冒烟自测用例
| 功能点 | 验证场景 | 预期结果 |
|---|---|---|

## 7. 用户确认记录

## 8. 实际代码改动

## 9. Code Review

## 10. 逻辑验证和冒烟结果

## 11. 遗留问题

## 12. 完成结论
```

执行流程：

```text
只读调查
→ 编写计划部分
→ 用户确认一次
→ 实现
→ Review
→ 逻辑验证和冒烟
→ 补全日志
→ 标记开发完成
```

编码前可以写 Review 检查范围，但不能伪造 Review 结论。实际 Review 和测试结果只能在执行后填写。

如果发现广泛依赖、核心架构变化、破坏性兼容问题、复杂迁移或无法界定的回归范围，升级为 L2。

Agent 在 L1 中不得执行 `git add`、`git commit`、`git push`；暂存、提交和推送由用户完成。变更日志中的请求响应、日志和测试证据必须脱敏。