@xulthekl/team-flow 0.60.0 → 0.62.0

package/skills/workflow-orchestrator/references/s1-path-router.md

@@ -24,7 +24,13 @@ S1 只做编排动作（需求选择、存在性检查、路径判断、阻塞
 | **重新计划** | PRD 已冻结，plan 需调整 | → S3 | 跳过 brainstorm；S3 完成后进 ARCH（产品级架构设计，v0.35.0）再拆 change |
 | **继续执行** | changes 已拆分，继续下一个 | → S4/S5 | 先输出状态恢复简报，用户确认后继续 |
 | **单 change 快速通道** | 需求极清晰，无需 PRD（仅限单一功能点、无 UI、无跨模块依赖的极小变更） | → 直接创建 change → workflow-start | 最轻量路径，无 PRD 锚点，**不可触发 S3→S2 回退** |
-| **紧急修复（Hotfix）** | bug/生产问题，需最小范围修复 | → 直接创建 change（type: hotfix，注入 bug 描述替代 PRD）→ workflow-start | closing 时强制补录复利 |
+| **紧急修复（Hotfix）** | bug/生产问题，需最小范围修复 | → 匹配源 change（见下「Hotfix 命中源 change」）→ 直接创建 change（type: hotfix，注入 bug 描述替代 PRD，带源 change 引用）→ workflow-start | closing 时强制补录复利 |
+
+**Hotfix 命中源 change（v0.61.0 增强，设计依据 v0.26 §203）**：用户报 bug / 线上问题时，先尝试把缺陷回溯到引入它的源 change，再做轻量修复：
+1. **匹配**：`git blame` 受影响文件 / 符号 → 定位引入 commit → 经 `change_dag` / `change-brief` / `learnings.md` 反查 `change_dir`；或按受影响 capability 在全局 `specs/` 检索归属 change。
+2. **命中** → 新建 hotfix change 时携带「源 change 引用」（写 `change-brief.md` 的 `source_change_ref`，无 brief 则记 `learnings.md`），workflow-start 路由时复用源 change 的 `design.md` / `specs` / `tests` 上下文做轻量修复，省去重复 scope 确认。
+3. **非命中**（独立缺陷 / 新文件）→ 走原 Hotfix，无源 change 引用。
+4. **必须用户确认匹配结果**；失准优雅降级 Hotfix，**绝不静默自动 reopen** 源 change。
 | **原型补跑/重跑**（v0.20.0） | PRD 已冻结（`frozen_downstream`）∧ `prototype/` 缺失/为空，或用户显式要求重做/重跑原型 | → 部分重入 S2 原型循环（S2 步骤 2→3→4） | PRD 不动，保留有效 S3 plan / S4 changes，闭环后恢复原 phase；`replan_log` 记往返 |
 
 **判断顺序**：先查活跃需求的 `orchestrator.yaml`（`.team-flow/requirements/<req-id>/orchestrator.yaml`，如存在 → 多半是「继续执行」或「重新计划」），再查 `requirement/` 目录（有 PRD → 「续版」候选；legacy: `prd/`），最后落到「全新需求」。Hotfix 由用户语义（bug/生产/紧急修复）显式触发。

package/skills/workflow-orchestrator/references/s2-prd-prototype-loop.md

@@ -82,13 +82,13 @@ PRD草稿生成后：
 
 **orchestrated 路径下完整性评审由编排层在此派发**（standalone 路径由 ce-brainstorm Phase 3.5 内部派发，见 ce-brainstorm `references/prototype-loop.md` §3.5.5）。
 
