@gordon.gan/specflow 1.8.0-alpha → 1.8.1-beta

package/prompts/document/map/api-design.md

@@ -1,17 +1,26 @@
-# 章节填充：api-design（接口设计）
+# 章节填充：api-design（接口设计 · 契约 + 前端对接）
 
 你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
 - kind=entity|mixed 的要点 → 产出结构化契约实体（JSON 块 ```json {"entities": {...}} ```）
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 
-## 接口章节硬规则（借鉴 approval api-guidance）
+## 接口章节硬规则（借鉴 approval api-guidance + F1/F2 前端对接合并）
 
 1. **分层契约，禁止混层**：每个契约面对应一个独立 `In`（L2 Worker HTTP / L3 RPC+HTTP / L4 客户端 RPC），禁止「内部经 I7 一行代替 L4 详设」。
 2. **RPC / 服务名冻结**：禁止「暂定 / 如 Xxx / 实现时命名」；给出冻结的 RPC 名 + proto 字段号 + http_path。
 3. **proto 最小集**：新接口尽量给出可生成的 Proto 草案（rpc 名 / message / field 编号 / google.api.http）。
 4. **G2 失败示例（强制）**：清单中每个接口（含「不变」）除成功示例外，必须 ≥1 组失败示例（参数校验失败/租约过期/未认证），附完整 HTTP 或等价示例。只有错误码表不合格。
 5. **固定顺序**：元信息 → 请求体字段（或路径/Query/CLI flags）→ 请求示例 → 成功响应字段 → 响应示例(成功) → 响应示例(失败)(G2) → 错误表 →（可选）处理顺序。
-6. **接口清单稳定编号**：`In` 稳定，供 §4.6 页面引用与跨章交叉引用。
-7. **优先级**：项目约定 + 现网 OpenAPI/proto > SpecFlow 骨架 > LLM。
+6. **接口清单稳定编号**：`In` 稳定，供页面引用与跨章交叉引用。
+
+## 前端对接维度（O5–O7，F1 §2.2 合并「契约+对接」）
+
+7. **前端请求封装**：统一请求层（拦截器：token 注入/统一错误处理/超时/重试策略/缓存），DTO → VO 映射层。禁止「每个页面自己 fetch + 自己处理错误」。
+8. **前端错误处理统一**：后端错误码 → 前端统一错误态映射（Loading-Empty-Error），禁止前后端各写一套错误码约定。
+9. **接口 Mock 与契约先行**：前端并行开发用 Mock，Mock 的数据结构必须与冻结契约一致（R5）；联调时切换真实接口不改变前端代码结构。
+10. **优先级**：项目约定 + 现网 OpenAPI/proto > SpecFlow 骨架 > LLM。
+
+> 前后端契约一致性是本章最高门禁：字段名、错误码、DTO 结构前后端必须对齐，禁止各写各的。

package/prompts/document/map/architecture.md

