soloforge 1.1.46 → 1.1.48

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,75 @@
+---
+id: ka-artifact-开发切片计划
+kind: artifact
+title: 开发切片计划
+sync_policy: copy_to_project
+status: active
+extra:
+  name: development-slice-plan
+  scope:
+    - '*'
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.0.0
+  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

@@ -11,8 +11,8 @@ extra:
     - backend
   products:
     - '*'
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
+  version: 2.0.0
+  last_reviewed: '2026-06-17'
   type: artifact
   domain: design
   stage: design
@@ -21,9 +21,14 @@ extra:
 
 # 数据库设计文档
 
-> **根本目标引用**：本产物的 `fundamental_need` 见需求分析文档 §1.3。若未声明，引用审查规则 FP-01。
+> **产物定位**：涉及数据模型/建表时产出（按需）。把表结构、关系、敏感级别、迁移回滚定清楚。
+> **核心纪律**：字段映射精确到 表.字段；migration 成对（up+down）可回滚（[[兼容性与迁移评估]]）。
+> **反退化纪律**：标 `[Always]` 的表格（实体列表/表字段/约束索引/API映射/SQL证据等）必须逐条填充，禁止空表、禁止用一行文字代替表格、禁止「…」占位；表多时每张表都填全字段，不得「其余表同上」。
+> **完成判定**：见文末。
 
-## 1. 目标数据库与权威 SQL [Always — 必填]
+> **根本目标引用**：本产物的 `fundamental_need` 见需求分析文档 §1.3。
+
+## 1. 目标数据库与权威 SQL [Always]
 
 | 项目 | 内容 |
 |------|------|
@@ -35,119 +40,102 @@ extra:
 | 上游架构文档路径 | |
 | 上游需求文档路径 | |
 
-## 2. 实体与关系 [Always — 必填，P0 最关键章节]
+## 2. 实体与关系 [Always — P0 最关键]
 
 ### 2.1 实体列表
-> 每个表须分配唯一表编号 `DD-T01`/`DD-T02`...（供切片计划/代码审查引用，cross_validation 据此校验一致性+覆盖）
-> 「来源需求/架构章节」列须填 `REQ-*`（需求编号）/`ARCH-*`（架构决策）真实编号（供 cross_validation 校验与需求分析一致），禁止仅写自然语言描述
+> 每个表分配唯一编号 `DD-T01`/`DD-T02`...（供切片/审查引用）
+> 「来源需求/架构章节」填 `REQ-*`/`ARCH-*` 真实编号
 
 | 表编号 | 实体名 | 中文名 | 业务含义 | 来源需求/架构章节 | 估计记录量级 |
 |--------|--------|--------|----------|-------------------|-------------|
-| DD-T01 | <!-- 实体名 --> | <!-- 中文名 --> | <!-- 业务含义 --> | <!-- REQ-001/ARCH-01 --> | <!-- 量级 --> |
 
 ### 2.2 关系定义
 | 关系编号 | 父实体 | 子实体 | 关系类型 | 基数 | 外键字段 | 级联行为 | 说明 |
 |----------|--------|--------|----------|------|----------|----------|------|
-<!-- 按实际填写 -->
-关系类型枚举：关联 / 组合 / 聚合
-基数枚举：1:1 / 1:N / M:N
+
+关系类型：关联 / 组合 / 聚合；基数：1:1 / 1:N / M:N
 
 ### 2.3 ER 图
-> 推荐 Mermaid erDiagram 语法
+> 推荐 Mermaid erDiagram
 
 ## 3. 表字段与敏感级别
 
 | 表 | 字段 | 类型 | 可空 | 默认值 | 业务含义 | 敏感级别 | 生命周期 |
 |----|------|------|------|--------|----------|----------|----------|
 
-## 4. 约束、索引与查询场景 [Always — 必填]
+## 4. 约束、索引与查询场景 [Always]
 
 ### 4.1 约束定义
 | 表名 | 约束名 | 约束类型 | 约束字段 | 约束条件 | 错误提示 |
 |------|--------|----------|----------|----------|----------|
-<!-- 按实际填写 -->
-约束类型枚举：PRIMARY KEY / UNIQUE / FOREIGN KEY / CHECK / NOT NULL / DEFAULT
+
+约束类型：PRIMARY KEY / UNIQUE / FOREIGN KEY / CHECK / NOT NULL / DEFAULT
 
 ### 4.2 索引定义
 | 表名 | 索引名 | 索引类型 | 字段列表 | 查询场景 | 创建理由 | 预估基数 |
 |------|--------|----------|----------|----------|----------|----------|
