@xulthekl/team-flow 0.60.0 → 0.62.0

package/skills/ce-brainstorm/SKILL.md

@@ -8,7 +8,7 @@ argument-hint: "[feature idea or problem to explore] [output:html]"
 
 **Note: The current year is 2026.** Use this when dating PRD documents.
 
-Brainstorming answers **WHAT** to build through collaborative dialogue, producing a **PRD document** (产品需求文档). It precedes `/ce-plan` (**HOW** to build). In compound engineering, write under `requirement/vN/prd.md`. The PRD template is configurable via `prd.template` config (default: `templates/prd.md`). This skill explores, clarifies, and documents — it does not implement code.
+Brainstorming answers **WHAT** to build through collaborative dialogue, producing a **PRD document** (产品需求文档). It precedes `/ce-plan` (**HOW** to build). In compound engineering, write under `requirement/vN/prd.md`. The PRD template is configurable via `prd.template` config (default: **plugin built-in** `templates/prd.md`, resolved against the **plugin root**, never the project root). The **§8.4 authoring spec** (`references/prd-84-authoring-spec.md`) is the sole authority for §8.4 form and rules. PRDs are written to be **business-readable** — a business reviewer must be able to read them without technical knowledge. This skill explores, clarifies, and documents — it does not implement code.
 
 ## 调用模式（v0.7 新增）
 
@@ -40,12 +40,13 @@ Brainstorming answers **WHAT** to build through collaborative dialogue, producin
 | 职责 | 执行方 | 说明 |
 |------|--------|------|
 | 需求澄清、场景确认、流程确认、方案决策 | **主会话** | 需要用户交互和判断的工作 |
-| PRD 文档撰写（Phase 3） | **prd-writer agent**（v0.47） | 执行性文档生成（契约级 §8.4），主会话做 QA 和冻结 |
+| PRD 文档撰写（Phase 3） | **prd-writer agent**（v0.62.0） | 执行性文档生成（业务可读 §8.4），主会话做 QA 和冻结 |
 | 流程图绘制（mermaid） | **子代理**（推荐） | 基于已确认的流程数据生成图表 |
 | 活动表批量生成 | **子代理**（推荐） | 基于已确认的 L4 子流程生成表格 |
 | 综合报告（synthesis summary） | **子代理**（可选） | 大量数据的汇总整理 |
 
 **子代理委托方式**：使用 `Agent` 工具（`context: fork` 或自定义 agent），将已确认的结构化数据作为输入，要求子代理按模板产出。主会话审查产出后决定接受或修正。PRD 撰写（Phase 3）固定委托命名 agent **prd-writer**（预加载 ce-brainstorm，只执行 Phase 3、不提问）；其余执行性产出（流程图/活动表/综合报告）可委托通用子代理。
+**prd-writer「不提问」的边界（v0.62.0 · G3）**：它不向用户提问，但**会断言并回传**——若模板/规范 hash 与插件内置不一致且无有效 `template_ack`，返回 `TEMPLATE_MISMATCH` + 差异摘要并**停止撰写**，由**主会话**向用户确认后再恢复。传入参数须含 `plugin_root` 与 `template_ack`。
 
 ### Stage Breakpoints
 
@@ -100,40 +101,91 @@ If no feature description was provided, ask the user. If `docs/ideation/*.md` ex
 
 > **⛔ GUARDRAIL：禁止写入 skill 源码目录**
 >
-> 项目级制品（PRD 模板、配置文件等）只在**项目工作区**创建/修改：
-> - 模板文件：`.team-flow/templates/`
+> 项目级制品只在**项目工作区**创建/修改：
 > - 配置文件：`.team-flow/team-flow.config.json`
 >
 > **绝不写入 skill 源码目录**（`skills/ce-brainstorm/` 等）。
+>
+> **⚠️ 模板例外（v0.62.0 · F2）——默认不落副本**：
+> - **默认使用插件内置模板**，**不得**在项目内创建模板副本；
+> - 仅当用户**明确选择**「项目内留副本以便定制」时，才在 `.team-flow/templates/` 创建，
+>   且**必须同时写入 `prd.template` 配置指向该副本**（否则成为无人消费的影子副本）；
+> - 项目内已存在的 `.team-flow/templates/prd.md` **非权威、不得直接读取**——
+>   生成规范一律以插件内置 `templates/prd.md` 与 `prd-84-authoring-spec.md` 为准。
 
 Determine `OUTPUT_FORMAT` (md or html). For the full 5-level precedence, read `references/output-format.md`.
 
 **Resolve PRD template — MANDATORY STEP, DO NOT SKIP.**
 
+> **v0.62.0（F2）默认不落副本**：「默认模板」= **直接使用插件内置模板**，**不 cp 到项目**。
+> 只有用户**明确选择**「项目内留副本以便定制」时才 cp，且**必须同时写入 `prd.template` 配置**。
+
 1. **检查 tf CLI 是否可用**：运行 `which tf`
-   - ✅ 可用：继续执行 `tf runtime config --get prd.template`
+   - ✅ 可用：执行 `tf runtime config --get prd.template`
+     - 有值（用户配置的自定义路径/副本路径）→ 解析该路径（相对路径按项目根解析）
+     - 无值 / 返回默认 `templates/prd.md` → **按插件内置解析**（见下方「基准」），**不查项目根**
    - ❌ 不可用：走降级逻辑（见下方）
 
-2. **降级逻辑（tf 不可用时）**：
-   - 通知用户：`tf` 命令不可用，将使用默认配置
-   - **询问用户**：默认模板 or 自定义路径？
-     - 默认模板：**直接 cp skill 内置模板到项目目录**（见下方步骤）
-     - 自定义路径：验证文件存在，在项目工作区记录配置
-   - **维护配置文件**：在 `.team-flow/team-flow.config.json` 中记录配置（如文件不存在则创建）
-
-3. **默认模板处理步骤（重要）**：
-   - **源文件**：skill 内置 `templates/prd.md`（相对于 skill 基础目录）
+2. **基准（v0.62.0 显式化，消除歧义）**：
+   - **内置路径一律以插件根为基准**：`${CLAUDE_PLUGIN_ROOT}/templates/prd.md`
+   - 项目根下若恰好存在同名 `templates/prd.md`，**不构成回退目标、不得使用**
+     （旧行为靠「项目根恰好没有同名文件」才不歧义，属隐性依赖）
+   - 用户配置值若为相对路径 → 按**项目根**解析
+
+3. **降级逻辑（tf 不可用时）**：
+   - 通知用户：`tf` 命令不可用，将按插件内置模板解析
+   - **询问用户**：使用插件内置模板，**还是在项目内留一份副本以便定制**？
+     - **插件内置**（默认）：直接解析 `${CLAUDE_PLUGIN_ROOT}/templates/prd.md`，**不 cp、不写配置**
+     - **项目内留副本**：cp 到 `.team-flow/templates/prd.md`
+       → **必须同时写入 `prd.template` 配置指向该副本**
+       （`tf config --set prd.template=.team-flow/templates/prd.md`）
+       → 否则该副本无人消费，成为误导性影子副本
+
+4. **副本创建步骤（仅当用户明确选择「项目内留副本」时）**：
+   - **源文件**：插件内置 `templates/prd.md`
    - **目标目录**：`.team-flow/templates/`（项目工作区）
