@gordon.gan/specflow 1.8.3-beta → 1.8.5-beta

package/prompts/document/map/requirement.md

@@ -3,6 +3,11 @@
 你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
 - kind=entity|mixed 的要点 → 产出结构化契约实体（JSON 块 ```json {"interfaces": [...], "tables": [...], "decisions": [...]} ```）
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
-- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.；**正文中文化**）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
 - **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 需求章节硬规则
+
+1. **不写 Given-When-Then 验收小节**：验收标准已从方案文档移除（可读性整改）；验收断言由「测试策略」章承接。本章只写功能需求描述、目标与边界（MVP 范围、跨仓依赖、约束）。
+2. **目标可验证**：每个目标一句"做成什么状态"，但验证落在测试策略章，不在本章列验收表。

package/prompts/document/map/test-strategy.md

@@ -13,7 +13,7 @@
 
 2. **测试环境与数据（T2）**：测试环境地址、测试数据准备（fixture/seed/工厂）、Mock 说明（接口 Mock/第三方 Mock）。
 
-3. **与验收标准映射（T3）**：每条验收标准（GWT）对应到至少一个测试层级，形成可追踪矩阵。
+3. **验收断言承接（T3，可读性整改）**：验收标准不再单独成章——把 Given-When-Then 断言**折叠进本表**，每行测试加「验收依据」列（如「运行 → 恰一个作业（job_count=1）」「非法引用类型 → 报错且不入队」），确保需求章的目标可验证且可追溯。
 
 4. **前端测试金字塔（T4）**：单元 60% / 组件 30% / E2E 10% 的投入比例；组件测试方式写明——Snapshot + 交互（render + fireEvent/userEvent 断言行为），关键组件/页面覆盖率目标。
 

package/prompts/document/outline/general.md

@@ -44,3 +44,12 @@
 5. **source_segments**：要点尽量标注来源段 id（来自全局摘要的段 id）。
 6. **每要点引用 ≤3 个实体**。
 7. **要点数量**：每章 2-5 个要点，覆盖该章必须覆盖的维度。
+8. **接口与数据分工（P11/P13）**：`api-design` 与 `data-model` 同时被选中时按「接口与数据设计 → 数据模型」顺序并列两章，**不合并**：
+   - 接口契约（请求/响应字段表、示例、错误表）内联进「接口与数据设计」章（渲染为「接口明细」）；
+   - **数据库表必须由「数据模型」章节组件承载**（表结构与 DDL、字段说明、存量填充 G3、回滚 G4、契约-表映射）——涉及持久化时必须选入 `data-model` 章，禁止把表塞进接口章或忽略；
+   - 契约-表映射（每接口 ↔ 读写表/列）写在「数据模型」章，接口约定与数据库通过映射表对齐。
+9. **完整性骨架（P7）**：涉及 ≥2 仓的合成文档必须含 `术语与约定`、`非目标汇总`、`风险与开放问题` 章节位。**不设决策记录（ADR）章节**——决策理由沉淀在技术选型（否决/备选列）与风险章即可，正文不得使用 `[D#]` 引用。
+10. **实体注册表增强**：接口实体注册时记录 `side`（console/worker/internal）、`consumers`、`producers`（仓名）；同一 method+path 只注册一个实体，`<repo>_<id>` 前缀仅作追溯别名（防 `duplicate_contract`）。
+11. **主流程含图（P12）**：`core-flow` 章必须输出整体流程图（含失败分支）+ 时序图 + 失败路径决策图，图必须有文字说明。
+12. **文档头与目录**：最终文档由引擎确定性渲染元信息头（标题/参与仓/生成时间）与目录；大纲只决定章节序与要点，不写文档头。
+13. **契约质量**：接口要点要求示例带真实 JSON body（`request_example`/`success_response_example`/`failure_response_example`）、请求/响应字段分列、错误表按 backend/guard/internal 分类。

package/prompts/document/shared/grounding.md