-- 派发：按名派发插件 agent `prd-completeness-reviewer`（6 维，含 §8.4 契约级细节 D6），传入 `prd_path` + `concepts_path`（可选）+ `template_path`（默认 `templates/prd.md`）+ `detail_ledger_path`（如有）。
-- 判定：PASS / PASS_WITH_WARNINGS → 进入步骤 4 冻结；**FAIL（Critical>0：D1/D2/D6 核心维度缺失、D6 悬空功能）→ 回 ce-brainstorm Phase 1.3/Phase 3 修订后重审**。
+- 派发：按名派发插件 agent `prd-completeness-reviewer`（6 维，含 §8.4 信息齐备性与业务可读形态 D6），传入 `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`（如有）。
+- 判定：PASS / PASS_WITH_WARNINGS → 进入步骤 4 冻结；**FAIL（Critical>0：D1/D2 缺失、D6 核心信息缺失、D6 悬空功能）→ 回 ce-brainstorm Phase 1.3/Phase 3 修订后重审**。D6 形态核验（G7）命中判 Important，不直接触发 FAIL，但须记录并交人工裁定。
 - **适用性**：需要原型（步骤 3 完成后）与不需要原型（纯后端无 UI，步骤 2 后）两条路径**均必须派发**——不因跳过原型循环而跳过完整性评审。
 
 ### 4. 冻结
 
-设置 `frozen_downstream`（见 state-model.md「双层冻结」）。冻结后，**迭代内变更不升版**，在 vN 内修订 + 记录决策/变更履历。
+设置 `frozen_downstream`（见 state-model.md「双层冻结」）。冻结后，**迭代内变更不升版**——**正文就地更新为最新态**（不累积历史），决策与变更记录写入 `requirement/vN/dialogue-log.md`（PRD 侧只留 §1.2 一行摘要）。
 
 ### 4.5 阶段产物同步门禁点（v0.37.0 §68.2 G1）
 

package/skills/workflow-orchestrator/references/s4-split-validate.md

@@ -87,6 +87,7 @@ upstream_plan_ref: requirement/vN/plan.md      # hotfix/快速通道为 null
 upstream_arch_ref: docs/architecture/iterations/vN/architecture.md  # 产品级架构快照（v0.36.3）；ARCH skip 或 hotfix 为 null
 upstream_change_id: C2                 # 对应 change_dag.id
 plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层未同步
+source_change_ref: <change-dir>         # 可选：本 change 是对某已存在 change 缺陷的快速修复（v0.61.0 bugfix 增强，设计依据 v0.26 §203）；非 bugfix 留空
 ---
 # Change Brief: <change-name>
 

package/skills/workflow-orchestrator/references/state-model.md

@@ -141,7 +141,7 @@ S1 判定「原型补跑/重跑」（PRD `frozen_downstream` ∧ `prototype/`
 - **制品保留**：S3 `plan.md` / S4 `changes/` 已存在且仍有效则**保留不动**，不重做、不归档。
 - **闭环恢复**：原型循环闭环（自动评审 PASS / 人工通过）后，`workflow_phase` 恢复原 phase（如 `s4-distribution`），S2 状态回 `completed`（去掉 `prototype-only` 子标记）。
 - **replan_log 必写**：`{ seq, trigger: "prototype-rerun", before: <原 phase>, after: "S2(prototype-only)", approved_by }`，并记结论「未暴露 scope 问题、changes 保持有效」。
-- **升级路径**：若原型循环暴露 PRD scope 问题 → **脱离本路径**，升级为 S3→S2 回退修订（临时解除 `frozen_downstream`，PRD vN 内修订 + 变更履历），不再按 prototype-only 处理。
+- **升级路径**：若原型循环暴露 PRD scope 问题 → **脱离本路径**，升级为 S3→S2 回退修订（临时解除 `frozen_downstream`；**PRD vN 就地更新为最新态** + 变更记录写 `dialogue-log.md`），不再按 prototype-only 处理。
 
 ## change_dag 结构
 

package/skills/workflow-start/SKILL.md

@@ -26,6 +26,18 @@ Do NOT invoke for: general coding tasks outside team-flow changes, casual questi
 3. **Overlay recovery scan**: Run `tf handoff list <change-dir> --json` and `tf checkpoint list <change-dir> --json`. A `result-ready` handoff requires explicit review and `tf handoff resolve` before resuming the affected work. An `active` handoff is non-blocking side work. Show a non-stale checkpoint as recovery context; show a stale checkpoint only as historical evidence.
 4. **Execution-control recovery scan**: For `approved-for-build`, `executing`, `debugging`, or `closing`, run `tf execution show <change-dir> --json`. Treat only `current: true` plus `waves[].eligible: true` as permission to start a wave; report plan revision, mode, next eligible wave, and every wave's receipt/blockers. A missing, invalid, or stale plan blocks implementation and routes to `build-executor`; do not infer progress from chat history.
 