-   - **操作**：直接 `cp` 源文件到目标目录，**不要自行创建简化版本**
-   - **验证**：检查目标文件是否存在且包含完整的11个章节
-
-Built-in `templates/prd.md` is relative to the skill's base directory. Custom paths are relative to project root.
+   - **操作**：直接 `cp`，**不要自行创建简化版本**
+   - **验证**：目标文件存在且含完整的 11 个章节
+   - **成对**：模板与 brainstorm profile 必须成对处理（见下）
 
 **⛔ 关键约束**：
-- **错误行为**：自行创建简化版本的PRD模板
-- **正确行为**：直接 cp 原始 PRD 模板到项目目录，保持模板完整性
+- **错误行为**：自行创建简化版本的 PRD 模板／默认往项目里 cp 副本／**直接读取项目内既有的 `.team-flow/templates/prd.md`**
+- **正确行为**：默认用插件内置；仅在用户明确定制时 cp，并同步写配置
+
+**Resolve brainstorm profile.** After template resolution, look for `<template-name>-brainstorm-profile.md`
+**in the same directory as the resolved template**——模板与 profile **成对**，cp / 删除 / 漂移检测一律成对处理。
+Store as `BRAINSTORM_PROFILE_PATH`. Fall back to built-in `templates/prd-brainstorm-profile.md`.
+
+5. **模板一致性确认门（DP-8，v0.62.0 · G1）—— 阻塞，不可跳过**：
+
+   模板解析完成后、**Phase 3 派发 prd-writer 之前**，运行 `tf prd check --plugin-root "${CLAUDE_PLUGIN_ROOT}"`
+   取判据（判据实现见 `scripts/lib/template-hash.mjs`，**不得在本 skill 另写一套**）：
 
-**Resolve brainstorm profile.** After template resolution, look for `<template-name>-brainstorm-profile.md` in the same directory. Store as `BRAINSTORM_PROFILE_PATH`. Fall back to built-in `templates/prd-brainstorm-profile.md`.
+   | STATUS | 行为 |
+   |---|---|
+   | `MATCH` | **静默继续**——三 hash 与 `template_ack` 全等，用户此前已确认过 |
+   | `NO_ACK` | **阻塞提问**（首次） |
+   | `MISMATCH` | **阻塞提问**（模板/规范已变化，上次确认失效） |
+   | `UNRESOLVED` | 无法定位模板或插件根 → 记 `missing_info` 并**降级为警告**，不阻断 |
+
+   **提问三选项**（一律在**主会话**执行；prd-writer 是"不提问"子代理）：
+
+   | 选项 | 含义 | 后续 |
+   |---|---|---|
+   | **A. 按最新模板与规则** | 采用插件内置模板 + 最新规范 | **先执行历史文档就地升级**（见下），再撰写；`tf prd ack set --mode adopt_latest …` |
+   | **B. 保留当前模板继续** | 沿用项目现有模板（已确认落后） | 直接撰写；`tf prd ack set --mode keep_legacy …`，**并落 `dialogue-log.md` 受控记录**（属偏离接受 waiver） |
+   | **C. 先看差异再定** | 输出差异摘要后回到 A/B | **不写 ack**（下次仍会问） |
+
+   **ack 写入**：`tf prd ack set`（原子命令，**不要**用多次 `tf config --set` 拼装——
+   现行 `--set` 的值解析不支持对象，且 6 字段分 6 次写无原子性）。
+   须写入 `in_use_hash` / `plugin_hash` / `spec_hash` / `plugin_version` / `mode` / `diff_digest`。
+
+   **选 A 时的历史文档前置处置（全部完成才放行撰写）**：
+   ① 同迭代旧形态 `prd.md` **就地升级为新形态**（**不归档、不改名**——改文件名会打断 S3/spec 路径引用与证据链）；
+   ② 成对处置项目内模板 / profile 副本；③ `dialogue-log.md` 登记「形态迁移」变更记录（**含升级前内容摘要值**，作为"不归档"的留痕替代）；
+   ④ 补齐 `detail-ledger.md` 结构；⑤ **信息保全核对**：先完整读取旧形态 → 升级时逐项核对旧文信息无一遗漏 → 通过才放行。
+
+   **自动化路径（jarvis 等夜间值守）**：遇本门**一律挂起**，**不得代答或跳过**。
 
 #### 0.1–0.5 Routing Sub-phases
 
@@ -155,7 +207,8 @@ For detailed routing logic, read `references/phase0-routing.md`. Summary:
 
 **1.3 Dialogue** — Follow Interaction Rules. Fire blindspot gate (if tripwire armed) and visual-probe gate (before first shape decision). Rigor probes fire as open-ended questions before Phase 2. Before exit: integration check for non-obvious consequences. **Exit when**: primary actor, outcome, scope, success criteria all known or recorded as assumptions.
 
-**1.3b 功能细节澄清（v0.47）** — Follow the brainstorm profile's「功能细节（契约级）」core dimension. Standard/Deep scope **强制契约级澄清**（UI 布局/字段/交互/异常/权限；非 UI 触发/输入输出/处理/异常/幂等并发/性能），Lightweight 简化。产出 **detail_ledger**（`requirement/vN/detail-ledger.md`，逐功能维度 → 已澄清/待澄清/NA），供 Phase 3 §8.4 撰写 + 冻结前 D6 核对。
+**1.3b 功能细节澄清（v0.62.0）** — Follow the brainstorm profile's「功能细节」core dimension. Standard/Deep scope **逐条澄清业务信息**（UI：谁用 / 展示什么 / 能做什么 / 失败怎么办；非 UI：何时触发 / 输入输出 / 出错怎么办），Lightweight 简化。产出 **detail_ledger**（`requirement/vN/detail-ledger.md`，逐功能 → 已澄清/待澄清/NA），供 Phase 3 §8.4 撰写 + 冻结前 D6 核对。
+**边界**：澄清的是**业务信息本身**，不是「正文该写成什么样」——形态由 `prd-84-authoring-spec.md` 规定。
 
 **1.4 Dialogue Log Persistence** — Automated step, no user interaction. Trigger: Phase 1.3 dialogue exits. Traverse each Q&A round extracting original text + decisions, generate dialogue summary and decision summary table. Write to `requirement/vN/dialogue-log.md` (create or append). No ledger update.
 