@@ -82,3 +82,10 @@ OpenAPI（`openapi.yaml`/`swagger.json` 等）、proto3（`*.proto`）、SQL DDL
 - 组件/页面：组件名、路由路径、状态 store 名应来自工程；页面清单可与用户核对。
 - 性能：基准数值必须来自实测（或标注"待实测"），禁止编造 LCP/包体数字。
 - 依赖升级：当前版本/目标版本来自 package.json；升级理由与收益向用户确认。
+
+## 七、整体性文档写作约定（P9/P11，所有章节通用）
+
+1. **首次定义、后续引用**：术语、关键事实（幂等键、零 DDL、禁直连等）只在首次出现处定义，后续一律引用，禁止跨章重复整段（防 P9 重复）。**不设决策记录（ADR）章、不使用 `[D#]` 引用**——决策理由沉淀在技术选型（否决/备选列）与风险章。
+2. **接口与数据同源**：接口字段与表列来自同一工程数据源；写契约-表映射时，字段↔列必须一一对齐，禁止接口讲接口、表讲表（P11）。
+3. **主流程必有图**：涉及多步流程的章节（core-flow 等）必须给出 mermaid 图（整体流程图/时序图），图必须有文字说明（P12）。
+4. **某仓无内容则不出现**：跨仓写作时，某仓在某维度无内容（如后端无 UI 组件）就**不写该仓的占位小节**，只写真实存在的内容（防"无 X"占位）。

package/prompts/shared/artifact-language.md

@@ -45,5 +45,14 @@ When `artifacts.language` is `zh-CN`:
 1. **简要** — 一句一事;禁止套话与大段散文。
 2. **有条理** — 「怎么做 / 怎么走 / 怎么处理」写成 **1. 2. 3.**,每步一句。
 3. **不改结构** — 表格、Mermaid、DDL、HTTP 示例、协议标记保持原样。
+4. **正文中文化（可读性整改）** — 正文叙述必须用**中文业务术语**替代代码标识符：
+   - 接口/表用中文名（如「调试执行接口」「逐步结果上报接口」「场景资产表」「作业表」），编号（I1/T3）只出现在接口总览表与字段表。
+   - 字段/配置用中文（`ref_type`→引用类型、`step_count`→步骤数、`job_type`→作业类型、`runtime_payload`→运行时信封、`param_overrides`→参数覆盖、`lease_epoch`→租约世代、`step_uid`→步骤标识、`step_order`→步骤序号）。
+   - 代码标识符只允许出现在：术语与约定表、接口字段表、JSON/HTTP 示例、代码块内。
+   - 首次出现确需给出原名时用括号注（如「运行时信封（runtime_payload）」）。
+5. **有条理 + 图文结合（可读性整改）**：
+   - 叙述内容多的章节**分条输出**：涉及步骤/规则/流程用 **1. 2. 3.** 编号，一句一条，禁止大段散文堆砌。
+   - 流程 / 状态流转 / 结构 / 决策分支类内容**必须配 Mermaid 图**（flowchart / sequenceDiagram / stateDiagram-v2），图紧跟一段文字说明——**图文成对**，禁止只有图没有文字、也禁止长叙述没有任何图。
+   - 图粒度：一图一事，多流程拆多图。
 
 `en`: keep prose brief; numbered steps for how-to. Same table/diagram exception.

package/skills/specflow-techdoc-synth/SKILL.md