+## 决策话术规范（人类化原则，v0.60.x 新增）
+
+本 skill 向用户提出的每一个决策问题（AskUserQuestion / 阻塞确认）必须遵守：
+
+1. **用大白话讲"结果"，不讲"机制"**：选项 label ≤ 12 字，描述"选了会怎样"；技术术语（SDD / Inline / 聚合 / 限界上下文 / CQRS 等）下沉到 description，且首次出现括注白话等价（如 `聚合（一组相关的业务数据，比如一张订单及其明细）`）。
+2. **选项是"你选哪个"的口吻**：给 2-3 个带取舍的候选 + 一项推荐，不抛单一路径让用户盲选。
+3. **决策点 = 帮你拍板的岔路口，不是考试**：只问用户有能力判断的事（范围 / 优先级 / 方向），不让他做机制选型。
+4. **术语精度保底在 description**：label 必须零术语；需要精确术语时在 description 内保留。
+
+反例：DP-4 label `执行模式选择：SDD / Inline / Batch Inline`。
+正例：DP-4 label `怎么推进这批改动？`；A「稳妥分批（推荐）」desc `每批带测试、可回退，最稳`；B「一口气写完」desc `快但出错难定位`；C「内联小改」desc `改动极小时用（术语 SDD=……）`。
+
 ## DP-0: User Confirmation Gate
 
 Run DP-0 when: change folder doesn't exist, planning artifacts missing/empty, or `dp_0_confirmed` ≠ `true`. Skip if `dp_0_confirmed` is `true`.
@@ -184,6 +196,7 @@ work.
 **不合并**：`arch_design_decision == required` 时 DP-A 必须独立——用户需单独审架构产物。
 
 - **Hotfix**: Route to contract-builder (minimal), skip need-explorer + spec-writer, guard check `exploring bridging --workflow hotfix`, then `bridging -> approved-for-build`, after DP-3 → build-executor (recommend, show, and confirm an execution mode), after → release-archivist (lightweight). Hotfix may skip `proposal.md`, `design.md`, and `specs/`, but it still requires a fresh minimal `execution-contract.md`, DP-3 approval, and a current execution plan before build. **`tasks.md` 不得静默缺失（v0.22 §85）**：hotfix 默认不产出该文件，但必须由 contract-builder 显式登记 `tasks_skipped=true` + `tasks_skip_reason`（或一并产出最小任务清单，归属 contract-builder）——`tasks-complete` 在 closing 考核该维度，静默缺失会死锁（修复前即此状态）。**architecture-design 不豁免**（v0.9 §26）：同样过 architecture-design 子代理判断门，快速判定是否涉及架构变更（hotfix 可能正是架构缺陷导致）
+- **Hotfix 命中源 change（v0.61.0 增强，设计依据 v0.26 §203）**：若 S1 已匹配到引入该缺陷的源 change（`source_change_ref`），本 change 路由时**复用源 change 的 `design.md` / `specs/` / `tests` 作为已知设计约束上下文**，省去重复 scope 确认——修复只针对缺陷点，不重做整体设计。消费方式：读取 `change-brief.md` 的 `source_change_ref`（或 `learnings.md` 记录）指向的源 change 目录，将其 design/specs 作为背景注入 contract-builder / build-executor。**门禁**：源 change 匹配结果由 S1 阶段用户确认；本层**绝不静默 reopen** 源 change，仅在本 hotfix change 内复用其上下文。匹配失准时退化为普通 Hotfix。
 - **Tweak**: Route to build-executor (direct edit), skip need-explorer + spec-writer + contract-builder, guard check `exploring approved-for-build --workflow tweak`, after → release-archivist (lightweight). **`tasks.md` 须显式 skip（v0.22 §85）**：tweak 跳过 spec-writer 与 contract-builder，故既无原生 `tasks.md` 也无人代写——由**主代理**经 `tf state set` 写入 `tasks_skipped=true` + `tasks_skip_reason`（`tf state set` 是 CLI 调用，不违反 Artifact Ownership 的 Edit/Write 禁令），否则 `tasks-complete` 在 closing 死锁。tweak 的 `executing:closing` 不含 `test-matrix-complete`（`guard.mjs:82`），矩阵豁免非 guard 必需。**architecture-design 不豁免**（v0.9 §26）：同样过 architecture-design 子代理判断门
 
 Post-transition: 💡 `tf inject <change-dir>` to update phase-guard artifacts.