@@ -193,15 +246,26 @@ Propose **2-3 approaches** (or recommend directly if one is clearly best). Use n
 - `requirement/ledger.md` — all requirement/scenario/process items and their associations
 - `requirement/vN/dialogue-log.md` — §1.2 revision record reference path
 - `requirement/vN/business-analysis.md` — data source for §2/§3/§7/§8
-- `requirement/vN/detail-ledger.md` — 功能细节澄清产出（v0.47），§8.4 逐功能详述数据源 + D6 核对基准
+- `requirement/vN/detail-ledger.md` — **维度清单载体 + 完整性台账 + D6 核对基准**（v0.62.0）：承载 11 维 / 7 维的内部校验清单与逐功能状态（已澄清 / 待澄清 / `NA + 理由`），是 §8.4 撰写的**信息数据源**（不是正文形态模板）
 
 **⛔ MANDATORY：生成PRD文档前，必须先读取 `references/brainstorm-sections.md`**
 
-**§8.4 功能模块提取规则（v0.47）**：规范唯一权威 = 模板 `templates/prd.md` §8.4「必含维度检查清单」（UI 11 维 / 非 UI 7 维双形态 + NA 机制），**本处不再重复维护维度清单**。生成 PRD 前必须读取模板检查清单，逐功能模块按适用维度详述；维度不适用标注 `NA + 理由`；**未标注 NA 且未覆盖 = 缺失**。
+**§8.4 功能模块提取规则（v0.62.0）**：**规范唯一权威 = `references/prd-84-authoring-spec.md`**
+（**不是**模板 §8.4、也**不是**项目内的模板副本）——本处不再重复维护规范。生成 PRD 前必须读取该规范文件：
+
+- 每个功能模块 = **一张两列表格 + 编号业务叙述**（定义 → 条件或触发 → 内容或要素 → 业务规则 → 异常与边界）
+- **左列必须是画面/入口锚点**（UI 用 `原型/UI`，非 UI 用 `触发入口`），**不得**写成「维度 / 字段 / 类型」
+- 完整性走**内部校验清单**（11 维 / 7 维）：撰写前核对信息齐备，**清单本身不写入正文**
+- 维度不适用 → 在 `detail-ledger.md` 标 `NA + 理由`，**不在正文标注 NA**
+- 面向**业务评审人**撰写：业务语汇为主干，技术标识符不进正文主干，禁弱词
 
 Read `references/brainstorm-sections.md` for doc-warranted criteria. If warranted: read template from `PRD_TEMPLATE_PATH`, fill via `references/prd-mapping.md`, write to `requirement/{ITERATION_VERSION}/prd.md`. Vocabulary capture: update `CONCEPTS.md` with resolved domain terms (only if it exists).
 
-> **子代理委托（v0.47）**：Phase 3 PRD 撰写委托 **prd-writer** agent。主会话将已确认结构化数据（business-analysis.md + dialogue-log.md + **detail_ledger** + synthesis summary + template_path）作为参数传入；prd-writer 按模板 §8.4 契约级检查清单逐功能详述，不提问、不虚构，`missing_info` 返回主会话决定是否回 Phase 1.3 补澄清。主会话负责 QA-4 审查和冻结确认。
+> **子代理委托（v0.62.0）**：Phase 3 PRD 撰写委托 **prd-writer** agent。主会话将已确认结构化数据
+> （business-analysis.md + dialogue-log.md + **detail_ledger** + synthesis summary + `template_path`
+> + **`plugin_root`** + **`template_ack`**）作为参数传入；prd-writer 按 **`prd-84-authoring-spec.md`**
+> 逐功能按业务认知顺序撰写，不提问、不虚构，`missing_info` 返回主会话决定是否回 Phase 1.3 补澄清。
+> 主会话负责 QA-4 审查和冻结确认。
 
 ### Phase 3.5: Prototype Inner Loop
 
@@ -209,7 +273,7 @@ Read `references/brainstorm-sections.md` for doc-warranted criteria. If warrante
 
 ### QA-4: PRD Quality Check
 
-Fires after Phase 3 (or Phase 3.5 if prototype loop ran). Read `references/evidence-chain-validation.md` for QA-4 criteria. Evaluates PRD completeness and traceability against business analysis artifacts. **冻结前完整性评审（6 维，含 §8.4 契约级细节 D6）的派发点已归并**：standalone 路径由 Phase 3.5（`references/prototype-loop.md` §3.5.5）派发 prd-completeness-reviewer；orchestrated 路径由 orchestrator S2 派发（见 `workflow-orchestrator/references/s2-prd-prototype-loop.md`）；**QA-4 自身不重复派发**，仅按评审结果判定是否回 Phase 1.3/Phase 3 修订。
+Fires after Phase 3 (or Phase 3.5 if prototype loop ran). Read `references/evidence-chain-validation.md` for QA-4 criteria. Evaluates PRD completeness and traceability against business analysis artifacts. **冻结前完整性评审（6 维，含 §8.4 信息齐备性与业务可读形态 D6）的派发点已归并**：standalone 路径由 Phase 3.5（`references/prototype-loop.md` §3.5.5）派发 prd-completeness-reviewer；orchestrated 路径由 orchestrator S2 派发（见 `workflow-orchestrator/references/s2-prd-prototype-loop.md`）；**QA-4 自身不重复派发**，仅按评审结果判定是否回 Phase 1.3/Phase 3 修订。
 
 ### Phase 3.6: PRD ↔ Scenario/Process Bidirectional Validation
 
@@ -241,7 +305,7 @@ requirement/
 ├── vN/                                # Iteration version
 │   ├── prd.md                         # PRD document
 │   ├── dialogue-log.md                # Dialogue log (Phase 1.4 output)
-│   ├── detail-ledger.md               # 功能细节澄清产出（v0.47，§8.4 数据源 + D6 核对基准）
+│   ├── detail-ledger.md               # 维度清单载体 + 完整性台账 + D6 核对基准（v0.62.0）
 │   └── business-analysis.md           # Business analysis (requirements + scenarios + processes)
 doc/
 └── active-registry/

package/skills/ce-brainstorm/references/brainstorm-sections.md

