soloforge 1.1.42 → 1.1.43

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

@@ -0,0 +1,185 @@
+---
+id: 架构设计
+kind: guidance
+title: 架构设计
+sync_policy: copy_to_project
+status: active
+triggers:
+  - 架构设计规则
+  - 架构规则
+  - architecture rule
+  - 架构红线
+  - 系统架构
+  - 模块划分
+  - 服务边界
+  - 跨模块调用
+  - 服务拆分
+  - 技术架构
+  - 平台建设
+extra:
+  name: architecture-design
+  type: constraint
+  scope:
+    - '*'
+  products:
+    - '*'
+  priority: P1
+  domain:
+    - design
+    - build
+    - verify
+  lifecycle_status: active
+  hard_blocks:
+    - 必要架构决策域未确认时生成正式架构设计文档
+    - 现有系统无现状与差距证据时声称架构完成
+  required_evidence:
+    - architecture_decision_workshop
+    - user_confirmation_ref
+  fallback: manual_required
+  verification_layer: L2
+  stage: design
+  owner_mechanism: mc-command-router
+---
+
+# 架构设计规则（设计域治理规则）
+
+> 合并自：架构设计.md + 架构决策研讨.md + 架构红线.md（3 件套职责重叠，统一为设计域治理规则）。
+>
+> **档位标注**（每条规则的可执行档位，对应 SoloForge 三档强制执行体系）：
+> - **A 档** = regex_pattern_scan 单行可判（命中=违规，仅适用「禁止 X」类规则）
+> - **B 档** = external_command（委托成熟工具做 AST 依赖图/行数/项目级存在性检查，不自造解析器）
+> - **C 档** = semantic（LLM 评判，advisory 不阻断，通过 Reflexion 反馈闭环改进）
+>
+> 关键约束：regex_pattern_scan 单行匹配 + 命中=违规，故「必须包含 X」「依赖方向」类检查无法用 regex，须归 B/C 档。
+
+## 架构决策研讨硬底线（原「架构决策研讨规则」并入）
+
+- 正式架构文档生成前必须覆盖业务流程、数据架构、安全架构、后端架构、前端架构、基础设施六类决策域。
+- 每个必要域必须记录事实和约束、候选方案、推荐理由、风险和用户确认引用。
+- 现有系统必须先引用现状分析和差距分析证据；空项目必须先确认目标、端范围和非功能约束。
+- 任一必要域为未开始、讨论中、待确认或返工状态时，只能输出讨论清单或明确的不可执行草案。
+- 决策变化必须将受影响设计产物标记为需要重新验证。
+
+### 低风险边界
+普通缺陷修复、样式或文案调整、只读解释不触发完整六域研讨；涉及契约、数据、安全、部署或重大模块边界变化时重新触发。
+
+- ADR-HARD-01: 每条架构决策必须有对应 ADR，禁止口头决策不留记录【C 档｜流程约束】
+- ADR-HARD-02: ADR 状态变更必须经用户确认，Agent 不得自动变更状态【C 档｜流程约束】
+- ADR-HARD-03: 已 Accepted 的 ADR 被推翻时，必须创建新 ADR 并标注 Superseded-By【A 档｜document_structure 可检测 Superseded-By 标记】
+- ADR-HARD-04: 跳过决策研讨必须用户明确声明，Agent 不得自行跳过【C 档｜流程约束】
+
+## 架构决策要求
+
+- 每个架构决策必须有 ADR（Architecture Decision Record）引用
+- ADR 必须包含：决策背景、候选方案、选择理由、影响范围
+- 重大架构变更（涉及 ≥3 个模块）必须经过决策研讨阶段确认
+
+## 技术选型要求
+
+- 技术选型必须列出至少 2 个候选方案
+- 每个候选方案必须列出优势和劣势
+- 最终选择必须有明确的理由说明（性能/成本/团队熟悉度/生态成熟度等）
+- 禁止仅凭"业界主流"作为选型理由
+- ARCH-MOD-04: 技术选型须有 NFR 量化对比【C 档｜LLM 评判量化合理性】
+  格式：{候选技术} {NFR维度} {量化指标} {数据来源}
+  示例：Redis vs Memcached 缓存命中率 >99.9% 基准测试报告
+
+## 技术选型格式要求
+
+- ARCH-TECH-01: 技术选型决策必须包含以下字段【B 档｜document_structure 检查文档字段存在性】
+  - 候选方案（≥2 个）
+  - 评估维度（性能/成熟度/团队熟悉度/社区活跃度/许可证）
+  - 评分矩阵（每维度 1-5 分）
+  - 最终选择 + 理由
+  - 关联 ADR-ID
+
+## 架构图要求
+
+- Mermaid 图必须反映实际模块关系，不得省略关键依赖
+- 每个模块的职责边界必须明确标注
+- 跨模块调用必须标注调用方向和数据流
+- 部署架构图必须包含所有基础设施组件
+
+## 模块依赖方向
+
+> 依赖方向类检查无法用 regex_pattern_scan（需 AST 跨文件 import 分析），统一委托外部成熟工具。
+
+- ARCH-DEP-01: 模块间依赖必须遵循分层架构方向（上层→下层，禁止反向依赖）【B 档｜external_command: Java→ArchUnit, JS/TS→dependency-cruiser】
+  检查方式：AST 依赖图分析（ArchUnit layeredArchitecture / dependency-cruiser no-controller-to-dao）
+  例外：通过依赖注入/事件解耦的反向调用不计入
+- ARCH-DEP-02: 循环依赖禁止（A→B→C→A）【B 档｜external_command: ArchUnit beFreeOfCycles / dependency-cruiser no-circular】
+  检查方式：依赖图环检测
+  例外：无
+- ARCH-DEP-03: 跨层直接访问禁止（表现层不得直接访问数据层）【B 档｜external_command: dependency-cruiser no-utils-to-feature / ArchUnit 分层规则】
+  检查方式：import/require 链分析
+  例外：工具函数/类型定义可跨层引用
+
+## Mermaid 图类型约束
+
+> 「必须使用 X 图类型」是存在性检查（命中=通过），regex_pattern_scan 命中=违规语义不适用，归 B 档（document_structure/grep 检测）。
+
+- ARCH-MER-01: 系统上下文必须使用 C4Context 或 deploymentDiagram【B 档｜document_structure】
+- ARCH-MER-02: 模块交互必须使用 graph (flowchart) 或 componentDiagram【B 档｜document_structure】
+- ARCH-MER-03: 时序交互必须使用 sequenceDiagram【B 档｜document_structure】
+- ARCH-MER-04: 状态流转必须使用 stateDiagram-v2【B 档｜document_structure】
+
+## 架构红线禁令（原「架构红线」并入）
+
+> 12 条架构红线禁令。按可执行性分档：禁止类代码 pattern 归 A 档（regex 命中=违规）；跨行/语义类归 B/C 档。
+
+### 语义/流程类禁令（C 档｜LLM 评判，Reflexion 反馈闭环）
+
+- 禁止绕过统一认证和数据范围控制直接暴露业务接口
+- 禁止通过 Patch JAR、docker commit 或运行时文件替换交付代码
+- 禁止前端、Controller 或定时任务跨服务边界直接访问持久化实现
+- 禁止将事务、认证、金额、库存、安全策略或数据库 Schema 变更打包为"小修改"而无设计追溯
+- 禁止菜单可见性与接口可调用性解耦（菜单隐藏但接口暴露，或菜单存在但无权限支撑）
+- 禁止异步消息、定时任务或补偿逻辑绕过主路径审计和幂等控制
+- 所有新增写操作必须有可追溯的审计记录
+
+### 跨行/深度检查类禁令（B 档｜external_command 成熟工具）
+
+- 禁止在循环内执行数据库操作（N+1），必须使用批量查询【与 verify-gate PER-01 同源，深度检查迁 B 档】
+- 禁止在事务内执行远程调用（HTTP/RPC），防止长事务锁表【跨行检查迁 B 档: checkstyle 自定义规则】
+
+### 代码 pattern 类禁令（A 档｜regex_pattern_scan 单行命中=违规）
+
+## ARCH-RED-01: 空 catch 块静默吞异常
+pattern: /catch\s*\([^)]*\)\s*\{\s*\}/
+severity: error
+check_type: deterministic
+executor: regex_pattern_scan
+scope: backend
+description: 禁止 catch 后空处理（同行空块），至少记录日志并标注忽略原因。多行空 catch 块单行 regex 不可靠，须 B 档 checkstyle 补充
+evidence_required:
+  - "扫描结果：含空 catch 块的文件路径+行号"
+
+## ARCH-RED-02: 直接使用 new Date() 获取时间
+pattern: /new\s+Date\s*\(\s*\)/
+severity: warning
+check_type: deterministic
+executor: regex_pattern_scan
+scope: backend
+description: 禁止直接 new Date()，必须通过时钟服务注入便于测试
+evidence_required:
+  - "扫描结果：含 new Date() 的文件路径+行号"
+
+## ARCH-RED-03: Service 层注入 HttpServletRequest/Response
+pattern: /(?:HttpServletRequest|HttpServletResponse)\s/
+severity: warning
+check_type: deterministic
+executor: regex_pattern_scan
+scope: backend
+description: 禁止 Service 层注入 Servlet API，保持层级清晰。与 verify-gate ARC-08 同源 pattern（本规则归设计红线，ARC-08 归代码审查，双重覆盖）
+evidence_required:
+  - "扫描结果：Service 层引用 Servlet API 的文件路径+行号"
+
+### 验收项
+
+- [AC-01] 业务接口经过统一认证
+- [AC-02] 无跨边界直接持久化访问
+- [AC-03] 菜单与接口权限同步定义
+- [AC-04] 写操作有审计记录
+- [AC-05] 无循环内数据库调用
+- [AC-06] 无事务内远程调用
+- [AC-07] 无空 catch 块

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