package/templates/prd-brainstorm-profile.md

@@ -14,15 +14,21 @@ Phase 2 产出的每个方案必须覆盖核心维度，按需覆盖扩展维度
 | 数据关系 | §4.3 信息结构图 | 核心业务实体之间的关联规则是什么？实体间的层级/归属/引用关系？ |
 | 业务规则 | §8.2.4 其他机制与规则 | 排序规则？搜索规则？加载机制？异常处理？校验逻辑？ |
 | 系统功能 | §7 D7.5 系统功能清单 | 需要哪些功能点？每个功能点关联哪个业务流程/活动？ |
-| 功能细节（契约级） | §8.4 功能模块详细说明 | UI 功能：每个功能的页面布局/字段/交互/异常/权限是什么？非 UI 功能：触发条件/输入输出/处理步骤/异常/幂等并发/性能是什么？ |
+| 功能细节 | §8.4 功能模块详细说明 | UI 功能：这个画面给谁用？展示哪些内容？能做什么操作？什么情况下会失败或不允许？非 UI 功能：什么情况下触发？输入什么、产出什么？出错时怎么办？ |
 
-> **功能细节澄清分级（v0.47）**：按功能复杂度分级——Standard/Deep scope **强制契约级澄清**（布局/字段/交互/异常/权限 或 触发/输入输出/处理/异常/幂等并发/性能），Lightweight scope 简化澄清（需求已足够清晰时）。澄清产出 **detail_ledger**（逐功能维度 → 已澄清/待澄清/NA），作为 §8.4 撰写数据源 + prd-completeness-reviewer D6 核对基准。
+> **功能细节澄清分级（v0.62.0）**：按功能复杂度分级——Standard/Deep scope **逐条澄清业务信息**
+> （谁用 / 展示什么 / 能做什么 / 失败怎么办，或 何时触发 / 输入输出 / 出错怎么办），
+> Lightweight scope 简化澄清（需求已足够清晰时）。澄清产出 **detail_ledger**
+> （逐功能 → 已澄清 / 待澄清 / NA），作为 §8.4 撰写数据源 + prd-completeness-reviewer D6 核对基准。
+>
+> **边界**：澄清的是**业务信息本身**，**不是**「正文该写成什么样」——
+> 形态由 `prd-84-authoring-spec.md` 规定，不在澄清环节讨论。
 
 ## 扩展思考维度（按需触发）
 
 | 维度 | 触发条件 | 对应 PRD 章节 | 引导问题 |
 |------|---------|-------------|---------|
-| 画面设计 | 涉及 UI 交互 | §4 D7.2 | 画面结构如何？页面间如何迁移？（视觉层面辅助，功能细节见核心维度「功能细节（契约级）」） |
+| 画面设计 | 涉及 UI 交互 | §4 D7.2 | 画面结构如何？页面间如何迁移？（视觉层面辅助，功能细节见核心维度「功能细节」） |
 | 业务术语 | 出现领域专有名词 | §6 D7.4 | 哪些术语需要统一定义？有无同义词？ |
 | 报表需求 | 用户提到"报表/统计/分析" | §5 D7.3 | 需要哪些报表？关联哪些流程和数据？ |
 | 交互机制 | 有特殊交互需求 | §8.2.2 | 键盘/画面/弹层交互细节？ |

