soloforge 1.1.46 → 1.1.48

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

@@ -1,177 +0,0 @@
----
-id: 架构设计
-kind: guidance
-title: 架构设计
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 架构设计规则
-  - 架构规则
-  - architecture rule
-  - 架构红线
-  - 系统架构
-  - 模块划分
-  - 服务边界
-  - 跨模块调用
-  - 服务拆分
-  - 技术架构
-  - 平台建设
-extra:
-  name: architecture-design
-  type: constraint
-  scope:
-    - '*'
-  products:
-    - '*'
-  domain:
-    - design
-    - build
-    - verify
-  lifecycle_status: active
-  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

@@ -1,130 +0,0 @@
----
-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
-  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/246/202/345/277/265/351/252/214/350/257/201/346/265/201/346/260/264/347/272/277.md

@@ -1,47 +0,0 @@
----
-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
-  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

@@ -1,58 +0,0 @@
----
-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
-  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

package/templates/design//347/216/260/346/234/211/347/263/273/347/273/237/345/267/256/350/267/235/345/210/206/346/236/220.md

@@ -1,114 +0,0 @@
----
-id: ka-procedure-现有系统差距分析工作流
-kind: guidance
-title: 现有系统差距分析
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 现有项目
-  - 新需求
-  - 已有系统
-  - 现有系统
-  - 差距分析
-  - gap analysis
-  - existing system
-  - 现有源码
-extra:
-  name: existing-system-gap-analysis-workflow
-  type: procedure
-  scope:
-    - backend
-    - frontend
-    - infrastructure
-  products:
-    - '*'
-  consumed_contracts:
-    - existing_system_analysis_contract_entry
-    - architecture_design_contract_entry
-    - technology_decision_contract
-    - brainstorm_contract
-    - detail_discipline_contract
-    - first_principles_contract
-  required_sections:
-    - 项目上下文检测
-    - 现有系统分析
-    - 需求差距分析
-    - 回归风险评估
-    - 主线集成计划
-    - 验证计划
-  hard_rules:
-    - >-
-      existing_system + new_requirement 必须先生成 ExistingSystemAnalysisContract 和
-      RequirementGapAnalysis
-    - new_system / empty_project 不得强制执行 ExistingSystemAnalysis
-    - unknown 必须 manual_required，不能猜测继续
-    - 现有系统分析必须读取真实代码和相关文档，不能只读需求文档
-    - >-
-      分析结论必须区分 fact / inference / assumption / unknown，并带 confidence 和
-      evidence_refs
-    - 差距分析必须列出现有能力、缺失能力、复用模块、required_changes、兼容/数据/权限/集成风险
-    - 实现前必须有 MainlineIntegrationPlan
-    - VerificationPlan 必须从 RequirementGapAnalysis 生成
-    - 回归风险评估须产出高回归风险区域列表和 AI 能力边界评估表，每项改造有风险等级
-    - 环境验证须通过（编译 + 测试套件 + 接口调用），未通过不得进入设计或编码；无测试套件时降级为编译通过 + 关键接口可调通
-  acceptance_checks:
-    - project_context_type 已检测且非 unknown
-    - ExistingSystemAnalysisContract 已创建
-    - RequirementGapAnalysis 已创建
-    - 现有项目已有技术栈和项目约定优先于 SoloForge 默认
-    - 分析结论包含 fact/inference/assumption/unknown 分类
-    - 回归风险评估已产出（高回归风险区域 + AI 能力边界评估）
-    - 环境验证已通过（编译 PASS + 测试 PASS + 接口可调通）
-    - 高回归风险区域已有缓解措施或人工确认记录
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  domain: design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-existing-system-analysis
----
-
-## 适用场景
-已有源码、路由、API、前端页面、权限模型和测试脚本的项目中开发新需求。必须先分析现有系统、再做差距分析、最后才进入设计或编码。
-
-## 步骤
-1. **项目上下文检测**: detectProjectContext 判断 project_context_type
-2. **现有系统分析**:
-   - 读取真实代码和相关文档
-   - 识别技术栈、路由、API、前端页面、权限模型、测试脚本
-   - 区分 fact / inference / assumption / unknown
-   - 同时读取 `历史遗留雷区清单` 和 `数据血缘图`，将发现标注到差距分析
-   - 雷区中"高风险"项 → 差距分析 required_changes 中标注 `minefield:high`
-   - 数据血缘图中受影响接口 → 差距分析中标注 `lineage:affected`
-3. **需求差距分析**:
-   - 列出现有能力、缺失能力、复用模块
-   - 列出 required_changes、optional_changes、out_of_scope
-   - 列出兼容/数据/权限/集成风险、前后端影响、测试回归范围
-3a. **头脑风暴触发**：若改造方案存在多种路径且无明确最优，或复用/重写决策不确定：
-   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴.md）
-   → 若 fundamental_need 为空 → 先触发 FP-01
-3b. **回归风险评估**（基于 SWE-CI 研究：75% AI 引入回归）:
-   - 量化每项改造的回归风险（高/中/低），产出结构化表格
-   - 评估每项改造的 AI 自主能力（低级编辑/接口调整/架构重构）
-   - 执行环境验证（编译 + 测试 + 接口调用），建立回归基线
-4. **主线集成计划**: 新增文件、组件、API、service、DTO/model、配置必须被真实消费
-5. **验证计划**: VerificationPlan 从 RequirementGapAnalysis 生成
-
-## 检查点
-- [ ] project_context_type 已检测
-- [ ] 现有系统分析读取了真实代码
-- [ ] 差距分析包含完整风险列表
-- [ ] MainlineIntegrationPlan 已创建
-- [ ] VerificationPlan 已从差距分析生成
-- [ ] 回归风险评估已产出（每项改造有风险等级 + AI 能力评估）
-- [ ] 环境验证已通过（编译 + 测试 + 接口调用）
-- [ ] 高回归风险区域已有缓解措施
-
-## 禁止退化
-- existing_system 未分析不得进入设计或编码
-- unknown 类型不得猜测继续，必须 manual_required
-- 不能只读需求文档，必须读代码
-- 缺差距分析不得 coding
-- 回归风险评估未产出不得进入设计或编码
-- 环境验证未通过不得进入设计或编码（降级策略按规则执行）

