soloforge 1.1.47 → 1.1.49

package/templates/design/enforced.md

@@ -15,17 +15,44 @@ checks:
     severity: error
     gate: design-gate
     required_artifact: 需求分析模版
-    rule: "需求分析文档须含「根本目标（fundamental_need）」「功能点清单」「非功能需求」章节"
+    rule: "需求分析文档须含「需求来源」「根本目标」「功能点清单」「非功能需求」「用户角色」「外部接口」「系统形态与交付边界」「完成判定」章节"
     evidence_required:
       - "docs/context/需求分析.md"
     target: self
+  - id: REQ-ID-FMT
+    executor: regex_pattern_scan
+    rule: "需求 REQ ID 须纯数字（REQ-001）或中文模块段（REQ-用户-01）；禁止字母/字母数字模块段（REQ-M01-01）与占位符（REQ-NNN）——cross_validation 正则只认纯数字/中文模块段，前置校验避免产出后双向改 ID"
+    severity: error
+    check_type: deterministic
+    pattern: '/REQ-[A-Za-z]/'
+    languages: [通用]
+    required_artifact: 需求分析模版
+    evidence_required: ["regex_pattern_scan 扫描结果（SRS 无 REQ-字母模块段/占位符命中）"]
+    gate: design-gate
+    target: self
   - id: ARCH-STRUCT
     executor: document_structure
     check_type: deterministic
     severity: error
     gate: design-gate
     required_artifact: 架构设计模版
-    rule: "架构设计文档须含「约束条件」「安全架构」「风险与回滚」章节"
+    rule: "架构设计文档须含「决策记录」「约束条件」「模块划分」「架构组成」「安全架构」「技术选型」「风险与回滚」「产物适用性」「完成判定」章节"
+    evidence_required:
+      - "docs/architecture/01-架构设计文档.md"
+    target: self
+  # —— 前端模块化结构（ARCH-FE-STRUCT：§6.3 端模块清单 FE-*，承接需求 §9 系统形态）——
+  - id: ARCH-FE-STRUCT
+    executor: document_structure
+    check_type: deterministic
+    severity: warning
+    gate: design-gate
+    required_artifact: 架构设计模版
+    rule: "架构 §6.3 端模块清单含 FE-* ID 表格行（承接需求 §9 端清单）；纯后端项目填「不适用」放行（warning 级不强阻断）"
+    block_check:
+      item_pattern: '端模块清单'
+      required_marks: ['FE-']
+      require_table: true
+      min_table_rows: 1
     evidence_required:
       - "docs/architecture/01-架构设计文档.md"
     target: self
@@ -35,7 +62,7 @@ checks:
     severity: error
     gate: design-gate
     required_artifact: 数据库设计文档模版
-    rule: "数据库设计文档须含「实体与关系」「表字段与敏感级别」章节"
+    rule: "数据库设计文档须含「目标数据库」「实体与关系」「表字段」「约束」「Migration」「回滚」「映射表」「真实验证证据」「完成判定」章节"
     evidence_required:
       - "docs/design/01-数据库设计文档.md"
     target: self
@@ -45,27 +72,190 @@ checks:
     severity: warning
     gate: design-gate
     required_artifact: API接口规格文档模版
-    rule: "API 接口规格文档须含「响应体字段」「错误与副作用」「验收场景」核心 section"
+    rule: "API 接口规格文档须含「Endpoint」「请求体字段」「响应体字段」「错误与副作用」「验收场景」「完成判定」章节"
     evidence_required:
       - "docs/design/02-API接口规格文档.md"
     target: self