package/templates/prd.md

@@ -15,9 +15,15 @@
 
 ### 1.2 修订记录
 
-| 版本号 | 修订日期 | 修订内容 | 修订人 |
+> **本节只记录「文档整体变更要点」的一句话摘要**。**逐条评审意见、决策依据与过程讨论一律见 `dialogue-log.md`**，本节不承载。
+
+| 版本号 | 修订日期 | 修订要点（摘要） | 修订人 |
 |---|---|---|---|
-| {版本} | {日期} | {变更描述} | {姓名} |
+| {版本} | {日期} | {一句话摘要} | {姓名} |
+
+> **约束（撰写与审查同判）**：① 单版本行要点 **≤ 200 字**；
+> ② **禁止**在旧版本行追加「已被 X 推翻 / 本行 ③ 已被 R2 推翻」式**反转注记**——补丁累积正是要消灭的；
+> ③ 功能级历史、决策依据、澄清过程一律迁 `dialogue-log.md`，本节只留最新态行。
 
 ## 二、业务流程一览
 
@@ -25,7 +31,11 @@
 
 | L1流程分类 | L2流程分组 | L3业务流程 | L4子流程 | 利益相关 | 价值描述 | 流程名称 | 流程描述 | 变更类型 | 关联系统 | 关联需求编号 | 备注 |
 |---|---|---|---|---|---|---|---|---|---|---|---|
-| {分类} | {分组} | {编号} | {子流程编号或/} | {相关方} | {价值} | {名称} | {描述} | {新增/变更} | {系统名} | {编号} | |
+| {分类} | {分组} | {编号} | {子流程编号或/} | {相关方} | {价值} | {名称} | {描述} | {本期新增/本期变更/本期不变} | {系统名} | {编号} | |
+
+> **「变更类型」列为受控枚举**（全文各表同判，含 §7.1 / §8.1 功能清单）：只能取 `本期新增` / `本期变更` / `本期不变` 三值。
+> **禁止**写入版本锚点（`v0.5ac`）、澄清轮次锚点（`Q8 新增`）、日期、旧值或变更原因——这些属**演变轨迹**，归 `dialogue-log.md`。
+> 该列服务的是**本期评审的范围认知**（这次动了什么），保留；追述「以前是什么」的内容一律迁出。
 
 ## 三、D7.1_业务流程
 
@@ -51,7 +61,7 @@
 
 | L1流程分类 | L2流程分组 | L3业务流程 | L4子流程 | 利益相关 | 价值描述 | 流程名称 | 流程描述 | 变更类型 | 关联系统 | 关联需求编号 | 备注 |
 |---|---|---|---|---|---|---|---|---|---|---|---|
-| {分类} | {分组} | {编号} | {子流程编号或/} | {相关方} | {价值} | {名称} | {描述} | {新增/变更} | {系统名} | {编号} | |
+| {分类} | {分组} | {编号} | {子流程编号或/} | {相关方} | {价值} | {名称} | {描述} | {本期新增/本期变更/本期不变} | {系统名} | {编号} | |
 
 ## 四、D7.2_画面原型及设计
 
@@ -87,13 +97,13 @@
 
 | 编号 | 关联流程 | 关联活动 | 关联任务 | 关联需求 | 类型 | 报表名称 | 报表描述 | 更新时间 | 备注 |
 |---|---|---|---|---|---|---|---|---|---|
-| {X.X.X.X_a1_r1} | {流程编号} | {活动编号} | {任务编号} | {需求编号} | {新增/变更} | {名称} | {描述} | {日期} | |
+| {X.X.X.X_a1_r1} | {流程编号} | {活动编号} | {任务编号} | {需求编号} | {本期新增/本期变更/本期不变} | {名称} | {描述} | {日期} | |
 
 ### 5.2 报表台账
 
 | 编号 | 关联流程 | 关联活动 | 关联任务 | 关联需求 | 类型 | 报表名称 | 报表描述 | 更新时间 | 备注 |
 |---|---|---|---|---|---|---|---|---|---|