@@ -0,0 +1,149 @@
+---
+id: ka-procedure-架构设计工作流
+kind: guidance
+title: 架构设计
+sync_policy: copy_to_project
+status: active
+triggers:
+  - design
+  - 架构
+  - architecture
+  - 设计系统
+  - 多端设计
+  - 系统设计
+  - 技术方案设计
+  - 模块划分
+  - 技术方案
+  - 方案设计
+  - 架构评审
+  - 技术架构
+  - 平台建设
+  - 服务拆分
+extra:
+  name: architecture-design-workflow
+  type: procedure
+  scope:
+    - backend
+    - frontend
+    - infrastructure
+  products:
+    - '*'
+  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
+  lifecycle_status: active
+  authority: supporting
+  priority: P1
+  consumes:
+    - mc-architecture-design
+    - user_intent
+    - project_context_detection
+    - existing_system_analysis
+    - 不确定时头脑风暴流程
+    - 第一性原理推理规则
+  emits:
+    - architecture_design_contract
+    - design_artifact_pack
+    - architecture_decision_records
+    - architecture_decision_workshop
+  required_evidence:
+    - workflow_id
+    - required_mechanisms
+    - architecture_decision_workshop
+    - user_confirmation_ref
+  version: 1.2.0
+  last_reviewed: '2026-06-04'
+  domain: design
+  verification_layer: L2
+  stage: design
+  owner_mechanism: mc-architecture-design
+---
+
+## 适用场景
+从多个 task 输入（原型说明、需求文档等）到完整架构设计产出的工作流。适用于多端、多模块、有不确定项的系统设计。原「架构决策研讨工作流」已内联并入步骤 2 的研讨子流程。
+
+## 步骤
+1. **输入集确认**: 识别docs/analyze/目录下所有的原型说明及docs/context/目录下的需求文档，确认覆盖所有端
+2. **架构决策研讨**: 逐域闭合业务流程、数据、安全、后端、前端和基础设施决策，生成 `docs/architecture/00-架构决策记录.md`
+   - 每条决策使用 MADR 格式记录（标题/状态/上下文/决策/候选方案/理由/后果）
+   - ADR 状态管理：Proposed → Accepted → Superseded（被新 ADR 替代时标注 Superseded-By）
+   - 跨域权衡检测：某个域的决策可能影响其他域时，自动标记需重新确认的域
+   - **研讨子流程**（原「架构决策研讨工作流」内联，六步闭合决策）:
+     2.1 判断项目为现有系统、新系统、空项目或重构升级
+     2.2 现有系统先获取现状与差距证据；空项目先确认业务目标和约束
+     2.3 默认按业务流程、数据、安全、后端、前端、基础设施逐域讨论
+     2.4 每域提供方案、推荐、风险与需要确认的问题；确认后记录 decision ref
+     2.5 全部必要域确认后生成 `docs/architecture/00-架构决策记录.md`
+     2.6 仅以该决策记录驱动正式架构设计与设计产物包
+   - **失败处理**: 缺证据、缺确认或决策返工时，停止生成正式文档并说明下一项待决事项；不得用模版默认值或模型偏好替代项目事实与用户决定
+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 真实复验通过
+
+## 检查点
+- [ ] 六类架构决策均已确认并记录 decision refs
+- [ ] 输出目录已用户确认
+- [ ] 技术栈有项目证据或用户确认支撑
+- [ ] 不确定项全部有推荐和用户确认问题
+- [ ] Mermaid sequenceDiagram 覆盖关键流程
+- [ ] reviewArchitectureDesign passed
+- [ ] 设计产物包进入 implementation_ready
+- [ ] 约束条件 4 类各至少 1 条
+- [ ] NFR 每项有量化目标值
+- [ ] 架构范式选择（若启用）有用户确认
+
+## 禁止退化
+- 未确认目录不得 delivered
+- 缺少 Mermaid 图不得 completed
+- 六类决策未确认或设计产物包未复验不得 completed
+- 架构级决策无 human gate 不得 approved
+- 模版章节缺失不得 completed
+- ADR 状态变更未经用户确认不得推进
+- 六域确认后不得推翻已确认域的决策（推翻须记录 ADR 并重新确认受影响域）

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

