soloforge 1.4.16 → 2.0.0

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

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

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

@@ -0,0 +1,41 @@
+---
+name: tool-invocation-workflow
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-procedure-工具调用流程
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-tool-invocation-contract
+priority: P1
+consumes:
+  - mc-workflow-contract
+emits:
+  - tool_invocation_result
+  - tool_trace
+required_evidence:
+  - tool_trace
+  - invocation_violations
+version: 1.1.0
+last_reviewed: '2026-06-01'
+type: procedure
+stages: ["任务规划", "编码与单元测试"]
+triggers: ["工具调用流程"]
+---
+
+# 工具调用流程
+
+## 步骤
+
+1. 接收工具调用请求 (tool_name, arguments)
+2. 在 Tool Invocation Contract Registry 中查找工具契约
+3. 检查当前调用链是否违反 forbidden_next_tools
+4. 检查 strict_controlled 工具的前置审批
+5. 执行工具调用
+6. 记录 tool_trace
+
+## 注意事项
+
+- 只读工具可自由调用，不受转换约束
+- 工具调用失败时记录到 task_context

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

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

@@ -0,0 +1,42 @@
+---
+deprecated: true
+deprecated_note: 此模版已由 mc-command-router (命令路由) 替代。保留仅为向后兼容。
+name: intent-routing-workflow
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-procedure-意图路由流程
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-command-router
+priority: P1
+consumes:
+  - mc-classifier
+emits:
+  - route_decision
+required_evidence:
+  - route_decision
+  - execution_shape
+version: 1.1.0
+last_reviewed: '2026-06-01'
+type: procedure
+stages: ["任务规划", "编码与单元测试"]
+triggers: ["意图路由流程"]
+---
+
+# 意图路由流程
+
+## 步骤
+
+1. 接收用户意图 (intent)
+2. 调用 routeIntent(intent) 获取 route_decision
+3. 检查 route_decision.route 是否为有效路由
+4. 检查 route_decision.execution_shape 是否匹配路由
+5. 将 route_decision 传递给 classifier 和 intent_expander
+6. 如果 degraded=true，记录降级日志
+
+## 注意事项
+
+- classifier 只提供兼容字段，不能修改 route_decision
+- intent_expander 必须基于 route_decision 生成 prompt

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

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

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

@@ -0,0 +1,56 @@
+---
+name: database-migration
+type: procedure
+scope:
+  - backend
+products:
+  - '*'
+id: ka-procedure-数据库迁移流程
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-knowledge-asset-governance
+priority: P1
+consumes:
+  - mc-knowledge-asset-governance
+emits:
+  - migration_script
+  - rollback_script
+  - migration_compatibility_check
+required_evidence:
+  - execution_evidence
+version: 1.1.0
+last_reviewed: '2026-06-01'
+stages: ["编码与单元测试", "联调验证"]
+triggers: ["数据库变更","表结构修改","migration","DDL","加字段","建表","索引","数据迁移","表结构变更"]
+---
+
+## 适用场景
+数据库表结构变更（新增表、加字段、改字段、加索引、数据迁移等）。所有 DDL 变更必须通过 migration 脚本管理，禁止手动执行。
+
+## 步骤
+1. 评估变更类型：加列、改列、删列、加索引、数据迁移、新建表
+2. 确认向前兼容性：新列必须有默认值或允许 NULL，不删除正在使用的列
+3. 编写 migration 脚本（Flyway/MyBatis Migrations），DDL 脚本放 resources/db，文件名 V{version}__{description}.sql（正向）和 U{version}__{description}.sql（回滚）
+4. 确保 migration 脚本幂等（重复执行不出错）
+5. 编写回滚脚本（每个 migration 必须有对应的 rollback）
+6. 禁止在 migration 脚本中写业务逻辑（业务变更走应用代码）
+7. 大表加列必须指定默认值或使用分批更新
+8. 在开发环境执行 migration，验证表结构变更正确
+9. 检查数据迁移逻辑：大数据量迁移需分批执行（每批 1000 条）
+10. 在测试环境验证：运行应用 + 执行全量测试
+11. 评估执行时间：大表加索引按锁表风险处理，需在低峰期执行并准备回滚窗口
+12. 生产执行前备份数据库（全量或变更表）
+
+## 检查点
+- [ ] migration 脚本有对应回滚脚本
+- [ ] migration 脚本幂等（可重复执行）
+- [ ] 新增列有默认值或允许 NULL（向前兼容）
+- [ ] migration 脚本无业务逻辑
+- [ ] 大数据量迁移使用分批策略
+- [ ] 生产执行前已完成数据库备份
+
+## 注意事项
+- 禁止使用 DROP COLUMN（应标记为 deprecated 后续清理）
+- 加索引在 >100 万行表上使用 ONLINE DDL 或 pt-online-schema-change
+- migration 脚本一旦执行到生产不可修改（只能新增补偿脚本）
+- 字段兼容策略必须同时覆盖四层：数据库、接口契约、前端展示、导出逻辑

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