-  # —— 设计主观规则（semantic，advisory 不阻断，随 Reflexion 反馈供 AI 评判）——
-  - id: DES-C-REVIEW
-    executor: semantic
-    rule: "客户端 AI 评判设计主观规则：① 每条架构决策须有对应 ADR，禁止口头决策不留记录 ② ADR/重大选型状态变更须经用户确认，Agent 不得自动变更 ③ 技术选型须有依据（性能/成本/熟悉度）而非仅凭业界主流 ④ 改老系统须有兼容性分析与回滚方案"
-    severity: info
-    check_type: semantic
-    evidence_required:
-      - "LLM 语义评估结论（pending 标记，advisory 不阻断，随 Reflexion 反馈供客户端 AI 评判/重试）"
+  - id: API-BLOCK
+    executor: document_structure
+    check_type: deterministic
+    severity: error
+    gate: design-gate
+    required_artifact: API接口规格文档模版
+    rule: "每个 endpoint 块须含基本信息/响应体/错误与副作用/验收场景 且有表格（反退化：禁前详后废/表格→文字/同上占位）"
+    block_check:
+      item_pattern: '^###\s+Endpoint'
+      required_marks: ['基本信息', '响应体', '错误与副作用', '验收场景']
+      require_table: true
+      min_table_rows: 4
+    evidence_required: ["docs/design/02-API接口规格文档.md"]
+    target: self
+  - id: SLICE-PLAN-STRUCT
+    executor: document_structure
+    rule: "开发切片计划须含「PHASE」「SLC」「AC」「完成判定」章节"
+    severity: error
+    check_type: deterministic
+    required_artifact: 切片计划模版
+    evidence_required: ["docs/architecture/02-开发切片计划.md"]
+    gate: design-gate
+    target: self
+  # —— 产物间一致性（cross_validation：ID 引用一致+覆盖，确定性）——
+  - id: XVAL-ARCH-REQ
+    executor: cross_validation
+    rule: "REQ-* 一致性+覆盖率"
+    severity: error
+    check_type: deterministic
+    required_artifact: 架构设计模版
+    evidence_required: ["需求分析模版"]
+    gate: design-gate
+    target: self
+  - id: XVAL-API-REQ
+    executor: cross_validation
+    rule: "REQ-* 一致性+覆盖率"
+    severity: warning
+    check_type: deterministic
+    required_artifact: API接口规格文档模版
+    evidence_required: ["需求分析模版"]
+    gate: design-gate
+    target: self
+  - id: XVAL-ARCH-API
+    executor: cross_validation
+    rule: "DD-A* 一致性（架构引用的 API ID 须在 API 文档存在；不强制覆盖率——架构不逐一引用所有 API ID）"
+    severity: warning
+    check_type: deterministic
+    required_artifact: 架构设计模版
+    evidence_required: ["API接口规格文档模版"]
+    gate: design-gate
+    target: self
+  - id: XVAL-ARCH-DB
+    executor: cross_validation
+    rule: "DD-T* 一致性（架构引用的 DB ID 须在 DB 文档存在；不强制覆盖率——架构不逐一引用所有 DB ID）"
+    severity: warning
+    check_type: deterministic
+    required_artifact: 架构设计模版
+    evidence_required: ["数据库设计文档模版"]
+    gate: design-gate
+    target: self
+  - id: XVAL-SLC
+    executor: cross_validation
+    rule: "ARCH-*/FE-* 一致性+覆盖率"
+    severity: warning
+    check_type: deterministic
+    required_artifact: 切片计划模版
+    evidence_required: ["架构设计模版"]
     gate: design-gate
     target: self