@@ -47,18 +47,18 @@ Cursor: `specflow:techdoc-synth run ...`; Codex: `$specflow-techdoc-synth run ..
    - 无 `--text` → **回退 `approve`**（原合成默认，不打断流程，保持向后兼容）。
 5. 可选：`specflow techdoc detect --text "..."` 查看确定性关键词识别的结果作为参考。
 
-> 场景识别决定合成文档的**章节结构**（如 bugfix → reproduce/root-cause/fix；feature → requirement/test-strategy；poc → research/poc-demo/benchmark/tech-selection；migration → compat-migration/migration-guide）。跨仓合成规则（统一大纲/命名空间/分仓小节/全局视角/跨仓依赖）对任何 profile 都适用。
+> 场景识别决定合成文档的**章节结构**（如 bugfix → reproduce/root-cause/fix；feature → requirement/test-strategy；poc → research/poc-demo/benchmark/tech-selection；migration → compat-migration/migration-guide）。跨仓合成规则（统一大纲/契约单一定义/整体性组织/全局视角/跨仓依赖）对任何 profile 都适用。
 
 ## 与 `techdoc approve --bundle` 的区别（为什么用 synth）
 
 | 维度 | `approve --bundle`（拼接） | `techdoc-synth`（合成） |
 |---|---|---|
 | 大纲 | 每仓独立 | **一次统一大纲**，章节覆盖所有仓 |
-| 契约实体 | 每仓独立 I1/T1，跨仓冲突 | **命名空间隔离**（`<repo>_<id>`） |
-| 章节内容 | 各仓各写各的 | **每章按仓分节**（`### <repo>`），细节不互相稀释 |
+| 契约实体 | 每仓独立 I1/T1，跨仓冲突 | **单一定义 + 追溯别名**（`<repo>_<id>`），同一端点不重复 |
+| 章节内容 | 各仓各写各的 | **整体性叙述**（仓归属用 `[repo]` 标注），某仓无内容则不出现 |
 | 全局视角 | 无 | goal 写多仓总目标；closed-loop/implementability 跨仓统一结论 |
 | 跨仓依赖 | 不识别 | 显式标注「跨仓依赖」（接口调用/数据共享/发布顺序） |
-| 质量门禁 | 无 | **分仓小节门禁**（validate 强制：每必选章含所有仓的 `### <repo>` 小节） |
+| 质量门禁 | 无 | **整体性门禁**（validate 强制：全文仓覆盖 `repo_coverage_missing` + 空壳小节 `repo_section_stub` + 契约质量 lint） |
 
 > 原有多仓多产物（`techdoc approve --workspace-root ... --bundle` 各仓独立文档 + 主仓合订）**保持不变**；`techdoc-synth` 是新增的"真正合成"路径，两者并存。
 
@@ -96,17 +96,20 @@ run [--workspace-root <root>]
 ## 跨仓合成规则（必须遵守，validate 强制）
 
 1. **统一大纲**：一次生成一份 outline，章节覆盖所有仓，**不按仓分章**（跨仓对比/汇总放进对应章节）。
-2. **契约实体命名空间**：跨仓实体 id 用 `<repo>_<id>` 前缀（如 `repo1_I1`、`repo2_T1`），**禁止不同仓共用裸 id**。
-3. **每章必须分仓小节（质量门禁）**：每个必选章节的叙述按仓分节，用 `### <repo>` 小节标题（可带后缀如 `### repo1 · 目标`），且**每个仓都必须出现**。禁止把多仓内容混写成一段（会导致细节互相稀释）。
-4. **全局视角**（若所选 profile 包含对应章节）：goal 写多仓总目标与边界；tech-selection 对比各仓技术方案；api-design/data-model 分仓列契约；closed-loop 跨仓统一闭环检查；implementability 跨仓统一可实施性评估。其他场景章节（如 reproduce/root-cause/fix、requirement/test-strategy、research/poc-demo/benchmark）同样按仓分节并给出跨仓结论。
+2. **契约单一定义**：同一物理端点（method+path）只定义一个实体，用 `side`（console/worker/internal）与 `consumers`/`producers`（仓名）标注面与消费方/生产方；`<repo>_<id>` 前缀仅作**追溯别名**，禁止不同仓重复定义同一接口（validate 以 `duplicate_contract` 拦截）。
+3. **整体性组织（替代按仓分节）**：每章按主题写成一段整体叙述，仓归属用内联 `[repo]` 标注或表格「归属」列；**禁止**为无内容的仓写占位小节（如「某仓无 UI」，validate 以 `repo_section_stub` 拦截）；validate 以全文级 `repo_coverage_missing` 防某仓被概括掉。
+4. **全局视角**（若所选 profile 包含对应章节）：goal 写多仓总目标与边界；tech-selection 对比各仓技术方案；**接口与数据分工**——接口契约内联进「接口与数据设计」章（接口明细），**数据库表必须由「数据模型」章组件承载**（DDL/存量 G3/回滚 G4），契约-表映射写数据模型章；closed-loop 跨仓统一闭环检查；implementability 跨仓统一可实施性评估。其他场景章节（如 reproduce/root-cause/fix、requirement/test-strategy、research/poc-demo/benchmark）同样给出跨仓结论。
 5. **跨仓依赖/风险**：涉及仓间依赖（接口调用/数据共享/发布顺序）时显式标注「跨仓依赖」。
