2.4 KiB
2.4 KiB
L0 与 L1 轻量流程
L0
仅对影响极小且不改变运行行为的变更使用 L0。
理解并定位
→ 说明具体改动和影响
→ 用户确认
→ 修改
→ 检查差异
→ 执行最小必要验证
→ 报告结果
确认内容可以很精简：
变更等级：L0
计划修改：
- ...
影响范围：
- ...
验证方式：
- ...
L0 不创建完整的 L2 PM 文档集，但仍必须保留用户已有改动、遵循项目规则、检查最终差异，并说明实际执行了哪些验证。
如果看似简单的修改会改变配置、运行行为、对外含义、契约或业务规则，必须升级。
L1
维护一份持续更新的文档：
01.精简变更日志.md
落地位置分两种情况：
- 独立需求：放在该需求的
management/PM-<编号>-<名称>/大需求根目录下。 - 大需求下的子任务：放在对应
tasks/ST-<编号>-<名称>/子任务目录内。
PM 编号尚未确定时使用 PM-待确认-<需求名称>，在本次 L1 编码前确认中由用户决定后再改为正式目录。Agent 不得自行生成永久编号。
编码前完成第 1–6 节并取得一次确认；编码后补充第 7–12 节。
# 精简变更日志
## 1. 基本信息
- 需求编号：
- 需求名称：
- 影响等级：L1
- 当前状态：
## 2. 需求说明
## 3. 变更范围
- 涉及工程：
- 涉及功能：
- 涉及接口：
- 非本次范围：
## 4. 影响及回归范围
## 5. 技术实现计划
- 现有逻辑：
- 复用内容：
- 计划改动：
- 数据变化：
- 风险与待确认项：
## 6. 冒烟自测用例
| 功能点 | 验证场景 | 预期结果 |
|---|---|---|
## 7. 用户确认记录
## 8. 实际代码改动
## 9. Code Review
## 10. 逻辑验证和冒烟结果
## 11. 遗留问题
## 12. 完成结论
执行流程：
只读调查
→ 编写计划部分
→ 用户确认一次
→ 实现
→ Review
→ 逻辑验证和冒烟
→ 补全日志
→ 标记开发完成
编码前可以写 Review 检查范围，但不能伪造 Review 结论。实际 Review 和测试结果只能在执行后填写。
如果发现广泛依赖、核心架构变化、破坏性兼容问题、复杂迁移或无法界定的回归范围，升级为 L2。
Agent 在 L1 中不得执行 git add、git commit、git push；暂存、提交和推送由用户完成。变更日志中的请求响应、日志和测试证据必须脱敏。