@@ -0,0 +1,187 @@
+---
+id: ka-artifact_template-架构设计模版
+kind: artifact
+title: 架构设计
+sync_policy: copy_to_project
+status: active
+extra:
+  name: architecture-design
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  lifecycle_status: active
+  authority: supporting
+  priority: P2
+  version: 1.2.0
+  last_reviewed: '2026-06-04'
+  consumes:
+    - requirement_analysis
+    - prototype_spec
+    - tech_decision_record
+  emits:
+    - docs/architecture/01-架构设计文档.md
+    - acceptance_report
+  type: artifact
+  domain: design
+  companions:
+    rules:
+      - '架构设计.md:execute'
+      - '架构审查.md:review'
+      - '第一性原理推理.md:review'
+    guides: []
+  requires_context: []
+  stage: design
+  owner_mechanism: mc-generic-artifact
+---
+
+# 架构设计文档
+
+## 1. 决策记录、范围与证据
+- 架构决策记录引用：`docs/architecture/00-架构决策记录.md`
+- 用户确认引用：
+- 输入证据引用：
+
+> **根本目标引用**：本产物的 `fundamental_need` 见需求分析文档 §1.3。若未声明，引用审查规则 FP-01。
+
+## 2. 六类架构决策状态总表
+
+| 架构域 | 状态 | 结论 | decision_id | user_confirmation_ref | 影响产物 |
+|--------|------|------|-------------|-----------------------|----------|
+
+## 3. 需求概要
+
+### 3.1 系统角色与关注点
+| 角色 | 关注点 | 说明 |
+|------|--------|------|
+
+### 3.2 功能需求引用
+> 引用需求分析阶段的 REQ-* ID，附摘要
+| REQ-ID | 需求摘要 | 对应架构模块 |
+|--------|---------|-------------|
+
+### 3.3 非功能需求清单
+| NFR-ID | 类别 | 指标 | 目标值 | 验证方式 |
+|--------|------|------|-------|---------|
+
+## 3a. 约束条件
+| 约束类型 | 描述 | 来源 | 影响范围 |
+|---------|------|------|---------|
+| 技术约束 | | | |
+| 组织约束 | | | |
+| 法规/合规约束 | | | |
+| 预算/时间约束 | | | |
+
+## 4. 模块划分
+- 模块清单与职责边界
+- 模块间依赖关系图
+- 核心接口契约（模块间调用方式）
+
+## 4a. 架构范式选择（可选）
+
+### 参考范式清单
+| 范式 | 解决什么问题 | 典型适用场景 |
+|------|------------|------------|
+| DDD | 业务边界划分 | 业务领域复杂 |
+| Clean Architecture | 依赖方向控制 | 中大型系统 |
+| Hexagonal | 外部依赖隔离 | 多接入方式 |
+| Modular Monolith | 模块边界 | 不确定是否微服务 |
+| GRASP | 职责归属 | 代码组织混乱 |
+| SOLID | 代码质量 | 所有项目 |
+| ADR | 决策可追溯 | 所有中大型项目 |
+
+### 本项目采用的范式
+| 范式 | 适用范围 | 关键约束 | 决策引用 |
+|------|---------|---------|---------|
+| （仅列出选择采用的） | | | |
+
+### 偏差处理
+选择的范式如需偏离，须在 Ch1 ADR 中记录偏离原因。
+
+## 5. 业务流程、数据流向与关键 Mermaid 时序图
+- 主流程数据流向图
+- 关键数据结构定义
+- 数据存储方案（数据库/缓存/文件）
+
+## 6. 前端、后端、安全与基础设施架构
+
+### 6.1 系统上下文（C4 Level 1）
+- 系统边界与外部系统交互图
+- 用户角色与接入方式
+- 外部依赖清单
+
+### 6.2 后端架构（C4 Level 2-3）
+- 服务拆分与职责
+- 核心接口契约
+- 数据存储方案
+- **核心业务流程系统实现时序图**（每个核心业务流程必须有一张 Mermaid sequenceDiagram，
+  展示从请求入口到持久化到响应的完整调用链）
+
+### 6.3 前端架构（C4 Level 2-3）
+- 应用结构与路由
+- 状态管理策略
+- 组件分层方案
+
+### 6.4 安全架构
+- 认证与授权方案
+- 数据加密策略
+- 安全边界与信任域
+
+### 6.5 基础设施与部署
+- 部署架构图
+- 环境规划（开发/测试/预发/生产）
+- CI/CD 策略
+- 监控与告警方案
+
+## 7. 技术选型与依据
+| 技术决策 | 候选方案 | 最终选择 | 选择理由 | 放弃方案原因 |
+|---------|---------|---------|---------|------------|
+|         |         |         |         |            |
+
+## 8. 数据库与 API 专项产物引用
+- 数据库设计：`docs/design/01-数据库设计文档.md`
+- API 规格：`docs/design/02-API接口规格文档.md`
+- OpenAPI：`docs/api/openapi.yaml`
+- SQL/migration：
+
+## 9. 状态机定义
+- 核心业务状态流转
+- 触发条件、守卫条件、失败/回滚动作
+
+## 10. 非功能需求、验证策略、风险与回滚
+
+### 10.1 性能预算与质量目标
+| 类别 | 指标 | 目标值 | 测量方式 | 关联 ADR |
+|------|------|-------|---------|---------|
+
+### 10.2 风险登记
+| RISK-ID | 风险描述 | 概率 | 影响 | 应对方案 | 关联 ADR | 状态 |
+|---------|---------|------|------|---------|---------|------|
+
+### 10.3 回滚与灾难恢复
+| 场景 | RTO | RPO | 恢复策略 | 触发条件 |
+|------|-----|-----|---------|---------|
+
+### 10.4 验证策略
+| NFR-ID | 验证方法 | 验证时机 | 通过标准 |
+|--------|---------|---------|---------|
+
+## 11. 未决项、延期影响和变更追踪
+
+## 12. 扩展点
+- 已识别的未来扩展方向
+- 预留的扩展机制（接口/配置/插件）
+
+## 13. 跨横切关注点
+| 关注点 | 方案 | 影响模块 |
+|--------|------|---------|
+| 日志与审计 | | |
+| 错误处理 | | |
+| 缓存策略 | | |
+| 国际化/本地化 | | |
+| 配置管理 | | |
+
+## 14. 术语表
+| 术语 | 定义 | 来源 |
+|------|------|------|

