# $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 等且可运行）→ 基线 = 跑通存量全量测试并记录结果，**不重复造快照**（实跑验证：184 用例的成熟项目直接复用，前后各跑一次）；**无测试资产** → 才写现状快照测试锁住将被修改模块的当前行为（不判断对错，只锁现状）。开发后复跑基线，变红即为碰坏老行为的信号
- **B4 specs 只覆盖增量**：不为整个存量系统补规格；只为本次改动涉及的模块建规格，存量行为"用到哪、记到哪"（记进参考文档 07，而不是 specs）
- **B5 拆分锚定地图**：feature 与任务的边界对齐业务地图，不凭感觉切——
  - **feature 沿业务线路拆**（07-business-logic 的线路）：需求同时触及多条线路（如"行情展示"+"导出"）→ 按线路切成多个 feature，一条线路一个 feature
  - **任务尽量单模块**（03-architecture 的模块关系）：一个任务的改动落在一个模块内；确需跨模块的任务，描述中显式列出涉及模块清单（审查与波及面据此聚焦）
  - **地图盲区检测**：需求涉及的逻辑在 07 中找不到对应线路 → 说明地图有盲区，先对该区域增量补扫（scan 只读相关目录）再拆分——拆错边界的成本远高于补扫

# $cm-prd 模式文件 — 变更模式

> 由 $cm-prd 模式判断检测到 `--change` 时读取本文件。规则内容与主文件同源拆分,语义未变。

## 变更模式

当输入 `$cm-prd --change {N}.{feature-name} 变更内容` 时执行。

### Step C1: 定位已有 specs

在 `{SPECS_DIR}/` 中查找匹配的编号目录。

如果只传了序号（如 `--change 1`），自动匹配 `1.*` 目录。

找不到则报错提示。

### Step C2: 读取现有 specs

读取该目录下的：

- `requirements.md` — 当前需求
- `design.md` — 当前设计
- `tasks.md` — 当前任务（注意哪些已完成 `[x]`）
- `test-cases.json` — 可选 AI 测试合同；存在时按
  `../../../runtime/test-contract.md` 读取

### Step C3: 解析变更内容

变更内容可以是：

- 纯文本描述变更
- 文件路径（新的需求文档）
- URL
- `--cases {json/md/txt路径}` 或本轮直接粘贴的新测试用例

### Step C4: 对比分析

**调用 `cm-product-manager` skill 的变更影响分析**：除识别增删改外，评估波及哪些已完成任务（返工风险）、哪些验收标准失效。

变更内容涉及**交易/资产/支付/代币/证券/金融营销**时，同时协同 `cm-finance-expert`：对变更做领域正确性审核与营销红线扫描，新引入的合规问题并入变更摘要供人审。

将变更内容与现有 requirements.md 对比，识别：

- **新增**的功能需求
- **修改**的功能需求
- **删除**的功能需求
- 对验收标准的影响

### Step C5: 更新 requirements.md

- 在「需求版本」表中追加新版本行：

```markdown
## 需求版本

| 日期       | 版本 | 说明             |
| ---------- | ---- | ---------------- |
| 2026-04-11 | v1   | 初始需求         |
| 2026-04-15 | v2   | 新增微信登录方式 |
```

- 在功能需求中标注变更：

```markdown
## 功能需求

1. [F-001] 邮箱 + 密码登录
2. [F-002] 手机号 + 验证码登录
3. [F-003] Tab 切换登录方式
4. [F-004] ~~短信验证码 5 分钟过期~~ `[v2 删除]`
5. [F-005] 微信扫码登录 `[v2 新增]`
6. [F-006] 表单验证 `[v2 修改: 新增微信回调校验]`
```

### Step C6: 更新 design.md

- 追加设计版本
- 新增/修改受影响的功能模块设计
- 不动未受影响的模块
- 标注变更原因

### Step C7: 更新 tasks.md

- 追加任务版本
- 已完成的任务 `[x]` 保持不动
- 受变更影响的未完成任务标记 `[CHANGED]` 并更新描述
- 因变更作废的任务标记 `[DROPPED]`
- 新增的任务标记 `[NEW]`

```markdown
## 任务列表

### 功能 1: 登录表单

- [x] T-001: 创建登录页面和 Tab 切换组件 ~30min
- [x] T-002: 实现邮箱登录表单 ~30min
- [ ] T-003: 实现手机号登录表单 ~30min `[CHANGED v2: 去掉倒计时]`
- [ ] ~~T-004: 短信过期逻辑~~ `[DROPPED v2]`

### 功能 2: 微信登录 `[NEW v2]`

- [ ] T-008: [NEW] 微信 OAuth 回调处理 ~30min
- [ ] T-009: [NEW] 微信登录按钮组件 ~15min
```

### Step C7.5: 更新 AI 测试合同

C7 完成后先按 `runtime/test-contract.md` 更新 `test-cases.json`：保留未受影响
用例，新增/修改受影响 AC 的用例，移除已删除需求对应的 generated 用例。变更会
删除或弱化 `origin: "user"` 用例时，必须在 C4 暂停取得明确确认；未确认则保留
需求与用例并将冲突列入摘要。最后重新校验 AC→TC→Task 引用和 JSON。

### Step C8: 输出变更摘要

```
📝 需求变更: 1.user-auth v1 → v2

新增: 2 个功能需求, 2 个任务
修改: 1 个功能需求, 1 个任务
删除: 1 个功能需求, 1 个任务
未受影响: 3 个已完成任务保持不动
测试合同: 新增 2 / 修改 1 / 待删除 1

请产品审查变更后，运行 $cm-ai 继续开发（会跳过已完成任务）
```

---

## 示例用法

```bash
# 新建需求 — 提供项目文件夹路径，docs/ 下放需求文档
$cm-prd ~/projects/my-app-specs
$cm-prd /path/to/project-specs

# 需求变更 — 同样基于项目文件夹，指定要变更的 feature
$cm-prd --change 1.user-auth 新增微信扫码登录方式
$cm-prd --change 2 ~/projects/my-app-specs
```

**审批位重置**：变更落盘后，将 `{SPECS_DIR}/.cm-specs-status` 重置为
`awaiting_review`，运行 `scripts/cm-spec-manifest.py` 重算 requirements/design/tasks/
test-cases 的完整 `specFiles`，并同步兼容字段 `testCases`；按 `runtime/logging.md` 写 `spec_lifecycle/changed`、
`spec_lifecycle/awaiting_review` 和 `run_done`。改过的规格等于没审过，N1 入口闸将
再次要求确认。

