soloforge 1.1.37 → 1.1.40

package/templates/patterns//351/242/206/345/237/237/351/251/261/345/212/250/350/256/276/350/256/241/350/247/204/350/214/203.md

@@ -1,37 +1,21 @@
 ---
 name: ddd-design
-when: '领域驱动设计, DDD, 领域模型, 聚合根, 值对象, 领域事件, 充血模型, 贫血模型, 模块设计'
 scope:
   - backend
 products:
   - '*'
 id: ka-pattern-ddd-design
-asset_kind: pattern
 lifecycle_status: active
 owner_mechanism_id: mc-backend-pattern
 authority: supporting
-routes:
-  - '*'
-primary_triggers:
-  - 领域驱动设计
-  - DDD
-  - 领域模型
-  - 聚合根
-  - 值对象
-  - 领域事件
-  - 充血模型
-  - 贫血模型
-  - 模块设计
 priority: P2
-specificity: 3
 version: 1.1.0
 last_reviewed: '2026-06-01'
 consumes: []
 emits: []
-secondary_triggers: []
-negative_triggers: []
 type: pattern
 stages: ["架构设计"]
+triggers: ["领域驱动设计","DDD","领域模型","聚合根","值对象","领域事件","充血模型","贫血模型","模块设计"]
 ---
 
 ## 决策规则

package/templates/procedures/OOD/350/256/276/350/256/241/345/267/245/344/275/234/346/265/201.md

@@ -1,28 +1,16 @@
 ---
 name: ood-design-workflow
 type: procedure
-when: '面向对象设计, SOLID, 领域服务, 业务规则实现, 重构'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-OOD设计工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-ood-solid-contract
-routes:
-  - code_change
-  - artifact_generation
-primary_triggers:
-  - OOD设计工作流
-secondary_triggers:
-  - SOLID
-negative_triggers:
-  - 文案修改
 priority: P1
-specificity: 5
 consumes:
   - mc-ood-solid-contract
 consumed_by:
@@ -30,24 +18,54 @@ consumed_by:
   - mc-backend-implementation-contract
 emits:
   - ood_design_summary
-  - code_review_findings
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["详细设计"]
+triggers: ["面向对象设计","SOLID","领域服务","业务规则实现","重构"]
 ---
 
+## 适用性判定（前置门控）
+
+| 判定条件 | 适用 | 不适用 |
+|---------|------|--------|
+| 复杂对象边界（多对象协作、继承/组合关系） | ✅ | |
+| 变化点（多策略/多实现/扩展点） | ✅ | |
+| 领域服务或业务规则封装 | ✅ | |
+| 简单 CRUD 或单表操作 | | ✅ |
+| 纯 UI/样式调整 | | ✅ |
+
+不适用时：记录"不适用理由"一句话，跳过本工作流。
+
 ## 步骤
 
-1. 判断任务是否确实存在对象边界或变化点，简单改动记录不适用理由。
-2. 列出对象职责、接口、依赖方向和主要协作流程。
-3. 对五项 SOLID 原则逐项说明适用风险与取舍。
-4. 编码后执行审查和验证，以实际源码 finding 为准。
-5. 存在硬失败则修复并重验，不能仅在报告中解释。
+### Step 1: 列出对象职责与依赖
+- **属性**: LLM 推理
+- **输入**: 架构设计文档中的模块/实体定义
+- **输出**: 对象职责清单 + 依赖方向图 + 主要协作流程
+
+### Step 2: SOLID 逐项分析
+- **属性**: LLM 推理
+- **输入**: Step 1 对象职责清单
+- **输出**: SOLID 风险与取舍分析
+- **Agent 行为**: 对 S/O/L/I/D 逐项分析，每项标注风险（高/中/低）+ 取舍说明
+
+### Step 3: 修正硬失败
+- **属性**: LLM 推理 + 确定性校验混合
+- **输入**: Step 2 SOLID 分析
+- **输出**: 修正后设计 + 验证证据
+- **Agent 行为**: 高风险项必须修正；修正后重新分析对应项；最多 3 轮；低风险项可标注"已知取舍"
 
 ## 输出摘要
 