package/templates/design//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,59 @@
+---
+id: ka-procedure-概念验证流水线
+kind: guidance
+title: 概念验证流水线
+sync_policy: copy_to_project
+status: active
+triggers:
+  - 技术验证
+  - POC
+  - 可行性验证
+  - 技术选型
+  - 技术调研
+  - 原型验证
+  - spike
+extra:
+  name: poc-pipeline
+  type: procedure
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  lifecycle_status: active
+  authority: supporting
+  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'
+  domain: design
+  verification_layer: L2
+  stage: design
+  owner_mechanism: mc-brainstorm-contract
+---
+
+# 技术验证管线
+
+## 第1步：调研分析
+明确验证目标和成功标准。调研候选方案的生态成熟度、社区活跃度、性能基准、与现有技术栈兼容性。列出关键评估维度和权重。
+产出保存到：docs/analyze/*/01-调研报告.md
+工具：（本步骤为任务入口，由 sf_task 统一路由）
+
+## 第2步：原型实现
+选择 1-2 个最有前景的方案实现最小原型。原型聚焦核心验证点，不追求完整功能。记录实现过程中的关键发现（坑、限制、惊喜）。
+工具：sf_work action=act, sf_scaffold
+
+## 第3步：评估结论
+对比各方案在关键维度的表现（附量化数据）。给出推荐方案和理由。列出遗留风险和后续关注点。明确结论：推荐采用/需进一步验证/不建议采用。
+模版：POC结论.md
+产出保存到：docs/review/\*\*/*POC*.md
+工具：sf_work action=verify, sf_gate