+6. **完整性骨架**：合成文档必须含术语与约定表、非目标汇总、风险与开放问题。**不设决策记录（ADR）章节、不用 `[D#]` 引用**——决策理由沉淀在技术选型（否决/备选列）与风险章。
+7. **契约质量**：接口示例带真实 JSON body（空壳示例拦截）、请求/响应字段分列、错误表按 backend/guard/internal 分类。
+8. **主流程必须含图**：主业务流程章输出整体流程图（含失败分支）+ 时序图 + 失败路径决策图。
 
-> 门禁是确定性的：`synthesize` 在 workRoot 写入 `repos.json`，`document validate` 读取后对每个必选章节检查 `### <repo>` 小节，缺失 → error（`repo_section_missing`）。非 synthesize 工作目录（`document run` / `approve --bundle`）不写 repos.json，门禁不触发。
+> 门禁是确定性的：`synthesize` 在 workRoot 写入 `repos.json`，`document validate` 读取后执行**整体性组织门禁**（全文级仓覆盖 `repo_coverage_missing` + 空壳小节 `repo_section_stub`）与契约质量 lint（`duplicate_contract`/`request_example_missing`/`response_example_missing`/`data_contract_mapping_missing`/`forward_decision_ref`）。非 synthesize 工作目录（`document run` / `approve --bundle`）不写 repos.json，跨仓门禁不触发。
 
 ## 产物
 
 - `<workspaceRoot>/.specflow/document-synthesized/document.md`（可用 `--work-root` 指定输出目录）
-- `repos.json`：参与合成的仓清单（门禁依据，自动写入）
+- `repos.json`：参与合成的仓清单（整体性门禁依据，自动写入）
 
 ## 说明
 

package/templates/document/chapters/api-design.yaml

@@ -1,13 +1,16 @@
-# 接口设计（候选；依赖架构；0→1 全栈/功能场景合并「契约+前端对接」）
+# 接口与数据设计（候选；依赖架构）
+# 接口契约（分层契约 + 前端对接）在本章内联呈现（渲染为「接口明细」）；数据库表由「数据模型」章组件承载，
+# 契约-表映射写「数据模型」章。跨仓合成遵循 buildSynthRules：接口单一定义（side/consumers/producers）、
+# 字段表请求/响应分列、示例带真实 JSON body、错误表按 backend/guard/internal 分类。
 id: api-design
-title: 接口设计
+title: 接口与数据设计
 when: input.containsApiChange
 depends_on: [architecture]
 outline_points:
-  - { id: O1, text: 接口总览与调用方/鉴权, required: true, kind: narrative }
-  - { id: O2, text: 逐接口字段表 + 成功示例, required: true, kind: mixed }
+  - { id: O1, text: 接口总览与调用方/鉴权（含面/消费方/生产方）, required: true, kind: narrative }
+  - { id: O2, text: 逐接口请求/响应字段表分列 + 请求/成功响应示例（真实 JSON body）, required: true, kind: mixed }
   - { id: O3, text: 每个接口 ≥1 失败示例（G2）, required: true, kind: entity }
-  - { id: O4, text: 错误码映射, required: true, kind: entity }
+  - { id: O4, text: 错误码映射（backend/guard/internal 分类）, required: true, kind: entity }
   - { id: O5, text: 前端请求封装（拦截器/重试/缓存/DTO→VO）, required: false, kind: narrative }
   - { id: O6, text: 前端错误处理（错误码统一/Loading-Empty-Error 状态）, required: false, kind: narrative }
   - { id: O7, text: 接口 Mock 与联调（Mock 策略/契约先行，前端可并行开发）, required: false, kind: narrative }
