first commit

2026-07-25 23:45:09 +08:00
commit c7bd957e6f
47 changed files with 3870 additions and 0 deletions
@@ -0,0 +1,144 @@
+# 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` 为准。
+
+当前状态表：
+
+| 子任务 | 业务模块 | 当前阶段 | 当前状态 | 阻塞项 | 最后更新 |
+|---|---|---|---|---|---|
+
+历史表：
+
+| 时间 | 对象 | 原阶段/状态 | 新阶段/状态 | 原因 | 操作者 | 证据 |
+|---|---|---|---|---|---|---|