@@ -30,7 +30,9 @@ New `ce-brainstorm` outputs follow the PRD artifact contract:
 - **Path:** `requirement/vN/prd.md` (N is the iteration version number, e.g., v1, v2). Legacy fallback: `prd/vN/prd.md`.
 - **Metadata:** `project_name`, `iteration_version`, `prd_template` (template path).
 - **Template source:** read `prd.template` from project configuration, or use
-  the default `templates/prd.md`.
+  the **plugin built-in** `templates/prd.md` (resolved against the **plugin root**;
+  a project-local `templates/prd.md` is **not** a fallback and must not be read directly).
+- **§8.4 authoring spec:** `prd-84-authoring-spec.md` — sole authority for §8.4 form and rules.
 - **Structure:** the PRD contains 11 chapters as defined by the PRD template:
   1. 版本修订记录
   2. 业务流程一览
@@ -255,6 +257,9 @@ as template placeholder.
 - **§6 D7.4_业务术语字典** — fill with domain terms actively defined during
   dialogue. Only include terms where the conversation pinned down a precise
   meaning. Skip terms merely mentioned in passing.
+  **v0.62.0**：该表是**业务与代码共享词汇表**——「术语名称」用**业务语汇**（PRD 正文主干一律用它），
+  并填「**代码标识**」列（该术语在代码中的对应标识：类名/字段名/枚举值等），供**实现侧对齐**；
+  **不得**用代码标识回写正文主干。业务上无对应代码概念的填「—」。
 
 - **§7 D7.5_系统功能清单** — fill from brainstorm Requirements. Each R-ID
   maps to a system function entry with the requirement's intent as the function
@@ -267,11 +272,13 @@ as template placeholder.
   所属流程 (BP-xxx). Skip §8.3 (hardware/network) and §8.5 (non-functional)
   unless the brainstorm explicitly covered these.
 
-  **§8.4 功能模块提取规则（v0.47）**：
-  - **规范权威**：模板 `templates/prd.md` §8.4「必含维度检查清单」是唯一权威（UI 11 维/非 UI 7 维双形态 + NA 机制），本文件不再重复维护维度清单。撰写（prd-writer）与审查（prd-completeness-reviewer D6）均以模板为基准。
-  - **详细程度**：保留原始需求文档中的关键细节，不要过度概括（页面布局/搜索字段/表格列/交互规则/动态字段/级联逻辑等——逐项见模板检查清单）
-  - **错误行为**：只提取输入/输出/业务规则，丢失原始需求文档中的大量关键细节
-  - **正确行为**：充分利用原始需求文档的详细内容，保持信息完整性
+  **§8.4 功能模块提取规则（v0.62.0）**：
+  - **规范权威**：**`prd-84-authoring-spec.md` 是唯一权威**（**不是**模板 §8.4、也**不是**项目内模板副本），本文件不再重复维护规范。撰写（prd-writer）与审查（prd-completeness-reviewer D6 + 形态核验 G7）均以该规范文件为基准。
+  - **呈现形态**：每个功能模块 = 一张两列表格 + 编号业务叙述（定义 → 条件或触发 → 内容或要素 → 业务规则 → 异常与边界）；**左列必须是画面/入口锚点**（`原型/UI` 或 `触发入口`）
+  - **完整性**：11 维 / 7 维降为**内部校验清单**，撰写前核对信息齐备，**清单本身不写入正文**；维度不适用在 `detail-ledger.md` 标 `NA + 理由`
+  - **详细程度**：保留原始需求文档中的关键**业务**细节，不要过度概括
+  - **错误行为**：只提取输入/输出/业务规则，丢失原始需求文档中的大量关键细节；或把维度清单写进正文
+  - **正确行为**：充分利用原始需求文档的详细内容，按业务认知顺序重组进正文，保持信息完整性
 
 ## Agent agency
 
@@ -297,8 +304,10 @@ Every PRD produced by `ce-brainstorm` carries metadata in YAML frontmatter.
 - **`iteration_version`** — the iteration version (e.g., "v1", "v2"),
   corresponding to the `requirement/vN/` directory.
 - **`date`** — creation date in ISO 8601 (`YYYY-MM-DD`).
-- **`prd_template`** — relative path to the PRD template used (e.g.,
-  `templates/prd.md`).
+- **`prd_template`** — relative path to the PRD template used. When the plugin built-in
+  is in effect (the default), record `templates/prd.md` and note it resolves against the
+  **plugin root**; `prd_84_spec` — relative path to the §8.4 authoring spec
+  (`skills/ce-brainstorm/references/prd-84-authoring-spec.md`).
 - **`prd_readiness`** — always `requirements-only` for new `ce-brainstorm`
   outputs. `ce-plan` produces a separate `plan.md` document (not modifying the PRD).
 
@@ -331,6 +340,15 @@ existing fields breaks downstream consumers.
   file layouts, code structure stay out unless the brainstorm itself is
   inherently about a technical or architectural change and those details are
   the subject of the decision.
+  **Vocabulary boundary (v0.62.0):** 正文主干用**业务语汇**（§6 术语字典的业务名）；
+  类名 / 方法名 / 表名 / 注解 / 字段名 / 行号**不得**出现在正文主干，确需时以**括注**附于业务名之后
+  （例：「生效版本（字段 `last_agreement_version`）」）。
+- **No history traces (v0.62.0).** 删除线、版本锚点（`v0.5ac`）、澄清轮次锚点（`Q8 新增`）、
+  「原口径作废」「已被推翻」「沿革留痕」一律**不进正文**——它们属演变轨迹，迁 `dialogue-log.md`。
+- **No internal checklist transcript (v0.62.0).** 11 维 / 7 维检查清单是**撰写者的内部校验清单**，
+  不得把清单本身（或「按 … 维覆盖，不适用标 NA」式转述）写进正文；不适用维度在 `detail-ledger.md` 标 `NA + 理由`。
+- **No weak words (v0.62.0).** 禁用比较级 / 主观词 / 歧义词 / 开放式 / 漏洞词
+  （较快 / 友好 / 支持 / 适当 / 等 / 尽可能 / 必要时）——模糊表述会被下游自行解释，产生静默缺陷。
 
 ## Rendering
 

package/skills/ce-brainstorm/references/evidence-chain-validation.md

@@ -16,7 +16,7 @@ This reference covers three connected operations after PRD generation: QA-4 qual
 | C5 | Consistency | PRD §2 process overview table matches business-analysis.md process list? | Error |
 | C6 | Consistency | PRD §3 process descriptions match business-analysis.md process details? | Error |
 | C7 | Metadata | PRD frontmatter complete (title / project_name / iteration_version / date / prd_template)? | Warning |