-| {X.X.X.X_a1_r1} | {流程编号} | {活动编号} | {任务编号} | {需求编号} | {新增/变更} | {名称} | {描述} | {日期} | |
+| {X.X.X.X_a1_r1} | {流程编号} | {活动编号} | {任务编号} | {需求编号} | {本期新增/本期变更/本期不变} | {名称} | {描述} | {日期} | |
 
 ## 六、D7.4_业务术语字典
 
@@ -101,15 +111,19 @@
 
 本次迭代新增/更新术语字典如下：
 
-| 序号 | 术语名称 | 定义 | 词性 | 同义词/近义词 | 来源 | 更新时间 | 备注 |
-|---|---|---|---|---|---|---|---|
-| 1 | {术语} | {定义} | {名词/动词/动词短语} | {近义词} | {来源} | {日期} | |
+> **§6 是「业务与代码共享词汇表」**：术语名称用**业务语汇**（PRD 正文主干一律用它）；
+> 「代码标识」列是该术语在代码中的对应标识（类名/字段名/枚举值等），**仅供实现侧对齐**，
+> **不得**用代码标识回写正文主干。业务上无对应代码概念的填「—」。
+
+| 序号 | 术语名称 | 代码标识 | 定义 | 词性 | 同义词/近义词 | 来源 | 更新时间 | 备注 |
+|---|---|---|---|---|---|---|---|---|
+| 1 | {术语} | {代码标识；无则填「—」} | {定义} | {名词/动词/动词短语} | {近义词} | {来源} | {日期} | |
 
 ### 6.2 业务术语字典台账（台账建议新建文档保存）
 
-| 序号 | 术语名称 | 定义 | 词性 | 同义词/近义词 | 来源 | 更新时间 | 备注 |
-|---|---|---|---|---|---|---|---|
-| 1 | {术语} | {定义} | {词性} | {近义词} | {来源} | {日期} | |
+| 序号 | 术语名称 | 代码标识 | 定义 | 词性 | 同义词/近义词 | 来源 | 更新时间 | 备注 |
+|---|---|---|---|---|---|---|---|---|
+| 1 | {术语} | {代码标识；无则填「—」} | {定义} | {词性} | {近义词} | {来源} | {日期} | |
 
 ## 七、D7.5_系统功能清单
 
@@ -119,13 +133,13 @@
 
 | 编号 | 关联流程 | 关联活动 | 类型 | 功能名称 | 功能描述 | 上层功能 | 变更类型 | 变更内容 | 更新时间 | 备注 |
 |---|---|---|---|---|---|---|---|---|---|---|
-| {X.X.X.X_a1_f1} | {流程编号} | {活动编号} | {新增} | {功能名} | {描述} | {/或上级功能名} | {新增/变更} | {变更内容} | {日期} | |
+| {X.X.X.X_a1_f1} | {流程编号} | {活动编号} | {新增} | {功能名} | {描述} | {/或上级功能名} | {本期新增/本期变更/本期不变} | {变更内容} | {日期} | |
 
 ### 7.2 系统功能台账
 
 | 编号 | 关联流程 | 关联活动 | 类型 | 功能名称 | 功能描述 | 上层功能 | 变更类型 | 变更内容 | 更新时间 | 备注 |
 |---|---|---|---|---|---|---|---|---|---|---|
-| {X.X.X.X_a1_f1} | {流程编号} | {活动编号} | {新增} | {功能名} | {描述} | {/或上级功能名} | {新增/变更} | {变更内容} | {日期} | |
+| {X.X.X.X_a1_f1} | {流程编号} | {活动编号} | {新增} | {功能名} | {描述} | {/或上级功能名} | {本期新增/本期变更/本期不变} | {变更内容} | {日期} | |
 
 ## 八、D7.6_系统功能处理说明书
 
@@ -135,10 +149,16 @@
 
 | 编号 | 关联流程 | 关联活动 | 类型 | 功能名称 | 功能描述 | 上层功能 | 变更类型 | 变更内容 | 更新时间 | 备注 |
 |---|---|---|---|---|---|---|---|---|---|---|