-| 对象/模块 | 单一职责 | 依赖接口 | 变化点 | SOLID 风险 | 验证证据 |
-|---|---|---|---|---|---|
-| | | | | | |
+| 对象/模块 | 单一职责 | 依赖接口 | 变化点 | SOLID 风险等级 | 修正状态 | 验证证据 |
+|---|---|---|---|---|---|---|
+
+## 输出消费方式
+- 数据库设计（E-01 Step 2）和 API 设计（E-01 Step 3）引用本工作流的对象职责清单和 SOLID 分析
+- 编码后的 SOLID 审查由编码阶段代码审查流程负责，不在此工作流中
+
+## 注意事项
+- 本工作流仅在详细设计阶段执行，不跨阶段
+- 输出摘要表必须填写完整，不得留空行

package/templates/procedures/Schema/345/217/230/346/233/264/346/265/201/346/260/264/347/272/277.md

@@ -1,24 +1,15 @@
 ---
 name: schema-change-pipeline
 type: pipeline_procedure
-when: '数据库结构变更, 加字段, 改字段, 新建表, 加索引, DDL变更, schema变更, 数据库迁移'
 scope:
   - backend
 products:
   - '*'
 id: ka-procedure-Schema变更流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-knowledge-asset-governance
-routes:
-  - code_change
-primary_triggers:
-  - Schema变更流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-knowledge-asset-governance
 emits:
@@ -30,25 +21,26 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["数据库结构变更","加字段","改字段","新建表","加索引","DDL变更","schema变更","数据库迁移"]
 ---
 
 # 数据库变更管线
 
-### 第1步：变更设计
+## 第1步：变更设计
 评估变更类型（加列/改列/删列/加索引/数据迁移/新建表）。确认向前兼容性（新列默认值或允许 NULL）。制定四层兼容策略（数据库→接口契约→前端展示→导出逻辑）。
 模版：数据库变更方案模版.md
 产出保存到：.soloforge/output/01-变更方案.md
-工具：sf_classify
+工具：sf_command
 
-### 第2步：迁移脚本
+## 第2步：迁移脚本
 编写 migration 脚本（正向 + 回滚），确保幂等。大表加列使用分批更新策略。大表加索引使用 ONLINE DDL。禁止 migration 中写业务逻辑。
 产出保存到：.soloforge/output/02-migration.sql
-工具：sf_expand
+工具：sf_stage_execute
 
-### 第3步：代码适配
+## 第3步：代码适配
 更新 Entity/DTO 映射。更新接口契约（请求/响应字段）。更新前端展示和表单。更新导出逻辑（如有）。更新相关测试数据和测试用例。
-工具：sf_expand
+工具：sf_stage_execute
 
-### 第4步：验证验收
+## 第4步：验证验收
 开发环境执行 migration 验证表结构。运行全量测试。代码审查重点关注：四层兼容完整性、回滚脚本有效性、大表性能影响评估。
-工具：sf_verify, sf_review, sf_learn
+工具：sf_gate_check, sf_review, sf_stage_advance

package/templates/procedures//344/270/215/347/241/256/345/256/232/346/227/266/345/244/264/350/204/221/351/243/216/346/232/264/346/265/201/347/250/213.md