-| C8 | Detail | §8.4 契约级细节：逐功能模块按模板检查清单覆盖适用维度（UI 11 维/非 UI 7 维，单一权威 = 模板 §8.4）+ §7↔§8.4 交叉核对无悬空功能（v0.47 并入 D6 模型：核心维度缺失/悬空 = Critical，辅助维度缺失 = Important） | Critical |
+| C8 | Detail | §8.4 信息齐备性与业务可读形态：逐功能模块按**业务认知顺序**核对信息是否可定位（**单一权威 = `prd-84-authoring-spec.md`**，**不是**模板 §8.4、也**不是**项目内模板副本）+ §7↔§8.4 交叉核对无悬空功能 + **形态核验 G7 六条**（左列为画面/入口锚点、§1.2 极简版本行、范围标记受控枚举、无历史痕迹、无技术标识符越界、维度清单未入正文）。判级：核心信息缺失/悬空 = Critical，辅助信息缺失/**形态核验命中** = Important | Critical |
 
 **Verdict rule:** All Error-level checks pass → PASS. Any Error fails → FAIL. Warnings are reported but do not block.
 

package/skills/ce-brainstorm/references/prd-84-authoring-spec.md

@@ -0,0 +1,182 @@
+# PRD §8.4 撰写规范（权威）
+
+> **本文件是 PRD §8.4 生成规范的唯一权威**（v0.62.0 · F1）。
+>
+> **为何外置**：`templates/prd.md` 同时承担「客户可能强制的 D7 体例骨架」与「team-flow 维护的生成规范」。
+> 一旦模板被拷贝进项目，规范就被连带冻结、插件升级推不动。解耦后：**骨架副本可以旧，规范永远新**。
+>
+> **适用范围**：撰写（`prd-writer`）、审查（`prd-completeness-reviewer` D6）、形态核验（G7）
+> 一律以本文件为准，**不得**依据模板副本或自身预期判断。
+> 模板 `templates/prd.md` §8.4 只承载**骨架与填空槽位**，并指向本文件。
+
+---
+
+## 1. 读者与立场
+
+§8.4 面向**业务评审人**撰写。**读本节的人不需要懂技术。**
+
+- 能写进正文的：业务动作、业务规则、界面呈现、异常与边界的业务后果。
+- 不能写进正文的：类名、方法名、表名、字段名、行号、框架注解、实现方案选型。
+  （确需说明时，以括注形式附在业务名之后，例如「生效版本（字段 `last_agreement_version`）」）
+
+---
+
+## 2. 目标形态
+
+### 2.1 一功能一表
+
+每个功能模块独立成表，**两列**：
+
+| 功能形态 | 左列名 | 右列内容 |
+|---|---|---|
+| **UI 功能** | `原型/UI` | 原型文件与容器定位 |
+| **非 UI 功能** | `触发入口` | 什么事件/时机触发该功能 |
+
+右列是**业务说明**，按 §2.2 的编号骨架展开。**不得**用 checkbox 维度清单替代叙述。
+
+> **核验要点**：左列必须是**画面/入口锚点**。出现「维度 / 字段 / 类型 / 信息结构」等**技术维度名**
+> 即为形态违规——即便表格是两列、叙述也编号，语义仍是按技术维度切分。
+
+### 2.2 编号业务叙述骨架
+
+右列按**业务认知顺序**展开（不按技术维度切分）：
+
+1. **定义** —— 这个功能是什么、给谁用、解决什么问题（1–3 句，业务语汇）
+2. **条件或触发** —— UI 功能写查询条件与控件；非 UI 功能写什么情况下触发
+3. **内容或要素** —— UI 功能写展示哪些字段、什么布局；非 UI 功能写输入什么、产出什么
+4. **业务规则** —— 生效的规则逐条写清，含前提条件与例外（**本功能最重要的部分**）
+5. **异常与边界** —— 空态 / 错误态 / 无权限 / 并发 / 极值 / 状态冲突 / 数据缺失 / 外部依赖失败
+   ——**按业务风险选取**，纯展示类写关键 2–3 项即可，**不要求逐功能写全**
+
+> **密度优先**：允许在右列内嵌字段表、决策表，避免为凑骨架而把一条规则拆成五段。
+
+### 2.3 可解析性硬约束（保护下游消费方，**必守**）
+
+叙述化不得牺牲可解析性。**字段类信息**在叙述中必须以
+「**字段名在前、冒号分隔、规则在后**」的**可辨识格式**呈现：
+
+```
+协议名称：输入框，模糊匹配，最长 50 字符
+```
+
+**理由**：`prototype-reviewer`（D3 字段一致性）、`prototype-env-scout`、
+`prototype/references/builder-methodology.md` 等下游**从 §8.4 提取字段**。
+若改为自由散文（如「用户可以按协议名称搜索，是模糊匹配，最多五十个字」），
+下游解析即失败——**可读性改造不能以牺牲下游可用性为代价**。
+
+**禁止**：把字段信息写成跨句的散文；**允许**：字段表（更推荐）、编号列表中的单行「字段：规则」。
+
+---
+
+## 3. 六条生成原则
+
+| # | 原则 | 要点 |
+|---|---|---|
+| 一 | **单一真相** | 正文 = 当前生效约定的完整重述。已失效的旧结论、版本演变轨迹、被推翻的论证**不得**出现 |
+| 二 | **一功能一表** | 见 §2.1 |
+| 三 | **按业务认知顺序** | 见 §2.2；不按技术维度切分 |
+| 四 | **业务语汇为主干** | 见 §1 |
+| 五 | **呈现与完整性解耦** | 完整性走内部清单（§5），**不写入正文** |
+| 六 | **精确性优先** | 见 §4 |
+
+### 3.1 原则一的三类内容判定
+
+| 内容类型 | 定义 | 归属 |
+|---|---|---|
+| **Rationale**（为什么这样定） | 当前生效约定的理由 | **保留在正文**（压缩为一句话） |
+| **Change history**（曾经怎么定） | 已失效的旧结论与演变轨迹 | **迁出**至 `dialogue-log.md` |
+| **本期范围标记** | 本期迭代新增/变更/不变 | **保留**（受控枚举，见 §6） |
+
+**判定测试**（写作者自检 + 审查者核对）：
+
+1. 删除该句后，读者对「**当前应该怎么做**」的理解是否改变？改变 → 保留。
+2. 若不变：读者对「**为什么这么做**」的理解是否受损？受损 → 属 rationale，压缩为一句话保留。
+3. 两者皆不变 → 历史噪音，删除或迁出。
+4. 这条信息是让评审人知道「**这次变了什么**」（范围标记 → 保留），
+   还是「**以前是什么**」（演变轨迹 → 迁出）？
+
+---
+
+## 4. 精确性（弱词规则）
+
+**禁用**：比较级（较快 / 更好）、主观词（友好 / 简洁）、歧义词（支持 / 处理 / 适当）、
+开放式（等 / 尽可能 / 视情况）、漏洞词（必要时 / 一般）。
+
+**理由**：PRD 是下游（plan / spec / 代码生成）的输入。模糊表述**不会**被当作"待澄清"，
+**会被下游自行解释**，产生静默缺陷。精确不是洁癖，是正确性的前提。
+
+---
+
+## 5. 完整性：内部校验清单（**不写入正文**）
+
+UI **11 维**：页面布局 / 权限规则 / 区块说明 / 搜索模块 / 表格列定义 / 交互规则 / 弹层结构 /
+动态字段 / 导入导出规则 / 状态操作差异 / 异常边界
+
+非 UI **7 维**：触发条件 / 输入输出 / 处理步骤 / 异常处理 / 权限角色 / 幂等并发 / 性能约束
+
+**用法**：
+
+- 撰写**前**：用它核对信息是否齐备（缺什么就去澄清什么）；
+- 撰写**时**：按 §2.2 的**业务认知顺序**重组进正文叙述；
+- **不得**把清单本身写进正文（无列名清单、无 checkbox 列表）；
+- 维度不适用时：在 `detail-ledger.md` 标注 `NA + 理由`，**不在正文标注 NA**。
+
+> **核验要点**：正文出现「按 … 维覆盖，不适用标 NA」之类**清单转述**，即为违规（原则五）。
+
+---
+
+## 6. 范围标记（受控枚举）
+
+§2 业务流程一览、§7.1 功能清单的「变更类型」列**只允许取三个受控值**：
+
+`本期新增` / `本期变更` / `本期不变`
+
+**禁止**在标记位写入版本锚点（`v0.5ac` / `v0.47`）、澄清轮次锚点（`Q8 新增`）、日期、旧值、变更原因。
+这些属**演变轨迹**，归属 `dialogue-log.md`。
+
+---
+
+## 7. 反填充约束
+
+**不得为「看起来完整」而填充。** 凡无法辩护的内容一律删除。
+
+**可核对判据**（「无法辩护」本身不可核对，须落到这两条）：
+
+1. **可指回来源**：正文每条业务规则必须能指回需求来源或澄清记录
+   （`business-analysis.md` / `dialogue-log.md`）；**指不回去的即删**。
+2. **NA 必附理由且可被挑战**：`detail-ledger.md` 的 NA 须写一句理由，审查者可挑战；
+   **冲突时以「有理由的 NA」优先**（防止为消灭 NA 而反向填充）。
+
+---
+
+## 8. 可读性自查项
+
+撰写完成后逐条自检（**自查 ≠ 规格正文**，不构成对业务方的规格条款，判定权仍在业务评审）：
+
+| # | 自查项 |
+|---|---|
+| 1 | 无类名 / 方法名 / 表名 / 行号出现在正文主干 |
+| 2 | 无历史痕迹（删除线、版本锚点、「原口径作废」「已被推翻」） |
+| 3 | 术语用 §6 术语字典的**业务名** |
+| 4 | 无弱词（见 §4） |
+| 5 | 维度清单未写入正文（见 §5） |
+
+> **非脚本门禁**：本节不得接入机械门禁脚本（弱词检测先落 LLM 审查层）。
+
+---
+
+## 9. 撰写后形态核验（G7）
+
+`prd-completeness-reviewer` 在 D6 内按此 6 条核验产出形态：
+
+| # | 核验项 | 判级 |
+|---|---|---|
+| 1 | §8.4 是否「一功能一表 + 编号业务叙述」，且**左列为画面/入口锚点** | 不符 = Important |
+| 2 | §1.2 是否极简版本行：单版本行要点 **≤ 200 字**；**无**「已被 X 推翻」式反转注记；功能级历史指向 `dialogue-log.md` | 不符 = Important |
+| 3 | 范围标记是否受控枚举（§6） | 不符 = Important |
+| 4 | 有无历史痕迹残留（删除线、版本锚点、章节名带版本） | 命中 = Important |
+| 5 | 有无技术标识符越界（类名 / 方法名 / 表名 / 注解 / 字段名 / 行号） | 命中 = Important |
+| 6 | 有无把维度清单写入正文（§5） | 命中 = Important |
+
+> **判据必须同时查「形态」与「内容」**——只查形态会被"形似神不似"的产出绕过。
+> 实证：某存量 PRD 确为两列表 + 编号叙述，但左列是「维度」；§1.2 表头合规但单行要点达 7,156 字。

package/skills/ce-brainstorm/references/prd-mapping.md

@@ -74,7 +74,7 @@ ce-brainstorm 的对话流程收集的信息需要映射到 PRD 模板的 11 个
 | `iteration_version` | frontmatter | `vN`（v1/v2/…） | **产品迭代版本** | 仅新迭代/新用户故事（vN+1）|
 | 产品版本 | 正文 §1.1 版本信息 | `vN.M`（v1.0/v1.1/…） | **文档修订次版本** | vN 内每次修订递增 M（呼应反馈环路「vN 内修订不升版」）|
 
-- vN 内修订（S3→S2 回退修订）→ 只递增正文 `vN.M` 的 M，**frontmatter `iteration_version` 不变**，并在 §1.2 修订记录追加一行 + 「决策与变更履历」章节记录。
+- vN 内修订（S3→S2 回退修订）→ 只递增正文 `vN.M` 的 M，**frontmatter `iteration_version` 不变**，并在 §1.2 修订记录追加**一行一句话摘要**（**≤ 200 字**，禁「已被 X 推翻」式反转注记），**功能级历史与决策过程写入 `dialogue-log.md`**（PRD 正文不承载）。
 - 新迭代 → frontmatter `iteration_version` 升 vN+1，正文产品版本重置为 `v(N+1).0`，新建 `requirement/v(N+1)/` 目录。
 
 **文档状态枚举（§1.1）——必须与 frontmatter `frozen` 一致**：
@@ -93,7 +93,7 @@ PRD 冻结时（`frozen_downstream`），在正文标题下方插入冻结声明
 
 ```markdown
 > **本文档已于 {YYYY-MM-DD} 冻结**（`frozen_downstream`，经原型循环验证 + 人工评审通过）。
-> 下游阶段（plan/spec/build）**不可直接修改**；如 plan 或实施暴露 scope 问题，经 **S3→S2 回退在 vN 内修订**并记录「决策与变更履历」（不升版）。
+> 下游阶段（plan/spec/build）**不可直接修改**；如 plan 或实施暴露 scope 问题，经 **S3→S2 回退在 vN 内修订**——**正文更新为最新态**（就地升级、不累积历史），决策与变更过程记入 `dialogue-log.md`（不升版）。
 > 仅当**启动新迭代 vN+1** 或**用户显式绝对冻结**（`frozen_absolute`）时，才需升版。
 ```
 
@@ -107,14 +107,19 @@ PRD 冻结时（`frozen_downstream`），在正文标题下方插入冻结声明
 
 | PRD 模板 | Brainstorm Profile |
 |----------|-------------------|
-| `templates/prd.md` | `templates/prd-brainstorm-profile.md` |
+| **插件内置** `templates/prd.md`（默认） | **插件内置** `templates/prd-brainstorm-profile.md` |
 | `my-project/prd-template.md` | `my-project/prd-template-brainstorm-profile.md` |
 | `.team-flow/custom-prd.md` | `.team-flow/custom-prd-brainstorm-profile.md` |
 
+> **v0.62.0（F2）**：模板与 profile **成对**——cp / 删除 / 漂移检测一律成对处理。
+> **默认不落副本**：未配置 `prd.template` 时直接用**插件内置**，不在项目内创建
+> `.team-flow/templates/` 副本；项目内已存在的副本**非权威、不得直接读取**。
+> 内置路径一律以**插件根**为基准解析（项目根同名路径不构成回退目标）。
+
 ### 查找优先级
 
 1. 自定义模板同目录的 profile 文件（按命名规则推导）
-2. 内置默认 `templates/prd-brainstorm-profile.md`（相对 skill 基目录）
+2. 内置默认 `templates/prd-brainstorm-profile.md`（**相对插件根**解析）
 
 ### Profile 三段结构
 

package/skills/ce-brainstorm/references/prototype-loop.md

@@ -43,10 +43,10 @@ PRD 文档写入后、Handoff 之前，执行原型内循环。原型是 PRD 的
 
 派发 `prd-completeness-reviewer` 子代理（独立上下文），评审 PRD「是否完整到能支撑后续 plan/spec 实施」（区别于 Phase 2.6 claim verifier——后者管"说得对不对"，本评审管"说得全不全"）。
 
-- 派发：按名派发插件 agent `prd-completeness-reviewer`（定义见插件 `agents/prd-completeness-reviewer.md`），传入 `prd_path` + `concepts_path`（可选）+ `template_path`（默认 `templates/prd.md`）+ `detail_ledger_path`（如有）。
+- 派发：按名派发插件 agent `prd-completeness-reviewer`（定义见插件 `agents/prd-completeness-reviewer.md`），传入 `prd_path` + `concepts_path`（可选）+ `template_path`（默认**插件内置** `templates/prd.md`）+ **`spec_path`**（默认 `${CLAUDE_PLUGIN_ROOT}/skills/ce-brainstorm/references/prd-84-authoring-spec.md`，§8.4 规范唯一权威）+ `detail_ledger_path`（如有）。
 - agent 直接写审查报告到 `requirement/{ITERATION_VERSION}/prd-completeness-review.md`。
 - 判定（柔性）：PASS / PASS_WITH_WARNINGS → 进入冻结；**FAIL（Critical>0）→ 回 Phase 1.3/Phase 3 补充**后重审。
-- 6 维度：用户故事完整性(Critical)/验收标准(Critical)/边界与非功能(Important)/术语一致性(Minor)/范围闭环(Important)/§8.4 契约级细节（核心维度缺失·悬空功能=Critical，辅助维度缺失=Important）。
+- 6 维度：用户故事完整性(Critical)/验收标准(Critical)/边界与非功能(Important)/术语一致性(Minor)/范围闭环(Important)/**§8.4 信息齐备性与业务可读形态**（核心信息缺失·悬空功能=Critical，辅助信息缺失·**形态核验 G7 命中**=Important）。
 
 ## 3.5.6 冻结
 

package/skills/ce-plan/references/change-splitting.md

@@ -17,6 +17,18 @@ Break the work into logical **changes** (team-flow change units). Each change re
 - 一个内聚功能模块（如"下单""权限体系"）通常对应一个所有权单元 → 通常 = 一个 change
 - 但"一个用户故事"不等于"一个 change"的充要条件——若多个故事共享同一所有权单元（如看板多视角共享同一读模型），它们应合为一个 change
 
+## 拆分默认姿态（粗粒度优先，v0.60.x 新增）
+
+**默认不拆细。** 把一个迭代版本的工作拆成 change 时，优先合并为少量**粗粒度** change（按所有权单元计）。只有在以下三条中**至少一条成立**时，才向下拆细：
+
+1. **越过所有权边界**：子块对应不同的聚合 / 限界上下文 / 读模型 / 契约所有权，必须各自独立做架构增量设计（即 D5 判据要求拆）。
+2. **需要独立并行验证**：子块可被不同人/不同时间独立实现并验证，合在一起反而难测。
+3. **团队领取需要**：协作分发时，必须拆开才能分给不同成员认领。
+
+**"拆太细"的代价**：每个 change 都要走完整 8 态 + 4+1 产物 + 架构增量设计 + 复利回写——当 change 细到单接口/单文件/单方法时，这些仪式开销远大于改动本身价值。`change-split-auditor` D3 会主动提示合并候选（见该 agent D3），但**仅为建议、不硬拦**（与 D5「切碎所有权」的硬 FAIL 不同级）。
+
+> 一句话：**宁粗勿细。拆细是例外，不拆是默认。**
+
 ## Good Changes
 
 **根因判据**：每个 change 的 scope 必须对应**一个所有权自包含的架构设计单元**——持有不被其它 change 分享的聚合/上下文/读模型/契约所有权，且该设计能在本 change 内闭合。

package/skills/prototype/references/orchestration-flow.md

@@ -112,7 +112,7 @@ agent 直接写审查报告到 `requirement/vN/prototype-auto-review.md`。
 ## 步骤 ⑥ 人工评审路由（主代理）
 
 主代理用 AskUserQuestion 呈现评审结论 + 争议项，LT 选择：
-- **PRD 有问题** → 回 orchestrator S2 修订 PRD（**vN 内修订 + 变更履历，非升版**；见 feedback-loops 设计）→ PRD 更新后再回 ① 更新原型。**独立调用 fallback**（非 orchestrator 触发时）：无 S2 可回，直接提示 LT 修订 `requirement/vN/prd.md` 后重入本 skill。
+- **PRD 有问题** → 回 orchestrator S2 修订 PRD（**正文就地更新为最新态 + 变更记录写 `dialogue-log.md`，非升版**；见 feedback-loops 设计）→ PRD 更新后再回 ① 更新原型。**独立调用 fallback**（非 orchestrator 触发时）：无 S2 可回，直接提示 LT 修订 `requirement/vN/prd.md` 后重入本 skill。
 - **原型需调整**（美观/体验/品牌/信息密度等自动评审查不到的维度）→ **⛔ 必须通过 SendMessage 恢复原 prototype-builder 实施调整**（`SendMessage(to: builder_agent_id, message: "用户评审反馈：{调整意见}。请修改原型。")`），修改后 SendMessage 恢复原 prototype-reviewer 重新评审。**禁止启动新子代理**（唯一例外：SendMessage 恢复失败时的 fallback）
 - **通过** → 冻结：PRD frontmatter `frozen: true`（frozen_downstream），prototype 定版
 - **设计系统增量确认（v0.54.0，新增分支）**：若 builder handoff 的 `outstanding_questions` 含 `ds_increment` 条目（`missing_component` / `outdated_token` / `new_variant`），在本次 AskUserQuestion 中**并入**呈现：

package/skills/workflow-orchestrator/SKILL.md

@@ -23,6 +23,18 @@ description: >-
 
 **设计哲学（v0.7）**：编排层**只编排**（状态判断、路由、阶段转换、用户确认），执行委托 subagent/会话 skill；从「固定管道」升级为「默认路径 + 任意时刻可重规划」；PRD vN = 一次迭代版本，迭代内变更不升版。
 
+## 决策话术规范（人类化原则，v0.60.x 新增）
+
+本 skill 向用户提出的每一个决策问题（AskUserQuestion / 阻塞确认，含 S1 路径路由、S4 同步门禁）必须遵守：
+
+1. **用大白话讲"结果"，不讲"机制"**：选项 label ≤ 12 字，描述"选了会怎样"；技术术语（续版需求 / 重新计划 / 单 change 快速通道 / 聚合 / 限界上下文 等）下沉到 description，首次出现括注白话等价。
+2. **选项是"你选哪个"的口吻**：给 2-3 个带取舍的候选 + 一项推荐，不抛单一路径让用户盲选。
+3. **决策点 = 帮你拍板的岔路口，不是考试**：只问用户有能力判断的事（走哪条路径 / 是否同步），不让他做机制选型。
+4. **术语精度保底在 description**：label 必须零术语。
+
+反例：S1 直接问 `单 change 快速通道 / 续版需求 / 重新计划` 不解释区别。
+正例：S1 问 `你这步想做什么？`；A「从头做新功能（推荐）」B「在已有版本上加功能」C「只调一下计划」——各自 desc 说明选了会怎样。
+
 ## Use This Skill When
 
 - 用户提出新的产品级需求：「我有个想法」「做一个 XX 功能」「从头开始」、模糊需求
@@ -73,7 +85,7 @@ prd_draft → user_review → prototype_loop → prd_frozen → completed
 - **错误行为**：PRD草稿完成后直接标记S3阶段完成
 - **正确行为**：PRD草稿完成后等待用户查看，确认后继续S2阶段的后续步骤
 
-调用 `/ce-brainstorm`（mode: orchestrated）产出 PRD 草稿（Phase 3 由 prd-writer agent 契约级撰写，v0.47）；**冻结前派 `prd-completeness-reviewer` 子代理做 PRD 完整性评审**（v0.15.0，管"说得全不全"；v0.47 并入 §8.4 契约级细节 D6 维度）；原型循环由编排层直接编排（prototype skill 内部编排产出 → prototype-reviewer 自动评审 → 人工评审 → 冻结）；冻结语义为 `frozen_downstream`（迭代内变更不升版）。反馈环路检查点：scope 是否合理。详见 `references/s2-prd-prototype-loop.md`。
+调用 `/ce-brainstorm`（mode: orchestrated）产出 PRD 草稿（Phase 3 由 prd-writer agent **按 `prd-84-authoring-spec.md` 业务可读撰写**，v0.62.0）；**冻结前派 `prd-completeness-reviewer` 子代理做 PRD 完整性评审**（v0.15.0，管"说得全不全"；v0.47 并入 D6 维度，**v0.62.0 改为 §8.4 信息齐备性 + 业务可读形态核验 G7**）；原型循环由编排层直接编排（prototype skill 内部编排产出 → prototype-reviewer 自动评审 → 人工评审 → 冻结）；冻结语义为 `frozen_downstream`（迭代内变更不升版）。反馈环路检查点：scope 是否合理。详见 `references/s2-prd-prototype-loop.md`。
 
 ### ARCH: 产品级架构设计（v0.36.0 新增；2026-08-19 LT 调整上移 S3 前——S3 计划/S4 拆分是最终任务拆分，须基于架构）
 

package/skills/workflow-orchestrator/references/feedback-loops.md

@@ -36,17 +36,22 @@ S5→S4 回退时，按在途 change 状态分区处置（前置条件）：
 - 回退时受影响制品重命名为 `.revN`（保留审计轨迹）
 - 重新进入阶段**不读取上一轮制品**，只读取修订后的上游制品，避免旧内容锚定
 
-## 变更履历格式
+## 变更记录格式（v0.62.0：迁出 PRD）
 
-记录在 PRD 文档的「决策与变更履历」章节：
+**记录位置 = `requirement/vN/dialogue-log.md`**（**不再写进 PRD 正文**——PRD 只承载最新态；
+正文若保留历史，即违反「单一真相」原则，且会被 `prd-completeness-reviewer` 的形态核验判 Important）。
 
 ```markdown
 ### 决策与变更履历
-| 时间 | 触发阶段 | 变更内容 | 原因 | 影响范围 |
-|------|---------|---------|------|---------|
-| 2026-07-24 | S3→S2 | 砍掉功能X | plan 分析发现技术不可行 | §7 功能清单、§8 处理说明 |
+| 变更编号 | 时间 | 触发阶段 | 受影响需求 ID | 受影响功能 ID | 变更前 | 变更后 | 理由 | 决策人 |
+|---|---|---|---|---|---|---|---|---|
+| CHG-001 | 2026-07-24 | S3→S2 | REQ-007 | F3 | 保留功能X | 砍掉功能X | plan 分析发现技术不可行 | LT |
 ```
 
+- **受影响需求 ID / 功能 ID 为强制字段**（不可留空：「无」也须显式写，不得空着）
+- **「理由」列为强制字段**——变更履历的价值在于下游能重建「为什么这样定」
+- PRD 侧只保留 §1.2 修订记录的**一行一句话摘要**（≤ 200 字），并指向本文件
+
 ## 与双层冻结的关系
 
 - S3→S2 回退 = **临时解除 frozen_downstream**，S2 重新完成后恢复