soloforge 1.1.37 → 1.1.40

package/templates/procedures//345/212/237/350/203/275/345/274/200/345/217/221/346/265/201/347/250/213.md

@@ -1,25 +1,16 @@
 ---
 name: feature-development
 type: procedure
-when: '新功能开发, 需求实现, feature, 新增功能, 需求开发, 功能实现, 新建功能'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-功能开发流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-task-context-lifecycle
-routes:
-  - code_change
-primary_triggers:
-  - 功能开发流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-task-context-lifecycle
 emits:
@@ -27,9 +18,10 @@ emits:
   - api_contract_alignment
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["新功能开发","需求实现","feature","新增功能","需求开发","功能实现","新建功能"]
 ---
 
 ## 适用场景
@@ -40,13 +32,13 @@ stages: ["编码与单元测试", "联调验证"]
 2. 技术方案设计：确定接口契约（API 定义）、数据模型、技术选型
 3. 自主技术选型（若涉及架构级选型）：调用 sf_explore 检索行业基准 → 四维矩阵 → 证伪循环 → A/B 决策诱导 → 等待人类选择
 4. 前后端对齐：API 文档/接口契约评审，确认字段和状态流转
-4. 后端开发：按 crud-operation / api-pagination 等模式实现，先写接口再写逻辑
-5. 前端开发：按 react-component / react-api-integration 等模式实现页面和接口对接
-6. 单元测试：Service 层核心逻辑 + 前端关键组件
-7. 联调测试：前后端联调，验证完整流程
-8. 代码审查：使用 sf_review 检查质量/安全/性能
-9. 提测：部署到测试环境，执行验收标准
-10. 修复反馈问题后准备发布
+5. 后端开发：按 crud-operation / api-pagination 等模式实现，先写接口再写逻辑
+6. 前端开发：按 react-component / react-api-integration 等模式实现页面和接口对接
+7. **切片验证**：运行当前切片的单元测试 → 检查覆盖率（≥9 场景）→ 确认变更在涉及文件范围内 → 更新切片测试状态（pending→red→green→refactored）
+8. 联调测试：前后端联调，验证完整流程
+9. 代码审查：使用 sf_review 检查质量/安全/性能
+10. 提测：部署到测试环境，执行验收标准
+11. 修复反馈问题后准备发布
 
 ## 检查点
 - [ ] API 接口契约已对齐并文档化
@@ -55,6 +47,7 @@ stages: ["编码与单元测试", "联调验证"]
 - [ ] 前后端联调通过
 - [ ] 涉及技术选型时已通过 sf_explore 完成行业基准对齐
 - [ ] 交付物末尾已签署终局宣言
+- [ ] 切片验证点已执行（步骤 7）
 
 ## 注意事项
 - 接口契约先于实现（避免前端等后端）

package/templates/procedures//345/220/216/347/253/257/346/216/245/345/217/243/345/256/236/347/216/260/345/267/245/344/275/234/346/265/201.md

@@ -1,26 +1,15 @@
 ---
 name: backend-api-implementation
 type: procedure
-when: '后端接口, Controller, DTO, API实现, 数据写入'
 scope:
   - backend
 products:
   - '*'
 id: ka-procedure-后端接口实现工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-backend-implementation-contract
-routes:
-  - code_change
-  - artifact_generation
-primary_triggers:
-  - 后端接口实现工作流
-secondary_triggers:
-  - REST API
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-backend-implementation-contract
 emits:
@@ -31,6 +20,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试"]
+triggers: ["后端接口","Controller","DTO","API实现","数据写入"]
 ---
 
 ## 步骤

package/templates/procedures//345/221/275/344/273/244/346/211/247/350/241/214/346/265/201/347/250/213.md

@@ -5,18 +5,10 @@ scope:
 products:
   - '*'
 id: ka-procedure-命令执行流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-command-execution
-routes:
-  - code_change
-primary_triggers:
-  - 命令执行流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-tool-invocation-contract
 emits:
@@ -28,9 +20,10 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 type: procedure
-when: 命令执行流程
 stages: ["任务规划", "编码与单元测试"]
+triggers: ["命令执行流程"]
 ---
+
 # 命令执行流程
 
 ## 步骤

package/templates/procedures//345/221/275/344/273/244/350/267/257/347/224/261/346/265/201/347/250/213.md