@@ -0,0 +1,92 @@
+---
+name: brainstorm-when-uncertain
+type: procedure
+scope: ['*']
+stages: ["需求分析", "架构设计", "详细设计", "编码与单元测试"]
+lifecycle_status: active
+owner_mechanism_id: mc-generic-review
+id: ka-procedure-不确定时头脑风暴流程
+authority: supporting
+priority: P0
+version: 1.0.0
+last_reviewed: '2026-06-04'
+triggers: ["头脑风暴", "brainstorm", "不确定", "你看着办", "都行"]
+---
+
+# 不确定时头脑风暴流程
+
+## 适用场景
+
+当用户表达不确定、需求不明确、技术选型开放、或 AI 自检不确定时，触发本流程辅助决策。本流程为全局流程，不属于特定管线阶段。
+
+## 不确定类型分类
+
+| 类型 | 触发关键词/信号 | 典型场景 |
+|------|---------------|---------|
+| 用户不确定 | "你看着办"/"都行"/"不确定"/"都可以" | 用户对方案选择无偏好 |
+| 需求不明确 | 需求描述矛盾/遗漏/模糊 | 需求文档存在冲突 |
+| 技术选型开放 | 多种技术方案均可/无明确约束 | 架构设计阶段技术选型 |
+| AI 自检不确定 | 置信度低/多种解释均合理 | AI 无法确定用户真实意图 |
+
+## 流程步骤
+
+### 步骤 1：识别不确定类型
+区分四类不确定，确定进入头脑风暴的原因。
+
+### 步骤 2：列举候选方案（≥ 3 个）
+每个候选方案须包含：
+- 描述：方案概述
+- 优势：该方案的优点
+- 劣势：该方案的缺点
+- 适用场景：最适合的情况
+
+**检查点**：方案间有本质区别（非假多样性）。若 3 个方案本质相同（仅措辞不同），须重新思考。
+
+**若 fundamental_need 为空 → 必须先触发 FP-01**（第一性原理推理规则），补充根本目标后再继续。
+
+### 步骤 3：标注 AI 偏好
+对每个方案标注 AI 偏好：推荐/可选/不推荐 + 理由。AI 偏好基于：
+- 与 fundamental_need 的契合度
+- 技术复杂度和风险
+- 项目约束条件
+- 维护成本
+
+### 步骤 4：呈现给用户
+以对比表格呈现，突出关键差异维度。表格至少包含：方案/优势/劣势/AI偏好/推荐理由。
+
+### 步骤 5：用户选择
+用户明确选择一个方案。用户回复须为明确的方案选择（非"都可以"/"你定"）。
+
+**未通过** → 进入用户模糊降级策略。
+
+### 步骤 6：记录决策
+将用户选择写入对应阶段产物：
+- 需求分析 → 更新需求分析文档
+- 架构设计 → 更新架构决策记录
+- 详细设计 → 更新设计文档
+- 编码阶段 → 更新技术决策注释
+
+## 用户模糊降级策略
+
+当用户回复仍为模糊/不确定时，按 3 级降级处理：
+
+| 级别 | 降级策略 | 条件 |
+|------|---------|------|
+| 1 级 | 重新引导 | 用户首次模糊 → 重新解释差异，追问偏好维度 |
+| 2 级 | 标注偏好 + 可推翻 | 用户二次模糊 → AI 标注推荐方案，告知用户可推翻 |
+| 3 级 | 直接采纳 | 用户三次模糊 → AI 采纳推荐方案，记录"用户未明确选择" |
+
+## 互触发关系
+
+| 触发条件 | 触发动作 |
+|---------|---------|
+| 头脑风暴步骤 2 中 fundamental_need 为空 | → 触发 FP-01（第一性原理推理规则） |
+| FP-03 检测到表面修复（同类问题 ≥ 3 次） | → 建议触发第一性原理推理 |
+| FP-01 和头脑风暴同时需要时 | → FP-01 优先（先确定根本目标，再做方案选择） |
+
+## 禁止行为
+
+1. **禁止直接选唯一方案**：不得在未列举 ≥ 3 个方案的情况下直接推荐唯一方案
+2. **禁止用"建议"替代对比**：不得仅说"建议方案 A"而不提供方案对比
+3. **禁止跳过枚举**：不得跳过候选方案列举步骤直接进入用户选择
+4. **禁止 3 方案本质相同**：候选方案间须有本质区别，不得通过假多样性绕过

package/templates/procedures//344/270/273/351/223/276/350/267/257/346/216/245/345/205/245/351/252/214/350/257/201/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-main-path-integration
-routes:
-  - code_change
-primary_triggers:
-  - 主链路接入验证流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-main-path-integration
 emits:
@@ -24,12 +16,13 @@ emits:
   - module_accessibility_status
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 type: procedure
-when: 主链路接入验证流程
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["主链路接入验证流程"]
 ---
+
 # 主链路接入验证流程
 
 ## 步骤
@@ -38,6 +31,10 @@ stages: ["编码与单元测试", "联调验证"]
 2. 扫描谁导入了该模块 (scanModuleImporters)
 3. 从入口点追踪可达性 (traceModuleReachability)
 4. 收集可观测证据 (collectModuleObservability)
