# $cm-prd 模式文件 — 二开模式（B2–B5）

> 由 $cm-prd Step 4 判定「存量项目且本次需求会修改存量代码」时读取本文件。B1(加载参考文档)保留在主文件 Step 4。规则内容与主文件同源拆分,语义未变。

**二开模式追加规则（GREENFIELD=false 且本次需求会修改存量代码时生效）**：

- **B2 波及面分析**：对每个将被修改的存量模块，基于参考文档（03-architecture 模块关系 / 04-api-routes 调用方 / 07-business-logic 线路）+ 代码搜索核实，在 design.md 写「波及面」段：改哪里 → 谁调用它 → 哪些老功能可能受影响。**波及面是 QA 回归范围的数据源**
- **B3 防护网基线**：凡 tasks.md 中包含"修改存量模块"的 feature，开发前要有防护网基线，用来判断改动后的失败是不是新引入的。
  - **项目已有测试资产**（jest/vitest 等且可运行）→ **不单列基线任务**，也不重复造快照。在**首个改代码任务**的验证要求里加一条：「宿主以改动前的代码重放项目检查，记录基线结果与可识别的测试计数」。开发方核对验证要求时把这条标为 `run:"baseline"`，由宿主重放结果核对：宿主在开发和交付检查之后，于私有副本里把范围内文件还原成改动前的样子，再跑一遍已冻结的检查命令。它证明旧代码跑检查是什么结果，不证明「改动前那一刻实跑过」。
    - 前提（缺一项就不能用这条写法）：cm-ai 批次策略为 `verification:"auto"`（`precheck` 交会话判断，`disabled` 或缺省会跳过核对）；单代码根，有合法非空的宿主检查命令；命令用相对路径在副本中运行，且实际覆盖存量测试。不满足时重放会停在 `verification_precheck_failed`，不会静默通过。
    - 计数只记可识别的：识别不了、命令没执行（如多条命令中首条失败后的命令）、测试没实际加载时，不能填零，也不能声称拿到了完整计数。「用例数不少于基线」这类数值要求，须确认所选命令覆盖存量测试且能给出可比较的计数，证据不足时不能判满足。
    - 旧代码检查本身失败（基线红）时如实记录，不阻断开发；开发后的检查仍须全绿。基线副本里范围内的新建文件会被删掉，跑的是存量测试，这是预期。
  - **无测试资产** → 首任务仍是「现状快照测试」：写测试锁住将被修改模块的当前行为（不判断对错，只锁现状）。它本身是改代码任务，照常由开发进程做。开发后复跑，变红即为碰坏老行为的信号。
  - 测试合同里引用基线的用例（如「用例数不少于基线」），`taskIds` 含首个改代码任务，`expected` 文字锚点写「首个改代码任务的宿主重放基线」。
  - 已批准的旧规格（单列了基线任务）不按本条重拆，照原样执行。
- **B4 specs 只覆盖增量**：不为整个存量系统补规格；只为本次改动涉及的模块建规格，存量行为"用到哪、记到哪"（记进参考文档 07，而不是 specs）
- **B5 拆分锚定地图**：feature 与任务的边界对齐业务地图，不凭感觉切——
  - **feature 沿业务线路拆**（07-business-logic 的线路）：需求同时触及多条线路（如"行情展示"+"导出"）→ 按线路切成多个 feature，一条线路一个 feature
  - **任务尽量单模块**（03-architecture 的模块关系）：一个任务的改动落在一个模块内；确需跨模块的任务，描述中显式列出涉及模块清单（审查与波及面据此聚焦）
  - **地图盲区检测**：需求涉及的逻辑在 07 中找不到对应线路 → 说明地图有盲区，先对该区域增量补扫（scan 只读相关目录）再拆分——拆错边界的成本远高于补扫