soloforge 1.1.37 → 1.1.40

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

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,28 +37,23 @@ acceptance_checks:
   - 主线消费检查无 orphan_findings
   - 编码完成审查 review.passed 为 true
 id: ka-procedure-测试优先编码工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-routes:
-  - code_change
-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","测试优先","先写测试"]
 ---
 
 ## 适用场景
@@ -72,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,25 +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
-routes:
-  - code_change
-primary_triggers:
-  - 源码原型交付流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-artifact-contract
 emits:
@@ -30,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
@@ -52,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_expand
+工具：sf_scaffold, sf_stage_execute
 
-### 第6步：测试与审查验收
+## 第6步：测试与审查验收
 执行自动验证（构建 + 测试）、代码审查（质量/安全/性能/架构/技术债务五维度）、学习记录。
-工具：sf_verify, sf_review, sf_learn
+工具：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,37 +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
-routes:
-  - code_change
-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","现有源码"]
 ---
 
 ## 适用场景
@@ -77,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 生成
 
@@ -90,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,25 +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
-routes:
-  - code_change
-primary_triggers:
-  - 知识维护流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-knowledge-injection-boundary
 emits:
@@ -30,27 +21,28 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码与单元测试", "代码审查", "联调验证"]
+triggers: ["知识维护","知识更新","知识审计","新增知识","知识库维护","SoloForge维护"]
 ---
 
 # 知识维护管线
 
-### 第1步：知识审计
+## 第1步：知识审计
 扫描现有知识库，识别过时条目（长期未被匹配/引用）、重复条目、缺失覆盖的领域。检查知识文件格式一致性。对比设计文档与实际实现的偏差。
 工具：sf_knowledge_audit
 
-### 第2步：知识新增
-根据审计结果和 sf_learn 积累的高频问题，生成新知识条目草稿。草稿保存到 .soloforge/knowledge/drafts/ 目录，人工 review 后移入正式目录。
+## 第2步：知识新增
+根据审计结果和 sf_stage_advance 积累的高频问题，生成新知识条目草稿。草稿保存到 .soloforge/knowledge/drafts/ 目录，人工 review 后移入正式目录。
 工具：sf_knowledge_add
 
-### 第3步：知识更新
+## 第3步：知识更新
 更新已有条目的决策边界、when 触发词、验收项。同步更新设计文档中对应的描述。标记废弃条目（不删除，标记 deprecated）。
 工具：sf_knowledge_update
 
-### 第4步：一致性验证
+## 第4步：一致性验证
 重新构建知识索引，验证新增/更新条目可被正确匹配。运行全量测试确认无功能影响。更新设计文档中的知识规模统计。
-工具：sf_verify, sf_learn
+工具：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,25 +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
-routes:
-  - code_change
-primary_triggers:
-  - 紧急修复流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-delivery-gate
 emits:
@@ -31,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_classify, sf_analyze
+工具：sf_command, sf_analyze
 
-### 第2步：最小修复
+## 第2步：最小修复
 从 main/release 分支拉取 hotfix 分支。编写最小修复代码（仅修复问题，不重构不优化），快速验证修复场景 + 回归核心功能。
-工具：sf_expand, sf_verify
+工具：sf_stage_execute, sf_gate_check
 
-### 第3步：验证部署
+## 第3步：验证部署
 合并到 main 和 release 分支，打 hotfix tag。部署到生产环境，验证修复效果，监控 30 分钟。
-工具：sf_verify, sf_deliver
+工具：sf_gate_check, sf_stage_advance
 
-### 第4步：故障复盘
-编写事故复盘（根因、影响范围、修复过程、暴露的监控盲区、后续改进项）。与 sf_learn 配合形成闭环。
+## 第4步：故障复盘
+编写事故复盘（根因、影响范围、修复过程、暴露的监控盲区、后续改进项）。与 sf_stage_advance 配合形成闭环。
 模版：故障复盘模版.md
 产出保存到：.soloforge/output/04-故障复盘.md
-工具：sf_learn
+工具：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,18 +5,10 @@ scope:
 products:
   - '*'
 id: ka-procedure-编码前澄清流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-core-engineering-principles
-routes:
-  - code_change
-primary_triggers:
-  - 编码前澄清流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-core-engineering-principles
 emits:
@@ -27,9 +19,10 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 type: procedure
-when: 编码前澄清流程
 stages: ["任务规划"]
+triggers: ["编码前澄清流程"]
 ---
+
 # 编码前澄清流程
 
 ## 适用场景
@@ -83,3 +76,8 @@ stages: ["任务规划"]
 - 写入 scope 不明确
 - 外部副作用未获授权
 - 存在未解决的 blocking 级不确定
+
+### 2.5 Blocking 超时约束
+- 用户未响应 >30 分钟 → 降级为 material，记录为 assumption_record
+- 同一 blocking 问题第 2 次未响应 → 自动记录假设，needs_manual_confirm=true
+- 超时降级不等于放行：假设须在编码完成后由用户确认

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,25 +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
-routes:
-  - code_change
-primary_triggers:
-  - 自主选型流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-decision-sovereignty
 emits:
@@ -31,6 +22,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["架构设计"]
+triggers: ["技术选型","不知道用什么","选型","方案对比","架构选型","方案选择","技术方案"]
 ---
 
 ## 适用场景
@@ -45,7 +37,7 @@ stages: ["架构设计"]
 6. 输出方案边界声明: 如实告知推荐方案的天花板，不做糖衣炮弹
 7. A/B 决策诱导: 输出两个精确选项，禁止提问"你想怎么做"
 8. 等待人类决策: 输入"选 A"或"选 B"后进入自动编码模式
-9. 基于选定方案继续 sf_expand 流程
+9. 基于选定方案继续 sf_stage_execute 流程
 
 ## 检查点
 - [ ] 至少 3 个行业标准方案已检索