soloforge 1.1.38 → 1.1.40

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,15 +9,11 @@ products:
   - '*'
 owner_mechanism_id: mc-architecture-decision-workshop
 id: ka-procedure-architecture-decision-workshop
-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:
   - architecture_decision_workshop
   - user_confirmation_ref
@@ -26,10 +21,13 @@ consumes:
   - user_intent
   - project_context_detection
   - existing_system_analysis
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
 emits:
   - architecture_decision_workshop
   - docs/architecture/00-架构决策记录.md
 stages: ["架构设计"]
+triggers: ["架构设计","技术架构","系统设计","平台建设","服务拆分"]
 ---
 
 # 架构决策研讨工作流
@@ -38,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,17 +45,13 @@ acceptance_checks:
   - Mermaid 图 render_check_status 为 passed
   - 架构设计审查 review.passed 为 true
 id: ka-procedure-架构设计工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-primary_triggers:
-  - 架构设计工作流
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-architecture-design
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
 emits:
   - architecture_design_contract
   - design_artifact_pack
@@ -61,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","设计系统","多端设计","系统设计","技术方案设计","模块划分","技术方案","方案设计","架构评审"]
 ---
 
 ## 适用场景
@@ -72,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 真实复验通过
 
 ## 检查点
@@ -93,6 +101,9 @@ stages: ["架构设计", "详细设计"]
 - [ ] Mermaid sequenceDiagram 覆盖关键流程
 - [ ] reviewArchitectureDesign passed
 - [ ] 设计产物包进入 implementation_ready
+- [ ] 约束条件 4 类各至少 1 条
+- [ ] NFR 每项有量化目标值
+- [ ] 架构范式选择（若启用）有用户确认
 
 ## 禁止退化
 - 未确认目录不得 delivered
@@ -100,3 +111,5 @@ stages: ["架构设计", "详细设计"]
 - 六类决策未确认或设计产物包未复验不得 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

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

package/templates/procedures//346/265/213/350/257/225/344/274/230/345/205/210/347/274/226/347/240/201/345/267/245/344/275/234/346/265/201.md

@@ -1,7 +1,6 @@
 ---
 name: test-first-coding-workflow
 type: procedure
-when: '实现需求, 编码, 开发功能, 写代码, coding, test first, 测试优先, 先写测试'
 scope:
   - backend
   - frontend
@@ -29,6 +28,8 @@ hard_rules:
   - 现有项目新需求必须消费 ExistingSystemAnalysis 和 RequirementGapAnalysis
   - 根据架构设计编码时必须消费 ArchitectureDesignContract
   - 测试失败不得删除测试、降低断言、skip 后声称通过
+  - 每个切片至少覆盖 ≥9 个测试场景（≥3 正常路径 + ≥3 边界条件 + ≥3 异常路径）
+  - 模式 B 不得用于支付/状态流转/权限/跨系统同步逻辑
 acceptance_checks:
   - CodingReadinessGate status 非 blocked
   - TestFirstPlan 已创建且 status 为 written 或 expected_failure_recorded
@@ -36,26 +37,23 @@ acceptance_checks:
   - 主线消费检查无 orphan_findings
   - 编码完成审查 review.passed 为 true
 id: ka-procedure-测试优先编码工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-primary_triggers:
-  - 测试优先编码工作流
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-coding-readiness
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
 emits:
   - test_first_plan
   - coding_completion_review
 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: ["实现需求","编码","开发功能","写代码","coding","test first","测试优先","先写测试"]
 ---
 
 ## 适用场景
@@ -70,7 +68,17 @@ stages: ["编码与单元测试"]
    - 有测试框架且行为可断言 → test_first（先写失败测试）
    - 不能自动测试 → verification_case_first 或 manual_acceptance_first
    - TestFirstPlan 绑定需求、主链路入口和验收标准
-3. **编码实现**: 按 TestFirstPlan 先写测试、再写实现
+2a. **头脑风暴触发**：若实现方案选择存在不确定性（模式 A/B 不确定、模块间依赖不清晰、反复修复同一逻辑）：
+   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴流程.md）
+   → 若 fundamental_need 为空 → 先触发 FP-01
+3. **编码实现**: 按 TestFirstPlan 选择模式：
+   - **模式 A**：严格测试先行（red→green→refactor）——推荐核心逻辑
+     1. 编写失败测试（red）
+     2. 编写最小实现使测试通过（green）
+     3. 重构优化（refactor）
+   - **模式 B**：红绿合并（同时编写测试和实现）——适用简单逻辑/CRUD
+     - 约束：不降低覆盖率（≥9 场景）；不适用于支付/状态流转/权限/跨系统同步
+   - **模式 B 约束**：不降低覆盖率（≥9 场景）；禁止用于支付/状态流转/权限/跨系统同步逻辑
 4. **主线消费检查**: 新增文件、组件、API、service 被真实消费
 5. **编码完成审查**: reviewCodingCompletion 验证所有硬规则
 

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

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