+  # —— 产物适用性强制（治本「按需产出」：声明适用必产/不适用放行）——
+  - id: XVAL-DBAPI-APPLICABILITY
+    executor: applicability_check
+    rule: "design_doc 产物适用性强制：database_design/api_specification 声明「适用」须产出对应产物，声明「不适用」放行（前端/无后端按需不产），未声明须表态"
+    severity: error
+    check_type: deterministic
+    required_artifact: 架构设计模版
+    evidence_required: ["数据库设计文档模版", "API接口规格文档模版"]
+    gate: design-gate
+    target: self
+  # —— 引用/附件完整性由 handleVerify 系统校验（从 contract produces 的 references/companion_files 派生，所有域所有产物自动全覆盖，不再单点 check）——
+  # —— 附件校验（openapi.yaml，external_command redocly lint）——
+  - id: OPENAPI-LINT
+    executor: external_command
+    command: npx
+    args: ["@redocly/cli", "lint", "--config", "redocly.yaml", "docs/api/openapi.yaml"]
+    rule: "openapi.yaml 须通过 redocly lint --config redocly.yaml（SoloForge 锁定规则；YAML 语法+OpenAPI 规范；缺文件/无 redocly 判失败）"
+    severity: warning
+    check_type: deterministic
+    evidence_required: ["redocly lint 输出（exitCode 0 通过）"]
+    gate: design-gate
+    target: self
+  # —— 字段映射校验（数据库 §3/§7 ↔ schema.sql 真实字段，确定性）——
+  - id: FMAP-DB-SCHEMA
+    executor: field_mapping_validation
+    rule: "表.字段 一致性+覆盖率"
+    severity: error
+    check_type: deterministic
+    required_artifact: 数据库设计文档模版
+    evidence_required: ["docs/design/schema.sql"]
+    gate: design-gate
+    target: self
+  - id: SLICE-BLOCK
+    executor: document_structure
+    check_type: deterministic
+    severity: error
+    gate: design-gate
+    required_artifact: 切片计划模版
+    rule: "每个 SLC 块须含涉及 ARCH / AC 验收标准 且有字段表格（反退化：禁前详后废/同上占位）"
+    block_check:
+      item_pattern: '^###\s+SLC-'
+      required_marks: ['涉及 ARCH', 'AC-']
+      require_table: true
+      min_table_rows: 5
+    evidence_required: ["docs/architecture/02-开发切片计划.md"]
+    target: self
+  - id: SLICE-DIMENSION
+    executor: slice_verifiability_check
+    check_type: deterministic
+    severity: error
+    gate: design-gate
+    required_artifact: 切片计划模版
+    rule: "切片维度硬约束：① 骨架/基础设施切片 ≤ 2（防按端/技术层横切——切片须垂直端到端业务价值 前端→后端→DB，基础设施只占 1~2 例外切片，不得每端/每层一个骨架）；② 每切片验收契约完整（可独立验证/验收范围/部署要求/E2E验证项，无通配占位）"
+    evidence_required: ["docs/architecture/02-开发切片计划.md"]
+    target: self
+  - id: DB-BLOCK
+    executor: document_structure
+    check_type: deterministic
+    severity: error
+    gate: design-gate
+    required_artifact: 数据库设计文档模版
+    rule: "数据库必填表格章节（实体/表字段/约束索引/Migration/API映射/SQL证据）须有表格行（反退化：禁空表/文字代替）"
+    block_check:
+      item_pattern: '^##\s+(1|2|3|4|6|7|8)\.'
+      require_table: true
+      min_table_rows: 1
+    evidence_required: ["docs/design/01-数据库设计文档.md"]
+    target: self
+  - id: REQ-BLOCK
+    executor: document_structure
+    check_type: deterministic
+    severity: error
+    gate: design-gate
+    required_artifact: 需求分析模版
+    rule: "需求必填表格章节（功能点/NFR/角色/外部接口/系统形态端清单等）须有表格行（反退化：禁空表/示例行后省略）"
+    block_check:
+      item_pattern: '^##\s+[2-9]\.'
+      require_table: true
+      min_table_rows: 1
+    evidence_required: ["docs/context/需求分析.md"]
+    target: self
+  # —— 系统形态研讨兜底（REQ-DELIB：涉及前端时强制 deliberate 研讨系统形态并留痕；纯后端跳过）——
+  - id: REQ-DELIB
+    executor: requirement_deliberation_gate
+    check_type: deterministic
+    severity: error
+    gate: design-gate
+    required_artifact: 需求分析模版
+    rule: "涉及前端（§9 形态含前后端分离/多端/纯前端，或端清单非空）时，须先 sf_work action=deliberate domain=design target=requirement_analysis 研讨系统形态并留痕研讨记录（docs/研讨记录/设计/需求分析-研讨记录.md）；纯后端跳过"
+    evidence_required: ["docs/研讨记录/设计/需求分析-研讨记录.md"]
+    target: self
+  - id: ARCH-BLOCK
+    executor: document_structure
+    check_type: deterministic
+    severity: error
+    gate: design-gate
+    required_artifact: 架构设计模版
+    rule: "架构必填表格章节（需求概要/约束/技术选型/风险/横切）须有表格行（反退化：禁其余同上/一句话代替）"
+    block_check:
+      item_pattern: '^##\s+(2|3|7|10|11)\.'
+      require_table: true
+      min_table_rows: 1
+    evidence_required: ["docs/architecture/01-架构设计文档.md"]
+    target: self
 ---
 
 # design-gate 强制检查清单
 
 design 阶段产物结构与决策质量检查。bridge 从此文件聚合。
 