@@ -0,0 +1,32 @@
+---
+name: command-routing-workflow
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-procedure-命令路由流程
+type: procedure
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-command-router
+priority: P1
+stages: ["任务规划", "编码与单元测试"]
+version: 1.0.0
+last_reviewed: '2026-06-02'
+---
+
+# 命令路由流程
+
+## 步骤
+
+1. 接收用户命令 (command)
+2. 状态机裁决命令类型和目标阶段
+3. 检查 command_state 是否有效
+4. 确定执行形状 (execution_shape)
+5. 如果 degraded=true，记录降级日志
+6. 传递给阶段执行器
+
+## 注意事项
+
+- 命令路由替代已废弃的意图路由
+- 快捷命令 (sf_direct_answer / sf_single_artifact) 绕过完整管线

package/templates/procedures//345/256/211/345/205/250/345/212/240/345/233/272/346/265/201/346/260/264/347/272/277.md

@@ -1,25 +1,16 @@
 ---
 name: security-hardening-pipeline
 type: pipeline_procedure
-when: '安全加固, 安全审计, 安全修复, 漏洞修复, 合规整改, 安全检查, 安全增强'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-安全加固流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-privacy-boundary
-routes:
-  - code_change
-primary_triggers:
-  - 安全加固流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-privacy-boundary
 emits:
@@ -31,29 +22,30 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["安全加固","安全审计","安全修复","漏洞修复","合规整改","安全检查","安全增强"]
 ---
 
 # 安全加固管线
 
-### 第1步：安全审计
+## 第1步：安全审计
 扫描现有代码和配置的安全漏洞（OWASP Top 10 维度）。检查认证授权机制的完整性。检查数据加密和脱敏策略。检查第三方依赖的已知漏洞。
 模版：安全审计模版.md
 产出保存到：.soloforge/output/01-安全审计.md
-工具：sf_classify, sf_analyze
+工具：sf_command, sf_analyze
 
-### 第2步：方案设计
+## 第2步：方案设计
 按风险等级（Critical/High/Medium/Low）排序修复优先级。针对每个漏洞设计修复方案。评估修复对现有功能的影响。确定合规要求（数据加密/审计日志/访问控制）。
 产出保存到：.soloforge/output/02-修复方案.md
 
-### 第3步：安全修复
+## 第3步：安全修复
 按优先级逐个修复安全漏洞。每个修复后回归验证功能无影响。禁止降级安全等级来通过测试。
-工具：sf_expand
+工具：sf_stage_execute
 
-### 第4步：验证验收
+## 第4步：验证验收
 重新扫描确认漏洞已修复。代码审查专注安全维度。学习记录（漏洞类型、修复模式、预防规则）。
-工具：sf_verify, sf_review, sf_learn
+工具：sf_gate_check, sf_review, sf_stage_advance
 
-### 第5步：深度安全扫描
+## 第5步：深度安全扫描
 运行依赖漏洞扫描（npm audit / OWASP Dependency-Check），高危漏洞阻断构建。运行容器镜像扫描（Trivy / Snyk），检测基础镜像已知漏洞。检查生产环境配置（禁用 debug 模式、关闭 actuator 暴露端点、验证 HTTPS 强制）。
 
 ## 检查点

package/templates/procedures//345/267/245/345/205/267/350/260/203/347/224/250/346/265/201/347/250/213.md

@@ -5,18 +5,10 @@ scope:
 products:
   - '*'
 id: ka-procedure-工具调用流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-tool-invocation-contract
-routes:
-  - code_change
-primary_triggers:
-  - 工具调用流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-workflow-contract
 emits:
@@ -28,9 +20,10 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 type: procedure
-when: 工具调用流程
 stages: ["任务规划", "编码与单元测试"]
+triggers: ["工具调用流程"]
 ---
+
 # 工具调用流程
 
 ## 步骤

package/templates/procedures//346/200/247/350/203/275/346/265/201/346/260/264/347/272/277.md

@@ -1,25 +1,16 @@
 ---
 name: performance-pipeline
 type: pipeline_procedure
-when: '性能优化, 慢查询, 内存泄漏, 首屏优化, 性能问题, 响应慢, 超时优化, 性能调优'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-性能流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-metric-governance
-routes:
-  - code_change
-primary_triggers:
-  - 性能流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-metric-governance
 emits:
@@ -31,24 +22,25 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["性能优化","慢查询","内存泄漏","首屏优化","性能问题","响应慢","超时优化","性能调优"]
 ---
 
 # 性能优化管线
 
-### 第1步：性能定位
+## 第1步：性能定位
 量化性能指标（当前值/目标值）。定位瓶颈（慢查询/内存/CPU/网络/前端渲染）。收集证据（APM/慢查询日志/浏览器 DevTools/压测数据）。确定优化优先级（收益/成本排序）。
 模版：性能分析模版.md
 产出保存到：.soloforge/output/01-性能分析.md