@@ -17,13 +20,19 @@ entities:
     each:
       failure_example: required
       errors_table: required
+      request_example: required
+      success_response_example: required
 narratives:
   design_notes: required
 gates:
   - 禁止「暂定/如/实现时」接口名
   - 每个接口必须 ≥1 失败示例
   - 接口编号稳定可交叉引用
+  - 请求字段与响应字段分列（禁止混成一张表）
+  - POST/PUT/PATCH 必须给真实 JSON 请求示例（无请求体显式标注「无请求体」）；有响应字段必须有成功响应示例
+  - 错误表按 backend（gRPC→HTTP 映射）/ guard（前端守卫行为）/ internal（Worker 内部语义）分类
   - 涉及前端对接时，请求封装与错误码统一方案必须与契约对齐（R5，字段名/错误码禁各写各的）
   - 前端接口 Mock 必须与契约一致（禁 Mock 一套、真实接口另一套）
+  - 涉及表实体时，契约-表映射由「数据模型」章给出（本处指引引用，不在本章写表 DDL）
 map_prompt: prompts/document/map/api-design.md
 output_budget_tokens: 8000

package/templates/document/chapters/architecture.yaml

@@ -1,4 +1,4 @@
-# 架构设计（0→1 候选；依赖技术选型；扩展：C4 分层 + ADR 决策记录）
+# 架构设计（0→1 候选；依赖技术选型；扩展：C4 分层）
 id: architecture
 title: 架构设计
 when: input.hasLogic && input.hasBackend
@@ -8,7 +8,6 @@ outline_points:
   - { id: AR2, text: 核心组件与职责边界, required: true, kind: narrative }
   - { id: AR3, text: 架构一致性自检, required: false, kind: narrative }
   - { id: AR4, text: C4 分层（Context 系统上下文 / Container 容器 / Component 组件），标注层级与依赖方向, required: false, kind: narrative }
-  - { id: AR5, text: 关键架构决策记录（ADR：背景/决策/后果/备选，沉淀 tech-selection 的 decisions）, required: false, kind: narrative }
 entities: {}
 narratives:
   architecture_notes: required

package/templates/document/chapters/core-flow.yaml

@@ -18,6 +18,8 @@ narratives:
   core_flow: required
 gates:
   - 主链路时序图必须 Mermaid 源码（```mermaid sequenceDiagram）+ 可渲染（diagram as code）
+  - 必须含整体流程图（```mermaid flowchart，覆盖编排→编译→入队→执行→上报→展示，含失败分支）
+  - 失败路径/决策部分必须单独成图（执行失败 vs 上报失败分支）
   - 时序图必须有文字说明（逐消息/逐分支），禁止只有图无文字
   - 每条主链路必须画异常/失败分支（禁只画 happy path）
   - 有写操作的链路必须给幂等/并发结论（禁「前端按钮防抖」当幂等方案）

package/templates/document/chapters/core-logic.yaml

@@ -1,16 +1,18 @@
-# 核心算法 / 逻辑说明
+# 关键实现规则（候选；依赖主业务流程——渲染紧随其后的"下一环节"；可读性整改：承接上下文、只写图中未覆盖规则）
 id: core-logic
-title: 核心算法/逻辑
+title: 关键实现规则
 when: input.hasLogic
-depends_on: [architecture]
+depends_on: [core-flow]
 outline_points:
-  - { id: LOG1, text: 核心算法/流程说明, required: true, kind: narrative }
-  - { id: LOG2, text: 边界与异常处理, required: true, kind: narrative }
+  - { id: LOG1, text: 编译规则（排序/展开/校验/信封冻结）, required: true, kind: narrative }
+  - { id: LOG2, text: 执行与上报规则（信封校验/共享变量/失败策略细节/写入顺序/幂等键/abort）, required: true, kind: narrative }
 entities: {}
 narratives:
   core_logic: required
 gates:
+  - 开头必须承接主业务流程上下文（一句话说明本规则回答"每一步实现怎么落地"），禁止孤立开头
+  - 只写主流程图未覆盖的细节；与主流程/接口章重复的内容必须用交叉引用
   - 超 5 行流程必须 Mermaid（G1）
-  - 复杂交互页状态机用 stateDiagram-v2
+  - 正文中文化（代码标识符只允许在术语表/字段表/示例）
 map_prompt: prompts/document/map/core-logic.md
 output_budget_tokens: 3000

package/templates/document/chapters/data-model.yaml

@@ -1,13 +1,16 @@
-# 数据模型（候选；依赖接口设计）
+# 数据模型（候选；依赖接口设计）——数据库表的唯一承载章节组件
+# 涉及数据库的表时本组件必选（when hasPersistence）：表结构与 DDL、字段说明、存量填充 G3、回滚 G4、
+# 契约-表映射。接口契约本体在「接口与数据设计」章（接口明细），本章通过映射表与接口对齐。
 id: data-model
 title: 数据模型
 when: input.hasPersistence
 depends_on: [api-design]
 outline_points:
-  - { id: DM1, text: 表结构与 DDL, required: true, kind: entity }
-  - { id: DM2, text: 字段说明 + 本迭代用法, required: true, kind: entity }
-  - { id: DM3, text: 存量填充策略（G3）, required: true, kind: narrative }
-  - { id: DM4, text: 回滚数据兼容（G4）, required: true, kind: narrative }
+  - { id: DM1, text: 数据流总览 + 契约-表映射（每接口 ↔ 读写表/列）, required: true, kind: mixed }
+  - { id: DM2, text: 表结构与 DDL, required: true, kind: entity }
+  - { id: DM3, text: 字段说明 + 本迭代用法, required: true, kind: entity }
+  - { id: DM4, text: 存量填充策略（G3）, required: true, kind: narrative }
+  - { id: DM5, text: 回滚数据兼容（G4）, required: true, kind: narrative }
 entities:
   tables:
     required: [id, name, ddl]
@@ -18,6 +21,7 @@ narratives:
   data_notes: required
 gates:
   - 每张表必须有完整 CREATE TABLE（含 ENGINE/CHARSET）
+  - 有接口实体时必须给出「契约-表映射」（每接口 ↔ 读写表/列），禁止接口讲接口、表讲表
   - JSON/新列必须有存量填充策略（G3）
   - 必须有回滚数据兼容说明（G4）
   - 零 DDL 迭代仍须展示现网 DDL（禁止假装不涉及数据库）

package/templates/document/chapters/mvp-boundary.yaml

@@ -7,9 +7,6 @@ outline_points:
   - { id: MVP1, text: MVP 核心功能清单, required: true, kind: entity }
   - { id: MVP2, text: 后续版本功能, required: true, kind: narrative }
   - { id: MVP3, text: 预估复杂度与开发阶段, required: true, kind: narrative }
-entities:
-  decisions:
-    required: [id, text]
 narratives:
   mvp_notes: required
 gates:

package/templates/document/chapters/requirement.yaml

@@ -1,18 +1,16 @@
-# 需求（feature 必选）
+# 需求（feature 必选；可读性整改：不写验收小节，验证由测试策略承接）
 id: requirement
 title: 需求
 when: null
 depends_on: []
 outline_points:
   - { id: REQ1, text: 功能需求描述, required: true, kind: narrative }
-  - { id: REQ2, text: 验收标准（Given-When-Then）, required: true, kind: mixed }
-entities:
-  decisions:
-    required: [id, text]
+  - { id: REQ2, text: 目标与边界（MVP 范围/跨仓依赖/约束；不写 Given-When-Then 验收）, required: true, kind: narrative }
+entities: {}
 narratives:
   requirement_notes: required
 gates:
-  - 需求必须可验证（有明确验收标准）
-  - 禁止含糊需求（如「更好的体验」）
+  - 需求聚焦目标与边界，禁止含糊需求（如「更好的体验」）
+  - 不写 Given-When-Then 验收小节（验收断言由测试策略章承接）
 map_prompt: prompts/document/map/requirement.md
 output_budget_tokens: 3000

