soloforge 1.1.38 → 1.1.42

package/templates/procedures//347/274/226/347/240/201/351/230/266/346/256/265/346/211/247/350/241/214/345/267/245/344/275/234/346/265/201.md

@@ -0,0 +1,101 @@
+---
+name: coding-stage-execution-workflow
+type: procedure
+scope: [backend, frontend]
+products:
+  - '*'
+stages: ["编码与单元测试"]
+owner_mechanism_id: mc-core-engineering-principles
+triggers: ["编码执行", "编码阶段", "coding stage", "开始编码"]
+version: 1.0.0
+last_reviewed: '2026-06-04'
+lifecycle_status: active
+consumes:
+  - mc-coding-readiness
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
+emits:
+  - coding_stage_completion_report
+required_evidence:
+  - workflow_id
+  - all_gate_results
+---
+
+# 编码阶段执行工作流
+
+## 适用场景
+编码与单元测试阶段的完整 Agent 执行工作流。从读取上游产物到推进至下一阶段的全流程编排。
+
+## 步骤
+
+### 1. [读取] 加载上游产物
+- 加载数据库设计文档（docs/architecture/02-数据库设计文档.md）
+- 加载 API 接口规格文档（docs/architecture/03-API接口规格文档.md）
+- 加载 openapi.yaml（若存在）
+- 加载追踪矩阵（若存在）
+- 确认所有设计产物无 hard_fail 状态
+
+### 2. [触发] 调用 sf_stage_execute
+- 获取当前 scope 和 forbidden_tools
+- 确认 stage 为"编码与单元测试"
+- 确认 forbidden_tools 不影响编码核心流程
+
+### 3. [任务规划] 执行任务拆解流程（E-01）
+- 执行任务拆解流程 → 选择分解策略 → 生成切片计划 → 生成依赖图
+- 运行 G-01 gate-任务规划（8 项检查）
+- gate 未通过 → 修复后重新执行步骤 3
+
+### 4. [编码准备] 执行编码前澄清流程（E-02）
+- 不确定性分级 → 澄清问题 → 输入完备报告
+- 运行 G-02 gate-编码准备（3 项检查）
+- status=blocked → 阻断，等待用户解决
+- status=allowed → 进入步骤 5
+
+4a. **头脑风暴触发**：若实现方案存在多种选择且无明确最优，或反复修复同一模块 ≥ 3 次：
+   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴流程.md）
+   → 若 fundamental_need 为空 → 先触发 FP-01
+
+### 5. [切片循环] 对每个切片执行
+- **5a.** 执行 E-03 测试优先编码工作流
+  - 模式 A（核心逻辑）：red→green→refactor
+  - 模式 B（简单 CRUD）：红绿合并
+- **5b.** 运行 G-03 gate-编码实现（3 项检查）
+- **5c.** 运行 G-06 gate-切片执行（3 项检查）
+- **5d.** 老系统切片：执行新老逻辑比对（100% 一致率）
+- **5e.** 切片验证点（E-04 步骤 7）：运行测试 → 检查覆盖率 → 确认涉及文件 → 更新测试状态
+- **5f.** 运行 G-05 gate-编码与单元测试（2 项检查）
+- **5g.** 若触发重规划（E-06 动态重规划）：
+  - 局部重规划 → 回到 5a
+  - 结构重规划 → 回到步骤 3
+  - 回退 → 阻断并通知用户
+
+### 6. [编码验证] 运行 G-04 gate-编码验证
+- 构建通过（0 error）
+- 测试通过（passed/failed/total）
+- 覆盖率达标（增量行覆盖率≥阈值）
+- gate 未通过 → 修复后重新运行
+
+### 7. [切片审查] 运行 G-07 gate-切片审查
+- 独立审查测试充分性
+- 无 hard_fail（代码质量检查）
+- 无遗留问题
+- gate 未通过 → 修复后重新审查
+
+### 8. [推进] 调用 sf_stage_advance
+- 所有 gate 通过后推进至下一阶段
+- 生成编码阶段完成报告
+
+## 检查点
+- [ ] 上游产物已全部加载且无 hard_fail
+- [ ] 任务规划 gate 通过（G-01）
+- [ ] 编码准备 gate 通过（G-02）
+- [ ] 每个切片：编码实现→切片执行→编码与单元测试 gate 全部通过
+- [ ] 编码验证 gate 通过（G-04）
+- [ ] 切片审查 gate 通过（G-07）
+- [ ] 编码阶段完成报告已生成
+
+## 禁止退化
+- 跳过任何 gate 直接推进
+- gate 失败后不修复直接重试
+- 切片循环中跳过老系统比对
+- 重规划时降低验收标准