# $cm-prd Step 4 — 渐进式上下文范围

本规则决定 `cm-prd` 消费项目上下文的范围，不减少规格、测试或审查产物。
地图缺失/陈旧先按 `../../codebase-context/references/writeback.md` 只读核实，再设置 `CONTEXT_SCOPE=targeted|full`。

## 1. 固定基础上下文

两种范围都先按 `runtime/project-context.md` 读取 AGENTS/CLAUDE 约束，以及存在的
`coding-style.md`、`testing.md`、`security.md` 和本需求已命中层的规则。需求源、项目
描述文件和两层目录概览已经由 Step 1–3 读取，不重复打开。

先读项目指定地图或存在的 `docs/codebase-context/00-index.md`；再用需求中的页面名、路由、可见
文案、接口名、类型名和业务术语做代码搜索，定位候选模块、直接调用方与最近测试。
搜索只用于定位，不把命中源码或需求正文写入运行日志。

## 2. 范围判定

只有以下条件**全部满足**才设置 `CONTEXT_SCOPE=targeted`：

- 存量项目，且本次初步只对应一条已有业务线路和一个现有模块；
- 候选源文件、直接调用关系和可执行验证入口均已定位；
- 地图已覆盖该线路，或定向代码核实已补齐该线路及直接调用关系；
- 未命中主 `SKILL.md` Step 9.5 的任何方案对抗审查触发条件；
- 需求不存在会改变实现范围的开放问题。

地图盲区先按任务术语定向查代码和调用方；补查后满足以上条件仍选 targeted，不因缺一段文档直接升级。
补查后仍无法确认边界，或命中跨业务线路/风险条件时才设 `CONTEXT_SCOPE=full`；Greenfield 仍走 full。

## 3. 加载清单

`targeted` 且业务地图存在时读取：

- 固定：`00-index.md` 与 `07-business-logic.md` 的当前业务链路；
- 按需：`01-overview.md` 的相关概况、`03-architecture.md` 的相关依赖、`08-conventions.md` 的适用约定；已在当前上下文且未变化的不重读；
- 涉及 API/service 或调用契约时追加 `04-api-routes.md`；
- 涉及类型、模型、存储或字段时追加 `05-data-models.md`；
- 涉及页面/UI、共享组件、Hook、Store 或复用判断时追加 `06-core-modules.md`；
- 不读取仅用于地图维护追溯的 `09-changelog.md`，也不为定位成功的任务重读
  `02-directory.md`。

清单只读实际存在的文档；局部地图缺少章节时以定向代码核实补证，项目自定地图读对应段落。
日期新旧不单独触发 full；仍按业务范围与风险判定，不能把陈旧描述当边界证据。

随后只读候选源文件、直接调用方和最近测试。`full` 扩展到本任务涉及的全部业务线路、共享依赖和风险边界，
仍按索引读取相关章节与代码，不机械加载 00–09 全部 10 份；范围扩展不等于读取整仓。

## 4. 执行期升级

Step 5–10 发现局部地图盲区，先定向补证；证实仍在原边界内就保留 targeted。
发现第二条业务线路、额外模块、上述风险信号，或补证后仍不确定时，才在最终 design/tasks 前
执行 `targeted → full`，补读受影响线路及共享依赖并重做波及面检查；关键证据仍缺失则暂停依赖它的设计。
只允许升级，不允许 full 降回 targeted；不能以节省 token 为由省略风险审查或截断关键依赖。

## 5. 日志与摘要

初次判定后按 `runtime/logging.md` 写 `decision` / `phase: context_scope`，数据只包含：

- `context_scope`: `targeted | full`；
- `reason_code`: `single_module_identified | greenfield | target_unresolved |
  map_blind_spot | cross_module | contract_or_data | security_sensitive |
  dependency_or_architecture | large_feature | scope_uncertain`；
- `context_docs`: 已加载地图的相对文件名数组；无地图时为空数组。

发生升级时再写一条 `decision` / `phase: context_scope`，增加
`transition: targeted_to_full`、`reason_code: scope_expanded` 和不含业务正文的原因分类。
摘要卡显示 `上下文范围: 定向 | 完整 | 定向→完整（{reason_code}）`。

# $cm-prd 模式文件 — 0→1 空项目分支（GREENFIELD）

> 由 $cm-prd Step 3 判定 GREENFIELD=true 时读取本文件。规则内容与主文件同源拆分,语义未变。

## 0→1 空项目分支（GREENFIELD）

Step 3 检测到 `GREENFIELD=true` 时叠加以下规则。核心思想：**架构决策也是需求的产物，走同一条 specs 流水线**——选型即设计，搭建即任务，享受同样的人审卡点、断点恢复和审计链。

### G1: 技术选型确认（并入 Step 5.5）

**先读完需求再谈选型，推荐必须从需求特征推导，不套通用默认。** 流程：

0. **交付形态必问（第一问，不可默认）**：Web / iOS / Android / 小程序 / 桌面 / 多端——这是所有架构决策的第一分叉，需求没写就必须问，答案强制写入 ADR 和 CLAUDE.md 的「交付形态」字段。**历史事故：需求只说"做一个 XX"，AI 默认 Web，用户要的是 App**
1. **联网校验当前最佳实践**：确认交付形态后，用当前运行时可用的网络搜索能力查该形态的当年主流架构搭配（脚手架生态迭代快，不可凭记忆推荐）；网络不可用 → 使用 `{CM_WORKFLOW_ROOT}/templates/arch-reference.md` 基准表兜底，并向用户标注快照日期建议复核；联网发现基准表过时 → 顺手更新它
2. **提取需求特征**并给出架构含义（展示推导过程，让人能审）：

```text
需求特征 → 架构含义（示例）
- 营销页/需要 SEO      → SSR/SSG 框架（Next/Nuxt/Astro）
- 纯工具/管理后台      → SPA 即可（Vite + React/Vue）
- 实时行情/推送        → WebSocket/SSE 支撑,考虑轻后端
- 多端(Web+小程序)     → 跨端框架(Taro/uni-app)或分仓
- 有交易/资产          → 后端必选,金融铁律生效(decimal/审计)
- 团队约束/部署条件    → 一票否决项,压过所有技术偏好
```