-<!-- 按实际填写 -->
-索引类型枚举：PRIMARY / UNIQUE / BTREE / HASH / GIN / GIST / COMPOSITE / PARTIAL
 
 ### 4.3 高频查询场景
 | 查询编号 | 查询场景 | 涉及表 | 查询条件 | 排序/分页 | 优化策略 |
 |----------|----------|--------|----------|-----------|----------|
-<!-- 按实际填写 -->
 
-## 5. 租户、安全、审计与数据生命周期 [Ask first — 多租户/敏感数据场景必填]
+## 5. 租户、安全、审计与数据生命周期 [多租户/敏感数据时必填]
 
 ### 5.1 租户隔离策略
 | 表名 | 隔离方式 | 租户字段 | 隔离级别 | 说明 |
 |------|----------|----------|----------|------|
-<!-- 按实际填写 -->
 
 ### 5.2 敏感数据保护
 | 字段路径 | 敏感级别 | 加密方式 | 脱敏规则 | 访问控制 | 合规要求 |
 |----------|----------|----------|----------|----------|----------|
-<!-- 按实际填写 -->
 
 ### 5.3 审计字段
 | 表名 | 创建时间字段 | 更新时间字段 | 创建人字段 | 更新人字段 | 软删除字段 |
 |------|-------------|-------------|-----------|-----------|-----------|
-<!-- 按实际填写 -->
 
 ### 5.4 数据生命周期
 | 数据类型 | 保留期限 | 归档策略 | 清理策略 | 合规依据 |
 |----------|----------|----------|----------|----------|
-<!-- 按实际填写 -->
 
-## 6. Migration、回滚、备份恢复 [Always — 必填]
+## 6. Migration、回滚、备份恢复 [Always]
 
 ### 6.1 Migration 脚本清单
 | 序号 | Migration 文件名 | 变更类型 | 涉及表 | 前置依赖 | 回滚脚本 |
 |------|-----------------|----------|--------|----------|----------|
-<!-- 按实际填写 -->
-变更类型枚举：CREATE_TABLE / ALTER_TABLE / ADD_COLUMN / DROP_COLUMN / ADD_INDEX / DATA_MIGRATION
+
+变更类型：CREATE_TABLE / ALTER_TABLE / ADD_COLUMN / DROP_COLUMN / ADD_INDEX / DATA_MIGRATION
 
 ### 6.2 回滚验证
 | Migration | 回滚命令 | 回滚验证 SQL | 预期结果 |
 |-----------|----------|-------------|----------|
-<!-- 按实际填写 -->
 
 ### 6.3 数据备份策略
 | 场景 | 备份方式 | 备份频率 | 恢复 RTO | 恢复 RPO |
 |------|----------|----------|----------|----------|
-<!-- 按实际填写 -->
 
-## 7. API/DTO 至字段映射表 [Always — 必填]
+## 7. API/DTO 至字段映射表 [Always]
 
 | API Endpoint | HTTP Method | 请求字段 | 映射表.字段 | 响应字段 | 映射表.字段 | DTO 类名 |
 |--------------|-------------|----------|------------|----------|------------|----------|
-<!-- 按实际填写 -->
 
-> 每个 API 字段必须精确追踪到数据库表.字段，无映射的字段标注"计算字段"/"外部服务"/"缓存"。
+> 每个 API 字段必须追踪到 表.字段，无映射的标注"计算字段"/"外部服务"/"缓存"。
 
-## 8. 真实验证证据与未决项 [Always — 必填]
+## 8. 真实验证证据 [Always]
 
 ### 8.1 SQL 执行证据
 | 验证项 | 执行 SQL | 预期结果 | 实际结果 | 状态 |
 |--------|----------|----------|----------|------|
-<!-- 按实际填写 -->
 
 ### 8.2 范式自检
 | 表名 | 函数依赖 | 当前范式 | 是否满足 3NF | 修正建议 |
 |------|----------|----------|-------------|----------|