-| {X.X.X.X_a1_f1} | {流程编号} | {活动编号} | {新增} | {功能名} | {描述} | {/或上级功能名} | {新增/变更} | {变更内容} | {日期} | |
+| {X.X.X.X_a1_f1} | {流程编号} | {活动编号} | {新增} | {功能名} | {描述} | {/或上级功能名} | {本期新增/本期变更/本期不变} | {变更内容} | {日期} | |
 
 ### 8.2 全局说明
 
+> **本期范围（受控句式，须挂 change 级 `proposal.md` 条款号，实现双向可追溯）**：
+> 本期包含：{…}（对应 proposal 条款 {编号}）；本期不包含：{…}（对应 proposal「范围外（Out of Scope）」条款 {编号}）。
+>
+> 范围以 change 级 `proposal.md` 的「范围外（Out of Scope）」为权威；本节只做**一句话交代 + 条款号回指**，
+> **不另立范围章节、不在本节展开讨论**（自由散文无法核对是否与 proposal 一致，故不用）。
+
 #### 8.2.1 权限说明
 
 **※ 说明本次系统功能需要的权限，若不涉及可以忽略；**
@@ -267,42 +287,39 @@
 
 ### 8.4 功能模块详细说明
 
-**契约级详述规范（v0.47）**：每个功能模块按下述「必含维度检查清单」逐项详述。UI 功能覆盖 11 维、非 UI 功能覆盖 7 维（按「功能形态」选择其一）；维度不适用时标注 `NA + 理由`；**缺失适用维度 = PRD 不完整**；核心维度缺失将判 FAIL，辅助维度缺失为 PASS_WITH_WARNINGS 交人工裁定（prd-completeness-reviewer D6，v0.47）。规范唯一权威为本节——撰写 agent（prd-writer）与审查 agent 均读取本节获得检查清单，不在他处重复维护。
+> **撰写规范唯一权威**：插件内置 `prd-84-authoring-spec.md`（**不是本模板**）。
+> 本模板只承载**骨架与填空槽位**。撰写（`prd-writer`）、审查（`prd-completeness-reviewer` D6）
+> 与形态核验一律以规范文件为准；项目内的模板副本**非权威、不得直接读取**。
+>
+> **三句话要点**：① 一个功能模块**一张表（两列）+ 编号业务叙述**；
+> ② 面向**业务评审人**撰写——业务语汇为主干，技术标识符不进正文主干；
+> ③ 完整性走**内部校验清单**，清单本身**不写入正文**（见规范文件 §5）。
 
 #### 8.4.1 {模块名称}
 
 ##### 8.4.1.1 {功能名称}
 