@@ -0,0 +1,90 @@
+---
+name: local-browser-acceptance-workflow
+type: procedure
+scope:
+  - backend
+  - frontend
+  - infrastructure
+products:
+  - '*'
+owner_mechanism_id: mc-local-acceptance
+consumed_contracts:
+  - local_acceptance_contract_entry
+  - coding_readiness_contract_entry
+  - detail_discipline_contract
+required_sections:
+  - 服务运行规格
+  - 浏览器验收计划
+  - 修复循环策略
+  - 最终访问交付
+hard_rules:
+  - 有可运行前端/全栈服务时，不得只停在单测、静态检查或审查报告
+  - 项目已有 docker-compose 时必须优先使用
+  - 必须识别 frontend、backend、database、env、ports 和 health checks
+  - 服务启动后必须等待 container healthy、backend health、frontend reachable
+  - >-
+    浏览器验收失败必须 capture → classify → map owner → repair → rebuild → redeploy →
+    rerun
+  - 最终必须给用户本地可访问 URL、运行状态、启动/停止命令
+  - 未给最终本地 URL 不得 delivered
+acceptance_checks:
+  - requiresLocalAcceptance 判断正确
+  - ServiceRuntimeSpec 已识别所有服务
+  - 浏览器验收计划覆盖任务相关页面和路由
+  - 修复循环策略包含 max_iterations 和 stop_conditions
+  - FinalLocalReviewAccess 包含 frontend_urls/backend_urls/docs_or_swagger_urls
+  - validateFinalAccess passed
+id: ka-procedure-本地浏览器验收工作流
+lifecycle_status: active
+authority: supporting
+priority: P1
+consumes:
+  - mc-local-acceptance
+emits:
+  - browser_acceptance_report
+  - service_urls
+required_evidence:
+  - workflow_id
+  - required_mechanisms
+version: 1.1.0
+last_reviewed: '2026-06-01'
+stages: ["联调验证"]
+triggers: ["本地验收","浏览器验收","Docker 验收","本地测试","local acceptance","browser test","docker compose"]
+---
+
+## 适用场景
+含前端/全栈服务的项目完成开发后，必须在本地启动服务并通过浏览器验收。适用于有 docker-compose、npm start 或类似启动方式的项目。
+
+## 步骤
+1. **判断是否需要本地验收**: requiresLocalAcceptance 判断
+2. **服务运行规格**:
+   - 识别 frontend、backend、database/cache、env、ports、health checks
+   - docker-compose 优先，否则用项目启动命令
+3. **启动服务**:
+   - 启动所有服务
+   - 等待 container healthy、backend health endpoint、frontend reachable、DB migrated
+   - 检查 logs 无关键错误、port open
+4. **浏览器验收**:
+   - 覆盖任务相关页面、路由、核心交互
+   - API 联动、登录/权限、错误提示、空状态/loading
+   - 检查控制台关键错误和 network 关键失败
+5. **失败处理** (修复循环):
+   - capture failure → classify failure → map owner files
+   - repair within scope → rebuild → redeploy → rerun
+   - retry budget 内循环；超预算 → manual_required
+6. **最终交付**:
+   - 给用户 frontend/backend/docs/swagger 本地 URL
+   - 给用户运行状态、启动/停止命令、测试账号说明、人工查验步骤、未覆盖风险
+
+## 检查点
+- [ ] requiresLocalAcceptance 判断正确
+- [ ] 所有服务启动且 healthy
+- [ ] 浏览器验收覆盖关键页面
+- [ ] 修复循环有预算和停止条件
+- [ ] 最终 URL 交付完整
+
+## 禁止退化
+- 不得只停在单测或审查报告
+- 无 URL 不得 delivered
+- CI 环境无 Docker 时 not_applicable_with_reason，但不能把 runnable 项目判为 delivered
+- retry budget 超出或 scope 不足必须 manual_required

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