package/templates/procedures//347/216/260/346/234/211/347/263/273/347/273/237/345/267/256/350/267/235/345/210/206/346/236/220/345/267/245/344/275/234/346/265/201.md

@@ -1,7 +1,6 @@
 ---
 name: existing-system-gap-analysis-workflow
 type: procedure
-when: '现有项目, 新需求, 已有系统, 现有系统, 差距分析, gap analysis, existing system, 现有源码'
 scope:
   - backend
   - frontend
@@ -20,6 +19,7 @@ required_sections:
   - 项目上下文检测
   - 现有系统分析
   - 需求差距分析
+  - 回归风险评估
   - 主线集成计划
   - 验证计划
 hard_rules:
@@ -35,35 +35,40 @@ hard_rules:
   - 差距分析必须列出现有能力、缺失能力、复用模块、required_changes、兼容/数据/权限/集成风险
   - 实现前必须有 MainlineIntegrationPlan
   - VerificationPlan 必须从 RequirementGapAnalysis 生成
+  - >-
+    回归风险评估须产出高回归风险区域列表和 AI 能力边界评估表，每项改造有风险等级
+  - >-
+    环境验证须通过（编译 + 测试套件 + 接口调用），未通过不得进入设计或编码；无测试套件时降级为编译通过 + 关键接口可调通
 acceptance_checks:
   - project_context_type 已检测且非 unknown
   - ExistingSystemAnalysisContract 已创建
   - RequirementGapAnalysis 已创建
   - 现有项目已有技术栈和项目约定优先于 SoloForge 默认
   - 分析结论包含 fact/inference/assumption/unknown 分类
+  - 回归风险评估已产出（高回归风险区域 + AI 能力边界评估）
+  - 环境验证已通过（编译 PASS + 测试 PASS + 接口可调通）
+  - 高回归风险区域已有缓解措施或人工确认记录
 id: ka-procedure-现有系统差距分析工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-primary_triggers:
-  - 现有系统差距分析工作流
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-existing-system-analysis
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
 emits:
   - existing_system_analysis
   - requirement_gap_analysis
   - mainline_integration_plan
   - verification_plan
+  - regression_risk_assessment
 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: ["现有项目","新需求","已有系统","现有系统","差距分析","gap analysis","existing system","现有源码"]
 ---
 
 ## 适用场景
@@ -75,10 +80,20 @@ stages: ["现有系统分析"]
    - 读取真实代码和相关文档
    - 识别技术栈、路由、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 生成
 
@@ -88,9 +103,14 @@ stages: ["现有系统分析"]
 - [ ] 差距分析包含完整风险列表
 - [ ] MainlineIntegrationPlan 已创建
 - [ ] VerificationPlan 已从差距分析生成
+- [ ] 回归风险评估已产出（每项改造有风险等级 + AI 能力评估）
+- [ ] 环境验证已通过（编译 + 测试 + 接口调用）
+- [ ] 高回归风险区域已有缓解措施
 
 ## 禁止退化
 - existing_system 未分析不得进入设计或编码
 - unknown 类型不得猜测继续，必须 manual_required
 - 不能只读需求文档，必须读代码
 - 缺差距分析不得 coding
+- 回归风险评估未产出不得进入设计或编码
+- 环境验证未通过不得进入设计或编码（降级策略按规则执行）

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

@@ -1,23 +1,16 @@
 ---
 name: knowledge-maintenance-pipeline
 type: pipeline_procedure
-when: '知识维护, 知识更新, 知识审计, 新增知识, 知识库维护, SoloForge维护'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-知识维护流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-knowledge-injection-boundary
-primary_triggers:
-  - 知识维护流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-knowledge-injection-boundary
 emits:
@@ -28,27 +21,28 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码与单元测试", "代码审查", "联调验证"]
+triggers: ["知识维护","知识更新","知识审计","新增知识","知识库维护","SoloForge维护"]
 ---
 
 # 知识维护管线
 
-### 第1步：知识审计
+## 第1步：知识审计
 扫描现有知识库，识别过时条目（长期未被匹配/引用）、重复条目、缺失覆盖的领域。检查知识文件格式一致性。对比设计文档与实际实现的偏差。
 工具：sf_knowledge_audit
 
-### 第2步：知识新增
+## 第2步：知识新增
 根据审计结果和 sf_stage_advance 积累的高频问题，生成新知识条目草稿。草稿保存到 .soloforge/knowledge/drafts/ 目录，人工 review 后移入正式目录。
 工具：sf_knowledge_add
 