package/templates/procedures//350/207/252/344/270/273/351/200/211/345/236/213/346/265/201/347/250/213.md

@@ -1,23 +1,16 @@
 ---
 name: autonomous-tech-selection
 type: procedure
-when: '技术选型, 不知道用什么, 选型, 方案对比, 架构选型, 方案选择, 技术方案'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-自主选型流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-decision-sovereignty
-primary_triggers:
-  - 自主选型流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-decision-sovereignty
 emits:
@@ -29,6 +22,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["架构设计"]
+triggers: ["技术选型","不知道用什么","选型","方案对比","架构选型","方案选择","技术方案"]
 ---
 
 ## 适用场景

package/templates/procedures//350/256/276/350/256/241/344/272/247/347/211/251/347/224/237/346/210/220/344/270/216/345/244/215/351/252/214/345/267/245/344/275/234/346/265/201.md

@@ -1,7 +1,6 @@
 ---
 name: design-artifact-pack-workflow
 type: procedure
-when: '架构设计文档, 数据库设计文档, API接口规格文档, 设计文档升级'
 scope:
   - backend
   - frontend
@@ -10,15 +9,11 @@ products:
   - '*'
 owner_mechanism_id: mc-design-artifact-pack
 id: ka-procedure-design-artifact-pack
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-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:
   - design_artifact_pack
   - consistency_verification
@@ -31,13 +26,37 @@ emits:
   - docs/architecture/99-设计一致性验收报告.md
   - implementation_ready
 stages: ["架构设计"]
+triggers: ["架构设计文档","数据库设计文档","API接口规格文档","设计文档升级"]
 ---
 
 # 设计产物生成与复验工作流
 
-1. 消费已经用户确认的架构决策记录。
-2. 新项目生成架构、数据库、API、OpenAPI、SQL/migration 及一致性报告。
-3. 现有文档先标记为需要复验，输出差距和待确认变化，不静默覆盖。
-4. 用户确认后归档旧版本并写入修订产物。
-5. 读取真实文件验证 API 字段、SQL 可执行性和跨文档追踪一致性。
-6. 全部通过后才标记为 `implementation_ready`，供后续编码和交付消费。
+## 步骤
+
+1. **确定产物清单**
+     输入：需求分析产出 + 管线状态机阶段信息
+     判断哪些子产物需要生成：
+     - 架构设计文档（必有）
+     - 数据库变更方案（若有数据库变更）
+     - 接口对接方案（若有第三方对接）
+     - 改造影响评估（老系统专属，若有改造范围）
+     - 隔离适配器方案（老系统专属，若有隔离需求）
+     输出：产物生成队列
+
+2. **逐产物增量验证**
+     对队列中每个产物：
+     - 生成产物
+     - 运行对应 Gate 检查项
+     - 通过 → 锁定产物，进入下一个
+     - 不通过 → 修复 → 重新检查（最多 3 次）
+     - 3 次不通过 → HOLD，通知用户决策
+
+3. **交叉一致性验证**
+     所有产物通过后：
+     - 数据库变更 ↔ 架构设计文档数据模型一致
+     - 接口对接方案 ↔ 架构设计文档接口设计一致
+     - 追踪矩阵覆盖所有子产物的设计决策
+
+4. **用户最终确认**
+     - 展示产物清单 + Gate 结果 + 交叉验证结果
+     - 用户确认 → 阶段推进