package/templates/design//347/237/245/350/257/206/347/273/264/346/212/244/346/265/201/346/260/264/347/272/277.md

@@ -1,64 +0,0 @@
----
-id: ka-procedure-知识维护流水线
-kind: guidance
-title: 知识维护流水线
-sync_policy: internal
-status: active
-triggers:
-  - 知识维护
-  - 知识更新
-  - 知识审计
-  - 新增知识
-  - 知识库维护
-  - SoloForge维护
-extra:
-  name: knowledge-maintenance-pipeline
-  type: procedure
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  domain:
-    - build
-    - design
-    - verify
-  verification_layer: L2
-  stage: design
----
-
-# 知识维护管线
-
-## 第1步：知识审计
-扫描现有知识库，识别过时条目（长期未被匹配/引用）、重复条目、缺失覆盖的领域。检查知识文件格式一致性。对比设计文档与实际实现的偏差。
-工具：sf_knowledge action=audit
-
-## 第2步：知识新增
-根据审计结果和 sf_work action=verify 积累的高频问题，生成新知识条目草稿。草稿保存到 .soloforge/knowledge/drafts/ 目录，人工 review 后移入正式目录。
-工具：sf_knowledge action=add
-
-## 第3步：知识更新
-更新已有条目的决策边界、when 触发词、验收项。同步更新设计文档中对应的描述。标记废弃条目（不删除，标记 deprecated）。
-工具：sf_knowledge action=update
-
-## 第4步：一致性验证
-重新构建知识索引，验证新增/更新条目可被正确匹配。运行全量测试确认无功能影响。更新设计文档中的知识规模统计。
-工具：sf_work action=verify, sf_gate
-
-## 第5步：定期审计与质量控制
-定期审计知识库（每月），检查过期/重复/不准确的条目。新增知识条目必须经过 review 后才发布（草稿 → 审核 → 正式）。知识条目使用统计数据纳入监控，低使用率条目评估是否保留。知识条目格式必须符合规约（字段顺序、body 标题、when 风格），使用 sf_knowledge action=audit 检查。
-
-## 检查点
-- [ ] 知识库审计执行完毕
-- [ ] 新增/更新条目索引验证通过
-- [ ] 新条目经过 review
-- [ ] 低使用率条目已评估
-- [ ] 格式规约检查通过
-
-## 注意事项
-- 废弃条目标记为 deprecated 而非直接删除，保留历史参考
-- 知识条目应保持精简（决策规则 ≤ 20 条），过长难以匹配和阅读
-- 知识条目变更应记录变更历史（更新原因、时间）