-- **REQ-STRUCT / ARCH-STRUCT / DB-STRUCT / API-STRUCT**：产物必含章节（document_structure，确定性）
-- **DES-C-REVIEW**：决策有 ADR / 选型有依据 / 改老系统有回滚（semantic，advisory）
+- **REQ-STRUCT / ARCH-STRUCT / DB-STRUCT / API-STRUCT**：产物必含章节（document_structure，确定性；ARCH-STRUCT 含「架构决策记录 ADR」章节——决策留痕+选型依据）
+- 设计主观纪律（选型变更须经用户确认 / 改老系统须兼容性分析）→ 软下限《设计决策纪律》guidance 注入（原 DES-C-REVIEW semantic 拆出）
 
 > 代码层正则检查（Controller 不含业务逻辑、写操作须事务等 ARC-*）已迁至 build-gate，那里才是代码实现阶段的归属。

package/templates/design//345/205/250/347/224/237/345/221/275/345/221/250/346/234/237/345/267/245/344/275/234/346/265/201/345/257/274/350/210/252.md

@@ -5,13 +5,13 @@ title: 全生命周期工作流导航
 sync_policy: internal
 status: active
 triggers:
-  - 下一步
-  - 继续
   - 现在能写代码吗
   - 工作流导航
   - navigation
   - 阶段判断
   - 工作包生成
+  - 项目阶段
+  - 生命周期
 extra:
   name: full-lifecycle-navigation
   type: procedure
@@ -57,19 +57,21 @@ extra:
 
 1. 输入材料收集 → 2. 需求明确化 → 3. 决策研讨 → 4. 架构设计 → 5. 详细设计 → 6. 数据库设计 → 7. API 设计 → 8. 切片规划 → 9. 编码实现 → 10. 本地验证 → 11. 测试 → 12. 代码审查 → 13. 修复复验 → 14. 交付验收 → 15. 发布准备 → 16. 发布后观察
 
+> 步骤 2「需求明确化」含**系统形态研讨**：确定是否前后端分离、几个端、各端技术栈，结论写进需求 §9（涉及前端时强制研讨留痕，REQ-DELIB 兜底；下游架构 §6.3 据端清单 FE-* 模块化前端）。
+
 ## 导航决策流程
 
-1. 调用 `sf_task action=query` 或 `sf_task action=query` 获取当前状态
+1. 调用 `sf_task action=query` 获取当前状态
 2. 检查配置完整性：resolveConfig 返回 missing 时，优先补充不可探测字段
 3. 检查是否有陈旧任务需要处理
 4. 读取 `confirmation_decisions`
    - `must_confirm` 非空时，先让用户选择，不得继续执行会被阻断的动作
    - `should_confirm` 非空时，明确说明建议确认的收益，但允许继续只读或低风险准备
    - `auto_resolvable` 非空时，按推荐命令修复或复验，不把它伪装成业务确认
-4. 读取返回的 work_package，按描述执行下一步
-5. 遵守 disallowed_actions 中的禁止动作
-6. 执行完成后运行 acceptance_commands 验证
-7. 如需用户确认，必须列出具体确认项、选项和不确认影响，不能笼统说“需要确认”
+5. 读取返回的 work_package，按描述执行下一步
+6. 遵守 disallowed_actions 中的禁止动作
+7. 执行完成后运行 acceptance_commands 验证
+8. 如需用户确认，必须列出具体确认项、选项和不确认影响，不能笼统说“需要确认”
 
 ## 空项目确认口径
 

package/templates/design//345/210/207/347/211/207/350/247/204/345/210/222.md

@@ -44,6 +44,10 @@ extra:
 4. **依赖有序**：被依赖的切片先做；循环依赖必须打破
 5. **爆炸半径可控**（改老系统）：每个切片可独立回滚，不牵连全局
 
+> **硬约束（design-gate SLICE-DIMENSION 兜底）**：骨架/基础设施切片 ≤ 2（超过 design verify 拦截）。多端项目合并为一个「全端骨架 + DB」切片，不每端一个骨架；其余切片必须垂直（端到端业务 前端→后端→DB）。
+>
+> **为什么必须垂直（shift-left 早验的结构前提）**：垂直切片每片端到端可独立跑 → slice-gate 每片能早验（SLICE-BUILD/UP/HTTP/E2E 交互 + 视觉局部自查）。横切（按端/技术层）单片跑不通全链路 → slice-gate 空转 → 所有早验失效、bug 积压到交付前。骨架无业务可验=验证空转，故限 ≤2（业界 walking skeleton 例外，通常 1）。
+
 ## 切片清单格式
 
 | 切片ID | 目标 | 涉及模块 | 上游依赖 | 主链路入口 | 验收标准 | 预估 |

package/templates/design//345/274/200/345/217/221/345/210/207/347/211/207/350/256/241/345/210/222.md

