# L2 需求管理

## PM 目录

收到新的 L2 需求后创建：

```text
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 编号由用户决定。尚未提供编号时，可以使用：

```text
PM-待确认-<需求名称>
```

作为需求分析期间的临时目录，并将 PM 编号列为 G1 需求评审的必确认项。用户确定编号后，在进入技术方案阶段前重命名为正式目录，并检查外部链接。Agent 不得自行生成永久 PM 编号。

大需求 `README.md` 负责总览和子任务索引。使用相对链接，并维护大需求与每个子任务之间的双向关联。

## 原始需求版本

将每次收到的需求保存为完整、不可变的版本快照：

```text
source/v1/
source/v2/
source/v3/
```

不得覆盖或修改原始文件。在 `source/README.md` 中记录版本、接收时间、来源、主要变化和当前/废止状态。对话中的临时补充在进入正式版本前，应作为补充需求单独记录。

收到新版本后：

1. 比较新旧版本；
2. 识别受影响的模块、需求、方案、用例和实现；
3. 重开失效阶段；
4. 更新状态历史；
5. 已通过门禁失效时重新确认。

除非变更说明明确，不得假设新版本自动解决了旧版本中的矛盾。

## 代码分析副本

用户在 `code/` 下维护分析用代码副本，默认基准分支为 `master`，项目另有配置时以项目为准。Agent 可以执行只读 Git 检查和安全的基准分支同步，但不得执行 `git add`、`git commit`、`git push`。

更新流程：

```text
检查仓库状态
→ 确认基准分支和本地无业务修改
→ 使用只允许安全快进的方式获取更新
→ 记录工程、分支、最新 Commit 和更新时间
→ 更新 MANIFEST
→ 重新判断既有分析是否过期
```

Agent 不得在副本中实现需求。允许使用 `git status`、`git diff`、`git log` 和安全同步命令调查；发现脏工作区、错误分支、历史分叉或无法安全快进时停止并报告，不得强制重置或擅自解决分叉。

维护 `code/MANIFEST.md`：

| 工程 | 本地目录 | 远端仓库 | 基准分支 | 当前 Commit | 更新时间 |
|---|---|---|---|---|---|

真正的需求开发在独立的项目开发工作区中完成。

## 需求矛盾与歧义

需求前后冲突、版本描述不一致、语义歧义或关键条件缺失时，禁止猜测。

在相关 `01.需求分析.md` 中记录：

| 编号 | 描述位置 A | 描述 A | 描述位置 B | 描述 B | 影响范围 | 状态 | 确认结论 |
|---|---|---|---|---|---|---|---|

使用 `RC-001` 等稳定编号。展示两处描述，说明受影响模块和功能，列出可能理解但不代替用户选择，并请求确认。

确认前：

- 标记为 `待确认`；
- 不设计或实现受影响的业务决策；
- 安全时可以继续不受影响的工作；
- 无法继续时将子任务标记为待确认或阻塞。

确认后记录结论、确认人、时间、来源和受影响文档，并同步更新。

## 状态历史

以 `STATUS.md` 作为当前状态和历史记录的唯一事实来源。阶段和状态分开维护。

阶段：

```text
需求接入 → 需求分析 → 技术方案设计 → 冒烟用例设计
→ 技术实现 → Code Review → 逻辑验证 → 测试 → 发布 → 归档
```

状态：

```text
未开始 / 进行中 / 待确认 / 已阻塞 / 待评审 / 已完成 / 已跳过 / 已取消
```

记录：

- 大需求状态摘要；
- 每个子任务的当前阶段和状态；
- G1/G2/G3 状态；
- 阻塞事项；
- 只追加的变更历史，包括时间、对象、原/新状态、原因、操作者和证据链接。

不得删除或改写历史来掩盖返工。旧记录有误时追加更正。验证或测试失败时，重新打开实现阶段并记录回退。

门禁记录必须包含确认的原始需求版本、文档及文档版本、用户提供的代码版本标识、确认时间、来源和范围。文档中的“当前状态”字段只作为展示，发生冲突时以 `STATUS.md` 为准。

当前状态表：

| 子任务 | 业务模块 | 当前阶段 | 当前状态 | 阻塞项 | 最后更新 |
|---|---|---|---|---|---|

历史表：

| 时间 | 对象 | 原阶段/状态 | 新阶段/状态 | 原因 | 操作者 | 证据 |
|---|---|---|---|---|---|---|