2.5 **团队首选脚手架优先**：`arch-reference.md` 中标注「团队首选」的脚手架（当前为 better-t-stack），当其能力矩阵覆盖本次选型所需组件时，推荐方案默认基于它生成（一条命令出全栈，前端/后端/ORM/鉴权按选型定制）；能力矩阵覆盖不了的场景按特征正常推导，不硬套
3. 基于特征给出 **2-3 套定制方案**，每套包含：技术栈、取舍、**对应的脚手架命令**（如 `npx create-expo-app`、`npx create-next-app`、`npm create vite@latest`、`taro init`），并标注推荐项及推导理由（含联网校验的来源）。**命令验证边界：只许 `--help` 核实参数、`--dry-run` 验证组合，不得实际生成项目**——生成是 T-001 的职责，G1 阶段生成会让 N1 撞上"目录非空 + T-001 未勾选"信号，凭空多一次人工确认（实测教训）
4. 人做选择题，不做填空题；确认结果连同脚手架命令写入 ADR，bootstrap T-001 直接使用该命令。**写入 ADR 的必须是全参数命令**（含包管理器等全部选项）——缺参数的命令会在无人值守执行时停下来交互式提问；现代脚手架（如 better-t-stack）完成/dry-run 时会回显"可复现完整命令"，抄它进 ADR 是标准做法

必须覆盖的提问维度：

- 团队已熟悉的技术栈（这是约束，不是偏好）
- 部署条件（自有服务器 / 云 / Serverless / 内网）
- 版本控制（默认本地 git init，写成"默认 X 如不符请指出"；用户明确不用 → bootstrap 的 CLAUDE.md 版本控制字段记 `none`，全链路降级）
- 性能与规模预期
- 第三方服务预算（数据库、鉴权、存储是自建还是用托管服务）

**选型未确认前不得进入 Step 6。**

### G2: 生成 0.bootstrap feature（在业务 feature 之前）

编号固定为 `0`，业务 feature 从 `1` 开始：

```text
{SPECS_DIR}/
├── docs/
├── 0.bootstrap/          ← 0→1 专属
│   ├── requirements.md   # 非功能需求：团队约束、部署条件、性能要求、预算
│   ├── design.md         # 即 ADR：候选方案对比表、最终选型、每项理由
│   └── tasks.md          # 见下方任务模板
└── 1.{business-feature}/
```

`design.md` 按 ADR（架构决策记录）写：候选方案对比表（方案 / 优势 / 代价 / 是否入选）+ 最终选型清单 + 每项决策的理由。**这份文件就是日后回答"当时为什么选 X"的唯一出处。**

`tasks.md` 任务模板（按需裁剪）：

```markdown
- [ ] T-001: 用官方脚手架生成项目骨架（{选定的 create 命令}）；脚手架未自带 git 时执行 git init ~15min
- [ ] T-002: 生成 .claude/ 规范（等同 $cm-init 产出，基于已选型技术栈） ~15min
- [ ] T-003: CI 与部署骨架（lint/test/build 流水线，环境变量模板） ~30min ——**计划迭代 ≥3 个 feature 的项目不得裁剪本任务**：测试是基建不是环节，第一周省下的半小时会在第五周连本带利还（实测两次 demo 裁剪 + 行业重度实践共同教训）
- [ ] T-004: 公共底座（请求封装、错误处理、基础布局/入口结构） ~30min
```

### G3: 业务 feature 的生成规则

业务 feature 的 design.md 基于 **G1 已确认的选型**生成（此时规范文件尚不存在，以选型结论为准）。执行时序由 $cm-ai 保证：`0.bootstrap` 最优先执行，完成后规范已落地，后续 feature 加载的就是真实的 CLAUDE.md 和 rules。

### G4: 后续架构变更

架构调整走已有变更模式：`$cm-prd --change 0.bootstrap 数据库从 SQLite 换 Postgres`——ADR 追加版本行，决策演进全程留痕。

**执行中发现架构错配的标准处置**（如 $cm-ai 跑到一半发现交付形态/框架不对）：

1. **干净停点**：当前任务走完 N5（标记+落盘）再停
2. **形态确认与回收率评估**（先问清目标形态再动手）：PWA/壳 ≈90% 可回收 / 跨端框架 30-60%（逻辑与 API 层可迁，UI 重写）/ 原生 ≈10%（只有 specs 与契约可复用）
3. `$cm-prd --change 0.bootstrap 交付形态从 X 改为 Y` → ADR 记 v2，受影响任务标 `[DROPPED]`/`[NEW]`（含显式迁移任务），已完成可保留的不动
4. **旧代码移入 `legacy/`**，可回收部分由迁移任务显式搬运；重跑 $cm-ai 时 N1 的目录信号会强制确认目录处置
5. 断点恢复按新标记续跑

# JS 需求变更、已审修订与恢复

原业务规则仍为`change-mode.md` C1–C8、主Skill与`phase-timing.md`。本文件只说明同一宿主如何执行。

## 需求变更

启动原`cm-prd-host.mjs serve`命令并追加`--change "1.feature"`（只传编号亦可；多匹配先选）。
保留代码根/specs根、runtime、用例参数与原写权限。不会发起provider或开发，也不增加C模式没有的审查轮次。

1. `start {text}`提交真实变更。`prd_analyze`执行C1–C4，读取原三件套、测试合同与相关代码，
   分析已完成任务和AC的影响。文件/URL须实际读取，没工具就提问；不得推断已读取或外发权限。
2. 用户疑问以`advance {text}`真实回答。`change_requirements`、`change_design`、`change_tasks`
   各用一次advance推进。`prd_generate`执行C5、C6、C7/C7.5：前阶段产物与清单必须原样带入下一阶段。
   问题未解决仍停当前阶段；不要把提示的问题当答案。生成器只返回当前请求列明的正文，不写文件。
3. `change_check`用advance执行原自检。仅失败可修正，最多两次任务稿；不是独立审查或自动批准。
   `change_confirmation`向用户展示proposal的summary、增改删文件/feature、completed保留数、
   `changedUserCases`逐条内容与未决项。确认前不覆盖规格。
4. 取得真实明确决定后发送`decision {proposalDigest,approved,allowUserCaseChanges}`；三个字段
   分别绑定展示的提案、是否执行、是否明确允许列出的用户用例删除/弱化。模型的建议不算用户决定。
   普通变更不额外要求同意用例变更；仅changedUserCases非空时必须特别确认。拒绝不保存。