-### 第3步：知识更新
+## 第3步：知识更新
 更新已有条目的决策边界、when 触发词、验收项。同步更新设计文档中对应的描述。标记废弃条目（不删除，标记 deprecated）。
 工具：sf_knowledge_update
 
-### 第4步：一致性验证
+## 第4步：一致性验证
 重新构建知识索引，验证新增/更新条目可被正确匹配。运行全量测试确认无功能影响。更新设计文档中的知识规模统计。
 工具：sf_gate_check, sf_stage_advance
 
-### 第5步：定期审计与质量控制
+## 第5步：定期审计与质量控制
 定期审计知识库（每月），检查过期/重复/不准确的条目。新增知识条目必须经过 review 后才发布（草稿 → 审核 → 正式）。知识条目使用统计数据纳入监控，低使用率条目评估是否保留。知识条目格式必须符合规约（字段顺序、body 标题、when 风格），使用 sf_knowledge_audit 检查。
 
 ## 检查点

package/templates/procedures//347/264/247/346/200/245/344/277/256/345/244/215/346/265/201/346/260/264/347/272/277.md

@@ -1,23 +1,16 @@
 ---
 name: hotfix-pipeline
 type: pipeline_procedure
-when: '紧急修复管线, 紧急修复, 生产事故处理管线, P0管线, 热修复管线, hotfix pipeline, hotfix, 线上故障管线, 线上问题修复, 线上报错, 紧急上线, P0, P1, 事故修复, 止血'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-紧急修复流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-delivery-gate
-primary_triggers:
-  - 紧急修复流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-delivery-gate
 emits:
@@ -29,30 +22,31 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["联调验证"]
+triggers: ["紧急修复管线","紧急修复","生产事故处理管线","P0管线","热修复管线","hotfix pipeline","hotfix","线上故障管线","线上问题修复","线上报错","紧急上线","P0","P1","事故修复","止血"]
 ---
 
 # 紧急修复管线
 
-### 第1步：故障定位
+## 第1步：故障定位
 确认问题影响范围和严重程度，通知相关干系人。评估止血方案（配置回滚/功能开关关闭/服务降级/版本回滚），执行止血操作。
 产出保存到：.soloforge/output/01-故障定位.md
 工具：sf_command, sf_analyze
 
-### 第2步：最小修复
+## 第2步：最小修复
 从 main/release 分支拉取 hotfix 分支。编写最小修复代码（仅修复问题，不重构不优化），快速验证修复场景 + 回归核心功能。
 工具：sf_stage_execute, sf_gate_check
 
-### 第3步：验证部署
+## 第3步：验证部署
 合并到 main 和 release 分支，打 hotfix tag。部署到生产环境，验证修复效果，监控 30 分钟。
 工具：sf_gate_check, sf_stage_advance
 
-### 第4步：故障复盘
+## 第4步：故障复盘
 编写事故复盘（根因、影响范围、修复过程、暴露的监控盲区、后续改进项）。与 sf_stage_advance 配合形成闭环。
 模版：故障复盘模版.md
 产出保存到：.soloforge/output/04-故障复盘.md
 工具：sf_stage_advance
 
-### 第5步：验证与闭环
+## 第5步：验证与闭环
 确认修复影响范围，评估是否需要数据修复脚本。修复代码必须包含回归测试，防止相同问题复现。修复后执行冒烟测试验证关键路径。修复上线后持续观察 1 小时监控，确认无副作用。修复完成后编写故障复盘（根因、影响、修复、预防措施）。
 
 ## 检查点

package/templates/procedures//347/274/226/347/240/201/345/211/215/346/276/204/346/270/205/346/265/201/347/250/213.md

@@ -5,16 +5,10 @@ scope:
 products:
   - '*'
 id: ka-procedure-编码前澄清流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-core-engineering-principles
-primary_triggers:
-  - 编码前澄清流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-core-engineering-principles
 emits:
@@ -25,9 +19,10 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 type: procedure
-when: 编码前澄清流程
 stages: ["任务规划"]
+triggers: ["编码前澄清流程"]
 ---
+
 # 编码前澄清流程
 
 ## 适用场景
@@ -81,3 +76,8 @@ stages: ["任务规划"]
 - 写入 scope 不明确
 - 外部副作用未获授权
 - 存在未解决的 blocking 级不确定
+
+### 2.5 Blocking 超时约束
+- 用户未响应 >30 分钟 → 降级为 material，记录为 assumption_record
+- 同一 blocking 问题第 2 次未响应 → 自动记录假设，needs_manual_confirm=true
+- 超时降级不等于放行：假设须在编码完成后由用户确认