package/templates/document/chapters/tech-selection.yaml

@@ -8,9 +8,6 @@ outline_points:
   - { id: TS2, text: 后端/数据库/基础设施选型与理由, required: true, kind: mixed }
   - { id: TS3, text: 选型理由（为何不用备选）, required: true, kind: narrative }
   - { id: TS4, text: 综合评估矩阵（候选方案 × 评估维度 × 得分 × 权重；F5 预研/选型用）, required: false, kind: mixed }
-entities:
-  decisions:
-    required: [id, text]
 narratives:
   selection_reason: required
 gates:

package/templates/document/chapters/test-strategy.yaml

@@ -6,16 +6,13 @@ depends_on: [api-design, data-model]
 outline_points:
   - { id: T1, text: 分层测试矩阵, required: true, kind: entity }
   - { id: T2, text: 测试环境与数据, required: true, kind: narrative }
-  - { id: T3, text: 与验收标准的映射, required: true, kind: narrative }
+  - { id: T3, text: 验收断言承接（Given-When-Then 折叠进本表，每行加「验收依据」列）, required: true, kind: narrative }
   - { id: T4, text: 前端测试金字塔（单元 60% / 组件 30% / E2E 10%，含组件测试 Snapshot+交互）, required: false, kind: narrative }
   - { id: T5, text: 回归测试范围（对应影响面，覆盖受影响功能）, required: false, kind: narrative }
-entities:
-  decisions:
-    required: [id, text]
 narratives:
   test_notes: required
 gates:
-  - 每个测试层级必须映射到具体验收标准/场景
+  - 每个测试层级必须给出验收依据（承接需求章目标；验收不再单独成章）
   - 每个层级有工具/框架 + 可验证目标
   - 不涉及测试变更时显式标注
   - 涉及前端时，测试金字塔比例与组件测试方式必须写明（禁「跑单测」空话）

package/templates/document/chapters/ui-design.yaml

@@ -12,9 +12,6 @@ outline_points:
   - { id: UI6, text: 路由守卫/懒加载（权限/登录态/动态 import）, required: false, kind: narrative }
   - { id: UI7, text: 埋点（页面曝光/点击事件 + 参数）, required: false, kind: narrative }
   - { id: UI8, text: 浏览器兼容策略（版本 + 降级手段，README §1.4）, required: false, kind: narrative }
-entities:
-  decisions:
-    required: [id, text]
 narratives:
   ui_notes: required
 gates:

package/templates/document/profiles/approve.yaml

@@ -12,11 +12,12 @@ required:
   - implementability # 可实施性评估（7 维）
 optional_candidates:
   - ui-design       # 前端/UI（条件: uiInScope）
-  - core-logic      # 核心算法/逻辑
+  - core-logic      # 关键实现规则（依赖闭合用 core-flow）
   - config-runtime  # 配置与运行环境
   - compat-migration # 兼容性与迁移
   - acceptance      # 验收标准
   - deploy          # 部署/发布/回滚
   - signoff         # 审批意见（签字栏）
 forbidden: [reproduce, root-cause, impact, fix, regression]
-shared: []
+shared:
+  - core-flow       # 仅依赖闭合：core-logic 依赖 core-flow，approve 不渲染主流程章

package/templates/document/profiles/feature.yaml

@@ -20,4 +20,4 @@ optional_candidates:
 shared:                       # 仅闭合允许、不渲染：impact 依赖 root-cause；前端链依赖 frontend-architecture
   - root-cause
   - frontend-architecture
-forbidden: [reproduce, root-cause, fix, regression, goal, mvp-boundary, non-goals, research, poc-demo, benchmark, migration-guide, deploy, ops, closed-loop, implementability, config-runtime, acceptance]
+forbidden: [reproduce, root-cause, fix, regression, goal, mvp-boundary, research, poc-demo, benchmark, migration-guide, deploy, ops, closed-loop, implementability, config-runtime, acceptance]