@@ -0,0 +1,50 @@
+---
+name: architecture-decision-workshop
+type: procedure
+scope:
+  - backend
+  - frontend
+  - infrastructure
+products:
+  - '*'
+owner_mechanism_id: mc-architecture-decision-workshop
+id: ka-procedure-architecture-decision-workshop
+lifecycle_status: active
+authority: supporting
+priority: P0
+version: 1.2.0
+last_reviewed: '2026-06-04'
+required_evidence:
+  - architecture_decision_workshop
+  - user_confirmation_ref
+consumes:
+  - user_intent
+  - project_context_detection
+  - existing_system_analysis
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
+emits:
+  - architecture_decision_workshop
+  - docs/architecture/00-架构决策记录.md
+stages: ["架构设计"]
+triggers: ["架构设计","技术架构","系统设计","平台建设","服务拆分"]
+---
+
+# 架构决策研讨工作流
+
+## 顺序
+
+1. 判断项目为现有系统、新系统、空项目或重构升级。
+2. 现有系统先获取现状与差距证据；空项目先确认业务目标和约束。
+2a. **头脑风暴触发**：若方案选项 ≥ 3 个且无明确最优，或 AI 自检不确定：
+   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴流程.md）
+   → 若 fundamental_need 为空 → 先触发 FP-01
+3. 默认按业务流程、数据、安全、后端、前端、基础设施逐域讨论。
+4. 每域提供方案、推荐、风险与需要确认的问题；确认后记录 decision ref。
+5. 全部必要域确认后生成 `docs/architecture/00-架构决策记录.md`。
+6. 仅以该决策记录驱动正式架构设计与设计产物包。
+
+## 失败处理
+
+- 缺证据、缺确认或决策返工时，停止生成正式文档并说明下一项待决事项。
+- 不得用模版默认值或模型偏好替代项目事实与用户决定。

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