@@ -0,0 +1,76 @@
+---
+id: ka-artifact_template-开发切片计划
+kind: artifact
+title: 开发切片计划
+sync_policy: copy_to_project
+status: active
+extra:
+  name: development-slice-plan
+  scope:
+    - '*'
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.0.0
+  last_reviewed: '2026-06-21'
+  type: artifact_template
+  domain: design
+  owner_mechanism: mc-generic-artifact
+---
+
+# 开发切片计划
+
+> **产物定位**：design 域最后产出（架构设计完成后），把项目拆成可独立开发、独立验证的切片。
+> **核心纪律**：每个切片须引用架构 ARCH-* / DD-* / FE-*（承接设计），声明 AC-* 验收标准（可独立验证）。
+> **反退化纪律**：每个 `SLC-*` 必须完整重复其字段表格（目标/涉及 ARCH-*/涉及 DD-*/涉及 FE-*/变更文件/上游依赖/主链路入口/AC-* 验收标准/预估），禁止退化——
+> - 禁止「前详后废」（前几个切片完整、后面的退化成一行文字或省略字段）
+> - 禁止「（同上格式）」「见上文」「…」等偷懒占位（模板自身曾以此示范，已纠正）
+> - 字段表格不得用一行文字代替
+> 任一切片字段表不完整 = 未完成。
+> **下游**：build 域按切片顺序编码，每切片完成跑 slice-gate（docker 构建/部署/HTTP/E2E）。
+
+## PHASE-* 阶段划分
+
+| PHASE | 目标 | 包含切片 | 前置依赖 |
+|-------|------|----------|----------|
+| PHASE-1 | （如：核心链路打通） | SLC-01~SLC-03 | 无 |
+| PHASE-2 | （如：扩展功能） | SLC-04~SLC-06 | PHASE-1 |
+
+## SLC-* 切片清单
+
+### SLC-01 切片名称
+
+| 字段 | 内容 |
+|------|------|
+| 目标 | 本切片完成什么（一句话） |
+| 涉及 ARCH-* | 引用的架构模块 ID（如 ARCH-01/ARCH-03） |
+| 涉及 DD-* | 引用的设计产物 ID（如 DD-A01/DD-T02） |
+| 涉及 FE-* | 引用的前端端 ID（如 FE-client-01），纯后端切片填"无" |
+| 变更文件 | 本切片涉及的文件清单（预估） |
+| 上游依赖 | 前置切片（如无填"无"） |
+| 主链路入口 | 本切片验证的入口（如 POST /api/v1/users） |
+| AC-* 验收标准 | 切片完成的可验证条件（至少 1 条） |
+| 预估 | 复杂度（S/M/L） |
+
+### SLC-02 切片名称
+
+| 字段 | 内容 |
+|------|------|
+| 目标 | 本切片完成什么（一句话） |
+| 涉及 ARCH-* | 引用的架构模块 ID |
+| 涉及 DD-* | 引用的设计产物 ID |
+| 涉及 FE-* | 引用的前端端 ID（如 FE-admin-01），纯后端切片填"无" |
+| 变更文件 | 本切片涉及的文件清单 |
+| 上游依赖 | 前置切片（如无填"无"） |
+| 主链路入口 | 本切片验证的入口 |
+| AC-* 验收标准 | 切片完成的可验证条件（至少 1 条） |
+| 预估 | 复杂度（S/M/L） |
+
+## 完成判定
+
+- [ ] 每个 SLC 引用至少 1 个 ARCH-* 或 DD-*（承接设计）
+- [ ] 每个 SLC 声明至少 1 个 AC-* 验收标准（可独立验证）
+- [ ] 所有架构模块（ARCH-*）被至少 1 个 SLC 覆盖（XVAL-SLC 校验）
+- [ ] 所有前端端模块（FE-*）被至少 1 个骨架 SLC 覆盖（XVAL-SLC 校验 ARCH-*/FE-*；前端骨架切片含路由/状态/API service 壳）
+- [ ] 切片粒度可独立 docker 部署 + 浏览器验证（slice-gate 可执行）
+- [ ] 每个 SLC 字段表格完整（无偷懒占位、无一字段降级为文字）

package/templates/design//346/225/260/346/215/256/345/272/223/350/256/276/350/256/241/346/226/207/346/241/243.md