5. `save_draft`保存已确认版本：先归档完整原稿/提案，使审批失效，再按原字节检查写入，最后重算
   **全部**feature的specFiles/testCases，写原`.cm-specs-status=awaiting_review`。不自动approved，
   不勾任务、不运行cm-ai。输出C8摘要与路径，请人审后另行运行cm-ai。

已完成任务行逐字保留；待办改变标CHANGED、作废标DROPPED、新任务标NEW。变更文档保留旧版本行并追加版本。
不受影响的feature保持原样。允许提案列明并确认的新feature、删除feature及可选测试合同变化；
带已完成任务的feature不能删除。删除feature整体移动到该提案的私有removed归档（连同资产），
删除测试合同原字节也保留在提案归档。名称/编号碰撞、复用旧审查slug、符号链接、第三方改动均停止。

## 拆分审查中的需求与设计补正

原 split 发现需要改 requirements.md 或 design.md 时，不必先 prepare_revision：按原处置计划保存补正，
执行一次 split 自检，再记录包含需求与设计新 SHA 的回执；该 feature 随后以回执中的版本为准，低风险项也适用。
已经编辑但还没写回执的旧会话也走这条路，具体请求见 `js-host.md`「拆分审查要求补正需求或设计」。
它不增加审查轮次、不重写旧设计回执；尚无完整计划或文件 SHA 不符时，其他操作仍拒绝漂移。

## 已审整稿受控升级

原未审整稿仍用promote_design；不要切变更模式规避它所需的设计/拆分审查。
同会话已有**保存且split处置完成**的整批规格，需要需求/设计/任务或清单变化时，先解释变化与影响，
再`prepare_revision {reason}`，进入上述C模式；每项旧design/split尝试须已经处置，unknown不准绕过。
`self_check_failed` 属于已处置但待人裁决，允许修订；原失败检查与处置决定继续绑定在修订历史中，不算自检通过。
整批完整清单成为修改边界；新增/删除须在最终proposal明确展示并经用户确认。
它是需要重新人审的需求变更，不是旧批准续期。旧r1、处置、风险选择、自检轮次不删除、不改写；
旧证据只作历史，新的C模式自检单独记录，不冒充原新建模式剩余额度，不再派发同一stage的r2。

## 原材料改变：终止旧批次并关联新批次

同批已有审查后，原材料、用户用例或有效配置真正改变，剩余审查报 `prd_inputs_changed`，
整批修订又要求原拆分审查完成时，不必恢复错误的旧材料。先向用户说明旧批次、已审与未审范围、
替换原因及新目录，取得明确同意；模型判断、普通写入开关、时间流逝均不算终止授权。

1. 准备同一代码项目下独立的新 specs 目录，放入当前正确的 docs；沿用原用例路径和运行环境。
   新旧 specs 不得相同或互相包含，新目录不得有功能目录、审查记录或审批状态。不要复制旧规格与回执。
2. 用原参数和 `--session {旧批次}` 打开旧宿主。输入摘要漂移后仍可 `status`，普通推进继续拒绝。
   确认新 docs 与当前旧目录中已修正的 docs 一致，再发送：

```json
{"requestId":"replace-1","operation":"replace_inputs","approved":true,"reason":"用户明确授权的真实替换原因","successorSpecs":"新 specs 的规范绝对路径","successorSessionId":"prd-new-batch"}
```

3. 成功返回 `stage: inputs_replaced`。不可覆盖的记录位于旧目录
   `.reviews/prd-sessions/{旧批次}/inputs-replaced.json`，保存原会话检查点与待定调用、审查文件原字节、
   未完成审查的功能及阶段、旧输入摘要、修正后摘要、新批次输入摘要与原因；旧文件不重写。
   同样请求可重复读取；换原因、目录或新批次标识会拒绝。记录写成即终止，进程中断不撤销它。
4. 新宿主使用新 specs、指定的新 `--session`，首次追加 `--predecessor {旧终止记录的绝对路径}`。
   JS 核验项目、运行环境、会话标识与新输入摘要，把关联写入新目录 `.reviews/prd-predecessor.json`。
   恢复新会话时保留这份关联；随后从分析开始，风险选择、自检和规定的审查重新执行；高风险功能重审设计，全部功能重审拆分。
   旧批次的批准、处置、已用轮次不进入新批次；新摘要会明确列出前序批次、原因和全部重审的边界。

终止后只提供 `status` 与 `read_batch` 历史读取；审查、补正、修订、摘要、发布、取消和恢复调用均拒绝。
即使旧 docs 被移走，原参数仍能打开终止会话读取记录。旧 specs 含已终止产物，不能汇总发布或另开会话复用。
未知审查调用如实归档为未知，不补造成功或重新派发；`read_batch` 包含私有原文，不得外发。

限制：仅适用于未发布的新建批次；已经进入 C 模式、取消或发布的批次不能用此操作撤销历史。
此入口绑定现有参数下的文件内容和有效配置变更，不支持更换代码根、用例路径或运行环境。
当前输入及新目录须可读取、配置须有效；终止记录受原会话 16 MiB 上限约束，超限停止而不截断历史。
这是正式结束旧批次的例外，不是带未审项的 revision，也不授权规格批准、开发、安装或发布。

## 跨进程恢复

`status`返回runId与recovery。未保存的问答、材料结果、草稿、风险选择、自检轮次也保存在
`{SPECS}/.reviews/prd-sessions/{runId}/state.json`（0600）；它是私有执行记录，不是任务真相库，
不进入全局镜像正文。`--allow-log-write`包含该必要本地执行记录，规格/审查写仍分别授权。

以原项目/specs/mode/runtime/--cases参数和`--session {runId}`重连。无pending时按原stage继续advance；
有pending时先走resume：`resume {resolution:null}`消费已经记录的返回，禁止直接发送advance跳过去。
未知调用先从原宿主找回**实际原输出**，再传：

```json
{"requestId":"recover-1","operation":"resume","resolution":{"callId":"status原值","requestDigest":"status原值","result":{},"evidence":"实际原调用输出的工具/消息引用"}}
```