-工具：sf_classify, sf_analyze
+工具：sf_command, sf_analyze
 
-### 第2步：方案设计
+## 第2步：方案设计
 针对瓶颈设计优化方案（索引优化/SQL 重写/缓存/连接池/异步/分页/懒加载）。评估方案影响范围和风险。确定可衡量的优化目标。
 产出保存到：.soloforge/output/02-优化方案.md
 
-### 第3步：优化实施
+## 第3步：优化实施
 按优先级逐步实施，每步优化后重新测量性能指标。禁止一次改多处再测量。保持优化前后功能行为一致。
-工具：sf_expand
+工具：sf_stage_execute
 
-### 第4步：效果验证
+## 第4步：效果验证
 对比优化前后的性能指标。全量测试确认无功能回归。代码审查关注：优化是否引入新问题、缓存一致性、并发安全。
-工具：sf_verify, sf_review, sf_learn
+工具：sf_gate_check, sf_review, sf_stage_advance

package/templates/procedures//346/204/217/345/233/276/350/267/257/347/224/261/346/265/201/347/250/213.md

@@ -1,22 +1,16 @@
 ---
+deprecated: true
+deprecated_note: 此模版已由 mc-command-router (命令路由) 替代。保留仅为向后兼容。
 name: intent-routing-workflow
 scope:
   - '*'
 products:
   - '*'
 id: ka-procedure-意图路由流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-owner_mechanism_id: mc-intent-router
-routes:
-  - code_change
-primary_triggers:
-  - 意图路由流程
-secondary_triggers: []
-negative_triggers: []
+owner_mechanism_id: mc-command-router
 priority: P1
-specificity: 5
 consumes:
   - mc-classifier
 emits:
@@ -27,9 +21,10 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 type: procedure
-when: 意图路由流程
 stages: ["任务规划", "编码与单元测试"]
+triggers: ["意图路由流程"]
 ---
+
 # 意图路由流程
 
 ## 步骤

package/templates/procedures//346/216/245/345/217/243/351/233/206/346/210/220/346/265/201/346/260/264/347/272/277.md

@@ -1,25 +1,16 @@
 ---
 name: api-integration-pipeline
 type: pipeline_procedure
-when: '第三方接口对接, 外部服务集成, API集成, 接口联调, 服务对接, 第三方API'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-接口集成流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-artifact-contract
-routes:
-  - code_change
-primary_triggers:
-  - 接口集成流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-artifact-contract
 emits:
@@ -28,33 +19,40 @@ emits:
   - integration_test_result
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["第三方接口对接","外部服务集成","API集成","接口联调","服务对接","第三方API"]
 ---
 
 # 接口对接管线
 
-### 第1步：契约分析
+## 第1步：契约分析
 梳理第三方 API 能力清单（认证方式、请求/响应格式、错误码、限流配额、沙箱环境）。识别核心交互场景和数据映射关系。
 模版：接口对接方案模版.md
 产出保存到：.soloforge/output/01-接口对接方案.md
-工具：sf_classify
+工具：sf_command
 
-### 第2步：适配层实现
+## 第2步：适配层实现
 实现统一的 API 客户端封装（超时、重试、熔断、日志）。定义请求/响应 DTO 映射。配置 Mock 方案（沙箱/本地 Mock）支持独立开发。错误码映射为业务异常。
-工具：sf_expand, sf_scaffold
+工具：sf_stage_execute, sf_scaffold
 
-### 第3步：联调测试
+## 第3步：联调测试
 使用 Mock 环境验证基本流程。切换到沙箱环境验证真实交互。覆盖：正常流程、网络超时、服务端错误、限流响应、数据格式异常。
 模版：测试计划模版.md
-工具：sf_verify
+工具：sf_gate_check
 
-### 第4步：验收上线
+## 第3a步：沙箱→生产差异记录
+
+| 差异项 | 沙箱行为 | 生产预期 | 风险评估 | 验证计划 |
+|--------|---------|---------|---------|---------|
+| | | | | |
+
+## 第4步：验收上线
 代码审查重点：超时配置、错误处理、敏感信息、日志脱敏。生产配置确认（URL、密钥、限流参数）。监控告警配置（调用成功率、响应时间）。
-工具：sf_review, sf_verify, sf_deliver
+工具：sf_review, sf_gate_check, sf_stage_advance
 
-### 第5步：契约管理与监控增强
+## 第5步：契约管理与监控增强
 定义接口契约（OpenAPI/Swagger），明确请求/响应格式、错误码、版本号。编写接口 Mock 服务，前后端并行开发。接口变更必须更新文档并通知消费方，给予充足迁移时间。集成测试覆盖正常流 + 异常流（超时、错误响应、边界值）。接口上线后配置监控告警（响应时间 P99、错误率、调用量）。
 
 ## 检查点