@@ -0,0 +1,115 @@
+---
+name: architecture-design-workflow
+type: procedure
+scope:
+  - backend
+  - frontend
+  - infrastructure
+products:
+  - '*'
+owner_mechanism_id: mc-architecture-design
+consumed_contracts:
+  - architecture_decision_workshop_contract
+  - design_artifact_pack_contract
+  - architecture_design_contract_entry
+  - technology_decision_contract
+  - brainstorm_contract
+  - detail_discipline_contract
+  - first_principles_contract
+required_sections:
+  - 输入集确认
+  - 输出目录决策
+  - 技术栈策略
+  - 前端仓库策略
+  - 不确定项决策
+  - Mermaid 图要求
+  - 架构设计审查
+  - 约束条件分析
+  - NFR 启发与权衡
+  - 架构范式选择
+hard_rules:
+  - 正式架构设计前必须完成六类架构决策研讨并引用用户确认的决策记录
+  - 架构设计必须进入包含数据库、API、OpenAPI/SQL 和一致性报告的设计产物包复验流程
+  - 输出目录名必须给推荐并进入用户确认；未确认时不得 delivered
+  - 后端必须默认优先 Java，除非存在项目证据或用户确认 override
+  - 前端必须默认优先最新稳定 Vue 生态 + TypeScript，除非存在项目证据或用户确认 override
+  - 不同前端端必须默认不同项目仓库或独立应用边界；合并仓库必须用户确认
+  - 不确定项必须包含推荐、理由、备选、风险和用户确认问题
+  - 架构级不确定项必须接 Brainstorm / Decision Sovereignty / User Confirmation
+  - 关键业务流程必须有 Mermaid sequenceDiagram
+  - Mermaid 必须可渲染
+acceptance_checks:
+  - ArchitectureDesignContract 已创建且 status 非 pending
+  - 输出目录决策 status 为 confirmed
+  - 所有 required_source_artifacts 已覆盖
+  - Mermaid 图 render_check_status 为 passed
+  - 架构设计审查 review.passed 为 true
+id: ka-procedure-架构设计工作流
+lifecycle_status: active
+authority: supporting
+priority: P1
+consumes:
+  - mc-architecture-design
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
+emits:
+  - architecture_design_contract
+  - design_artifact_pack
+  - architecture_decision_records
+required_evidence:
+  - workflow_id
+  - required_mechanisms
+version: 1.2.0
+last_reviewed: '2026-06-04'
+stages: ["架构设计", "详细设计"]
+triggers: ["架构设计","架构","architecture","设计系统","多端设计","系统设计","技术方案设计","模块划分","技术方案","方案设计","架构评审"]
+---
+
+## 适用场景
+从多个 task 输入（原型说明、需求文档等）到完整架构设计产出的工作流。适用于多端、多模块、有不确定项的系统设计。
+
+## 步骤
+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 真实复验通过
+
+## 检查点
+- [ ] 所有 task-* 输入已识别并覆盖
+- [ ] 六类架构决策均已确认并记录 decision refs
+- [ ] 输出目录已用户确认
+- [ ] 技术栈有项目证据或用户确认支撑
+- [ ] 不确定项全部有推荐和用户确认问题
+- [ ] Mermaid sequenceDiagram 覆盖关键流程
+- [ ] reviewArchitectureDesign passed
+- [ ] 设计产物包进入 implementation_ready
+- [ ] 约束条件 4 类各至少 1 条
+- [ ] NFR 每项有量化目标值
+- [ ] 架构范式选择（若启用）有用户确认
+
+## 禁止退化
+- 未确认目录不得 delivered
+- 缺少 Mermaid 图不得 completed
+- 六类决策未确认或设计产物包未复验不得 completed
+- 架构级决策无 human gate 不得 approved
+- 模版章节缺失不得 completed
+- ADR 状态变更未经用户确认不得推进
+- 六域确认后不得推翻已确认域的决策（推翻须记录 ADR 并重新确认受影响域）

package/templates/procedures//346/246/202/345/277/265/351/252/214/350/257/201/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,45 @@
+---
+name: poc-pipeline
+type: pipeline_procedure
+scope:
+  - backend
+  - frontend
+products:
+  - '*'
+id: ka-procedure-概念验证流水线
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-brainstorm-contract
+priority: P1
+consumes:
+  - mc-brainstorm-contract
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
+emits:
+  - poc_research_report
+  - poc_prototype
+  - poc_conclusion
+required_evidence:
+  - execution_evidence
+version: 1.1.0
+last_reviewed: '2026-06-01'
+stages: ["架构设计"]
+triggers: ["技术验证","POC","可行性验证","技术选型","技术调研","原型验证","spike"]
+---
+
+# 技术验证管线
+
+## 第1步：调研分析
+明确验证目标和成功标准。调研候选方案的生态成熟度、社区活跃度、性能基准、与现有技术栈兼容性。列出关键评估维度和权重。
+产出保存到：.soloforge/output/01-调研报告.md
+工具：sf_command
+
+## 第2步：原型实现
+选择 1-2 个最有前景的方案实现最小原型。原型聚焦核心验证点，不追求完整功能。记录实现过程中的关键发现（坑、限制、惊喜）。
+工具：sf_stage_execute, sf_scaffold
+
+## 第3步：评估结论
+对比各方案在关键维度的表现（附量化数据）。给出推荐方案和理由。列出遗留风险和后续关注点。明确结论：推荐采用/需进一步验证/不建议采用。
+模版：POC结论模版.md
+产出保存到：.soloforge/output/03-POC结论.md
+工具：sf_gate_check, sf_stage_advance