result必须是原返回，不可填空占位。信封只做绑定，宿主必须核实引用与实际执行，不得由模型自报批准。
找不到原返回时保持unknown，或对**不含任何prd_review调用**的操作显式放弃；不自动补调、不推断未执行。
审查恢复仍由原claim/r1发布器验原包与独立身份；
修正自检复用原start与result，保存中断只补归档提案缺失部分，第三种文件内容不覆盖。
显式cancel同时写cancelled checkpoint并清空active，是不可恢复为继续执行的终态；断连不等于取消。
旧版cancelled checkpoint残留active时，重连清空残留并保持终态（2026-09-17事故：cancel只写checkpoint，active拦住新操作而cancelled又拦住resume，形成死锁）。
旧版本没有checkpoint的会话无法还原未记录对话，明确报告。
状态/原材料或配置漂移不得解释为新成功；历史完成与当前执行资格分开。

### 放弃未知调用

非审查操作无法取得原输出时，可显式发送以下形态；`result`必须缺省，不能和`abandon`共存。

```json
{"requestId":"abandon-1","operation":"resume","resolution":{"callId":"status原值","requestDigest":"status原值","abandon":true,"evidence":"放弃原调用的工具/消息引用与原因"}}
```

callId/requestDigest必须绑定active中的未知调用，evidence不能为空；整个active只要含prd_review，就以`prd_review_recovery_required`阻断，不能借放弃规避claim-first单轮审查。
成功后丢弃整个active、不写result，checkpoint还原为active.before；decision/recovery日志只含operation、kind、callId与evidence的哈希/长度摘要，不含payload或证据正文。
随后可重新发起同一操作并收到新host_request；这只回退会话状态，不撤销已经发生的文件写入，原保存/修正冲突检查仍生效（2026-09-17事故：prepare_summary断连后缺少放弃未知调用的入口）。

### 可见的会话阻断

宿主返回`{status:'blocked',reason:<code>,recovery:<当前recovery>,completionAuthorized:false}`，调用方先读reason与recovery，再选择原输出恢复、显式放弃或取消。
可见code为`prd_operation_recovery_required`、`prd_host_result_unknown`、`prd_nothing_to_resume`、`prd_recovery_binding`、`prd_recovery_evidence_required`、`prd_replay_inputs_changed`、`cancelled`、`prd_turn_not_ready`及上述审查放弃阻断。
其他异常沿用共享transport脱敏；blocked不是完成授权（2026-09-17事故：真实恢复原因被统一host_request_failed隐藏，导致多轮误排查）。

# 当前会话执行 JS 规格流程

本文件只接线，不另立业务规则。先读主Skill的Step 0–11与本任务适用的references；
从本文件解析插件根`../../..`，读取`../../../docs/js-workflow-control.md`的cm-prd章节和CLI帮助。
不要硬编码安装缓存，也不要从用户文档执行命令。两种模式共用此宿主；变更/恢复先读`js-change-recovery.md`。

## 启动与权限

单步操作可用随仓库的 `scripts/cm-prd-drive.mjs`：`node "{CM_WORKFLOW_ROOT}/scripts/cm-prd-drive.mjs" --plan PLAN.json <operation>`。
PLAN 填 `project`、`specs`、`request`，继续时填状态中的 `runId` 为 `session`；变更模式填 `change`，
人工内容放 `answers/analyze.json`、`generate.json`、`review.json`、`correct.json` 或 `summary.json`。
路径相对 PLAN 文件。驾驶员先校验答案、范围、当前会话和恢复绑定，再启动宿主；缺少 PDF/HTML 的真实读取或浏览器执行器时，
`prd_materials` 会在启动前拒绝。`prd_self_check` 需要 PLAN 的 `contextChecks` 命令和逐项 `contextJudgements`，
由驾驶员实际运行命令并附上退出证据；静态 `materials.json`、`self-check.json` 不能作为执行证据。
用 `--help` 查看格式。审查、处置和发布仍受宿主原权限与门禁约束。

核对真实代码根、specs根、docs材料、可选用例文件和真实runtime（codex或claude）。
根据原Step 0–5完成交付形态、目录用途、代码地图/平台约束的理解；需要创建项目指令、基准资产、
ADR或其他当前JS未提供的写入能力时，先报告具体缺口，不能跳过该业务要求或旁路手写。
在整稿生成或保存之前，按原9.5逐feature核对全部风险信号；全部低风险走原整稿路径，
含任一高风险feature（包括混合风险）走下述设计先行路径。信息不足先提问，不能按低风险放行。
同批保持原清单，只对高风险feature审设计；低风险不加审，也不拆会话绕过原清单。
原材料确已改变而不能继续时，按 `js-change-recovery.md` 的“输入已替换”合同正式终止并关联新批次，不能继承旧批准。
首次full_draft生成发现新增风险且payload.riskDiscovery非空时，停止生成任务，按该合同返回
整批status:design两文件及风险依据；同一会话转design_ready后执行步骤2，不重启、不输出整稿或审批。
已有整稿后发现风险，先停止直接advance/save_draft；仅无design/split审查记录且自检有剩余额度时，
发送`{requestId,operation:"promote_design",draftDigest:"当前draft的原值",reason:"实际风险及依据"}`。
成功进入design_ready后按步骤2登记风险并继续，不再次plan_design；原稿与已用轮次保留，后续仅用剩余额度。
已保存整稿还须整批完整、与当前原稿逐字相同且0600；部分保存、用户改动、额外合同、有审查记录、
已处置设计或额度耗尽时保留现场，不删除文件、重启会话、重置轮次或补审绕过。
已保存升级完成原设计处置及自检后仍用save_draft；JS先归档原稿/新版，再仅更新任务和既有测试合同。
promote_design不改需求/设计，不增删清单；已审整稿需修改范围时走js-change-recovery的受控变更，不删除旧审查重来。
用户已要求生成规格时，可为该规格目录启用必要的日志和规格写入；不因此取得provider、
安装、外发、Git或开发权限。审查通道及其发送包仍须现有授权；没有就停在待审点。

通过当前会话可持续交互的进程工具启动，并保留真实进程句柄：

```bash
node "{CM_WORKFLOW_ROOT}/scripts/cm-prd-host.mjs" serve \
  --skill-dir "{CM_WORKFLOW_ROOT}/skills/cm-prd" \
  --project "{CODE_PROJECT}" --specs "{SPECS_DIR}" \
  --runtime "{codex或claude}" --allow-log-write --allow-spec-write
```

