@xulthekl/team-flow 0.60.0 → 0.62.0

package/.claude/always/phase-guard.md

@@ -1,3 +1,3 @@
-# team-flow v0.60.0 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.62.0 | 阶段: {{state}} | 工作流: {{workflow}}
 当前阶段允许的操作由 workflow-start 路由规则定义。
 禁止跨越 DP gate 进入下一阶段。变更范围以 execution-contract.md 的 Intent Lock 为准。

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "team-flow",
       "description": "8-state spec workflow + compound global compounding + architecture-design (4A/DDD) + local HTML prototype + product-level orchestration + bootstrap + e2e + session handoff + workflow feedback + independent business analysis. 28 skills + 17 agents with embedded TDD, SDD, code review, debugging, delta spec sync, and design-system-driven prototyping.",
-      "version": "0.60.0",
+      "version": "0.62.0",
       "source": "./",
       "author": {
         "name": "LT",

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.60.0",
+  "version": "0.62.0",
   "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking) + business-analysis (independent requirement/scenario artifact) + design-system (design tokens + component contract + AI primer + showcase) + test-strategy (test strategy design) + project-initialize (new service onboarding) + jarvis (team-flow decision agent, opt-in). 28 skills + 17 agents, one install.",
   "source": "./",
   "author": {

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.60.0",
+  "version": "0.62.0",
   "description": "Spec-first workflow that bridges OpenSpec-style planning and Superpowers-style execution discipline.",
   "author": {
     "name": "MageByte",

package/.cursor-plugin/marketplace.json

@@ -5,7 +5,7 @@
   },
   "metadata": {
     "description": "Unified workflow plugin marketplace for Cursor (team-flow: team-flow + compound + architecture-design + prototype).",
-    "version": "0.60.0"
+    "version": "0.62.0"
   },
   "plugins": [
     {

package/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "team-flow",
   "displayName": "team-flow",
   "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking) + business-analysis (independent requirement/scenario artifact) + jarvis (team-flow decision agent, opt-in). 28 skills + 17 agents, one install.",
-  "version": "0.60.0",
+  "version": "0.62.0",
   "author": {
     "name": "LT",
     "url": "https://github.com/LT"

package/.github/plugin/marketplace.json

@@ -6,13 +6,13 @@
   },
   "metadata": {
     "description": "Unified workflow plugins and skills for AI coding agents (team-flow: team-flow + compound + architecture-design + prototype).",
-    "version": "0.60.0"
+    "version": "0.62.0"
   },
   "plugins": [
     {
       "name": "team-flow",
       "description": "Unified workflow with planning artifacts, execution contracts, TDD, review gates, systematic debugging, delta spec sync, architecture-design, independent business analysis, and local HTML prototyping.",
-      "version": "0.60.0",
+      "version": "0.62.0",
       "source": ".",
       "author": {
         "name": "LT",

package/AGENTS.md

@@ -154,7 +154,7 @@ STRATEGY.md CONCEPTS.md 产品策略(BA) / 领域词汇
      冻结前 PRD 完整性评审（prd-completeness-reviewer，v0.15.0）
      原型循环由 orchestrator 直接编排（prototype skill 内部编排器，主代理只编排）：
      env-scout → builder 绘制 → reviewer 评审 → 人工评审 → 冻结
-     PRD vN 内修订 + 变更履历（不升版）；反馈环路：scope 问题可回退修订
+     PRD 正文就地更新为最新态（不累积历史）+ 变更记录写 dialogue-log.md（不升版）；反馈环路：scope 问题可回退修订
   S3 计划阶段 → ce-plan（pipeline 快速路径，入口问定 plan_mode）
      plan.md：change 拆分 + 依赖 DAG + 高阶技术方向（不含接口清单）
      反馈环路：plan 暴露 PRD 问题可回退 S2
@@ -252,8 +252,8 @@ STRATEGY.md CONCEPTS.md 产品策略(BA) / 领域词汇
 | change-split-auditor | plan.md 拆分质量审计 | Read/Bash/Grep/Glob | orchestrator S4 脚手架前（必选门禁，PASS 方可继续） |
 | code-reviewer | spec 合规审查（批次完成/合并门禁） | Read/Bash/Grep/Glob | build-executor 批次完成、release-archivist 合并前 |
 | cross-change-consistency-checker | 跨 change 冲突检测 | Read/Bash/Grep/Glob | orchestrator S5 多 change 并行/closing 时 |
-| prd-completeness-reviewer | PRD 完整性评审（能否支撑 plan/spec，6 维度含 §8.4 契约级细节 D6） | Read/Bash/Grep/Glob | orchestrator S2 / ce-brainstorm 冻结前门禁（v0.15.0，v0.47.0 并入 D6） |
-| prd-writer | PRD 撰写 agent——契约级 §8.4 逐功能详述（ce-brainstorm Phase 3 委托；可写型，PRD 唯一所有者，先读模板检查清单） | Read/Bash/Grep/Glob/Write/Edit | ce-brainstorm Phase 3 委托（v0.47.0） |
+| prd-completeness-reviewer | PRD 完整性评审（能否支撑 plan/spec，6 维度含 §8.4 信息齐备性与业务可读形态 D6 + 形态核验 G7） | Read/Bash/Grep/Glob | orchestrator S2 / ce-brainstorm 冻结前门禁（v0.15.0，v0.47.0 并入 D6，v0.62.0 改信息齐备性 + 形态核验） |
+| prd-writer | PRD 撰写 agent——**业务可读** §8.4 逐功能详述（ce-brainstorm Phase 3 委托；可写型，PRD 唯一所有者，**先读 `prd-84-authoring-spec.md`**；v0.62.0 起含模板一致性前置断言） | Read/Bash/Grep/Glob/Write/Edit | ce-brainstorm Phase 3 委托（v0.47.0，v0.62.0 重写） |
 | prototype-builder | 原型绘制执行者（种子优先：template.html+layouts.md 组合；**v0.20.0 产物落盘硬闸门**：index.html 未落盘非空禁返 done + 大产出分片；**v0.21.0 决策点 SendMessage stop-and-resume**） | Read/Write/Edit/Bash/Grep/Glob | prototype skill 内部编排步骤③/⑤修正轮（v0.15.0，v0.18.0 种子优先） |
 | prototype-env-scout | 原型环境探查 + 2-3 差异化方向（direction-picker；**v0.20.0 简报完整性闸门**：简报未完整禁返 done） | Read/Bash/Grep/Glob | prototype skill 内部编排步骤①（v0.15.0，v0.18.0 direction-picker） |
 | prototype-reviewer | PRD 6 维度 + P0 grep + craft 4 席 rubric 评审 | Read/Bash/Grep/Glob | orchestrator S2 原型循环每轮产出后 |
@@ -303,7 +303,9 @@ docs/solutions/
 
 项目 `team-flow.config.json` 可注入（**插件层扩展字段，非 team-flow 原生 schema**；原生仅 `artifacts.order` / `artifacts.skip`）：
 
-- `prd.template`：PRD 模板路径（默认 `templates/prd.md`，GTMC D7 业务要件 11 章结构）。ce-brainstorm Phase 0.0 首次运行时若未配置，会交互式询问用户选择默认模板或自定义路径，并自动写入配置。自定义模板应配套 brainstorm profile（`<模板名>-brainstorm-profile.md`），否则回退使用内置默认的 GTMC D7 profile
+- `prd.template`：PRD 模板路径（默认**插件内置** `templates/prd.md`，GTMC D7 业务要件 11 章结构；**按插件根解析**，项目根同名路径不构成回退）。**v0.62.0（F2）起默认不再往项目内拷贝副本**——直接用插件内置；仅当用户明确选择「项目内留副本以便定制」时才 cp，并**必须同时写入该配置指向副本**。自定义模板应配套 brainstorm profile（`<模板名>-brainstorm-profile.md`，**成对处置**）
+- `prd.spec`：§8.4 撰写规范文件路径（默认 `skills/ce-brainstorm/references/prd-84-authoring-spec.md`）。**规范唯一权威**——与模板骨架解耦（F1），故项目内持有旧骨架副本**不影响规范**
+- `prd.template_ack`：模板一致性确认记忆（v0.62.0 G2）。由 `tf prd ack set` **原子写入**，含 `in_use_hash` / `plugin_hash` / `spec_hash` / `mode` / `diff_digest` / `plugin_version` / `acknowledged_at` / `acknowledged_by`；三个 hash 全等时静默，任一变化触发 DP-8 重新提问
 - `prototype.designSystem`：项目 `design-system.md` 路径
 - `prototype.entry`：原型入口（默认 `prototype/index.html`）
 

package/CHANGELOG.md

@@ -4,6 +4,39 @@ All notable changes to `team-flow` will be documented in this file.
 
 The format loosely follows Keep a Changelog.
 
+## [0.62.0] - 2026-09-22
+
+### Changed（PRD 业务可读性改造：§8.4 形态重写 + 规范与体例解耦 + 模板一致性确认门）
+
+**背景**：三条诉求——① 正式产物只留最新态、变更历史独立文件；② §8.4 改为「一功能一表 + 业务视角说明」；③ 业务语汇优先，非技术评审人看得懂。经方法论评审（ISO 29148 / ASPICE / DDD 三线）+ 五路交叉评审后落地，共 60 项改造点。
+
+1. **§8.4 形态重写（A 类 6 项）**：`templates/prd.md` §8.4 由「功能形态表 + 11 维/7 维 checkbox 清单」改为**骨架 + 填空槽位**——一个功能模块**一张两列表格**（UI 用 `原型/UI`，非 UI 用 `触发入口`）+ **编号业务叙述**（定义 → 条件或触发 → 内容或要素 → 业务规则 → 异常与边界）。§1.2 修订记录收敛为四列**极简版本行**（单行要点 ≤ 200 字、禁「已被 X 推翻」式反转注记）；§8.2 新增**受控句式范围边界**（挂 proposal 条款号实现双向可追溯）；§6 术语字典增「**代码标识**」列并定位为「业务与代码共享词汇表」；**§9.1.9 要件阅读体验**空表填为指向规范文件的指针式自查表；范围标记列改**受控枚举**（`本期新增 / 本期变更 / 本期不变`，禁版本锚点与日期）。
+2. **规范与体例解耦（F1，根治）**：新增插件侧权威文件 `skills/ce-brainstorm/references/prd-84-authoring-spec.md`，承载 §8.4 生成规范（目标形态 / 六原则 / 三类内容判定 / 弱词规则 / 内部校验清单 / 范围标记 / 反填充约束 / 可读性自查 / **形态核验 6 条** / **可解析性硬约束**）。**根因**：模板同时承担「客户可能强制的 D7 体例骨架」与「team-flow 维护的生成规范」，一旦被 cp 进项目，规范即被连带冻结。解耦后**骨架副本可以旧、规范永远新**。全部「模板 §8.4 为唯一权威」表述（`prd-writer` / `prd-completeness-reviewer` / `brainstorm-sections` / `ce-brainstorm SKILL` / `prd-mapping` / `evidence-chain-validation` / `prototype-loop` / `s2-prd-prototype-loop`）已改指规范文件。
+3. **项目空间模板同步（F2–F5）**：**F2** Phase 0.0 语义澄清——「默认模板」= 直接用插件内置，**不再 cp 副本**；仅当用户明确定制时才 cp 且必须同时写 `prd.template`；默认值基准显式化（一律按**插件根**解析，项目根同名路径不构成回退）；模板与 profile **成对**处置。**F3** `check-project-config.mjs` 增「PRD 模板漂移」维度（真消费点比对 + 影子副本提示，exit 0 不阻断）。**F4** 升级说明。**F5** 新增 `scripts/lib/template-hash.mjs`——hash 判据收敛为**唯一实现**（sha256 + CRLF→LF 归一化），F3 与 G1 共用。
+4. **模板一致性确认门（G 类 8 项，DP-8）**：撰写前比对「实际使用模板 / 插件内置模板 / **规范文件**」三个 hash，不一致则**阻塞提问**（A 按最新 / B 保留当前 / C 先看差异）；确认结果由**新增原子命令 `tf prd ack set`**（`scripts/lib/cmd-prd.mjs`，子命令分发照 `cmd-arch.mjs` 惯例）写入 `prd.template_ack`，三 hash 全等则静默；选 A 时**先做历史文档就地升级**（不归档改名，留痕由 dialogue-log 记升级前摘要值）再放行撰写。**新增撰写后形态核验（G7）**——在既有 `prd-completeness-reviewer` D6 内增 6 条形态判据（左列须为画面/入口锚点、§1.2 量化、范围标记受控枚举、无历史痕迹、无技术标识符越界、**维度清单未入正文**）。本门已登记 **DP-8**（默认动作＝挂起）。
+5. **既有缺陷修复（G5）**：`tf config --set` 原固定写 `<cwd>/team-flow.config.json`（legacy 第 2 顺位），而读取**首选** `<cwd>/.team-flow/team-flow.config.json` 且首个命中即返回 → 在已有 `.team-flow/` 配置的项目里 `--set` **静默无效**。改为写入 `findConfigFile()` 命中的文件（`resolveConfigWritePath()`）。
+6. **agent 与 skill 规则同步（B 类 14 项 / C 类 17 项 / D 类 4 项）**：`prd-writer` 重写（Iron Law 由 4 条扩为 **10 条**，含模板一致性前置断言、业务认知顺序、清单不入正文、反填充双判据、精确性指针；输入表补 `plugin_root` 与 `template_ack`）；`prd-completeness-reviewer` D6 由「契约级细节」改为「**信息齐备性 + 业务可读形态**」并补形态核验表；变更记录结构迁 `dialogue-log.md` 并新增**可追溯字段**（变更编号 / 受影响需求 ID / 受影响功能 ID / 理由 / 决策人）。
+
+### Added（验证与证据）
+
+- **P1.5-A 对抗验证（3 项高价值项实测，报告见工作区 `docs/plan/prd-p15a-verification.md`）**：**⑨ 撰写后形态核验可行性**——用 1806 行存量 PRD 做样本，实测**原 5 条判据会被绕过**（形态确为两列表 + 编号叙述但**左列为「维度」**；§1.2 表头合规但**单行要点 7,156 字**；**完全漏掉「维度清单入正文」**），据此补 3 条判据。**⑦ GUARDRAIL 方向冲突确认**——`ce-brainstorm/SKILL.md` 原写「模板文件：`.team-flow/templates/`」与 F2 相反，且位于模板解析步骤**之前**，改为「默认使用插件内置；项目内副本非权威、不得直接读取」。**⑤ Phase 0.0 读取路径**——正常路径不读副本（解析层不成立），但 e2e 日志实证有子代理直读项目副本（行为层成立）。**④ F3 实测**——在 `emp-auth` / `fytx-agreement` 两个真实项目成功报出未被消费的影子副本。
+
+### Changed（存量项目处置：不清理副本）
+
+- 两个存量项目的 `.team-flow/templates/` 副本**保留不清理**（决策 DEC-22）。前提：清理并非「启用新版规范」的开关（config 未配 `prd.template` → 默认即解析插件内置，升级即生效）。代价已记账：影子副本误导（F1/F2 兜底）、落后无提示（F3 闭合）、agent 直读（改 GUARDRAIL 闭合）。
+
+## [0.61.0] - 2026-09-21
+
+### Added（三优化点：决策话术人类化 / Hotfix 命中源 change / 拆分粗粒度优先）
+
+1. **决策话术人类化规范**（v0.61.0 新增）：在 `workflow-orchestrator` 与 `workflow-start` 两入口 skill 新增「决策话术规范（人类化原则）」节（4 条规则 + 反例），并在 `docs/decision-points.md` 顶部加锚点。面向用户的决策提问用白话、给可理解选项，避免暴露内部路径名/技术术语（反例：S1 直接问"path 路由名" → 改为"你这步想做什么" + 白话选项）。
+2. **Hotfix 增强：命中源 change**（v0.61.0 新增，纯文档承载）：bug 修复时优先匹配源 change（`git blame` 定位）→ 命中则复用源 change 的 design/specs/tests 上下文做轻量修复，并在 `change-brief.md` frontmatter 写入 `source_change_ref`；非命中走原 Hotfix 快通道。绝不静默 reopen 源 change，失准须降级并请用户确认。**实现形态**：复用 `bug-investigator` 报告段 + `change-brief` `source_change_ref` + learnings 承载，**不动 `state-loader` SETTABLE_FIELDS**（规避门禁变更）。
+3. **change 拆分粗粒度优先**（v0.61.0 新增）：`ce-plan/references/change-splitting.md` 顶部加「拆分默认姿态（粗粒度优先）」节——宁粗勿细，仅当「越过所有权边界 / 需独立并行验证 / 团队领取需要」任一成立才拆细；`change-split-auditor` D3「Too small」段加主动建议合并（change 数 > Standard 5 时给合并候选）。拆太细仅建议不硬拦（D3 维持 advisory）。
+
+### Changed（设计增强方案）
+
+- 设计增强方案升 `docs/architecture-api-db-design-enhancement-v0.26.md`（承袭 v0.25，目标插件 v0.61.0）：§202 话术规范、§203 bugfix 增强 Hotfix 纯文档承载、§204 粗粒度优先、§205 P1.5 可跳过判定、§206 制品链校验清单、§207 决策落实状态表。
+
 ## [0.60.0] - 2026-09-12
 
 ### Changed（`decision-surrogate` → `jarvis`：更名 + 重定位 + 首次通道实测修订）

package/GEMINI.md

@@ -8,7 +8,7 @@ The workflow is self-contained and does not require OpenSpec or Superpowers at r
 
 
 <!-- team-flow-phase-guard-start -->
-# team-flow v0.60.0 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.62.0 | 阶段: {{state}} | 工作流: {{workflow}}
 当前阶段允许的操作由 workflow-start 路由规则定义。
 禁止跨越 DP gate 进入下一阶段。变更范围以 execution-contract.md 的 Intent Lock 为准。
 <!-- team-flow-phase-guard-end -->

package/INSTALL.md

@@ -7,7 +7,7 @@
 - [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) — 规划引擎（Schema 验证、Delta Spec、工件解析）
 - [obra/superpowers](https://github.com/obra/superpowers) — 执行纪律（TDD 铁律、SDD、系统化调试、代码审查）
 
-当前发布版本：**v0.60.0**。
+当前发布版本：**v0.62.0**。
 
 ---
 

package/README.md

@@ -1,6 +1,6 @@
 # team-flow
 
-> 当前版本：`v0.60.0`
+> 当前版本：`v0.62.0`
 
 > 统一插件：**team-flow**（spec 驱动开发）+ **compound-engineering 核心子集**（全局复利）+ **architecture-design**（4A+DDD 增量设计）+ **prototype**（本地 HTML 原型）+ **e2e**（AC 驱动 E2E）+ **workflow-orchestrator**（产品级编排）+ **workflow-bootstrap**（既有项目接入）。一次安装，十三套能力协同（详见下文「十三套能力」）。
 
@@ -88,7 +88,7 @@ STRATEGY.md CONCEPTS.md 策略 / 领域词汇
 
 ### 配套 agents（17 个，v0.47.0 增至 17）
 
-全部由编排层 dispatch（主代理只编排，need-explorer 为主进程交互式澄清）：architecture-design（架构设计门控）/ architecture-reviewer（架构自动审查）/ bug-investigator（bug 根因调查）/ change-split-auditor（拆分质量审计）/ code-reviewer（代码审查）/ cross-change-consistency-checker（跨 change 一致性）/ prd-completeness-reviewer（PRD 完整性评审，含 §8.4 契约级细节 D6）/ prd-writer（PRD 契约级撰写）/ prototype-builder（原型绘制）/ prototype-env-scout（原型环境探查）/ prototype-reviewer（原型评审）/ need-explorer（需求探索）/ spec-writer（规格编写）/ contract-builder（执行契约构建）/ build-executor（TDD 构建执行）/ release-archivist（发布归档）/ business-analysis（独立业务分析）。
+全部由编排层 dispatch（主代理只编排，need-explorer 为主进程交互式澄清）：architecture-design（架构设计门控）/ architecture-reviewer（架构自动审查）/ bug-investigator（bug 根因调查）/ change-split-auditor（拆分质量审计）/ code-reviewer（代码审查）/ cross-change-consistency-checker（跨 change 一致性）/ prd-completeness-reviewer（PRD 完整性评审，含 §8.4 信息齐备性与业务可读形态 D6）/ prd-writer（PRD 业务可读撰写）/ prototype-builder（原型绘制）/ prototype-env-scout（原型环境探查）/ prototype-reviewer（原型评审）/ need-explorer（需求探索）/ spec-writer（规格编写）/ contract-builder（执行契约构建）/ build-executor（TDD 构建执行）/ release-archivist（发布归档）/ business-analysis（独立业务分析）。
 
 ### 命名约定
 

package/agents/change-split-auditor.md

@@ -58,6 +58,7 @@ Use Bash for mechanical extraction (`grep` for depends_on patterns) and manual g
 1. For each change, assess scope from its description, task count, and affected modules
 2. **Too large** signals: >5 modules affected, >15 tasks estimated, spans multiple bounded contexts → Important (recommend split)
 3. **Too small** signals: single-file change, <2 tasks, trivial config tweak → Important (recommend merge)
+   - **主动建议合并（v0.61.0 粗粒度优先，设计依据 v0.26 §204）**：当本 PRD 的 change 总数超过中等上限（Standard > 5）时，审计员除标记单体"太小"外，**必须主动给出合并候选**——列出可合并的 change 对及其共同所有权单元，供 ce-plan 回退收敛。目的：落实"宁粗勿细"默认姿态，避免每个细 change 都走完整 8 态 + 4+1 产物 + 架构增量 + 复利回写（ceremony 开销 > 价值）。
 4. Report the distribution: list changes by estimated size, flag outliers (>2x median or <0.5x median)
 
 This dimension is advisory — flag but do not FAIL on granularity alone.

package/agents/prd-completeness-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: prd-completeness-reviewer
-description: PRD 完整性自动评审。在 PRD 写入后、冻结前，独立检查"需求描述是否完整到能支撑后续 plan/spec 实施"（6 维度，含 §8.4 契约级细节 D6），输出分级完整性报告。直接写审查报告文件，返回摘要 + 文件路径。与 claim verifier 分工——claim verifier 管"说得对不对"（核查事实声明），本 agent 管"说得全不全、能否落地"。由编排层在 PRD 冻结前显式派发（workflow-orchestrator S2 / ce-brainstorm Phase 3.6 前）。
+description: PRD 完整性自动评审。在 PRD 写入后、冻结前，独立检查"需求描述是否完整到能支撑后续 plan/spec 实施"（6 维度，含 §8.4 信息齐备性与业务可读形态 D6），输出分级完整性报告。直接写审查报告文件，返回摘要 + 文件路径。与 claim verifier 分工——claim verifier 管"说得对不对"（核查事实声明），本 agent 管"说得全不全、能否落地"以及"形态是否符合规范"（撰写后形态核验 G7）。由编排层在 PRD 冻结前显式派发（workflow-orchestrator S2 / ce-brainstorm Phase 3.6 前）。
 
 model: inherit
 color: yellow
@@ -26,7 +26,8 @@ Do NOT duplicate claim verification. A statement can be factually correct yet st
 |-----------|-------------|
 | `prd_path` | PRD 文件路径（e.g., `requirement/v1/prd.md`） |
 | `concepts_path` | （可选）CONCEPTS.md 路径，用于术语一致性比对 |
-| `template_path` | PRD 模板路径（可选，默认 `templates/prd.md`；§8.4 检查清单单一权威，以解析后的模板为基准） |
+| `template_path` | PRD 模板路径（可选，默认插件内置 `templates/prd.md`；模板只承载骨架与槽位） |
+| `spec_path` | **（v0.62.0 新增，可选）** 撰写规范文件路径，默认 `${CLAUDE_PLUGIN_ROOT}/skills/ce-brainstorm/references/prd-84-authoring-spec.md`——**§8.4 规范唯一权威**，D6 与形态核验均以它为基准 |
 | `detail_ledger_path` | （可选）detail_ledger 路径（功能细节澄清产出；存在时用于 D6 交叉核对 NA 标注一致性） |
 
 If `prd_path` is missing or unreadable, report `FAIL` with reason `INPUT_ERROR`.
@@ -40,7 +41,7 @@ If `prd_path` is missing or unreadable, report `FAIL` with reason `INPUT_ERROR`.
 | D3 | 边界与非功能 | 空/错/异常状态、性能/兼容约束 | Important |
 | D4 | 术语一致性 | 与 CONCEPTS.md / §6 业务术语一致 | Minor |
 | D5 | 范围闭环 | in/out scope 明确，无悬空功能 | Important |
-| D6 | §8.4 契约级细节 | 逐功能模块按模板检查清单覆盖适用维度（UI 11 维/非 UI 7 维）；§7↔§8.4 交叉核对无悬空功能。**基准 = 模板 §8.4 检查清单（单一权威）** | Critical（核心维度缺失/悬空）/ Important（辅助维度缺失） |
+| D6 | §8.4 信息齐备性与业务可读形态 | **（a）信息齐备性**：逐功能模块核对业务信息是否**可定位**（不核对"正文里有没有该维度标题"）；§7↔§8.4 交叉核对无悬空功能。**（b）形态核验（v0.62.0 G7）**：按 6 条判据核验产出形态是否符合规范（见下方 D6 执行细则）。**基准 = `prd-84-authoring-spec.md`（唯一权威，不是模板 §8.4）** | Critical（核心信息缺失 / 悬空功能）/ Important（辅助信息缺失、**形态核验命中**） |
 
 ## Review Process
 
@@ -74,13 +75,37 @@ If `prd_path` is missing or unreadable, report `FAIL` with reason `INPUT_ERROR`.
    - Any out-of-scope item that other requirements implicitly depend on?
    Missing scope declaration or dangling feature = Important.
 
-8. **D6 §8.4 契约级细节完整度**：Read the template §8.4 checklist FIRST — `template_path`（默认 `templates/prd.md`）is the single authority (UI 11 维 / 非 UI 7 维), never judge against your own expectations. Then for each function module in the PRD §8.4:
-   - 判定功能形态（UI/非 UI），按对应维度清单核对覆盖度；**未标注 NA 且未覆盖的适用维度 = 缺失**
-   - **核心维度缺失 = Critical**：功能概述缺失；UI 页面布局/表格列定义缺失；非 UI 输入输出/处理步骤/异常处理缺失
-   - **辅助维度缺失 = Important**：UI 权限规则/搜索模块/弹层结构/动态字段/导入导出/状态操作差异/异常边界；非 UI 触发条件/权限角色/幂等并发/性能约束
+8. **D6 §8.4 信息齐备性与业务可读形态**：Read the **spec file** FIRST — `spec_path`
+   （默认 `${CLAUDE_PLUGIN_ROOT}/skills/ce-brainstorm/references/prd-84-authoring-spec.md`）
+   is the **single authority**——never judge against your own expectations,
+   and never against the template skeleton（模板只承载骨架与槽位）.
+
+   **（a）信息齐备性**（核对**信息是否可定位**，**不**核对"正文里有没有该维度标题"）：
+
+   - 逐功能模块按**业务认知顺序**（定义 / 条件或触发 / 内容或要素 / 业务规则 / 异常与边界）核对信息是否齐备
+   - **核心信息缺失 = Critical**：功能定义缺失；UI 展示内容与可操作项缺失；非 UI 输入输出 / 处理 / 异常处理缺失
+   - **辅助信息缺失 = Important**：权限、并发、性能、状态差异等
    - **§7 系统功能清单 ↔ §8.4 详述块交叉核对**：§7 列出但 §8.4 无详述 = **悬空功能 = Critical**
-   - 维度不适用但已显式标注 `NA + 理由` 的模块 = 不视为缺失（但需抽查 NA 理由合理性）
-   - **detail_ledger 交叉核对（可选）**：若 `detail_ledger_path` 提供，对比澄清期确认的维度状态与 PRD §8.4 覆盖/NA 标注——澄清已确认内容但 PRD 缺失或标 NA = Critical；澄清标 NA 但 PRD 有详述 = 记录不阻断
+   - 维度不适用的模块：查 `detail-ledger.md` 是否有 `NA + 理由`（**正文不该出现 NA 标注**）；
+     有理由 = 不视为缺失，无理由 = Important
+   - **detail_ledger 交叉核对（可选）**：澄清已确认内容但 PRD 缺失或标 NA = Critical；
+     澄清标 NA 但 PRD 有详述 = 记录不阻断
+
+   **（b）形态核验（v0.62.0 · G7）——判据必须同时查「形态」与「内容」**：
+
+   | # | 核验项 | 判级 |
+   |---|---|---|
+   | 1 | §8.4 是否「一功能一表 + 编号业务叙述」，且**左列为画面/入口锚点**（出现「维度 / 字段 / 类型」等技术维度名 = 违规） | Important |
+   | 2 | §1.2 是否极简版本行：单版本行要点 **≤ 200 字**；**无**「已被 X 推翻」式反转注记；功能级历史指向 `dialogue-log.md` | Important |
+   | 3 | 范围标记是否受控枚举（`本期新增 / 本期变更 / 本期不变`；无版本锚点、澄清轮次锚点、日期） | Important |
+   | 4 | 有无历史痕迹残留（删除线、版本锚点、章节名带版本、「原口径作废」「已被推翻」） | Important |
+   | 5 | 有无技术标识符越界（类名 / 方法名 / 表名 / 注解 / 字段名 / 行号出现在正文主干） | Important |
+   | 6 | 有无把维度清单写入正文（「按 … 维覆盖，不适用标 NA」式转述） | Important |
+
+   > **实证提醒**：只查形态会被"形似神不似"绕过——某存量 PRD **确为**两列表 + 编号叙述，但**左列是「维度」**；
+   > §1.2 表头合规但**单行要点达 7,156 字**。**形态对了 ≠ 语义对了。**
+
+   **（c）精确性**：主观词 / 歧义词命中 = Minor；关键规则因弱词不可验证 = Important。
 
 ### Phase 3: 汇总判定
 
@@ -133,7 +158,20 @@ Aggregate findings → final verdict per the Judgment Criteria.
 ### D5 范围闭环 — {PASS/WARN}
 [in/out scope 声明状态 + 悬空功能列表]
 
-### D6 §8.4 契约级细节 — {PASS/FAIL} ({m}/{n} modules contract-grade)
+### D6 §8.4 信息齐备性与业务可读形态 — {PASS/FAIL} ({m}/{n} modules)
+
+#### D6-(a) 信息齐备性
+[逐模块检查：模块 id | 定义 | 条件/触发 | 内容/要素 | 业务规则 | 异常与边界 | 状态]
+
+#### D6-(b) 形态核验（G7）
+| 核验项 | 命中 | 判级 | 证据（章节 + 摘录） |
+|---|---|---|---|
+| 1 一功能一表 + 左列为画面/入口锚点 | {是/否} | {Important/—} | |
+| 2 §1.2 极简版本行（≤200 字、无反转注记） | {是/否} | {Important/—} | |
+| 3 范围标记受控枚举 | {是/否} | {Important/—} | |
+| 4 无历史痕迹残留 | {是/否} | {Important/—} | |
+| 5 无技术标识符越界 | {是/否} | {Important/—} | |
+| 6 维度清单未写入正文 | {是/否} | {Important/—} | |
 [逐功能模块检查：功能形态 | 适用维度覆盖 | NA 标注 | 悬空功能 | 状态]
 
 ## Findings
@@ -160,7 +198,7 @@ Aggregate findings → final verdict per the Judgment Criteria.
 - Distinguish "missing" from "present-but-unverifiable" (both Critical for D2, but different fixes)
 - Give a clear, unambiguous verdict
 - Treat vague AC ("表现良好"/"快速响应" without threshold) as a D2 Critical
-- Read the template §8.4 checklist BEFORE assessing D6 — the template is the single authority, not your expectations
+- Read the **spec file**（`prd-84-authoring-spec.md`）BEFORE assessing D6 — **it** is the single authority, not your expectations and **not** the template skeleton（模板只承载骨架与槽位；项目内模板副本非权威）
 - Distinguish "维度不适用（已标注 NA）" from "维度缺失（未标注 NA 且未覆盖）" in D6
 
 **DON'T:**

package/agents/prd-writer.md

@@ -1,6 +1,6 @@
 ---
 name: prd-writer
-description: PRD 撰写 agent——在 ce-brainstorm 主会话完成交互澄清（Phase 0-2.6 + 功能细节澄清）之后、QA-4 审查之前，按 PRD 模板 §8.4 契约级检查清单将已确认产出整理为契约级 PRD 草稿（requirement/vN/prd.md）。可写型，负责 PRD 文档。
+description: PRD 撰写 agent——在 ce-brainstorm 主会话完成交互澄清（Phase 0-2.6 + 功能细节澄清）之后、QA-4 审查之前，按 `prd-84-authoring-spec.md` 规范将已确认产出整理为**业务可读**的 PRD 草稿（requirement/vN/prd.md）。可写型，负责 PRD 文档。
 
 model: inherit
 color: green
@@ -9,7 +9,10 @@ skills:
   - ce-brainstorm
 ---
 
-You are an independent PRD Writer. You turn the confirmed brainstorm outputs (business-analysis.md, dialogue-log.md, detail_ledger, synthesis summary) into a contract-grade PRD document at `requirement/vN/prd.md`. You execute ONLY the PRD writing phase — interactive clarification (Phase 0-2.6) is ALREADY DONE by the main conversation.
+You are an independent PRD Writer. You turn the confirmed brainstorm outputs (business-analysis.md, dialogue-log.md, detail_ledger, synthesis summary) into a **business-readable** PRD document at `requirement/vN/prd.md`. You execute ONLY the PRD writing phase — interactive clarification (Phase 0-2.6) is ALREADY DONE by the main conversation.
+
+> **业务可读** = 面向**业务评审人**撰写——读 PRD 的人不需要懂技术。
+> 业务语汇为主干，技术标识符不进正文主干；完整性走内部清单，**清单本身不写入正文**。
 
 ## Scope Boundary
 
@@ -19,50 +22,81 @@ You write PRD documents only. You do NOT run interactive phases, do NOT ask the
 
 **You are the sole owner of `requirement/vN/prd.md`.** No other agent or the orchestration layer may directly edit it. Modification requests (review feedback) MUST be routed through you via `SendMessage` resume.
 
-**Your preloaded Skill (ce-brainstorm) contains the detailed methodology** — PRD template resolution, `references/brainstorm-sections.md` chapter mapping (incl. §8.4 功能模块提取规则), `references/prd-mapping.md` version format. Follow it for HOW. This prompt defines WHO you are and WHAT you must deliver.
+**Your preloaded Skill (ce-brainstorm) contains the detailed methodology** — PRD template resolution, `references/brainstorm-sections.md` chapter mapping, `references/prd-mapping.md` version format. Follow it for HOW. This prompt defines WHO you are and WHAT you must deliver.
 
 ## Iron Law
 
-1. **先读模板 §8.4 检查清单再撰写**：定位 `template_path`（默认 `templates/prd.md`）§8.4（UI 11 维 / 非 UI 7 维），以解析后的模板为逐功能详述的强制基准，不在他处猜测规范。
-2. **逐功能模块契约级详述**：每个功能按「功能形态」（UI/非 UI）覆盖对应必含维度；维度不适用时标注 `NA + 一句理由`；**未标注 NA 且未覆盖 = PRD 不完整**。
-3. **无信息章节保留模板占位，不虚构**：data source 未覆盖的内容保留 `{占位}`，并列入 `missing_info`。
-4. **不写实现契约**：接口路径/表字段/类结构/算法实现属 change 级 spec/design，PRD 只写产品行为与规则。
+**0. 模板一致性前置断言（v0.62.0 · G3）**：收到 `template_path` 后**先**比对 hash——
+对「实际使用模板」与「插件内置模板 + 规范文件 `prd-84-authoring-spec.md`」取 hash
+（算法见 `scripts/lib/template-hash.mjs`，**不得自行另写判据**）。
+若不一致且无有效 `template_ack` → 返回 `status: blocked`、`reason: TEMPLATE_MISMATCH` + 差异摘要，
+**不撰写、不静默、不自行裁决**。（你是"不提问"的子代理——确认动作一律回主会话 Phase 0.0 / S2。）
+
+1. **先读规范文件再撰写**：规范唯一权威是插件内置 **`prd-84-authoring-spec.md`**
+   ——**不是**模板 §8.4、**不是**项目内的模板副本。撰写前必须读取它，不在他处猜测规范。
+2. **按业务认知顺序呈现**：§8.4 每个功能模块 = **一张两列表格 + 编号业务叙述**
+   （定义 → 条件或触发 → 内容或要素 → 业务规则 → 异常与边界）。
+   **左列必须是画面/入口锚点**（`原型/UI` 或 `触发入口`），不得写成「维度 / 字段 / 类型」。
+3. **完整性走内部清单，清单不入正文**：撰写**前**用 11 维 / 7 维清单核对信息是否齐备；
+   撰写**时**按业务认知顺序重组进正文叙述。**不得**把清单本身写进正文。
+   维度不适用时在 `detail-ledger.md` 标 `NA + 理由`，**不在正文标注 NA**。
+4. **业务语汇为主干**：正文主干用 §6 术语字典的**业务名**；类名 / 方法名 / 表名 / 行号不得出现，
+   确需时以括注附于业务名后。
+5. **无信息章节保留模板占位，不虚构**：data source 未覆盖的内容保留 `{占位}`，并列入 `missing_info`。
+6. **不写实现契约**：接口路径 / 表字段 / 类结构 / 算法实现属 change 级 spec/design，PRD 只写产品行为与规则。
+7. **rationale 按需保留**：澄清中确实产生过重要取舍时，随规则保留**一句话**理由；
+   **已失效的旧结论、版本演变轨迹、被推翻的论证一律不写进正文**（迁 `dialogue-log.md`）。
+   判定测试见规范文件 §3.1。
+8. **反填充**：不得为「看起来完整」而填充。可核对判据——
+   ① **可指回来源**：正文每条业务规则必须能指回需求来源或澄清记录，**指不回去的即删**；
+   ② **NA 必附理由且可被挑战**：`detail-ledger.md` 的 NA 须写一句理由，
+   **冲突时以「有理由的 NA」优先**（防止为消灭 NA 而反向填充）。
+9. **精确性自检**：交付前按 `prd-84-authoring-spec.md` **§4 弱词清单**扫一遍正文——
+   禁用比较级 / 主观词 / 歧义词 / 开放式 / 漏洞词。（清单正文见规范文件，**不在此重复**。）
 
 ## Inputs
 
 | Parameter | Description |
 |-----------|-------------|
 | `prd_path` | 目标 PRD 路径（e.g., `requirement/v1/prd.md`） |
-| `template_path` | PRD 模板路径（默认 `templates/prd.md`） |
+| `template_path` | PRD 模板路径（默认插件内置 `templates/prd.md`） |
+| `plugin_root` | **（v0.62.0 新增）** 插件根目录（`${CLAUDE_PLUGIN_ROOT}`），用于定位内置模板与 `prd-84-authoring-spec.md` |
+| `template_ack` | **（v0.62.0 新增）** 模板一致性确认记忆（hash 组 + mode），供 Iron Law 0 断言 |
 | `business_analysis_path` | business-analysis.md 路径（§2/§3/§7/§8 数据源） |
 | `dialogue_log_path` | dialogue-log.md 路径（§1.2 修订记录引用） |
 | `detail_ledger_path` | detail_ledger 路径（功能细节澄清产出，§8.4 数据源） |
 | `synthesis_summary` | 综合确认产出（scope 判定与核心决策） |
 
 If `template_path` is missing or unreadable, report `FAIL` with reason `INPUT_ERROR`.
+If `plugin_root` is missing, Iron Law 0 **降级为警告**——无法定位规范文件时记入 `missing_info` 并继续撰写，不阻断。
 
 ## Structured Output Contract
 
 Return the following YAML to the orchestration layer:
 
 ```yaml
-status: done | blocked              # done: PRD 草稿已写入并通过自检
+status: done | blocked | fail
 artifact_path: requirement/vN/prd.md
 missing_info: [...]                 # 保留占位的未澄清信息清单（供 QA-4 / D6 定位）
+blocked_reason: TEMPLATE_MISMATCH   # 仅 status=blocked 时；附差异摘要
 summary: "..."                      # 2-3 sentence overview + 待主会话确认点
 ```
 
 ## Red Lines
 
 **DO:**
-- 先读模板 §8.4 检查清单，再逐功能模块按维度详述
-- 从 detail_ledger / business-analysis.md 提取已确认信息，保持信息完整（页面布局/搜索字段/表格列/交互规则/级联逻辑等关键细节不得丢失或过度概括）
+- 先读 `prd-84-authoring-spec.md`，再逐功能模块按业务认知顺序撰写
+- 从 detail_ledger / business-analysis.md 提取已确认信息，保持信息完整（关键业务细节不得丢失或过度概括）
 - 功能描述含糊到"一句话说不清"时，先拆分功能再详述
 - 结束回复用显式终止标记：`FINAL VERDICT: <DONE | BLOCKED | FAIL>`
 
 **DON'T:**
-- 不执行交互阶段，不向用户提问（澄清已由主会话完成）
+- 不执行交互阶段，不向用户提问（澄清已由主会话完成）——模板不一致时**回传** `TEMPLATE_MISMATCH`，不自行裁决
 - 不虚构未确认信息——data source 缺失就保留占位 + 列入 missing_info
-- 不写接口/表/类/算法等实现契约（属 change 级 spec/design）
+- 不写接口 / 表 / 类 / 算法等实现契约（属 change 级 spec/design）
 - 不修改 business-analysis.md / dialogue-log.md / detail_ledger / ledger.md
 - 不删除模板占位——无信息章节保留 `{占位}`
+- **不把维度清单写进 §8.4 正文**（无列名清单、无 checkbox 列表、无「按…维覆盖，不适用标 NA」式转述）
+- **不写历史痕迹**：删除线、版本锚点（`v0.5ac` / `v0.47`）、「原口径作废」「已被推翻」一律不进正文
+- **不写技术标识符**：类名 / 方法名 / 表名 / 行号不进正文主干
+- **不用弱词**：禁止"较快 / 友好 / 支持 / 适当 / 等 / 尽可能 / 必要时"——模糊表述会被下游自行解释，产生静默缺陷

package/docs/README_en.md

@@ -126,7 +126,7 @@ npm install -g team-flow
 
 ### Version
 
-- Current: `v0.60.0`
+- Current: `v0.62.0`
 - v0.9.1 highlights: DP-4 execution-mode recommendations, a portable runtime across 17 platforms, and a raw-package smoke with no plugin-root variable.
 - Self-contained — no OpenSpec or Superpowers runtime required
 - Upstream: [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec), [obra/superpowers](https://github.com/obra/superpowers)

package/docs/decision-points.md

@@ -2,6 +2,10 @@
 
 本文档集中定义了 team-flow 工作流中所有需要用户明确确认的决策点。每个决策点（Decision Point）都是工作流中的关键门禁，确保用户在自动化流程中始终保持最终决策权。工作流中的 skill 在到达决策点时必须暂停执行、向用户呈现所需信息，并等待明确指令后方可继续。
 
+## 话术规范（人类化原则，v0.61.0 新增）
+
+所有 DP 的提问文案必须遵守「用大白话讲结果、不讲机制」：选项 label ≤ 12 字、零术语，描述"选了会怎样"；技术术语下沉 description 且首现括注白话等价；决策点 = 帮你拍板的岔路口，不让你做机制选型。详细规则与正反例见 `workflow-orchestrator` / `workflow-start` SKILL.md 的「决策话术规范」节（设计依据：设计增强方案 v0.26 §202）。
+
 ## DP-0: 设计前确认（User Confirmation Gate）
 
 - **编号**：DP-0
@@ -74,6 +78,26 @@
 - **预期输出**：用户确认归档并批准 delta spec 合并，或要求调整合并范围后再执行
 - **关联 skill**：`team-flow:release-archivist`
 
+## DP-8: PRD 模板一致性确认（v0.62.0）
+
+- **编号**：DP-8
+- **名称**：PRD 模板一致性确认门（对应改造项 G1）
+- **触发条件**：ce-brainstorm Phase 0.0 解析出 `template_path` 之后、Phase 3 派发 prd-writer 之前；
+  判据由 `tf prd check` 给出（共享模块 `scripts/lib/template-hash.mjs`，**不得另写判据**）：
+  `STATUS: MISMATCH`（三个 hash 任一与 ack 不同）或 `STATUS: NO_ACK`（首次）
+- **所需输入**：实际使用模板 / 插件内置模板 / **规范文件** `prd-84-authoring-spec.md` 三个 hash + 差异摘要
+- **预期输出**：用户三选一——
+  **A 按最新模板与规则**（先执行历史文档就地升级，再撰写；`mode: adopt_latest`）、
+  **B 保留当前模板继续**（属**偏离接受 waiver**，须落 `dialogue-log.md` 受控记录；`mode: keep_legacy`）、
+  **C 先看差异再定**（输出差异摘要后回到 A/B，不写 ack）
+- **关联 skill**：`team-flow:ce-brainstorm`（orchestrated 路径为 workflow-orchestrator S2 步骤 3.5 前）
+- **默认动作**：**挂起** —— jarvis 夜间值守等自动化路径遇此门**一律挂起，不得代答或跳过**
+  （与「架构门禁一律挂起」的既定策略一致）
+- **状态字段**：配置 `prd.template_ack`（`in_use_hash` / `plugin_hash` / `spec_hash` / `mode` /
+  `diff_digest` / `plugin_version` / `acknowledged_at` / `acknowledged_by`），由 `tf prd ack set` 原子写入
+- **失效规则**：三个 hash 任一变化即失效并重问（上一选择作默认项）；
+  `STATUS: MATCH` 时静默按 ack.mode 执行，不再提问
+
 ## DP-A: 架构设计确认（v0.29.0 §37）
 
 - **编号**：DP-A
@@ -96,6 +120,7 @@
 | DP-5 | 调试升级 | `team-flow:bug-investigator` | 执行 |
 | DP-6 | 验证失败 | `team-flow:release-archivist` | 收尾 |
 | DP-7 | 归档确认 | `team-flow:release-archivist` | 收尾 |
+| DP-8 | PRD 模板一致性确认 | `team-flow:ce-brainstorm` | 需求（Phase 0.0） |
 | DP-A | 架构设计确认 | `team-flow:workflow-start` | 架构 |
 
 ## 确认点合并（v0.22 §88.3.1）