@@ -23,6 +23,7 @@ extra:
 
 > **产物定位**：涉及数据模型/建表时产出（按需）。把表结构、关系、敏感级别、迁移回滚定清楚。
 > **核心纪律**：字段映射精确到 表.字段；migration 成对（up+down）可回滚（[[兼容性与迁移评估]]）。
+> **反退化纪律**：标 `[Always]` 的表格（实体列表/表字段/约束索引/API映射/SQL证据等）必须逐条填充，禁止空表、禁止用一行文字代替表格、禁止「…」占位；表多时每张表都填全字段，不得「其余表同上」。
 > **完成判定**：见文末。
 
 > **根本目标引用**：本产物的 `fundamental_need` 见需求分析文档 §1.3。
@@ -137,3 +138,4 @@ extra:
 - [ ] migration 成对（up + down），回滚脚本已验证
 - [ ] 敏感字段标注敏感级别 + 保护方式
 - [ ] SQL 执行证据为真实运行结果（非静态分析）
+- [ ] 标 [Always] 的表格均已逐条填充，无空表/无文字代替/无「其余同上」占位

package/templates/design//346/236/266/346/236/204/350/256/276/350/256/241.md

@@ -24,6 +24,7 @@ extra:
 
 > **产物定位**：架构阶段（4 阶段第 2 步）的产出。把"怎么做"想清楚，承接需求分析的 fundamental_need。
 > **核心纪律**：每条架构决策须有 ADR 留痕（[[开发者宪法]]），技术选型须有依据而非凭主流（[[证据驱动与反幻觉]]），须考虑回滚/兼容/安全。
+> **反退化纪律**：模块划分/技术选型/风险登记 等表格与列表必须逐条填写，禁止「其余模块同上」「…」省略、禁止用一句话代替表格行。
 > **完成判定**：见文末。
 
 ## 1. 决策记录与范围
@@ -32,6 +33,9 @@ extra:
 - 输入证据引用：
 
 ## 2. 需求概要
+
+> 填需求分析 §2 的**真实 REQ 编号**（如 REQ-001，非占位符 REQ-NNN）。design-gate cross_validation 校验架构↔需求的 REQ-* 一致性+覆盖率。
+
 | REQ-ID | 需求摘要 | 对应架构模块 |
 |--------|---------|-------------|
 
@@ -72,6 +76,15 @@ extra:
 - 状态管理策略
 - 组件分层
 
+#### 端模块清单（承接需求 §9 系统形态，每端一个 FE-* 模块；无前端项目填「不适用」）
+
+| 端 ID（FE-*） | 端名称 | 项目目录 | 技术栈 | 职责 | 对应需求 §9 端 |
+|--------------|--------|---------|--------|------|--------------|
+| FE-client-01 | | client-portal | | | |
+| FE-shared | shared | shared | | 类型/API client/工具共享 | |
+
+> 端 ID **单段**命名（FE-client-01/FE-admin-01，禁多段横杠 FE-client-portal-01）——承接校验正则约束。「项目目录」是 build 域工程目录（`根/{目录}/src/`），build scope 据此放行写入；后端工程目录固定 `backend/`（§6.2）。XVAL-SLC 校验每个 FE-* 被切片覆盖；纯后端项目填「不适用」。
+
 ### 6.4 安全架构
 - 认证与授权方案
 - 数据加密策略
@@ -90,6 +103,15 @@ extra:
 > 选型须有依据（性能/成本/团队熟悉度/生态），禁止"业界主流所以选它"。详见 [[决策与选型]]。
 
 ## 8. 专项产物引用
+
+**产物适用性声明**（必填，XVAL 按此判定 database_design / api_specification 是否需产出）：
+- 数据库设计文档：____ — 依据：...（填「适用」或「不适用」；不适用例：纯前端无后端持久化；适用则下方填引用）
+- API接口规格文档：____ — 依据：...（填「适用」或「不适用」；不适用例：无对外 API / 纯内部模块；适用则下方填引用）
+
+> 列出本架构涉及的接口/表真实编号（cross_validation 校验 DD-A*/DD-T* 跨文档一致+覆盖率）：
+> - 接口 ID（对应 API 规格）：DD-A01、DD-A02 ...
+> - 表 ID（对应数据库设计）：DD-T01、DD-T02 ...
+
 - 数据库设计：`docs/design/01-数据库设计文档.md`
 - API 规格：`docs/design/02-API接口规格文档.md`
 - OpenAPI：`docs/api/openapi.yaml`