有用例文件才加--cases；粘贴用例保留在真实对话和对应宿主请求中，不擅自写临时业务文件。
已明确具备审查通道与记录权限时，启动前追加--allow-review-write与--host-context真实作者上下文ID；
需要处置回执时追加--allow-disposition-write。这些开关不授权额外provider进程或安装。
无法维持双向会话、启动所需环境不支持或缺权限时停止并解释，不声称已执行JS，也不自动重启换路径。

## 控制与宿主请求

收到host_ready后发送`{requestId,operation:"start",text:"用户实际需求"}`，再按状态用advance传真实回答。
用唯一requestId关联每个响应；持续读取中途host_request，不等advance结束才处理。
读取payload.reference及其要求的实际业务资料，严格按当前请求的返回合同回复：

```json
{"type":"host_result","sessionId":"原值","callId":"原值","requestDigest":"原值","result":{}}
```

result必须填真实结果，不留空对象。不同kind的合同见当前请求及产品文档，禁止混用字段。

| kind | 当前宿主执行 |
| --- | --- |
| prd_analyze | 按原Step 0–5分析与提问；保留用户用例、形态、平台与范围约束。question交给用户，不能代答。 |
| prd_materials | 用已可用、已授权的实际工具处理材料；HTML交互只走Codex内置浏览器，PDF逐页覆盖，不伪造截图/页数/证据。能力不足返回blocked。 |
| prd_generate | 按payload.phase执行：design只做Step6–9的需求/设计；tasks_after_design默认保留acceptedDesign原feature及正文；整稿自检失败时按下文登记同清单修订；full_draft走原Step6–10。保留UI基准与原粒度约束，只回正文不写文件。 |
| prd_self_check | 读取spec-self-check.md与相关真实代码/地图/用例，逐项返回有依据的结果；机械通过不等于语义通过，不能用自检冒充独立审查。 |
| prd_review | 按原9.5或10.6，使用实际授权的新上下文独立审查，核实作者/审查者身份并原样回传。无法独立时只允许预先选定的显式self-degraded；开始后不换模式或补审。 |
| prd_correct | 对原findings提出完整原路径清单与逐项采纳/升级决定；不自行写规格，不新增范围/勾任务/再次review。 |
| prd_summary | 按原Step11核对交付形态、开放问题、风险、平台/UI基准及原9.5风险信号；未知明确写待核对，不能推断人工批准。 |

读取角色Skill不代表配置模型已调用；非当前runtime角色路由被JS阻断时如实报告。
JS拥有日志、草稿保存、修订写入、自检轮次、审查记录、处置和审批位写入；宿主不再运行
主Skill中的同名手工写入命令补齐缺口。JS记录配对阶段事件；合并生成的阶段共享真实调用区间，不能相加或编造内部耗时。

## 审查、保存与交接

1. 低风险analysis_ready后advance生成草稿；draft_ready后advance自检，按原最多两轮处理。
   通过后save_draft保存当前草稿；冲突/unknown保留现场，不覆盖或自动重试。
2. 含高风险的批次在analysis_ready发送`{requestId,operation:"plan_design",text:"真实设计要求"}`；疑问用advance答复。
   design_ready后先按实际设计复核原9.5，发送`{requestId,operation:"select_design_reviews",draftDigest,risks}`。
   draftDigest取当前designDraft；risks逐一覆盖全部feature：`{feature,signals,evidence}`，不漏低风险项。
   signals包含greenfieldAdr、architectureOrDataFlow、newRuntimeDependencyOrToolchain、publicContractDataOrSecurity、
   fiveOrMoreFunctions五个布尔值，evidence写实际代码/需求/设计核对依据；未知先问，不填写猜测的false。
   每会话只登记一次；登记不授权review或审批，已有design尝试不能改列低风险，不能重启会话重置。
   再save_design保存整批需求和设计；仅signals任一为true的feature用final_review（stage:design）进入原9.5，
   final_review_package只准备包，不授权调用。模式须预先选定，不在开始后改换。
   review_findings读取结果；有发现用correct_findings，再将其packageDigest/decisions/artifacts交review_disposition；
   无发现用原findings响应的packageDigest/reviewedArtifacts和空decisions写原处置回执。
   全部需审feature处置后advance共同生成任务；低风险须无design尝试且保存正文未变，不补空审查回执。
   保留当前整批设计与编号，再advance原自检，通过后save_draft，继续步骤3。
   处置未完成、blocked或漂移不能生成任务；升级项保留到摘要供人裁决，不补审。
3. split为原10.6必需审查；每feature每stage只一轮。用review_findings读取原结果，
   correct_findings让JS归档并保存提案，再将返回的packageDigest/decisions/artifacts交review_disposition。
   split可按原发现修改requirements.md、design.md及任务文件；先保存，再由JS重跑原自检，失败或unknown不能重调。
   review_disposition须包含原packageDigest、逐项decisions和完整artifacts（含新requirements.md、design.md的SHA），无发现也须原回执。
   回执完成后，其需求与设计的新SHA成为已接受版本；save_draft复用已保存的新稿，不把内存旧稿写回。
4. 全部feature处置后prepare_summary。展示返回的事实计数、宿主说明、风险/阻断和未勾选清单；
   blockers未清不能publish_summary。保存使用刚展示的summaryDigest，不能用旧稿或evidenceDigest替代。
5. 仅awaiting_review后报告等待人工审查，展示具体specs路径。不能自动将状态写approved，
   不能因为用户说“继续”在本命令内启动开发；明确提示审查通过后单独运行$cm-ai。

### 设计接受后的整稿自检修订

仅 `draft_self_check_failed` / `self_check_failed` 的重生成可改已有需求/设计；问题澄清后仍须绑定原失败。
`prd_generate` 的 `payload.selfCheckRevision` 非空时，返回原 draft 格式并增加非空
`selfCheckRevisionReason`，说明修订回应的失败；feature 顺序、编号、文件清单全部保留，不增删。
JS 在 checkpoint 的 `selfCheckRevision` 记录原失败及其摘要、轮次、原因和各文件前后 SHA；
失败仍在 `selfCheckHistory`，总计最多两轮。未失败、缺原因、范围变化或任意磁盘漂移均不放行。
通过自检后用 `save_draft`：先写不可覆盖的 `.reviews/prd-{feature}-self-check-revision.json`，
再保存记录的新版；部分写入只允许同会话显式恢复原版本，不接受第三种内容。
保存后 `selfCheckRevisionSaved` 为 true，不能恢复成旧稿；再继续原 split，不发第二次设计审查。
后续接受顺序是已完成 split 回执、自检修订、原设计基线；split 包必须绑定修订后的需求/设计 SHA。
摘要风险信息逐 feature 自动注明原因、文件、轮次及“拆分审查已审、未另做设计审查”，说明本身不阻断。
未使用此路径的运行不产生新字段或档案，旧 checkpoint 仍可恢复。