@@ -1,7 +1,27 @@
-# 章节填充：architecture
+# 章节填充：architecture（架构设计 · C4 分层 + ADR）
 
 你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
 - kind=entity|mixed 的要点 → 产出结构化契约实体（JSON 块 ```json {"entities": {...}} ```）
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 架构章节硬规则（G1 + README §1.7 + C4/ADR，见 f1-0to1.md §2.7.4）
+
+1. **架构图必须有图 + 文字（README §1.7 门禁）**：
+   - Mermaid 组件图/容器图（```mermaid block）。
+   - 图后逐节点说明职责/边界/「不放什么」，禁止只复述节点名，也禁止只有图无文字。
+   - 超 5 行流程必须 Mermaid（G1）。
+
+2. **每个组件必须写「不做什么」边界**（反AI决策 #1 在架构层）：组件职责一句话 + 明确不放什么（如「网关不做业务逻辑」「缓存层不做持久化」）。
+
+3. **C4 分层（AR4）**：按需给 Context（系统上下文，外部系统/用户）/ Container（可部署单元：Web/API/DB/消息）/ Component（模块组件）分层；每层给依赖方向。与 core-flow 的组件层交互时序对接（R5，交叉引用冻结 id）。
+
+4. **ADR 决策记录（AR5）**：把 tech-selection 的关键决策沉淀为 ADR——背景 / 决策 / 后果 / 备选（为什么不用备选）。引用 tech-selection 的 decisions 实体 id，不另起名。
+
+5. **架构一致性自检（AR3）**：对照目标（可扩展/可维护/性能），检查架构是否满足，给出自检结论。
+
+6. **功能场景（F2）特殊**：architecture = 功能架构（不是项目架构）——只画本次功能涉及的模块/组件边界/与现有系统的集成点，不重画整个项目架构。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/benchmark.md

@@ -0,0 +1,26 @@
+# 章节填充：benchmark（Benchmark 数据）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown（含测量数据表）
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## Benchmark 章节硬规则（F5 预研/选型 · 数据说话的严谨性）
+
+1. **同条件同设备（铁律）**：所有候选必须在**同一台设备/同一环境/同一数据规模**下测量，并写明条件（硬件型号 / OS / 版本 / 数据集 / 压测工具 / 次数）。**禁止**拿别人文档里的数字和自己实测比，也禁止不同环境互相硬比。
+
+2. **必须给原始测量值**：每个指标给**原始数据**（如 `P95 延迟 = 23ms`、`冷启动 = 1.8s`、`bundle gzip = 186KB`、`QPS = 1200`），再谈相对提升。**禁止**只写「提升 50%」「性能大幅提升」这类无原始数据的结论（反AI决策 #2 数字门禁）。
+
+3. **双维度覆盖（全栈）**：按预研对象取舍——
+   - **前端维度**：渲染速度（首屏/交互）、内存占用、bundle 体积（raw/gzip）、加载时间、Lighthouse。
+   - **后端维度**：吞吐（QPS/RPS）、延迟（P50/P95/P99）、内存/CPU 占用、连接数、DB 查询耗时。
+   - 只评估前端的预研可以只测前端维度，但**要说清为什么后端维度不适用**（如「纯前端库，无服务端运行时」）。
+
+4. **DX 对比也量化**：HMR 速度、调试工具链（DevTools 集成/断点）、类型体验（TS 支持等级）、文档质量、迁移成本。DX 可以主观，但要有「为什么」；能数字化的给数字。
+
+5. **注明数据可信度**：每个结论标注「可复现（附复现步骤）/ 单次测量（未复现）/ 样本数 N」。数据可信度决定选型结论的权重——不可复现的数据不能支撑硬结论。
+
+6. **结论承接选型**：benchmark 结论（哪个候选在哪些维度占优）要能被 tech-selection 评估矩阵引用，作为「得分」的事实依据。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目红线（如「性能目标是 LCP<2.5s」）优先于通用规则。

package/prompts/document/map/closed-loop.md

@@ -5,4 +5,5 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 - 涉及项目规约/DB/API/前端约束时，遵循「项目约定 > SpecFlow guidance > LLM」优先级

package/prompts/document/map/compat-migration.md

@@ -1,8 +1,31 @@
-# 章节填充：compat-migration
+# 章节填充：compat-migration（兼容性与迁移 · 新旧 API 对照）
 
 你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
 - kind=entity|mixed 的要点 → 产出结构化契约实体（JSON 块 ```json {"entities": {...}} ```）
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 - 涉及项目规约/DB/API/前端约束时，遵循「项目约定 > SpecFlow guidance > LLM」优先级
+
+## 兼容迁移章节硬规则（G3/G4 + F4 迁移扩展）
+
+1. **接口/数据兼容结论（CM1）**：本次变更是否破坏兼容——接口签名、数据结构、字段增减、行为变化。给明确结论（兼容/不兼容 + 影响面）。
+
+2. **存量填充策略（CM2 · G3）**：新数据/新字段对存量数据的填充策略（回填默认值/延迟填充/首次访问计算），写明触发时机与可回滚性。
+
+3. **回滚数据兼容（CM3 · G4）**：回滚后旧版本能否安全跳过/忽略新数据，必须写明。禁止「回滚就完事」。
+
+4. **新旧 API 变化对照（CM4）**：有 Breaking Change 时逐项对照：
+   ```
+   | 旧 API/字段 | 新 API/字段 | 变更类型（重命名/删除/改类型/新增必填） | 迁移动作 |
+   ```
+   禁止只写「不兼容」。
+
+5. **浏览器/依赖兼容（CM5）**：目标版本 + 降级手段（README §1.4），禁「支持最新浏览器」空话。
+
+6. **渐进式迁移（CM6）**：分阶段迁移计划、新旧代码共存（双构建/双运行/特性开关）、每阶段结束可运行。
+
+7. **零变更**：显式「无新旧互读问题」。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/component-design.md

@@ -0,0 +1,30 @@
+# 章节填充：component-design（组件设计）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown（含组件树）
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 组件设计章节硬规则（frontend-dev-guide 组件方法论 + README §1.1/§1.2）
+
+1. **组件树必须标注流向（禁只列组件名）**：
+   ```
+   页面 PageX
+     └─ 容器 ContainerX（数据获取 + 状态）──Props 向下──
+           └─ 展示组件 PresenterX（只渲染）──Events 向上──
+                 └─ 基础组件 BaseX（default/loading/empty/error 四态）
+   ```
+   每条连线标注「props 流向」或「event 名 + 参数」。
+
+2. **单一职责 + 组合优先**：一个组件只做一件事；优先组合而非继承。给出每个组件的「职责一句话」和「不做什么」。
+
+3. **四态必须逐组件覆盖（README §1.2 结构模板）**：default / loading / empty / error（含重试），禁止只写成功态。每态给出 UI 表现（骨架屏/空文案+引导/错误重试）。
+
+4. **容器/展示分离**：容器组件负责数据获取与状态管理，展示组件只负责渲染。必须写明每个组件属于哪一类，数据从哪来。
+
+5. **复用与拆分边界（反AI决策 #1）**：至少给 1 条「本迭代不拆/不复用」的边界（如「两个页面暂共享此组件，但差异超过 30% 时拆开」）。禁止为抽象而抽象。
+
+6. **禁臆造组件树（README §1.1）**：组件树必须能追溯到页面/路由清单与设计输入；不存在于输入或推断来源的页面树禁止臆造。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/config-runtime.md

@@ -5,4 +5,5 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 - 涉及项目规约/DB/API/前端约束时，遵循「项目约定 > SpecFlow guidance > LLM」优先级

package/prompts/document/map/core-flow.md

@@ -0,0 +1,62 @@
+# 章节填充：core-flow（主业务流程时序）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown（含 Mermaid 时序图）
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 时序图硬规则（README §1.7 架构图规范 + seqdiagram 精神）
+
+1. **必须有图**：主链路时序图用 Mermaid `sequenceDiagram` 源码块（diagram as code，可进 git/diff）。禁止用文字描述代替图，也禁止贴图片。
+
+2. **必须有文字说明图（图 + 文成对）**：
+   - 图前写一段「本图说明」：这条链路在讲什么、参与者（lifeline）分别是谁。
+   - 图后逐条解释关键消息/分支：每条消息为什么这么走、谁负责什么、失败时怎么办。
+   - **禁止只有图没有文字**，也禁止只有文字没有图。
+
+3. **覆盖关键分支**（禁止只画 happy path）：
+   - 成功路径：正常完成整条链路。
+   - 异常/失败路径：错误码 → 降级 → 重试 → 回滚（`alt`/`opt` 块）。
+   - 写操作链路：幂等（重复请求/重复提交如何保证只生效一次）+ 并发（并发写/乐观锁）。
+   - 异步/消息链路：回调/补偿/死信/超时（`par`/`Note` 标注）。
+   - 第三方交互：webhook/回调/超时降级/隔离（防雪崩）。
+
+4. **标注易错决策点**（seqdiagram-examples 精神）：每条主链路至少标 1 处「第一次容易做错的决策」——如幂等键怎么生成、超时设多少、回调如何防重、降级策略是什么。用 `Note right of` 或紧随图的文字说明。
+
+5. **交叉引用一致（R5）**：时序图里用到的接口/表，引用上游冻结契约 id（如 `I1`/`T1`），不要另起新名；与 api-design/data-model 保持一致。
+
+6. **粒度**：一图一事——一条主链路一张图，不要把所有流程塞进一张巨型图；图多时按业务主链路拆开，每图配文字。
+
+## Mermaid sequenceDiagram 模板（可填空）
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant U as 用户
+    participant FE as 前端
+    participant BE as 后端
+    participant DB as 数据库
+    participant TP as 第三方
+    participant WK as 异步任务
+    U->>FE: 触发主操作（{页面/按钮}）
+    FE->>BE: {API 调用 + 参数}
+    BE->>BE: 校验/幂等键（{幂等方案}）
+    BE->>DB: {读写 + 事务/锁}
+    alt 成功
+        BE-->>FE: 200 + {返回结构}
+        FE-->>U: 成功态（{UI 表现}）
+    else 失败
+        BE-->>FE: {错误码 + 降级}
+        FE-->>U: 错误态（{重试/回退}）
+    end
+    opt 异步
+        BE->>WK: 投递任务（{队列/补偿}）
+    end
+    opt 第三方
+        BE->>TP: {调用 + 超时/重试}
+        TP-->>BE: {回调/webhook}
+    end
+```
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令（如「禁止引入消息队列」）不得被通用规则覆盖。