package/templates/procedures//350/256/276/350/256/241/345/256/241/350/256/241/346/265/201/347/250/213.md

@@ -1,7 +1,6 @@
 ---
 name: audit-design-procedure
 type: procedure
-when: '设计审计, 详细设计审计, 架构审计, 设计审核, 审核设计, audit design, design audit, 接口审计'
 scope:
   - backend
   - frontend
@@ -9,21 +8,11 @@ scope:
 products:
   - '*'
 id: ka-procedure-设计审计流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-intent-expander
 stages: ["代码审查"]
-primary_triggers:
-  - 设计审计
-  - 详细设计审计
-secondary_triggers:
-  - 设计审核
-  - 审核设计
-  - 架构审计
-negative_triggers: []
 priority: P2
-specificity: 5
 consumes:
   - mc-command-router
   - mc-knowledge-injection-boundary
@@ -35,6 +24,7 @@ pipeline_scope:
   - existing-system
 applicable_tech_stack:
   - '*'
+triggers: ["设计审计","详细设计审计","架构审计","设计审核","审核设计","audit design","design audit","接口审计"]
 ---
 
 # 设计审计流程
@@ -67,33 +57,39 @@ applicable_tech_stack:
 - 架构文档 / 详细设计 / API 设计 / 数据库设计 命名、边界、调用链是否一致
 - 同一概念是否在不同文档中使用不同名称
 - 接口契约（参数 / 返回 / 异常）在 API 文档与详细设计中是否完全一致
+- **引用审查规则：UCV-REV-01, UCV-REV-02**
 
 ### 维度 2: OOD/SOLID 合规
 - 单一职责: 模块 / 类 / 函数边界是否清晰
 - 开闭原则: 扩展点是否通过抽象隔离
 - 依赖倒置: 高层模块是否依赖抽象而非具体实现
 - 命名 / 分层是否反映职责
+- **引用审查规则：SOLID-SRP, SOLID-LSP, SOLID-ISP, SOLID-DIP, SOLID-OCP**
 
 ### 维度 3: 防孤岛设计
 - 新模块与现有系统的集成点是否明确
 - 是否定义了与上游（消费者）和下游（依赖）的契约
 - 跨团队 / 跨服务协作边界是否清晰
+- **引用审查规则：ARC-01, ARC-06**
 
 ### 维度 4: 契约破坏性
 - 新设计是否破坏已有 API / 事件 / 数据契约
 - 版本兼容性: 是否有 deprecation 路径
 - 客户端 / 调用方升级成本是否评估
+- **引用审查规则：SEC-01~12, CON-01~10**
 
 ### 维度 5: SQL/数据迁移回滚性
 - DDL 是否可回滚（DROP / ALTER 必须有 rollback 脚本）
 - 数据迁移是否可在中断后恢复
 - 是否定义了数据回滚检查点
 - 是否区分可逆 / 不可逆变更（DELETE 无回滚需特别标注）
+- **引用审查规则：MNT-05, ARC-07**
 
 ### 维度 6: 索引/性能覆盖
 - 主链路查询是否有索引支撑
 - 是否评估了 N+1、全表扫描、热点行更新风险
 - 分页 / 排序字段是否有联合索引
+- **引用审查规则：PER-01~09**
 
 ---
 
@@ -101,9 +97,9 @@ applicable_tech_stack:
 
 | 级别 | 含义 | 是否阻塞实施 |
 |------|------|--------------|
-| `hard_fail` | 设计错误 / 破坏性变更 / 数据丢失风险 | 是 |
+| `error` | 设计错误 / 破坏性变更 / 数据丢失风险 | 是 |
 | `warning` | 建议修改，存在风险但不致命 | 否（建议修复） |