+   evidence_required:
+     - "模块导入者列表（scanModuleImporters 输出）"
+     - "入口点可达性追踪日志（traceModuleReachability 输出）"
+     - "集成测试文件路径（findIntegrationTests 输出）"
 5. 查找集成测试 (findIntegrationTests)
 6. 判断接入状态 (integrated / implemented_not_integrated / ...)
 7. 运行 orphanGate 和 validateMainPathIntegration

package/templates/procedures//344/273/243/347/240/201/351/227/250/347/246/201/346/265/201/347/250/213.md

@@ -1,25 +1,16 @@
 ---
 name: code-gate
 type: procedure
-when: '代码门禁, 代码审查门禁, gate review, 发布门禁, 上线检查, 代码评审, 发布审查'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-代码门禁流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-guard-evaluation
-routes:
-  - code_change
-primary_triggers:
-  - 代码门禁流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-guard-evaluation
 emits:
@@ -30,6 +21,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["代码门禁","代码审查门禁","gate review","发布门禁","上线检查","代码评审","发布审查"]
 ---
 
 ## 适用场景

package/templates/procedures//344/273/273/345/212/241/346/213/206/350/247/243/346/265/201/347/250/213.md

@@ -1,25 +1,16 @@
 ---
 name: task-breakdown
 type: procedure
-when: '任务拆解, 工作分解, task breakdown, 任务拆分, 任务规划, 工单, 工作拆分'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-任务拆解流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-intent-expander
-routes:
-  - code_change
-primary_triggers:
-  - 任务拆解流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-intent-expander
 emits:
@@ -27,9 +18,10 @@ emits:
   - task_cards
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["任务规划"]
+triggers: ["任务拆解","工作分解","task breakdown","任务拆分","任务规划","工单","工作拆分"]
 ---
 
 ## 适用场景
@@ -38,10 +30,16 @@ stages: ["任务规划"]
 ## 步骤
 1. 确定工单模式：skip（跳过）/ mini（简化）/ full（完整），基于变更类型和风险等级
 2. 先产出交付蓝图：目标、冲突、推荐方案、确认状态、验收标准、3 轮重试策略
+   - **选择分解策略**：
+     - sequential：串行依赖链（A→B→C）——适用强依赖场景
+     - parallel：并行扇出（A→[B,C,D]）——适用独立模块
+     - hierarchical：分层递归（A→[B→[C,D], E]）——适用复杂嵌套
+     - 策略写入切片计划「分解策略」字段
 3. 生成任务卡片：每张卡有明确成功标准、上游引用、验收映射和测试映射
 4. DDL 独立为前置任务；多服务按服务拆分；单接口/页面可合并为一张可验证卡
 5. 控制实现上下文：必须读/可选读/默认不读列表，引用上游路径而非复制全文
 6. 验证可追溯性：每张任务卡追溯到需求、接口和设计锚点
+7. **生成依赖图**：基于任务卡片依赖声明生成分组依赖图（同组 parallel/跨组 sequential/regression_blocking 标注）
 
 ## 检查点
 - [ ] 工单模式匹配风险等级和变更类型
@@ -49,6 +47,7 @@ stages: ["任务规划"]
 - [ ] 任务卡追溯到需求和设计锚点，无孤立任务
 - [ ] DDL 独立为前置任务
 - [ ] 外部系统/大表 DDL/数据迁移/权限安全标记为高风险
+- [ ] 分解策略已声明（sequential/parallel/hierarchical）
 
 ## 注意事项
 - 禁止复制上游全文到工单中（引用路径）

package/templates/procedures//344/273/273/345/212/241/350/247/204/345/210/222/345/267/245/344/275/234/346/265/201.md