package/templates/design//346/272/220/347/240/201/345/216/237/345/236/213/344/272/244/344/273/230.md

@@ -0,0 +1,64 @@
+---
+id: ka-procedure-源码原型交付流程
+kind: guidance
+title: 源码原型交付
+sync_policy: copy_to_project
+status: active
+triggers:
+  - 用户提供需求文档、原型源码
+extra:
+  name: source-prototype-to-delivery
+  type: procedure
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  lifecycle_status: active
+  authority: supporting
+  priority: P1
+  consumes:
+    - mc-artifact-contract
+  emits:
+    - prototype_specification
+    - source_code_delivery
+  required_evidence:
+    - execution_evidence
+  version: 1.1.0
+  last_reviewed: '2026-06-01'
+  domain: design
+  verification_layer: L2
+  stage: design
+  owner_mechanism: mc-artifact-contract
+---
+
+# 源码原型需求到交付
+
+## 第1步：原型抓取
+只能从导出的源码包（如 React/Vite zip）或已解压源码目录提取原型信息：路由、页面组件、布局结构、状态变量、事件处理、弹窗/导航/表单交互、样式令牌和导入的业务说明。禁止使用 Figma MCP、浏览器运行态、figma.site 或截图作为补充来源。若未提供源码包或源码目录，停止原型抓取并要求补充源码输入。对每个端或页面独立输出原型说明。
+模版：原型说明.md
+产出保存到：docs/analyze/*/01-原型说明.md
+工具：source
+
+## 第2步：架构设计
+根据原型说明和需求文档，设计系统模块划分、数据流向、技术选型与依据、风险点与应对方案。
+产出保存到：docs/architecture/01-架构设计文档.md
+
+## 第3步：详细设计
+根据架构设计产出，把数据结构和接口契约落到正式设计载体。
+默认产出：
+- docs/design/01-数据库设计文档.md
+- docs/design/02-API接口规格文档.md
+- docs/api/openapi.yaml
+- db/migration 或 db/migrations 下的 SQL/migration 权威资产
+
+## 第4步：接口设计
+设计 API 路径、请求/响应结构、错误码、鉴权方案。接口契约必须写入 `docs/design/02-API接口规格文档.md` 并与 `docs/api/openapi.yaml` 对齐。
+
+## 第5步：编码实现
+根据切片计划绑定的 `SLICE-*`、`DD-*`、`AC-*` 进行前后端编码实现。可使用脚手架生成骨架代码。
+工具：sf_scaffold, sf_work action=act
+
+## 第6步：测试与审查验收
+执行自动验证（构建 + 测试）、代码审查（质量/安全/性能/架构/技术债务五维度）、学习记录。
+工具：sf_work action=verify, sf_gate