-| `advisory` | 供参考的改进建议 | 否（仅供参考） |
+| `info` | 供参考的改进建议 | 否（仅供参考） |
 
 ---
 
@@ -114,14 +110,14 @@ interface AuditReport {
   dimensions: Array<{
     name: string;                       // "跨文档一致性" | "OOD/SOLID" | ...
     findings: Array<{
-      severity: "hard_fail" | "warning" | "advisory";
+      severity: "error" | "warning" | "info";
       location: string;                 // 文档路径 + 章节/行号
       issue_zh: string;                 // 中文问题描述
       recommendation_zh: string;        // 中文修复建议
     }> | Array<{ no_issue_observed: true; note_zh: string }>;
   }>;
-  overall_status: "blocked" | "advisory";
-  blocking_findings_count: number;      // severity=hard_fail 的总数
+  overall_status: "blocked" | "passed";
+  blocking_findings_count: number;      // severity=error 的总数
   input_artifacts: Array<{ kind: string; path: string }>;
   audited_at: string;                   // ISO 8601
 }
@@ -129,26 +125,26 @@ interface AuditReport {
 
 ### 4.1 整体状态判定
 - `blocking_findings_count > 0` → `overall_status = "blocked"`
-- `blocking_findings_count = 0` → `overall_status = "advisory"`
+- `blocking_findings_count = 0` → `overall_status = "passed"`
 
 ---
 
 ## 5. 流程步骤
 
-```
+```text
 [用户] sf_command (intent: "开始详细设计审计", input_artifacts: [...])
    ↓
 [路由] 识别 audit action → workflow_intent = "audit_design"
    ↓
 [路由] EXTENSION_WORKFLOW_MAP.audit_design → route=analysis, mutation=false
    ↓
-[扩展] 加载 audit_design_prompt 模板 + 关联知识（review_rule / pattern）
+[扩展] 加载 audit_design_prompt 模版 + 关联知识（review_rule / pattern）
    ↓
 [执行] 6 维度审计，每维度遍历 input_artifacts 中相关章节
    ↓
 [输出] audit_report + blocking_findings_count
    ↓
-[结束] overall_status="blocked" 时建议用户先修复 hard_fail，再进入实施
+[结束] overall_status="blocked" 时建议用户先修复 error，再进入实施
 ```
 
 ---
@@ -165,7 +161,7 @@ interface AuditReport {
 
 ## 7. 关联资产
 
-- **Prompt 模板**: `audit_design_prompt` (`src/engine/pipeline/intent_expander/templates.ts`)
+- **Prompt 模版**: `audit_design_prompt` (`src/engine/pipeline/intent_expander/templates.ts`)
 - **工作流契约**: `wf-audit-design` (`src/engine/workflow/workflow_contract_registry.ts`)
 - **ARTIFACT_ALIASES**: `design_doc` / `detailed_design` / `api_spec` / `database_design`
 - **Pipeline hint**: `code-review`（复用代码审查流程的规则与模式资产）

package/templates/procedures//350/257/246/347/273/206/350/256/276/350/256/241/346/265/201/347/250/213.md

@@ -1,25 +1,20 @@
 ---
 name: detailed-design
 type: procedure
-when: '详细设计, 接口设计, 数据库设计, DDL设计, 类设计, 详细方案, detailed design'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-详细设计流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-architecture-design
-primary_triggers:
-  - 详细设计流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-architecture-design
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
 emits:
   - database_design
   - api_specification
@@ -27,9 +22,16 @@ emits:
   - traceability_matrix
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["详细设计"]
+triggers: ["详细设计","接口设计","数据库设计","DDL设计","类设计","详细方案","detailed design"]
+companion_rules:
+  - 详细设计审查规则.md:review
+  - 一致性校验规则.md:check
+  - 追踪矩阵ID规则.md:check
+companion_procedures:
+  - OOD设计工作流.md
 ---
 
 ## 适用场景
@@ -45,24 +47,89 @@ stages: ["详细设计"]
 `docs/architecture/04-详细设计文档.md` 仅作为复杂模块或旧项目迁移的可选补充；如果数据库设计和 API 规格已完整承载详细设计，门禁不得强制要求该文件。
 
 ## 步骤
-1. 确认架构设计已冻结，并在详细设计中引用 `ARCH-*`。
-2. 产出数据库详细设计，声明 `DD-T*`，并同步 SQL/migration 权威资产。
-3. 产出 API 详细设计，声明 `DD-A*`，并同步 `docs/api/openapi.yaml`。
-4. 维护追踪矩阵，把 `REQ/PROTO/ARCH/DD` 关系写入 `docs/traceability/01-需求原型设计实现追踪矩阵.md`。
-5. 进入切片规划前，确保后续切片能引用 `DD-*` 或 `ARCH-*` 并生成 `SLICE-*` 与 `AC-*`。
+
+### Step 1: 确认架构设计冻结
+- **属性**: 确定性校验（纯函数，不经过 LLM 推理）
+- **输入**: 架构设计文档中所有 ARCH-* 编号
+- **输出**: 架构冻结确认 + ARCH-* 编号清单
+- **Agent 行为**: 校验是否有未决 ARCH-* 项，有则阻断回到架构阶段
+
+### Step 2: 产出数据库详细设计
+- **属性**: LLM 推理
+- **输入**: ARCH-* 编号清单 + 架构设计文档
+- **输出**: 02-数据库设计文档.md + SQL/migration 文件
+- **产出 ID**: DD-T*
+- **依赖**: Step 1
+
+2a. **头脑风暴触发**：若数据模型方案存在多种设计选择且无明确最优，或 AI 自检不确定：
+   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴流程.md）
+   → 若 fundamental_need 为空 → 先触发 FP-01
+- **子流程**: 涉及复杂对象边界时先执行 OOD 工作流，获取摘要后再生成
+
+### Step 3: 产出 API 详细设计
+- **属性**: LLM 推理
+- **输入**: ARCH-* 编号清单 + DD-T* 数据库设计（Step 2 产出）
+- **输出**: 03-API接口规格文档.md + openapi.yaml
+- **产出 ID**: DD-A*
+- **依赖**: Step 2（API 字段需追溯到 DD-T* 数据库字段）
+- **子流程**: 涉及复杂业务逻辑/状态机时先执行 OOD 工作流
+
+### Step 4: 维护追踪矩阵
+- **属性**: 确定性校验 + LLM 推理混合
+- **输入**: DD-T* + DD-A* + ARCH-* + REQ-*
+- **输出**: 追踪矩阵更新
+- **依赖**: Step 2 + Step 3
+
+### Step 5: 编码准备确认
+- **属性**: 确定性校验（纯函数）
+- **输入**: 所有详细设计产出 + 追踪矩阵
+- **输出**: 编码准备就绪确认 + DD-* 编号索引
+- **依赖**: Step 4
+
+## 验证闭环
+
+1. **error 级失败**（DD-REV-01~07, CON-DD-01~03）：
+   回到失败步骤重做，retry_hint 标注具体规则 ID
+   例：DD-REV-02（实体覆盖）失败 → 回到 Step 2 补充遗漏表
+2. **warning 级失败**（DD-REV-08~09, CON-DD-04）：
+   在未决项中标注，允许继续但编码前必须解决
+3. **修正后重验**：最多 3 次，超过请求用户介入
 
 ## 检查点
-- [ ] DDL 命名/注释/审计字段/主键完备
-- [ ] DDL 有兼容窗口和回滚策略
-- [ ] 数据库设计声明 `DD-T*` 并引用 `ARCH-*`
-- [ ] API 规格声明 `DD-A*` 并引用 `ARCH-*`
-- [ ] OpenAPI 与 API 文档路径和字段一致
-- [ ] SQL/migration 权威资产存在
-- [ ] 页面映射/字段变更/菜单权限/状态机可追溯到 UI 交互设计
-- [ ] 新增/修改菜单的角色授权和权限标识已文档化
-- [ ] 实现锚点可供任务拆解直接消费
+
+- [ ] [error] DDL 命名/注释/审计字段/主键完备
+- [ ] [error] DDL 有兼容窗口和回滚策略
+- [ ] [error] 数据库设计声明 DD-T* 并引用 ARCH-*
+- [ ] [error] API 规格声明 DD-A* 并引用 ARCH-*
+- [ ] [error] OpenAPI 与 API 文档路径和字段一致
+- [ ] [error] SQL/migration 权威资产存在
+- [ ] [warning] 页面映射/字段变更/菜单权限/状态机可追溯到 UI 交互设计
+- [ ] [warning] 新增/修改菜单的角色授权和权限标识已文档化
+- [ ] [error] 实现锚点可供任务拆解直接消费
 
 ## 注意事项
 - 禁止先写说明文字再补实现锚点（锚点优先）
-- 禁止只写 `04-详细设计文档.md` 而缺少数据库设计、API 规格、OpenAPI 或 SQL/migration 权威资产
+- 禁止只写 04-详细设计文档.md 而缺少数据库设计、API 规格、OpenAPI 或 SQL/migration
 - DDL 必须指定关联策略和审计策略
+- 复杂对象边界/变化点时必须先执行 OOD 工作流（Step 2/3 子流程）
+- 详细设计文档（04-详细设计文档.md）为条件产物，不强制生成
+
+## Agent 完整执行工作流（E-03）
+
+1. [读取] 加载上游产物（架构设计文档 + ADR + 数据库变更方案 + 接口对接方案）
+   老系统额外加载：隔离适配器方案 + 改造影响范围评估
+2. [触发] 调用 sf_stage_execute，获取 scope 和 forbidden_tools
+3. [前置校验] Step 1: 确认架构设计冻结（确定性校验）
+4. [OOD 判定] 判断是否需要执行 OOD 工作流（前置门控）
+   - 需要 → 执行 E-02，获取 OOD 摘要
+   - 不需要 → 记录不适用理由
+5. [填充 DB] Step 2: 生成数据库详细设计（LLM 推理）
+6. [填充 API] Step 3: 生成 API 详细设计（LLM 推理）
+   - API 字段追溯到 DD-T* 数据库字段
+7. [追踪矩阵] Step 4: 更新追踪矩阵（混合校验）
+8. [准备确认] Step 5: 编码准备确认（确定性校验）
+9. [验证] 运行 Gate 检查（G-01 shared 15 项 + 老系统 G-02 3 项）
+   - error 失败 → 回到对应步骤重做（验证闭环）
+   - warning 失败 → 标注未决项
+10. [老系统] 生成一键开关配置 + 紧急回滚手册（若为老系统管线）
+11. [推进] 调用 sf_stage_advance

package/templates/procedures//350/260/203/350/257/225/346/216/222/346/237/245/346/265/201/347/250/213.md

@@ -1,23 +1,16 @@
 ---
 name: debug-investigation
 type: procedure
-when: '调试, 排障, 排查问题, bug定位, 问题排查, 线上排查, 异常排查, 错误定位, 日志排查, 缺陷修复, Bug修复, 问题修复, 异常修复, 错误修复, bug fix, 缺陷处理'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-调试排查流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-verifier
-primary_triggers:
-  - 调试排查流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-verifier
 emits:
@@ -26,9 +19,10 @@ emits:
   - minimal_fix
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["调试","排障","排查问题","bug定位","问题排查","线上排查","异常排查","错误定位","日志排查","缺陷修复","Bug修复","问题修复","异常修复","错误修复","bug fix","缺陷处理"]
 ---
 
 ## 适用场景
@@ -52,6 +46,32 @@ stages: ["编码与单元测试", "联调验证"]
 9. 使用 RED-GREEN 验证：回退修复 → 确认失败 → 恢复修复 → 确认通过
 10. 添加回归测试（防止同类问题再发生）
 
+## 调试报告格式
+
+### 基本信息
+| 项目 | 内容 |
+|------|------|
+| 问题描述 | <!-- 现象描述 --> |
+| 影响范围 | <!-- 用户/模块/接口 --> |
+| 复现条件 | <!-- 步骤 --> |
+| 严重程度 | P0/P1/P2 |
+
+### 调试过程
+| 阶段 | 假设 | 验证方法 | 结果 |
+|------|------|---------|------|
+| 观察 | — | <!-- 日志/监控 --> | <!-- 发现 --> |
+| 假设 1 | <!-- 假设内容 --> | <!-- 验证方法 --> | 确认/否定 |
+| 假设 2 | <!-- 假设内容 --> | <!-- 验证方法 --> | 确认/否定 |
+
+### 修复方案
+| 修改文件 | 修改内容 | 关联切片 |
+|---------|---------|---------|
+| <!-- 文件路径 --> | <!-- 修改说明 --> | SLC-{模块}-{序号} |
+
+### RED-GREEN 验证
+- [ ] 回退修复后测试失败（RED）
+- [ ] 恢复修复后测试通过（GREEN）
+
 ## 检查点
 - [ ] 问题可稳定复现（或记录了偶现条件）
 - [ ] 日志中有 traceId 可追踪完整链路
@@ -66,3 +86,5 @@ stages: ["编码与单元测试", "联调验证"]
 - 性能问题优先看慢查询日志和接口耗时
 - 同一现象修复失败 3 次后停止猜测，重新审视假设，考虑是否为架构问题
 - 禁止通过删除断言、增加 sleep、降低覆盖率、增加 mock 来制造通过
+- 调试修复须遵守 SED-04（禁止跨任务修改），修复范围仅限当前切片涉及文件
+- 修复范围超出当前切片涉及文件时，须触发重规划（参见切片计划 §7 动态重规划）

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

@@ -1,23 +1,16 @@
 ---
 name: migration-pipeline
 type: pipeline_procedure
-when: '技术迁移, 框架升级, 技术栈迁移, 版本升级, 迁移, migration, 系统迁移, 组件替换'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-迁移流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-knowledge-asset-governance
-primary_triggers:
-  - 迁移流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-knowledge-asset-governance
 emits:
@@ -29,24 +22,25 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["技术迁移","框架升级","技术栈迁移","版本升级","迁移","migration","系统迁移","组件替换"]
 ---
 
 # 技术迁移管线
 
-### 第1步：迁移评估
+## 第1步：迁移评估
 评估迁移范围和影响（模块数、代码量、依赖链）。评估迁移路径（渐进式/一次性）。评估兼容性风险（API 变更、行为差异、性能差异）。制定回滚方案。
 模版：迁移评估模版.md
-产出保存到：.soloforge/output/01-迁移评估.md
+产出保存到：docs/architecture/08-迁移方案.md
 工具：sf_command, sf_analyze
 
-### 第2步：方案设计
+## 第2步：方案设计
 制定分阶段迁移计划（每阶段可独立验证和回滚）。识别兼容层需求（适配器/Shim/Feature Flag）。定义每个阶段的完成标准和验证方式。
-产出保存到：.soloforge/output/02-迁移方案.md
+产出保存到：docs/architecture/08-迁移方案.md
 
-### 第3步：渐进迁移
+## 第3步：渐进迁移
 按计划逐步迁移，每阶段完成后全量测试。保持双写/双读过渡期（如需要）。记录每阶段发现的行为差异和兼容性问题。
 工具：sf_stage_execute, sf_gate_check
 
-### 第4步：清理验证
+## 第4步：清理验证
 移除兼容层和废弃代码。全量功能验证。性能对比确认无退化。更新文档和依赖配置。
 工具：sf_gate_check, sf_review, sf_stage_advance, sf_stage_advance