@@ -0,0 +1,83 @@
+---
+name: task-planning-workflow
+type: procedure
+scope:
+  - '*'
+system_scope: existing-system
+products:
+  - '*'
+id: ka-procedure-任务规划工作流
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-existing-system-artifact
+priority: P1
+consumes:
+  - mc-existing-system-artifact
+emits:
+  - structured_slice_plan
+  - historical_data_cleanup_script
+required_evidence:
+  - 切片计划文件路径
+  - 清洗脚本文件路径
+version: 1.0.0
+last_reviewed: '2026-06-04'
+stages: ["任务规划"]
+triggers: ["任务规划工作流","老系统任务规划","切片缓冲规划","清洗脚本产出","任务规划流程"]
+---
+
+# 任务规划工作流（老系统专属）
+
+> 适用范围：老系统管线阶段 5（任务规划）
+> 输入：详细设计文档 + 一键开关配置 + 回滚手册 + 改造影响范围评估
+> 输出：带缓冲切片计划 + 历史数据清洗脚本
+
+## 步骤 1：读取阶段输入
+
+1. 读取详细设计文档
+2. 读取一键开关配置
+3. 读取紧急回滚手册
+4. 读取改造影响范围评估
+5. **检查点**：所有输入产物存在且可读
+6. 在切片计划 §1.5 阶段输入声明中，逐项标注 ☑ 已读取
+
+## 步骤 2：按切片规划规则拆分切片
+
+1. 使用 shared 切片规划规则（与新系统相同）
+2. 产出切片列表，每个切片标注：DD-* 编号、模块、影响范围
+3. **检查点**：每个切片均有 DD-* 或 ARCH-* 上游引用
+
+## 步骤 3：计算排查缓冲（老系统专属）
+
+1. 对每个切片按特征匹配缓冲比例（见切片计划 §3 判定标准）
+2. 产出结构化缓冲表格（见切片计划 §2 排查缓冲字段）
+3. **检查点**：涉及 DB 迁移的切片缓冲 ≥ 35%
+
+## 步骤 4：产出历史数据清洗脚本
+
+1. 识别涉及数据迁移的切片（缓冲比例 ≥ 35%）
+2. 按清洗脚本模版产出：清洗 SQL + 备份 SQL + 回滚 SQL
+3. 在切片计划 §5 中建立脚本与切片的关联
+4. **检查点**：涉及 DB 迁移的切片均有对应清洗脚本
+
+## 步骤 5：自检
+
+1. 切片与详细设计 DD-* 编号对齐
+2. 排查缓冲表格每项活动有预估时间
+3. 阶段输入声明中所有产物已标注"已读取"
+4. §5 中涉及 DB 迁移的切片均有清洗脚本关联
+
+## 步骤 6：gate-任务规划 校验
+
+1. 运行 gate-任务规划（shared 检查 + 老系统扩展检查）
+2. 通过 → 进入编码阶段
+3. 失败 → 返回对应步骤修正
+
+### 失败回退映射
+
+| gate 检查失败项 | 回退步骤 |
+|---------------|---------|
+| 切片计划完备 | 步骤 2 |
+| 切片与接口/数据库一致性 | 步骤 2 |
+| 排查缓冲完整性（老系统） | 步骤 3 |
+| 阶段输入声明完整性（老系统） | 步骤 1 |
+| 清洗脚本关联完整性（老系统） | 步骤 4 |

package/templates/procedures//344/274/232/350/257/235/346/201/242/345/244/215/346/265/201/347/250/213.md

@@ -1,27 +1,15 @@
 ---
 name: session-resume
 type: procedure
-when: '会话启动, 恢复, resume, 继续开发'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-会话恢复流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-routes:
-  - code_change
-  - planning
-primary_triggers:
-  - 会话恢复流程
-secondary_triggers:
-  - 恢复上下文
-  - 继续上次工作
-negative_triggers: []
 priority: P1
-specificity: 5
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码与单元测试", "代码审查", "联调验证"]
@@ -34,6 +22,7 @@ emits:
   - task_context_snapshot
 required_evidence:
   - session_resume_report
+triggers: ["会话启动","恢复","resume","继续开发"]
 ---
 
 # 会话恢复流程
@@ -51,7 +40,7 @@ required_evidence:
 
 ### 步骤 1: 检查工作区状态
 
-1. 读取 `.soloforge/config.yaml` 获取项目配置
+1. 通过 `resolveProjectConfig()` 恢复项目配置（优先读取 intent.yaml，回退到项目文件探测）
 2. 检查 `tasks/` 目录中是否存在未完成的任务
 3. 检查 git 工作区是否有未提交的变更
 