-| 功能形态 | UI 功能 / 非 UI 功能 | | |
-|---|---|---|---|
-| 所属流程 | BP-{xxx} | 关联需求 | REQ-{xxx} |
-| 关联场景 | SC-{xxx} | 功能概述 | {1-2 句；若不能一句话说清，先拆分功能} |
-
-**UI 功能必含维度（11 维）**：
-
-- [ ] 页面布局：{布局结构（上下分栏/标准列表等）}
-- [ ] 权限规则：{角色/状态/操作权限；与 §8.2.1 全局权限的差异}
-- [ ] 区块说明：{各区块内容与职责}
-- [ ] 搜索模块：{搜索组件/占位符/选项/筛选联动}
-- [ ] 表格列定义：{完整列清单：列名/类型/格式/排序}
-- [ ] 交互规则：{默认选中/点击切换/筛选联动/级联选择逻辑等}
-- [ ] 弹层结构：{弹层触发/内容/交互}
-- [ ] 动态字段：{按领域动态字段/动态列名说明}
-- [ ] 导入导出规则：{格式/字段映射/校验}
-- [ ] 状态操作差异：{已发布/草稿/已停用等状态下的操作差异}
-- [ ] 异常边界：{空态/错误态/并发/极值}
-
-**非 UI 功能必含维度（7 维）**：
-
-- [ ] 触发条件：{定时/事件/手动触发}
-- [ ] 输入输出：{输入参数/输出结果/格式}
-- [ ] 处理步骤：{处理流程/算法/业务规则}
-- [ ] 异常处理：{异常场景/重试/补偿}
-- [ ] 权限角色：{可执行角色/鉴权}
-- [ ] 幂等并发：{幂等性/并发控制}
-- [ ] 性能约束：{耗时/吞吐/资源}
-
-> **NA 机制**：维度不适用时标注 `NA + 一句理由`（如 `页面布局：NA，后台批处理无画面`）；**未标注 NA 且未覆盖 = 缺失**，审查将判 FAIL。
+| {UI 功能填「原型/UI」；非 UI 功能填「触发入口」} | {业务说明} |
+|---|---|
+| {原型文件与容器定位 / 触发入口描述} | {按下方编号骨架展开} |
+
+**1、定义**：{这个功能是什么、给谁用、解决什么问题（1-3 句，业务语汇）}
+
+**2、{查询条件 / 触发条件}**：{UI：查询条件与控件；非 UI：什么情况下触发}
+
+**3、{列表字段与布局 / 输入与输出}**：{UI：展示哪些字段、什么布局；非 UI：输入什么、产出什么}
+
+**4、业务规则**：{逐条写清，含前提条件与例外——本功能最重要的部分}
+
+**5、异常与边界**：{按业务风险选取：空态 / 错误态 / 无权限 / 并发 / 极值 / 状态冲突 / 数据缺失 / 外部依赖失败；纯展示类写关键 2-3 项即可，不必逐项罗列}
+
+> **可解析性（必守）**：字段类信息须写成「**字段名：控件，规则**」的单行可辨识格式
+> （如 `协议名称：输入框，模糊匹配，最长 50 字符`），**不得**写成跨句散文——
+> 下游 `prototype-reviewer` / `prototype-env-scout` / `builder-methodology` 依赖从本节提取字段。
+
+> **语汇**：正文主干用 §6 术语字典的**业务名**；类名 / 方法名 / 表名 / 行号不得出现，确需时以括注附于业务名后。
+> **精确**：禁用弱词（较快 / 友好 / 支持 / 适当 / 等 / 尽可能 / 必要时）——模糊表述会被下游自行解释，产生静默缺陷。
+> **完整性**：11 维 / 7 维清单**降为内部校验清单**，撰写前用它核对信息齐备，撰写时按业务认知顺序重组进正文，**不得**把清单写进正文；不适用维度在 `detail-ledger.md` 标 `NA + 理由`。
 
 ### 8.5 非功能性需求说明
 
@@ -396,9 +413,19 @@
 
 #### 9.1.9 要件阅读体验
 
-| 编号 | 大类 | 明细 | 内容 | 结果 | 备注 |
-|---|---|---|---|---|---|
-| 1 | {大类} | {明细} | {检查内容} | {◎/○/✕} | |
+> **自查项以规范文件为准**：逐条对照 `prd-84-authoring-spec.md` **§8 可读性自查项**填写结果。
+> 本表只列名目与结果，**不重复列出条款正文**——同一规则两处维护必然漂移。
+>
+> **两处声明**：① **自查 ≠ 规格正文**——本节是**撰写者自检清单**，不构成对业务方的规格条款，
+> 判定权仍在业务评审；② **非脚本门禁**——不得将本节接入机械门禁脚本。
+
+| 编号 | 自查项（详见规范文件 §8） | 结果 | 备注 |
+|---|---|---|---|
+| 1 | 正文主干无类名 / 方法名 / 表名 / 行号 | {◎/○/✕} | |
+| 2 | 无历史痕迹（删除线、版本锚点、「原口径作废」「已被推翻」） | {◎/○/✕} | |
+| 3 | 术语用 §6 业务名 | {◎/○/✕} | |
+| 4 | 无弱词（规范文件 §4） | {◎/○/✕} | |
+| 5 | 维度清单未写入正文（规范文件 §5） | {◎/○/✕} | |
 
 ## 十、D7.8_要件定义完成报告