package/prompts/document/map/core-logic.md

@@ -5,4 +5,5 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 - 涉及项目规约/DB/API/前端约束时，遵循「项目约定 > SpecFlow guidance > LLM」优先级

package/prompts/document/map/data-model.md

@@ -5,6 +5,7 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 
 ## 数据章节硬规则（借鉴 approval database-guidance）
 

package/prompts/document/map/deploy.md

@@ -1,8 +1,26 @@
-# 章节填充：deploy
+# 章节填充：deploy（部署交付方案 · 12-Factor）
 
 你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
-- kind=entity|mixed 的要点 → 产出结构化契约实体（JSON 块 ```json {"entities": {...}} ```）
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 - 涉及项目规约/DB/API/前端约束时，遵循「项目约定 > SpecFlow guidance > LLM」优先级
+
+## 部署交付章节硬规则（F1 §2.6.2 + Twelve-Factor App）
+
+1. **环境拆分（DP1）**：dev/staging/prod 各自用途、谁访问、数据隔离。禁止「部署到服务器」这种空话。
+
+2. **CI/CD 流水线（DP2）**：代码检查 → 测试 → 构建 → 部署 各环节的工具与触发方式。**构建产物与运行分离（不可变制品）**：一次构建的镜像/产物用于所有环境，禁止「环境不同产物不同」。
+
+3. **部署拓扑（DP3）**：后端（容器/K8s/Serverless/虚拟机）+ 前端（静态托管/CDN/**SPA 路由回退**——history 模式必须配 fallback 到 index.html，否则刷新 404）。写明部署方式与理由。
+
+4. **发布策略（DP4）**：蓝绿 / 金丝雀 / 滚动 选择并给理由（按风险与回滚速度取舍）。
+
+5. **回滚（DP5）**：触发条件（什么指标/谁决策）、方式（切流量/重部署旧版本）、**数据一致性结论（G4 语义）**——回滚后新数据如何处理、旧版本能否安全读取，必须写明。禁止「出问题就回滚」一句话。
+
+6. **配置管理（DP6 · 12-Factor）**：配置来自环境变量；密钥（DB 密码/API key）不进代码仓库、不进制品；写明密钥管理方式（Secrets Manager/.env 注入）与生效时机（重启/热更新）。
+
+7. **纯库/CLI 项目**：可写「不涉及运行时部署」，并说明交付形态（npm 包/二进制/构建产物）。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/fix.md

@@ -5,3 +5,4 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造

package/prompts/document/map/frontend-architecture.md

@@ -0,0 +1,35 @@
+# 章节填充：frontend-architecture（前端架构设计）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown（含 Mermaid 架构图）
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 前端架构章节硬规则（frontend-dev-guide 目录分层 + README §1.7 架构图规范）
+
+1. **目录分层必须给「职责 + 不放什么」边界**：
+   ```
+   pages/         # 路由级页面：只做组合与数据装配，不放业务逻辑
+   components/    # 可复用 UI 组件：只做渲染，不直接发请求（容器层负责）
+   hooks/         # 可复用逻辑：状态与副作用封装，不放页面专属逻辑
+   services/      # 数据访问层：封装 API 调用，统一错误处理与缓存
+   utils/         # 纯函数工具：无副作用，不依赖框架
+   types/         # 类型定义与契约（DTO/VO），与后端契约对齐
+   ```
+   每层都要写「这一层**不放什么**」——反AI决策 #1（不做决策）在目录层面的体现。
+
+2. **模块化/Monorepo 决策必须给结论 + 理由**：单仓 vs Monorepo、包如何划分、共享代码如何复用。禁止只罗列利弊不选边。
+
+3. **工程化配置给工具 + 版本**：ESLint（+ 版本）/ Prettier / Husky（pre-commit lint-staged）/ TypeScript 等级（L1/L2/L3，README §1.4）/ CSS 决策树（Tailwind/CSS Modules/styled-components 选哪个，为什么）。禁止「用 ESLint 和 Prettier」这种空话。
+
+4. **架构图必须有图 + 文字（README §1.7 门禁）**：
+   - Mermaid 组件图/容器图（```mermaid block），展示目录层之间、前后端之间的依赖方向。
+   - 图后逐节点说明职责/边界/「不放什么」，禁止只复述节点名。
+   - 纯前端变体（frontend-0to1）不画后端容器，只画前端层与 API 边界。
+
+5. **与 state-management 的衔接**：本章只给数据流总览（方向与归属的骨架），细述交 state-management 章节。交叉引用保持一致（R5）。
+
+6. **项目约定优先**：若项目已有目录规范/工程化约定（docs/ 或 IDE rules），以其为准并显式引用；未发现则标注「未发现项目规约」。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/goal.md

@@ -5,3 +5,4 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造

package/prompts/document/map/impact.md

@@ -5,3 +5,4 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造

package/prompts/document/map/implementability.md

@@ -5,4 +5,5 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 - 涉及项目规约/DB/API/前端约束时，遵循「项目约定 > SpecFlow guidance > LLM」优先级

package/prompts/document/map/migration-guide.md

@@ -0,0 +1,36 @@
+# 章节填充：migration-guide（代码迁移指南）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown（含 checklist）
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 迁移指南章节硬规则（frontend-dev-guide 场景四 · 代码迁移）
+
+1. **逐模块 checklist 必须可勾选**：
+   ```
+   - [ ] 模块 A（src/pages/auth）：
+         - 步骤 A1：xxx（改完自测通过，验收：y）
+         - 步骤 A2：xxx
+   - [ ] 模块 B（src/services）：
+         - 步骤 B1：xxx
+   ```
+   每个模块列可勾选步骤 + 每步验收标准。禁止笼统「迁移 auth 模块」。
+
+2. **自动化迁移脚本（codemod）**：给出工具（如 jscodeshift / eslint 自动修复 / 正则批量替换）与规则示例。能自动化的给脚本，不能的显式标「需人工」。
+
+3. **常见陷阱「现象 + 原因 + 解法」三段式**：
+   ```
+   ### 陷阱 1：迁移后首屏白屏
+   - 现象：xxx
+   - 原因：xxx（如 Vite 下 __dirname 不可用）
+   - 解法：xxx（如用 import.meta.url）
+   ```
+   禁止只写「注意兼容性」。
+
+4. **迁移顺序保证中间态可运行（f4 §5.3 双构建双运行）**：先迁依赖 → 再迁基础层（utils/services）→ 再迁页面 → 最后清理旧代码。每一步结束系统可构建可运行（新旧代码共存策略、双构建/双运行方案）。
+
+5. **培训计划**：分享/Slide 大纲、代码示例对照（新旧 API 对比表）、最佳实践文档链接。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/mvp-boundary.md

@@ -5,3 +5,4 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造

package/prompts/document/map/non-goals.md

@@ -5,3 +5,4 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造

package/prompts/document/map/ops.md

@@ -0,0 +1,33 @@
+# 章节填充：ops（运维运营方案）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 运维运营章节硬规则（SRE 四金信号 + PRR/Launch + DORA，见 f1-0to1.md §2.6）
+
+1. **监控必须覆盖四金信号（SRE）**：延迟（Latency）/ 流量（Traffic）/ 错误（Errors）/ 饱和度（Saturation）。每个信号给出指标名、采集方式、阈值、告警对象。缺一即不完整。前端侧补 RUM + CWV（LCP/FID/CLS）。
+
+2. **上线检查清单逐项带证据（PRR 精神）**：
+   ```
+   - [ ] 可观测性：监控/日志/告警已配置（证据：监控面板链接 + 最近一次告警演练记录）
+   - [ ] 回滚：回滚方案已演练（证据：回滚演练记录 + 时间）
+   - [ ] 备份：数据备份已启用且可恢复（证据：RTO/RPO + 最近一次恢复演练）
+   - [ ] 依赖：外部依赖（DNS/证书/第三方）已就绪（证据：证书有效期 + 依赖清单）
+   - [ ] 文档：runbook/值班手册已更新（证据：文档链接）
+   ```
+   每一项必须有「证据」，空证据 → 视为未完成。
+
+3. **告警与值班**：告警分级（P0/P1/P2）、升级路径、响应时限、值班轮换（on-call）。on-call 与告警阈值需匹配（避免告警疲劳）。
+
+4. **备份恢复**：数据备份策略（全量/增量频率）、RTO/RPO 目标、恢复演练频率。无数据库/无状态服务需显式写「不涉及」。
+
+5. **安全基线**：密钥管理（不用环境变量明文存密钥）、CSP、HTTPS 强制、防火墙/访问控制、审计日志。按项目形态取舍并写明理由。
+
+6. **成本控制**：资源规模预估、预算告警、用量治理（闲置资源回收）。按团队规模取舍。
+
+7. **DORA 度量**：部署频率/变更前置时间/MTTR/变更失败率的目标值与度量方式，作为持续改进依据。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/performance.md

@@ -0,0 +1,32 @@
+# 章节填充：performance（性能方案）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 性能章节硬规则（frontend-dev-guide 性能 KPI + README §1.3 + 反AI决策 #2）
+
+1. **优化必须带数字（前后对比）**：每一项优化给出「优化前 → 优化后」的具体数字（体积 KB、耗时 ms、Lighthouse 分数），并注明测量工具与口径。禁止只写「用 React.memo + useMemo」（反AI决策 #2）。
+
+2. **CWV 指标给目标值（README §1.3 KPI 表）**：
+   | 指标 | 目标 | 测量工具 |
+   |------|------|---------|
+   | LCP | < 2.5s | Lighthouse / Web Vitals |
+   | FID | < 100ms | Web Vitals |
+   | CLS | < 0.1 | Web Vitals |
+   | TTI | < 3.5s | Lighthouse |
+   | Bundle (JS gzip) | < 200KB | bundle-analyzer |
+   | Lighthouse Score | > 90 | Lighthouse |
+   目标值必须给到数字，禁止「越快越好」。
+
+3. **打包与体积**：bundle 分析结论、代码分割/懒加载方案（路由级/组件级）、依赖体积审计（是否有可替换的大依赖）。
+
+4. **渲染性能**：列表渲染优化（虚拟滚动/增量渲染）、重渲染控制（memo/useMemo 的实际收益，用数字说明）、避免不必要的响应式更新。
+
+5. **缓存策略**：HTTP 缓存（Cache-Control/ETag）、CDN、请求合并与防重复请求、接口数据缓存（SWR 等）。
+
+6. **测量口径明确**：在哪测（设备/网络模拟）、用什么工具、测什么页面（关键路径），保证数字可复现（README §1.3 门禁）。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/poc-demo.md

@@ -0,0 +1,25 @@
+# 章节填充：poc-demo（PoC Demo）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## PoC 章节硬规则（F5 预研/选型 · 验证假设而非做功能）
+
+1. **PoC 只验证「最不确定的风险点」**：PoC 不是做功能 demo。先回答「这个技术最大的不确定性是什么」（性能？兼容？DX？生态？），PoC 就为验证它而生。禁止把 PoC 范围写成一个小型生产系统。
+
+2. **边界必须明确（验证什么 / 不验证什么）**：写清楚「本 PoC 验证 X，**不**验证 Y（Y 留待生产期）」。没有「不验证什么」的 PoC 边界 = 没有边界。
+
+3. **判据可证伪**：每个验证点给**可量化的成功/失败判据**（如「QPS ≥ 1000」「冷启动 < 2s」「可无障碍接入现有登录」）。判据可证伪，验证才有意义；「感觉还行」不算判据。
+
+4. **文档只写 PoC 设计/边界/判据/结论**，**不写实现代码**：可运行的 demo 代码另行落库（指定仓库/目录路径即可），本文档是方案文本产物，不是代码仓库。
+
+5. **已知限制与未验证项 ≥1 条**：诚实列出 PoC 没覆盖到的场景/数据量/边界（如「未测百万级数据」「未验证 IE 兼容」）。这直接决定选型结论的适用范围。
+
+6. **生产化差距必写**：PoC 结论之后，说明「从 PoC 到生产还差什么」——性能余量、健壮性、监控、安全、团队维护成本。禁止「PoC 通过了就可以上生产」。
+
+7. **结论承接选型**：PoC 结论（验证通过/失败/部分通过）要能被 tech-selection 章节引用，作为评估矩阵里「验证证据」的输入。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令（如「禁止做某方案 PoC」）不得被通用规则覆盖。

package/prompts/document/map/regression.md

@@ -5,3 +5,4 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造

package/prompts/document/map/reproduce.md

@@ -5,3 +5,4 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造

package/prompts/document/map/requirement.md

@@ -5,3 +5,4 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造

package/prompts/document/map/research.md

@@ -0,0 +1,25 @@
+# 章节填充：research（技术调研报告）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown（含对比表格）
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 技术调研章节硬规则（F5 预研/选型 · 反AI决策精神）
+
+1. **候选方案 ≥2 个**：列出全部被认真评估的候选（含「被否掉的」——说明否掉的理由，这是预研的价值）。禁止只调研一个然后硬推。
+
+2. **对比维度表必须同列可比**：表格行为候选、列为同一组维度（成熟度/性能/社区/学习成本/许可…），**禁止不同候选用不同维度**（那是"定制对比"，等于没比）。每个格子给事实或「未验证」标注，不写空话。
+
+3. **社区活跃度必须给数字**：GitHub Star 数 / open issue 数 / Release 频率（近 12 个月）/ 最近 release 时间 / 维护者响应。数字要给到能支撑结论的粒度；「社区活跃」不给数字 = 拍脑袋。
+
+4. **团队匹配度有依据**：团队现有技能栈、迁移学习成本（给个估计：多少天/多少人）、长期维护意愿。禁止「团队能学会」这种空话。
+
+5. **兼容性与约束**：浏览器/Node/现有技术栈/许可证（MIT/Apache/商业授权）的匹配；与项目红线（如「禁止引入消息队列」）冲突时要显式标出。
+
+6. **调研结论喂给后续**：明确「哪些问题留待 PoC 验证」「哪些数据留待 Benchmark 测量」，让 poc-demo/benchmark 章节承接（交叉引用，禁各写各的）。
+
+7. **优先候选**：给一个明确的优先候选方向（不一定是最终结论——最终结论在 tech-selection，这里给「值得深入验证的方向」）。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/root-cause.md

@@ -5,3 +5,4 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造

package/prompts/document/map/signoff.md

@@ -5,4 +5,5 @@
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 - 涉及项目规约/DB/API/前端约束时，遵循「项目约定 > SpecFlow guidance > LLM」优先级

package/prompts/document/map/state-management.md

@@ -0,0 +1,23 @@
+# 章节填充：state-management（状态管理）
+
+你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
+- kind=narrative|mixed 的要点 → 产出叙述 Markdown
+- 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
+- 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
+
+## 状态管理章节硬规则（frontend-dev-guide 数据流方法论）
+
+1. **状态归属逐条列出（字段级）**：每条状态写清「字段名 → 存放位置（局部 state / 全局 store / URL 参数 / 服务端）→ 来源（用户输入/接口/派生）」。禁止笼统「状态放 store」。
+
+2. **禁止「全部放 store」（反AI决策 #1）**：明确哪些状态**不该**进全局 store——页面局部 UI 状态（折叠/展开/输入草稿）、与路由绑定的状态放 URL。给出「进 store 的标准」（跨页面共享/多组件消费/需持久化）。
+
+3. **Store 结构按域拆分**：全局 store 按业务域拆分模块（如 auth/cart/theme），模块内只含该域状态与 action。禁止一个巨型 store 装所有状态。
+
+4. **数据流方向必须单向**：action → reducer/store → selector → view → action。异步请求的 loading/error 归属要写明（是 store 字段还是局部状态），并给出竞态处理（请求序号/AbortController）。
+
+5. **持久化与恢复**：需要持久化的状态给存储介质（localStorage/URL/服务端）与恢复时机；SSR/Hydration 场景要写明首屏一致性与「水合闪烁」处理。
+
+6. **缓存与防重复请求**：服务端状态缓存策略（SWR/React Query 或自建）、失效时机、避免同一接口多处重复请求。
+
+> 优先级：项目约定 > SpecFlow guidance > LLM。项目禁令不得被通用规则覆盖。

package/prompts/document/map/tech-selection.md

@@ -1,10 +1,11 @@
-# 章节填充：tech-selection（技术方案评估）
+# 章节填充：tech-selection（技术方案评估 / 技术选型）
 
 你是方案文档撰写员。按大纲要点"填空题"式展开本章，逐要点填充，不自由发挥。
 - kind=entity|mixed 的要点 → 产出结构化契约实体（JSON 块 ```json {"entities": {...}} ```）
 - kind=narrative|mixed 的要点 → 产出叙述 Markdown
 - 遵循 prompts/shared/artifact-language.md 的中文叙述规范（简要；怎么做用 1. 2. 3.）
 - 禁止 stub（TODO/待补充/此处省略）；禁止含糊词
+- **事实从工程数据源提取，意图向用户询问，推理由你完成**（见 `prompts/document/shared/grounding.md`）：本章涉及的接口字段/表列/组件名/依赖版本必须来自工程，缺失的关键信息列入缺口清单一次性询问用户，禁止编造
 
 ## 技术评估章节硬规则（借鉴 approval 技术方案评估）
 
@@ -15,3 +16,14 @@
 5. **现状与约束**：用可读中文归纳现状与硬约束（含「本迭代禁止…」类红线）；禁止代码腔堆砌。
 6. **设计质量评估**：检查过度设计（YAGNI）——是否合理扩展性 vs 不必要的复杂度。
 7. **优先级**：项目约定 + 用户确认 > SpecFlow guidance > LLM。
+
+## 预研/选型模式（F5 fullstack-poc · 本要点出现时启用）
+
+当大纲含 **TS4（综合评估矩阵）**，即当前是预研/选型场景（有候选方案横向对比），追加以下硬规则：
+
+1. **综合评估矩阵（得分表）**：候选方案 × 评估维度（成熟度/性能/社区/团队匹配/成本/许可…）的二维表，每格给 1–5 分，每列给**权重**，末尾给**加权总分**。矩阵必须有得分与权重，禁止「候选 A 略优于 B」这类无分数的结论。
+2. **一句话立场（反AI决策 #1）**：推荐结论必须有一句话讲清「本项目**不**适用什么 / 什么条件下不选」——只列功能清单不算有立场。
+3. **证据引用**：矩阵得分尽量引用 research（调研）/ poc-demo（验证）/ benchmark（实测数据）的证据，标注来源章节，禁止自说自话。
+4. **风险与回退**：推荐方案的失败代价 + 回退路径 + 替代方案。
+
+> 非预研场景（0to1/approve 等，无 TS4 要点）保持 1–7 规则即可，不需要评估矩阵。