package/templates/procedures//346/225/260/346/215/256/345/272/223/350/277/201/347/247/273/346/265/201/347/250/213.md

@@ -1,24 +1,15 @@
 ---
 name: database-migration
 type: procedure
-when: '数据库变更, 表结构修改, migration, DDL, 加字段, 建表, 索引, 数据迁移, 表结构变更'
 scope:
   - backend
 products:
   - '*'
 id: ka-procedure-数据库迁移流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-knowledge-asset-governance
-routes:
-  - code_change
-primary_triggers:
-  - 数据库迁移流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-knowledge-asset-governance
 emits:
@@ -30,6 +21,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["数据库变更","表结构修改","migration","DDL","加字段","建表","索引","数据迁移","表结构变更"]
 ---
 
 ## 适用场景

package/templates/procedures//346/234/254/345/234/260/346/265/217/350/247/210/345/231/250/351/252/214/346/224/266/345/267/245/344/275/234/346/265/201.md

@@ -1,7 +1,6 @@
 ---
 name: local-browser-acceptance-workflow
 type: procedure
-when: '本地验收, 浏览器验收, Docker 验收, 本地测试, local acceptance, browser test, docker compose'
 scope:
   - backend
   - frontend
@@ -36,17 +35,9 @@ acceptance_checks:
   - FinalLocalReviewAccess 包含 frontend_urls/backend_urls/docs_or_swagger_urls
   - validateFinalAccess passed
 id: ka-procedure-本地浏览器验收工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-routes:
-  - code_change
-primary_triggers:
-  - 本地浏览器验收工作流
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-local-acceptance
 emits:
@@ -58,6 +49,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["联调验证"]
+triggers: ["本地验收","浏览器验收","Docker 验收","本地测试","local acceptance","browser test","docker compose"]
 ---
 
 ## 适用场景

package/templates/procedures//346/236/266/346/236/204/345/206/263/347/255/226/347/240/224/350/256/250/345/267/245/344/275/234/346/265/201.md

@@ -1,7 +1,6 @@
 ---
 name: architecture-decision-workshop
 type: procedure
-when: '架构设计, 技术架构, 系统设计, 平台建设, 服务拆分'
 scope:
   - backend
   - frontend
@@ -10,17 +9,11 @@ products:
   - '*'
 owner_mechanism_id: mc-architecture-decision-workshop
 id: ka-procedure-architecture-decision-workshop
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-routes:
-  - artifact_generation
-primary_triggers:
-  - 架构决策研讨
 priority: P0
-specificity: 5
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 required_evidence:
   - architecture_decision_workshop
   - user_confirmation_ref
@@ -28,10 +21,13 @@ consumes:
   - user_intent
   - project_context_detection
   - existing_system_analysis
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
 emits:
   - architecture_decision_workshop
   - docs/architecture/00-架构决策记录.md
 stages: ["架构设计"]
+triggers: ["架构设计","技术架构","系统设计","平台建设","服务拆分"]
 ---
 
 # 架构决策研讨工作流
@@ -40,6 +36,9 @@ stages: ["架构设计"]
 
 1. 判断项目为现有系统、新系统、空项目或重构升级。
 2. 现有系统先获取现状与差距证据；空项目先确认业务目标和约束。
+2a. **头脑风暴触发**：若方案选项 ≥ 3 个且无明确最优，或 AI 自检不确定：
+   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴流程.md）
+   → 若 fundamental_need 为空 → 先触发 FP-01
 3. 默认按业务流程、数据、安全、后端、前端、基础设施逐域讨论。
 4. 每域提供方案、推荐、风险与需要确认的问题；确认后记录 decision ref。
 5. 全部必要域确认后生成 `docs/architecture/00-架构决策记录.md`。

package/templates/procedures//346/236/266/346/236/204/350/256/276/350/256/241/345/267/245/344/275/234/346/265/201.md

@@ -1,7 +1,6 @@
 ---
 name: architecture-design-workflow
 type: procedure
-when: '架构设计, 架构, architecture, 设计系统, 多端设计, 系统设计, 技术方案设计, 模块划分, 技术方案, 方案设计, 架构评审'
 scope:
   - backend
   - frontend
@@ -25,6 +24,9 @@ required_sections:
   - 不确定项决策
   - Mermaid 图要求
   - 架构设计审查