@@ -127,3 +149,5 @@ extra:
 - [ ] 含风险登记 + 回滚方案（RTO/RPO）
 - [ ] 跨横切关注点（日志/错误/缓存/配置）有方案
 - [ ] 引用的数据库/API 专项产物路径有效
+- [ ] §6.3 前端架构含端模块清单（FE-* ID，单段命名，承接需求 §9 端清单）
+- [ ] 模块/选型/风险等表格逐条填写，无「其余同上」省略、无一句话代替

package/templates/design//350/256/276/350/256/241/345/206/263/347/255/226/347/272/252/345/276/213.md

@@ -0,0 +1,58 @@
+---
+id: ka-guidance-设计决策纪律
+kind: guidance
+title: 设计决策纪律
+sync_policy: engine_only
+status: active
+triggers:
+  - 技术选型
+  - 决策记录
+  - 框架选型
+  - 中间件选型
+  - 数据库选型
+  - 改造
+  - 重构方案
+  - 选型变更
+  - 兼容性分析
+  - 回滚方案
+extra:
+  name: design-decision-discipline
+  scope:
+    - '*'
+  products:
+    - '*'
+  type: constraint
+  lifecycle_status: active
+  version: 1.0.0
+  domain: design
+  owner_mechanism: mc-workflow-contract
+---
+
+# 设计决策纪律
+
+> **来源**：从 design-gate 的 `DES-C-REVIEW`（semantic advisory，不阻断）拆出的**主观 / 须人确认**部分。
+> 确定性的（ADR 章节、选型依据）已并入 `ARCH-STRUCT` 硬检查；本文件承载**不可机器判定**的纪律——靠 triggers 注入 + AI/用户自觉。
+
+## 须用户确认（Agent 不得自动变更）
+
+- **重大技术选型状态变更**（换框架 / 换数据库 / 换中间件 / 换部署形态）须经**用户确认**，Agent 不得自行变更
+- 架构风格的根本性变更（如单体→微服务、同步→异步）须用户拍板
+- 确认方式：在对话框明确告知变更影响，等用户确认后才写入 ADR
+
+> 为何软：机器无法判定"是否经用户确认"（需对话记录）。靠本纪律提醒 Agent 主动确认。
+
+## 改老系统须兼容性分析（brownfield）
+
+- 改造已有系统前，须产出**兼容性分析**：影响哪些现有功能 / 接口 / 数据 / 调用方
+- 须有**回滚方案**：变更失败如何恢复（ARCH-STRUCT 的「风险与回滚」章节承载）
+- 兼容性分析可写入架构设计文档或 [[兼容性与迁移评估]]
+
+## 决策方法论（选型依据）
+
+- 技术选型须有**可证伪依据**：性能 / 成本 / 团队熟悉度 / 生态 / 已有架构约束
+- **禁止**仅凭"业界主流 / 大厂在用"作唯一依据
+- 每条决策在 ADR 记录：**上下文 → 候选方案 → 依据 → 结论**
+
+## 关联
+- 确定性部分（ADR 章节存在）→ `ARCH-STRUCT` 硬检查
+- [[决策与选型]]（选型方法论）/ [[兼容性与迁移评估]]（迁移分析）/ [[证据驱动与反幻觉]]（依据可证伪）

package/templates/design//350/256/276/350/256/241/350/264/250/351/207/217/350/246/201/347/202/271.md