package/templates/procedures//345/205/250/347/224/237/345/221/275/345/221/250/346/234/237/345/267/245/344/275/234/346/265/201/345/257/274/350/210/252.md

@@ -1,28 +1,16 @@
 ---
 name: full-lifecycle-navigation
 type: procedure
-when: '下一步, 继续, 现在能写代码吗, 工作流导航, navigation, 阶段判断, 工作包生成'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-全生命周期工作流导航
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-workflow-navigation-contract
-routes: ['operation', 'artifact_generation']
-primary_triggers:
-  - 全生命周期工作流导航
-secondary_triggers:
-  - 下一步
-  - 继续
-  - 现在能写代码吗
-  - 阶段导航
-negative_triggers: []
 priority: P0
-specificity: 5
 consumes:
   - mc-workflow-navigation-contract
   - current_task_context
@@ -39,6 +27,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码与单元测试", "代码审查", "联调验证"]
+triggers: ["下一步","继续","现在能写代码吗","工作流导航","navigation","阶段判断","工作包生成"]
 ---
 
 # 全生命周期工作流导航
@@ -49,9 +38,9 @@ stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码
 
 | 阶段 | 判断条件 | 下一步 |
 |------|----------|--------|
-| 未初始化 | .soloforge/ 不存在或无 config.yaml | 运行 soloforge init |
-| 配置待确认 | config.yaml 存在但字段未确认 | 先区分自动修复项和业务确认项；机械类型/evidence 问题运行 soloforge config repair，业务口径再运行 soloforge config confirm |
-| 知识就绪 | 配置已确认、知识库已索引 | 提交开发意图开始新任务 |
+| 未初始化 | .soloforge/ 不存在或无 intent.yaml | 运行 soloforge init |
+| 配置不完整 | resolveConfig 返回 missing 字段 | 通过 `soloforge config set` 或 `sf_config_update` 补充不可探测偏好（产品类型、交付设置等）；技术栈和构建命令由项目文件自动探测 |
+| 知识就绪 | 配置完整（tech_stack + build_commands 已就绪）、知识库已索引 | 提交开发意图开始新任务 |
 | 设计进行中 | 设计产物存在但未通过审计 | 完成设计并通过审计 |
 | 实现就绪 | 设计产物已通过审计 | 制定开发切片计划 |
 | 开发进行中 | 有任务在编码/验证阶段 | 继续编码和验证 |
@@ -68,8 +57,9 @@ stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码
 ## 导航决策流程
 
 1. 调用 `sf_navigation` 或 `soloforge next` 获取当前状态
-2. 检查是否有陈旧任务需要处理
-3. 读取 `confirmation_decisions`
+2. 检查配置完整性：resolveConfig 返回 missing 时，优先补充不可探测字段
+3. 检查是否有陈旧任务需要处理
+4. 读取 `confirmation_decisions`
    - `must_confirm` 非空时，先让用户选择，不得继续执行会被阻断的动作
    - `should_confirm` 非空时，明确说明建议确认的收益，但允许继续只读或低风险准备
    - `auto_resolvable` 非空时，按推荐命令修复或复验，不把它伪装成业务确认
@@ -101,12 +91,13 @@ stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码
 当 Edit、Write、Bash 或 MCP 工具被 SoloForge 阻断时：
 
 - 先读取阻断输出中的 `recovery_command`、`template_path` 和 `confirmation_decisions`
+- 配置不完整时，按 `soloforge config set` 补充缺失字段后重试
 - 自动修复项按命令修复后重试对应工具
 - 业务确认项列出具体必须确认内容后等待用户确认
 - 不得取消任务后直接写代码
 - 不得改用 Bash 绕过受控任务、设计复验或追踪矩阵
 - 不得手动删除 `.soloforge/state`
-- 若确认为陈旧任务，必须通过 `sf_status action=archive_stale confirm=true` 或导航推荐命令归档，再重新 `sf_classify -> sf_expand`
+- 若确认为陈旧任务，必须通过 `sf_status action=archive_stale confirm=true` 或导航推荐命令归档，再重新 `sf_command -> sf_stage_execute`
 
 ## 常见导航场景