-<!-- 按实际填写 -->
-
-### 8.3 字段映射覆盖自检
-| 检查项 | 覆盖状态 | 缺失说明 |
-|--------|----------|----------|
-| 所有 API 字段已追踪到数据库字段 | <!-- 是/否 --> | <!-- 按实际填写 --> |
-| 所有数据库字段已被至少一个 API 引用 | <!-- 是/否 --> | <!-- 按实际填写 --> |
-| 所有外键关系已在 Ch2 定义 | <!-- 是/否 --> | <!-- 按实际填写 --> |
-| 所有索引已在 Ch4 定义且覆盖高频查询 | <!-- 是/否 --> | <!-- 按实际填写 --> |
-
-### 8.4 未决项
-| 编号 | 未决项 | 不确定分级 | 候选方案 | 状态 |
-|------|--------|-----------|----------|------|
-<!-- 按实际填写 -->
+
+## 完成判定
+
+- [ ] 所有 API 字段已追踪到 表.字段
+- [ ] 所有外键关系已在 §2 定义
+- [ ] 所有索引已定义且覆盖高频查询
+- [ ] migration 成对（up + down），回滚脚本已验证
+- [ ] 敏感字段标注敏感级别 + 保护方式
+- [ ] SQL 执行证据为真实运行结果（非静态分析）
+- [ ] 标 [Always] 的表格均已逐条填充，无空表/无文字代替/无「其余同上」占位

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

@@ -12,8 +12,8 @@ extra:
   products:
     - '*'
   lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
+  version: 2.0.0
+  last_reviewed: '2026-06-17'
   type: artifact
   domain: design
   stage: design
@@ -22,34 +22,27 @@ extra:
 
 # 架构设计文档
 
-## 1. 决策记录、范围与证据
-- 架构决策记录引用：`docs/architecture/00-架构决策记录.md`
-- 用户确认引用：
-- 输入证据引用：
-
-> **根本目标引用**：本产物的 `fundamental_need` 见需求分析文档 §1.3。若未声明，引用审查规则 FP-01。
+> **产物定位**：架构阶段（4 阶段第 2 步）的产出。把"怎么做"想清楚，承接需求分析的 fundamental_need。
+> **核心纪律**：每条架构决策须有 ADR 留痕（[[开发者宪法]]），技术选型须有依据而非凭主流（[[证据驱动与反幻觉]]），须考虑回滚/兼容/安全。
+> **反退化纪律**：模块划分/技术选型/风险登记 等表格与列表必须逐条填写，禁止「其余模块同上」「…」省略、禁止用一句话代替表格行。
+> **完成判定**：见文末。
 
-## 2. 六类架构决策状态总表
-
-| 架构域 | 状态 | 结论 | decision_id | user_confirmation_ref | 影响产物 |
-|--------|------|------|-------------|-----------------------|----------|
+## 1. 决策记录与范围
+- 架构决策记录：`docs/architecture/00-架构决策记录.md`
+- 根本目标引用：需求分析 §1.3 `fundamental_need`
+- 输入证据引用：
 
-## 3. 需求概要
+## 2. 需求概要
 
-### 3.1 系统角色与关注点
-| 角色 | 关注点 | 说明 |
-|------|--------|------|
+> 填需求分析 §2 的**真实 REQ 编号**（如 REQ-001，非占位符 REQ-NNN）。design-gate cross_validation 校验架构↔需求的 REQ-* 一致性+覆盖率。
 
-### 3.2 功能需求引用
-> 引用需求分析阶段的 REQ-* ID，附摘要
 | REQ-ID | 需求摘要 | 对应架构模块 |
 |--------|---------|-------------|
 
-### 3.3 非功能需求清单
 | NFR-ID | 类别 | 指标 | 目标值 | 验证方式 |
 |--------|------|------|-------|---------|
 
-## 3a. 约束条件
+## 3. 约束条件
 | 约束类型 | 描述 | 来源 | 影响范围 |
 |---------|------|------|---------|
 | 技术约束 | | | |
@@ -59,53 +52,38 @@ extra:
 
 ## 4. 模块划分
 - 模块清单与职责边界
-- 模块间依赖关系图
+- 模块间依赖关系
 - 核心接口契约（模块间调用方式）
 
-## 4a. 架构范式选择（可选）
-
-### 参考范式清单
-| 范式 | 解决什么问题 | 典型适用场景 |
-|------|------------|------------|
-| DDD | 业务边界划分 | 业务领域复杂 |
-| Clean Architecture | 依赖方向控制 | 中大型系统 |
-| Hexagonal | 外部依赖隔离 | 多接入方式 |
-| Modular Monolith | 模块边界 | 不确定是否微服务 |
-| GRASP | 职责归属 | 代码组织混乱 |
-| SOLID | 代码质量 | 所有项目 |
-| ADR | 决策可追溯 | 所有中大型项目 |
-
-### 本项目采用的范式
-| 范式 | 适用范围 | 关键约束 | 决策引用 |
-|------|---------|---------|---------|
-| （仅列出选择采用的） | | | |
-
-### 偏差处理
-选择的范式如需偏离，须在 Ch1 ADR 中记录偏离原因。
-
-## 5. 业务流程、数据流向与关键 Mermaid 时序图
-- 主流程数据流向图
-- 关键数据结构定义
+## 5. 业务流程与数据流向
+- 主流程数据流向图（Mermaid）
+- 核心业务流程时序图（每个核心流程一张，请求入口→持久化→响应完整链路）
 - 数据存储方案（数据库/缓存/文件）
 
