4.9 KiB
L2 需求管理
PM 目录
收到新的 L2 需求后创建：
management/
└─ PM-<大需求编号>-<需求名称>/
├─ README.md
├─ STATUS.md
├─ 技术侧需求分析.md
├─ source/
│ ├─ README.md
│ ├─ v1/
│ └─ v2/
├─ code/
│ └─ MANIFEST.md
└─ tasks/
└─ ST-001-<业务模块>/
├─ 01.需求分析.md
├─ 02.技术实现方案.md
├─ 03.冒烟与逻辑验证.md
├─ 04.技术实现记录.md
├─ 05.代码Review报告.md
└─ 06.验收与交付报告.md
测试、上线和上线验证完成后，在大需求根目录新增一份 归档记录.md；不移动整个目录。
PM 编号由用户决定。尚未提供编号时，可以使用：
PM-待确认-<需求名称>
作为需求分析期间的临时目录，并将 PM 编号列为 G1 需求评审的必确认项。用户确定编号后，在进入技术方案阶段前重命名为正式目录，并检查外部链接。Agent 不得自行生成永久 PM 编号。
大需求 README.md 负责总览和子任务索引。使用相对链接，并维护大需求与每个子任务之间的双向关联。
原始需求版本
将每次收到的需求保存为完整、不可变的版本快照：
source/v1/
source/v2/
source/v3/
不得覆盖或修改原始文件。在 source/README.md 中记录版本、接收时间、来源、主要变化和当前/废止状态。对话中的临时补充在进入正式版本前，应作为补充需求单独记录。
收到新版本后：
- 比较新旧版本；
- 识别受影响的模块、需求、方案、用例和实现；
- 重开失效阶段；
- 更新状态历史；
- 已通过门禁失效时重新确认。
除非变更说明明确，不得假设新版本自动解决了旧版本中的矛盾。
代码分析副本
用户在 code/ 下维护分析用代码副本，默认基准分支为 master，项目另有配置时以项目为准。Agent 可以执行只读 Git 检查和安全的基准分支同步，但不得执行 git add、git commit、git push。
更新流程：
检查仓库状态
→ 确认基准分支和本地无业务修改
→ 使用只允许安全快进的方式获取更新
→ 记录工程、分支、最新 Commit 和更新时间
→ 更新 MANIFEST
→ 重新判断既有分析是否过期
Agent 不得在副本中实现需求。允许使用 git status、git diff、git log 和安全同步命令调查；发现脏工作区、错误分支、历史分叉或无法安全快进时停止并报告，不得强制重置或擅自解决分叉。
维护 code/MANIFEST.md：
| 工程 | 本地目录 | 远端仓库 | 基准分支 | 当前 Commit | 更新时间 |
|---|
真正的需求开发在独立的项目开发工作区中完成。
需求矛盾与歧义
需求前后冲突、版本描述不一致、语义歧义或关键条件缺失时，禁止猜测。
在相关 01.需求分析.md 中记录：
| 编号 | 描述位置 A | 描述 A | 描述位置 B | 描述 B | 影响范围 | 状态 | 确认结论 |
|---|
使用 RC-001 等稳定编号。展示两处描述，说明受影响模块和功能，列出可能理解但不代替用户选择，并请求确认。
确认前：
- 标记为
待确认； - 不设计或实现受影响的业务决策；
- 安全时可以继续不受影响的工作；
- 无法继续时将子任务标记为待确认或阻塞。
确认后记录结论、确认人、时间、来源和受影响文档，并同步更新。
状态历史
以 STATUS.md 作为当前状态和历史记录的唯一事实来源。阶段和状态分开维护。
阶段：
需求接入 → 需求分析 → 技术方案设计 → 冒烟用例设计
→ 技术实现 → Code Review → 逻辑验证 → 测试 → 发布 → 归档
状态：
未开始 / 进行中 / 待确认 / 已阻塞 / 待评审 / 已完成 / 已跳过 / 已取消
记录：
- 大需求状态摘要；
- 每个子任务的当前阶段和状态；
- G1/G2/G3 状态；
- 阻塞事项；
- 只追加的变更历史，包括时间、对象、原/新状态、原因、操作者和证据链接。
不得删除或改写历史来掩盖返工。旧记录有误时追加更正。验证或测试失败时，重新打开实现阶段并记录回退。
门禁记录必须包含确认的原始需求版本、文档及文档版本、用户提供的代码版本标识、确认时间、来源和范围。文档中的“当前状态”字段只作为展示，发生冲突时以 STATUS.md 为准。
当前状态表：
| 子任务 | 业务模块 | 当前阶段 | 当前状态 | 阻塞项 | 最后更新 |
|---|
历史表：
| 时间 | 对象 | 原阶段/状态 | 新阶段/状态 | 原因 | 操作者 | 证据 |
|---|