## 恢复与退出

status只读查询；只有用户明确取消才cancel，断连不等于取消。结束发送`{type:"host_close",sessionId:"原值"}`并保留结果。
有修订档案先inspect_correction，获原spec/review写权限后resume_correction，只补原提案缺失写入。
会话、未保存草稿、风险与轮次自动私有持久化。新进程用原--session/runId和参数继续；待定操作只能resume原记录。
未知审查/自检不得重发；凭原宿主真实回执恢复，旧无记录调用保留人工恢复。不能重新登记、改false或换session重置尝试。
真实provider、安装后加载、完整跨平台和真实需求验收均不得借源码fixture宣称完成。

### 拆分审查要求补正需求或设计

设计阶段回执不改写。拆分审查已经返回且尚未处置时，可在同一 feature 的原发现中列明 requirements.md 或 design.md 改动，
由 correct_findings 归档并保存；随后直接 review_disposition，内置原 10.5 自检。补正保存有中断仍用
inspect_correction / resume_correction，只认归档的原字节或提案字节，不接受第三种内容。

已经手工编辑而卡住的旧会话，无须重建：准备原 split 包的 packageDigest、完整 decisions 和 artifacts，
逐项列出 changedPaths，并使每个 SHA 与磁盘一致，再调用 review_disposition。
需要先读 review_findings 时可一并传这三个字段；correct_findings 已保存的场景可省略，宿主从原补正归档读取计划。
只有这些带计划的读取、处置及其自检可以暂时接受已列明的需求或设计变化；save_draft、final_review_package、普通生成和原自检不放行待处置漂移。
底层归档读取器仅核验原审查记录，不替代宿主对当前会话与文件的校验。

完成后使用同一 feature、同一原设计和需求字节、原 split 包及其回执；会话还须匹配原整稿摘要。
汇总、发布待审状态和 prepare_revision 共用该校验。回执完成后再次修改需求或设计（包括改回旧版本）、
漏列或错列 SHA、借用其他 feature／其他包均拒绝。拆分审查前的需求与设计仍须匹配原基准；原发现以外的需求变更仍走变更流程。

混合风险批次也按 feature 校验。低风险项没有设计审查回执时，以原设计草稿中的需求、设计为基准，
只接受绑定同一整稿和原 split 包的补正计划或已完成回执，不补建空的设计审查。A 完成补正后可继续 B 的审查与整批汇总。


### 修正自检失败后交人裁决

`review_disposition` 的单次修正自检有明确失败结果时，返回 `disposition_recorded`，回执的
`disposition` 为 `self_check_failed`。它表示「修正已保存、处置已登记、自检失败待人工裁决」，不是通过。
回执保留原检查输入（含逐项决定与文档）、结果摘要绑定；原 correction 归档、check-start 和 check-result 不覆盖。
全部 finding 计入待裁决数，不把已经改过的 finding 强改成不允许文件变化的 `escalated`。

下一步是 `prepare_summary`，展示 `riskCard` 和摘要「风险点」中由程序附入的失败项目及证据，
再以刚展示的摘要调用 `publish_summary`，进入 `awaiting_review`。发布不是批准；人仍可批准或拒绝整批。
已记录的机械失败也以失败原样展示；未被该回执覆盖的新失败仍阻断。此状态只能由宿主读取真实失败记录后产生，
不能用普通 gate CLI 的一个 disposition 参数声明失败；design 阶段、缺记录或实际通过均拒绝。

`self_check_failed` 也是完整的 split 回执，因此同批其他 feature、保存、汇总和 `prepare_revision`
可读取它绑定的 requirements.md / design.md 新字节。这只是确认当前文档身份，不能推导质量通过或开发授权。
如需下一版，说明原因后走受控修订；旧失败留在历史中。结果 unknown 仍阻断，只恢复原返回；
不再独立审查、不自动修复、不重跑检查、不用新会话或改决定绕过一次检查限制。

# $cm-prd 阶段耗时事件

本规则复用 `runtime/logging.md` 的 `progress/start|complete`。时间以事件 envelope 的
`at` 为准，不新增计时器，不写调用方猜测的 `duration_ms`，也不启动心跳。

## 1. 事件配对

每个实际执行阶段在开始前写 `progress/start`，完成后写 `progress/complete`。一对事件
必须具有相同的 `operation_id`、`phase_name` 和 `segment`；`segment` 从 1 开始。

开始事件只记录上述三个字段。完成事件可追加以下最小元数据：

- `outcome`: `completed | awaiting_input | blocked`；
- `context_scope`、`feature_count`、`functional_count`、`ac_count`、`task_count`、
  `test_case_count`、`finding_count` 等非负计数或枚举；
- 审查阶段可记录 `reviewer`、`independent`、`verdict` 和相对 evidence 路径。

不得记录需求、源码、diff、prompt、模型回答、开放问题正文或用户回复正文。未实际执行
的阶段不写 start/complete，也不为了让图表完整伪造 `skipped`。

## 2. 新建模式边界

| operation_id / phase_name | start | complete |
| --- | --- | --- |
| `prd-context` / `context_load` | Step 4 读取项目上下文前 | 初次 `CONTEXT_SCOPE` 判定和加载完成后 |
| `prd-requirements` / `requirements_analysis` | Step 5 分析需求前 | Step 8 `requirements.md` 写完后 |
| `prd-design` / `design_generation` | Step 8.5 开始前 | Step 9 `design.md` 写完、Step 9.5 审查前 |
| `prd-design-review` / `design_review` | Step 9.5 实际触发审查前 | 审查凭证落盘且处置完成后 |
| `prd-task-split` / `task_split` | Step 10 拆任务前 | `tasks.md` 写完后 |
| `prd-spec-validation` / `spec_validation` | Step 10.4 前 | Step 10.5 测试合同校验与规格自检完成后 |
| `prd-spec-review` / `spec_review` | Step 10.6 审查前 | 审查凭证落盘且处置完成后 |

Step 9.5 未触发时不写 `prd-design-review`；已有 `decision/design_review` 继续记录跳过原因。

## 3. 变更模式边界