-## 6. 前端、后端、安全与基础设施架构
+## 6. 架构组成
 
-### 6.1 系统上下文（C4 Level 1）
-- 系统边界与外部系统交互图
+### 6.1 系统上下文（C4 L1）
+- 系统边界与外部系统交互
 - 用户角色与接入方式
-- 外部依赖清单
 
-### 6.2 后端架构（C4 Level 2-3）
+### 6.2 后端架构（C4 L2-3）
 - 服务拆分与职责
 - 核心接口契约
 - 数据存储方案
-- **核心业务流程系统实现时序图**（每个核心业务流程必须有一张 Mermaid sequenceDiagram，
-  展示从请求入口到持久化到响应的完整调用链）
 
-### 6.3 前端架构（C4 Level 2-3）
+### 6.3 前端架构（C4 L2-3）
 - 应用结构与路由
 - 状态管理策略
-- 组件分层方案
+- 组件分层
+
+#### 端模块清单（承接需求 §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 安全架构
 - 认证与授权方案
@@ -113,17 +91,27 @@ extra:
 - 安全边界与信任域
 
 ### 6.5 基础设施与部署
-- 部署架构图
+- 部署架构
 - 环境规划（开发/测试/预发/生产）
 - CI/CD 策略
-- 监控与告警方案
+- 监控告警
 
 ## 7. 技术选型与依据
 | 技术决策 | 候选方案 | 最终选择 | 选择理由 | 放弃方案原因 |
 |---------|---------|---------|---------|------------|
-|         |         |         |         |            |
 
-## 8. 数据库与 API 专项产物引用
+> 选型须有依据（性能/成本/团队熟悉度/生态），禁止"业界主流所以选它"。详见 [[决策与选型]]。
+
+## 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`
@@ -133,39 +121,33 @@ extra:
 - 核心业务状态流转
 - 触发条件、守卫条件、失败/回滚动作
 
-## 10. 非功能需求、验证策略、风险与回滚
-
-### 10.1 性能预算与质量目标
-| 类别 | 指标 | 目标值 | 测量方式 | 关联 ADR |
-|------|------|-------|---------|---------|
+## 10. 风险与回滚（必填）
 
-### 10.2 风险登记
-| RISK-ID | 风险描述 | 概率 | 影响 | 应对方案 | 关联 ADR | 状态 |
-|---------|---------|------|------|---------|---------|------|
+### 10.1 风险登记
+| RISK-ID | 风险描述 | 概率 | 影响 | 应对方案 | 关联 ADR |
+|---------|---------|------|------|---------|---------|
 
-### 10.3 回滚与灾难恢复
+### 10.2 回滚与灾难恢复
 | 场景 | RTO | RPO | 恢复策略 | 触发条件 |
 |------|-----|-----|---------|---------|
 
-### 10.4 验证策略
-| NFR-ID | 验证方法 | 验证时机 | 通过标准 |
-|--------|---------|---------|---------|
+> 任何上线变更必须有回滚方案（[[开发者宪法]]）。
 
-## 11. 未决项、延期影响和变更追踪
-
-## 12. 扩展点
-- 已识别的未来扩展方向
-- 预留的扩展机制（接口/配置/插件）
-
-## 13. 跨横切关注点
+## 11. 跨横切关注点
 | 关注点 | 方案 | 影响模块 |
 |--------|------|---------|
 | 日志与审计 | | |
 | 错误处理 | | |
 | 缓存策略 | | |
-| 国际化/本地化 | | |
 | 配置管理 | | |
 
-## 14. 术语表
-| 术语 | 定义 | 来源 |
-|------|------|------|
+## 完成判定
+
+- [ ] 每条架构决策有对应 ADR，重大选型经用户确认
+- [ ] 约束条件覆盖技术/组织/法规/预算
+- [ ] 含安全架构（认证/授权/加密）
+- [ ] 含风险登记 + 回滚方案（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 量化/一致）、攻击方（安全威胁）、合规方（安全规范）维度复核