+  - 约束条件分析
+  - NFR 启发与权衡
+  - 架构范式选择
 hard_rules:
   - 正式架构设计前必须完成六类架构决策研讨并引用用户确认的决策记录
   - 架构设计必须进入包含数据库、API、OpenAPI/SQL 和一致性报告的设计产物包复验流程
@@ -43,19 +45,13 @@ acceptance_checks:
   - Mermaid 图 render_check_status 为 passed
   - 架构设计审查 review.passed 为 true
 id: ka-procedure-架构设计工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-routes:
-  - code_change
-primary_triggers:
-  - 架构设计工作流
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-architecture-design
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
 emits:
   - architecture_design_contract
   - design_artifact_pack
@@ -63,9 +59,10 @@ emits:
 required_evidence:
   - workflow_id
   - required_mechanisms
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["架构设计", "详细设计"]
+triggers: ["架构设计","架构","architecture","设计系统","多端设计","系统设计","技术方案设计","模块划分","技术方案","方案设计","架构评审"]
 ---
 
 ## 适用场景
@@ -74,16 +71,25 @@ stages: ["架构设计", "详细设计"]
 ## 步骤
 1. **输入集确认**: 识别所有 task-* 目录下的原型说明及需求文档，确认覆盖所有端
 2. **架构决策研讨**: 逐域闭合业务流程、数据、安全、后端、前端和基础设施决策，生成 `00-架构决策记录.md`
+   - 每条决策使用 MADR 格式记录（标题/状态/上下文/决策/候选方案/理由/后果）
+   - ADR 状态管理：Proposed → Accepted → Superseded（被新 ADR 替代时标注 Superseded-By）
+   - 跨域权衡检测：某个域的决策可能影响其他域时，自动标记需重新确认的域
+2a. **头脑风暴触发**：若架构决策存在 ≥ 3 个候选方案且无明确最优，或 AI 自检不确定：
+   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴流程.md）
+   → 若 fundamental_need 为空 → 先触发 FP-01
+2b. **约束条件分析**: 读取需求文档中的约束、技术栈限制、合规要求，按技术/组织/法规/预算分类填充 Ch3a
 3. **输出目录决策**: 给出推荐目录名，等待用户确认
 4. **技术栈策略**:
    - 后端默认 Java 优先（项目证据或用户确认可 override）
    - 前端默认最新稳定 Vue 生态 + TypeScript（语言、构建工具、路由、状态管理、接口类型、测试、lint/format）
    - 项目已有技术栈优先于 SoloForge 默认
+4a. **架构范式选择**（可选）: 参考七范式栈启发式菜单（DDD/Clean Architecture/Hexagonal/Modular Monolith/GRASP/SOLID/ADR），Agent 推荐 + 用户选择，填充 Ch4a。跳过条件：用户明确表示不需要范式指导
 5. **前端仓库策略**: 不同前端端默认不同仓库；合并仓库需用户确认
 6. **不确定项决策**: 每个不确定项包含推荐、理由、备选、风险和用户确认问题
 7. **架构级不确定项**: 接入 Brainstorm → Decision Sovereignty → User Confirmation
 8. **设计产物包**: 架构、数据库、API、OpenAPI/SQL 和一致性报告按权威来源联动生成/升级
 9. **Mermaid 图**: 关键业务流程、登录鉴权、跨端协作、前后端交互、异步任务必须有 sequenceDiagram
+9a. **NFR 启发与权衡**: 按 4 类 13+ 质量属性启发（性能/可靠性/安全性/可维护性），每项 NFR 须有量化目标值 + 验证方式，填充 Ch10.1 性能预算表 + Ch10.4 验证策略表
 10. **架构设计审查**: reviewArchitectureDesign 与 DesignArtifactPack 真实复验通过
 
 ## 检查点
@@ -95,6 +101,9 @@ stages: ["架构设计", "详细设计"]
 - [ ] Mermaid sequenceDiagram 覆盖关键流程
 - [ ] reviewArchitectureDesign passed
 - [ ] 设计产物包进入 implementation_ready
+- [ ] 约束条件 4 类各至少 1 条
+- [ ] NFR 每项有量化目标值
+- [ ] 架构范式选择（若启用）有用户确认
 
 ## 禁止退化
 - 未确认目录不得 delivered
@@ -102,3 +111,5 @@ stages: ["架构设计", "详细设计"]
 - 六类决策未确认或设计产物包未复验不得 completed
 - 架构级决策无 human gate 不得 approved
 - 模版章节缺失不得 completed
+- ADR 状态变更未经用户确认不得推进
+- 六域确认后不得推翻已确认域的决策（推翻须记录 ADR 并重新确认受影响域）