@@ -0,0 +1,58 @@
+---
+id: ka-guidance-设计质量要点
+kind: guidance
+title: 设计质量要点
+sync_policy: engine_only
+status: active
+triggers:
+  - 非功能需求
+  - NFR
+  - 性能预算
+  - 可用性
+  - SLA
+  - 安全设计
+  - 威胁建模
+  - 权限模型
+  - 数据分类
+  - 设计质量
+extra:
+  name: design-quality-essentials
+  scope:
+    - '*'
+  products:
+    - '*'
+  type: constraint
+  lifecycle_status: active
+  version: 1.0.0
+  domain: design
+  owner_mechanism: mc-stage-gate-engine
+---
+
+# 设计质量要点
+
+> **为什么是软规则**：`document_structure` 只查章节**存在**，不查**内容质量**。以下是要点内容质量（NFR 是否真量化、安全设计是否充分）——机器难确定性判，靠本 guidance 注入 + cross-artifact 对抗审查（用户方/攻击方/合规方）复核。强行硬判会假覆盖。
+
+## NFR 须量化（非功能需求要有可测量数值）
+
+禁止模糊表述，须有**具体数值**：
+- 性能：响应 `< 3s`、QPS `>= 1000`、P99 `< 500ms`（非"快"/"高性能"）
+- 可用性：SLA `99.9%`、RTO `< 5min`、RPO `< 1min`
+- 安全：加密算法（AES-256）、密码策略、会话超时
+- 容量：用户数/数据量上限
+
+**对抗审查用户方复核**：NFR 是否真量化（有数值）；架构的 NFR 目标值是否与需求分析的 NFR 一致（避免需求 < 3s、架构写 < 5s 的漂移）。
+
+## 安全设计须有深度（不止"有章节"）
+
+`ARCH-STRUCT` 验证「安全架构」章节存在，但内容须覆盖：
+- **威胁建模**：关键资产的威胁路径与缓解
+- **权限模型**：认证/授权方案（RBAC/ABAC、数据权限）
+- **数据分类**：敏感数据识别 + 加密/脱敏/传输保护
+- **信任边界**：内外网边界、服务间信任、第三方接入
+
+**对抗审查攻击方/合规方复核**：安全设计是否真覆盖上述（非空章节/泛泛而谈）。
+
+## 关联
+- [[设计决策纪律]]（决策须 ADR + 用户确认）
+- [[证据驱动与反幻觉]]（NFR/安全依据可证伪）
+- cross-artifact 对抗审查：用户方（NFR 量化/一致）、攻击方（安全威胁）、合规方（安全规范）维度复核

package/templates/design//351/234/200/346/261/202/345/210/206/346/236/220.md

@@ -24,6 +24,7 @@ extra:
 
 > **产物定位**：需求阶段（4 阶段第 1 步）的产出。把"做什么"想清楚，不是"怎么做"。
 > **核心纪律**（[[工程执行总纲]]）：先暴露阻塞困惑，禁止把模糊需求直接转成方案；区分事实/假设/需确认。[[证据驱动与反幻觉]]：需求声明要有来源证据。
+> **反退化纪律**：功能点清单/非功能需求/角色 等表格必须逐条填写真实内容，禁止空表、禁止只填示例行后省略、禁止「…」占位。
 > **完成判定**：见文末，不满足不算交付。
 
 ## 1. 需求来源
@@ -86,10 +87,33 @@ confirmed_by: <!-- 用户确认标记，未确认不得进入实现 -->
 
 > 若系统无外部依赖，显式标注"本系统无外部接口依赖"。
 
+## 9. 系统形态与交付边界
+
+> 决定系统长什么样：是否前后端分离、几个端、各端技术栈。这是下游架构 §6.3 前端模块化（`FE-*` 端 ID）的依据，**须与用户研讨确认（非 AI 代决，属 must_confirm）**。
+> 纯后端 API 项目：形态填「纯后端 API」，端清单留空（REQ-DELIB 不强制研讨前端形态）。
+
+- 系统形态：纯后端 API / 前后端分离 / 多端 / 纯前端
+- 是否有前端：是/否
+
+### 端清单（有前端时逐端填写，每端对应架构 §6.3 一个 FE-* 端模块）
+
+| 端 ID（FE-*） | 端名称 | 形态 | 技术栈 | 职责 | 本期交付 |
+|--------------|--------|------|--------|------|---------|
+| FE-client-01 | | Web/移动/桌面 | | | 是/否 |
+
+> 端 ID 用**单段**命名（`FE-client-01`/`FE-admin-01`），不用多段（非 `FE-client-portal-01`）——承接校验正则约束。
+
+### 交付边界
+- 本期交付的端：
+- 后续迭代的端：
+- 前后端契约方式：RESTful / GraphQL / BFF
+
 ## 完成判定
 
+- [ ] §9 系统形态与交付边界已填写（形态/端清单/技术栈已与用户研讨确认；涉及前端时须有研讨记录）
 - [ ] `fundamental_need` 是用户目标而非解决方案，且 `confirmed_by` 已标记
 - [ ] 每个 REQ 有验收标准（可验证，非"功能正常"模糊表述）
 - [ ] 阻塞级未确认项已解决或已升级
 - [ ] NFR 有量化验收指标
 - [ ] 无证据的需求声明已标注来源/不确定
+- [ ] 各表格逐条填写真实内容，无空表/无示例行后省略/无「…」占位