| operation_id / phase_name | start | complete |
| --- | --- | --- |
| `prd-context` / `context_load` | C1 定位 specs 前 | C3 现有 specs 与变更输入读取完成后 |
| `prd-requirements` / `requirements_analysis` | C4 对比分析前 | C5 `requirements.md` 更新完成后 |
| `prd-design` / `design_generation` | C6 前 | `design.md` 更新完成后 |
| `prd-task-split` / `task_split` | C7 前 | `tasks.md` 更新完成后 |
| `prd-spec-validation` / `spec_validation` | C7.5 前 | 测试合同更新、引用校验和审批位重算完成后 |

变更模式没有实际执行 Step 9.5/10.6 时，不写 review timing 事件。

## 4. 暂停、恢复与失败

需要等待用户回答、登录或选择时，在硬停车前写当前阶段 `progress/complete`，设置
`outcome: awaiting_input`。恢复后用相同 operation/phase、递增后的 `segment` 写新一对
start/complete；因此后续分析只汇总 active segments，不把人工等待算成执行耗时。

阶段无法继续时写 complete + `outcome: blocked`，随后按主流程写 warning/error/run_done。
同一 segment 不得出现两个 complete；恢复不得复用已关闭的 segment。

## 5. 最终报告

最终摘要只说明“阶段耗时事件已记录”，不手算或猜测耗时。需要复盘时运行
`python3 {CM_WORKFLOW_ROOT}/scripts/cm-prd-timing.py --last 5`；它只读全局镜像，按
operation_id + phase_name + segment 配对时间戳，并明确显示未配对事件。

## JS 宿主的合并调用

JS按实际上下文读取、分析/生成/保存/处置请求记录活动segment；返回问题时关闭，回答后另开，
进程意外终止的未配对start保留为中断证据。C模式的需求/设计/任务生成分阶段请求。
已验收的新建full_draft为节省调用将需求/设计/任务合并生成，其三个阶段记录同一实际调用的重叠区间，
标记`timing_scope: combined_host_call`。这不是三次模型调用，也不能相加为总耗时或宣称测到了模型内部逐节耗时。
日志只有事件字段/计数，不写正文、问题或回答。

# $cm-prd Step 10.5 — 规格自检

输出摘要卡之前，先对刚生成的三件套与可选测试合同跑机器可查项。机器项由 AI
自行清干净；拆分审查补正的单次检查仍失败时，保留失败交人裁决。

## 通用自检项

- [ ] 任务依赖无环；单 feature ≤15 个任务；同一文件/组件的行为未拆散到多任务
- [ ] 基线/度量任务仅在后续任务真正读取其产物时作为前置；接口签名已冻结且可分人时已先拆契约任务，实现方与调用方都依赖契约任务、彼此不依赖，调用方与实现方任务描述已说明「契约任务的占位体会抛错，这是预期状态，不要等待它被实现、不要因此报 blocked」；新增用例按任务独立测试文件，不向同一个已有测试文件追加
- [ ] 每条 AC 都能回答“怎么验证”；验证方式不明的 AC 视为不过
- [ ] test-cases.json 语法/结构合法，AC→TC→Task 完整，用户用例未被弱化
- [ ] 任务产物查重：不与项目已有资产重复；有地图查 04/05/06，无地图用代码搜索核实

## 二开附加项（存在业务地图时）

- [ ] **引用真实性**：specs 提到的每个存量文件/函数/组件名都已用代码搜索核实
  真实存在（二开引用不存在的存量代码，人审通常发现不了、执行期才会失败）
- [ ] **B5 合规**：feature 未跨多条 07 业务线路；跨模块任务已列出模块清单
- [ ] **B3 合规**：修改存量模块的 feature，第一个任务是防护网基线
- [ ] **B2 完整**：design.md 含「波及面」段，所列模块在地图/代码中真实存在

设计已接受后，只有整稿自检明确失败，才可在原重生成步骤修改同批已有 feature 的
requirements.md、design.md 正文；必须填写非空修订原因，不得增删 feature 或文件。
宿主把改动文件、前后摘要、原因、轮次和所回应的失败记录绑定到会话；通过重跑后用 save_draft 保存新版，
不先手改磁盘。失败记录与已用轮次保留，不能靠修订增加轮次；未知结果不算失败。

接受顺序为：已完成拆分处置的版本 → 已登记并保存的自检修订 → 原设计阶段版本。
拆分审查必须读取修订版；旧版审查不能授权新版。摘要在各 feature 的风险信息旁说明原因和改动文件，
明确这些改动由拆分审查审阅、未另做设计审查；这条说明本身不阻断交付，也不增加审查调用。

首次整稿有不过项时自行修正 specs 后重跑，最多 2 轮。2 轮后仍不过的项不得静默放行，
写入摘要卡「风险点」交人裁决。自检结果一行附在摘要卡底部。

拆分审查后的补正只检查一次，不适用上述两轮修正。明确失败由 `review_disposition` 记录
`self_check_failed`，失败项与证据进入摘要风险卡，再发布待审或受控修订；不能把失败改写成通过。

# Step 11：摘要范围规则

- 摘要卡增加「历史 feature：N 个已登记，M 个含旧版归档说明」；M 按存在归档异常的 feature 去重，具体异常放入 `notes`。
- 摘要只裁决本会话 `currentFeatures`；历史 feature 保留完整 `documents`、`specFiles` 与发布证据哈希，审查门禁结果只登记，旧版归档或缺失回执进入 `notes`，不进入 `blockers`、新草稿机械自检或当前设计风险裁决（2026-09-17 真实项目 dogfood：已开发 specs 目录新增 feature 时，摘要因历史 feature 的 `[x]`、旧版归档与已完成任务被三重阻断）。
- 准备、复核与发布沿用同一当前 feature 清单；无草稿时只从 `.reviews/prd-sessions` 当前会话记录恢复，无法确定时报 `prd_summary_scope_unknown` 停止，不回退为全目录重审。
- 当前 feature 的回执覆盖、归档读取、机械自检仍严格执行；`[x]` 的只读规范化不豁免新任务必须待办。历史说明不表示重新审查或批准，发布 `.cm-specs-status` 仍覆盖全部 feature 规格哈希。
- 功能与任务统计、自检和设计风险裁决以当前 feature 为准；历史登记单独呈现。旧 API 不传 `currentFeatures` 时保持原严格检查语义，宿主必须显式提供范围。