sillyspec 3.19.2 → 3.20.0

package/src/stages/plan.js

@@ -1,6 +1,16 @@
-import { existsSync, readFileSync } from 'fs'
+import { existsSync, readFileSync, readdirSync } from 'fs'
 import path from 'path'
 
+// 从 plan-postcheck.js 重导出（保持向后兼容）
+export {
+  topoSortWaves,
+  validateBlueprintConsistency,
+  validatePlanArtifacts,
+  validatePlanFeasibility
+} from './plan-postcheck.js'
+
+// 这些解析函数已迁移到 plan-postcheck.js，此处不再定义
+
 /**
  * 校验 design.md 是否满足 plan 执行契约
  * 第一版是轻量 markdown 结构检查，不强 schema。
@@ -66,15 +76,28 @@ export const definition = {
   steps: null // 动态生成
 }
 
-// 固定前缀步骤
-export const fixedPrefix = [
-  {
-    name: '复杂度分类',
-    prompt: `在生成计划之前，先判定本次需求的复杂度等级（plan_level）。
+// ═══════════════════════════════════════════════════════════════
+// 第 1 步（LLM）：复杂度分类 + 上下文加载（合并原 ①②③④）
+// ═══════════════════════════════════════════════════════════════
+
+const stepClassify = {
+  id: 'classify',
+  name: '复杂度分类与上下文加载',
+  prompt: `在生成计划之前，先加载上下文并判定本次需求的复杂度等级（plan_level）。
 
 ### 操作
-1. 读取 tasks.md 和 design.md，了解需求范围
-2. 按「分级规则」判定 plan_level
+1. 运行 \`sillyspec progress show\`，确认 currentStage 为 "plan"
+2. 读取 CODEBASE-OVERVIEW.md + 各子项目上下文
+3. 读取 proposal.md、design.md、requirements.md、tasks.md
+4. 如果存在 decisions.md，必须读取并提取所有当前版本 D-xxx@vN 决策 ID
+   - 如果发现 priority=P0/P1 且 status=unresolved/blocking 的决策，停止生成计划，要求先回到 brainstorm 的 Design Grill 修正
+   - 如果发现 superseded 决策，只引用最新版本，不引用旧版本
+5. 读取 CONVENTIONS.md、ARCHITECTURE.md、STACK.md
+6. 读取 local.yaml 获取构建/测试命令
+7. 读取 \`.sillyspec/docs/<project>/modules/_module-map.yaml\`（不存在则跳过）
+   - 根据 design.md 的文件变更清单匹配模块
+   - 读取匹配到的模块文档
+   - 利用模块依赖关系辅助分析（depends_on / used_by）
 
 ### 分级规则
 判定 plan_level 为 none 时，需**同时满足**以下所有条件：
@@ -118,72 +141,27 @@ needs_parallel_execution: true | false
 needs_human_review: true | false
 \`\`\`
 
-分类完成后，继续进入下一步。`,
-    outputHint: '复杂度分类结果',
-    optional: false
-  },
-  {
-    name: '状态检查',
-    prompt: `检查当前状态，确认可以执行 plan。
-
-### 操作
-1. 运行 \`sillyspec progress show\`
-2. 确认 currentStage 为 "plan"
-
-### 输出
-当前状态摘要`,
-    outputHint: '状态摘要',
-    optional: false
-  },
-  {
-    name: '加载上下文',
-    prompt: `加载所有规范文件和代码库上下文。
-
-### 操作
-1. 读取 CODEBASE-OVERVIEW.md + 各子项目上下文
-2. 读取 proposal.md、design.md、requirements.md、tasks.md
-3. 如果存在 decisions.md，必须读取并提取所有当前版本 D-xxx@vN 决策 ID
-   - 如果发现 priority=P0/P1 且 status=unresolved/blocking 的决策，停止生成计划，要求先回到 brainstorm 的 Design Grill 修正
-   - 如果发现 superseded 决策，只引用最新版本，不引用旧版本
-4. 读取 CONVENTIONS.md、ARCHITECTURE.md、STACK.md
-5. 读取 local.yaml 获取构建/测试命令
-
-### 模块文档加载
-6. 读取 \`.sillyspec/docs/<project>/modules/_module-map.yaml\`（不存在则跳过以下步骤）
-7. 根据 design.md 的文件变更清单匹配 _module-map.yaml 中的模块
-8. 读取匹配到的 \`.sillyspec/docs/<project>/modules/<module>.md\`
-9. 将模块文档作为制定计划的上下文，确保计划符合模块当前设计
-10. **利用模块依赖关系辅助分析**：
-   - 用 depends_on 判断哪些模块会被间接影响
-   - 用 used_by 判断变更会不会影响下游模块
-   - 将依赖关系纳入 Wave 分组决策（依赖同一模块的任务尽量同 Wave）
-   - 如果变更涉及多个有依赖关系的模块，在 plan.md 的任务总表中标注模块依赖
+然后列出已加载的文件清单（含 decisions.md 当前版本/未决项状态、模块文档 + 模块依赖关系摘要）。
 
-### 输出
-已加载的文件清单（含 decisions.md 当前版本/未决项状态、模块文档 + 模块依赖关系摘要）`,
-    outputHint: '文件清单',
-    optional: false
-  },
-  {
-    name: '锚定确认',
-    prompt: `确认已读取的文件。
+分类完成后，继续进入下一步。`,
+  outputHint: '复杂度分类结果 + 文件清单',
+  optional: false
+}
 
-### 操作
-列出已读取的文件，标注存在/不存在。
+// ═══════════════════════════════════════════════════════════════
+// 第 2 步（LLM）：生成分级计划 + 自检（合并原 ⑤⑥）
+// ═══════════════════════════════════════════════════════════════
 
-### 输出
-文件加载确认清单`,
-    outputHint: '文件确认清单',
-    optional: false
-  },
-  {
-    name: '按复杂度生成分级计划',
-    prompt: `根据「复杂度分类」步骤的 plan_level 结果，按对应级别生成计划。
+const stepGeneratePlan = {
+  id: 'generate_plan',
+  name: '生成分级计划与自检',
+  prompt: `根据上一步的 plan_level 结果，按对应级别生成计划，然后立即自检。
 
 ### 操作
 1. 读取上一步输出的 plan_level 分类结果
 2. 读取 tasks.md 和 design.md 了解需求范围
 3. 按 plan_level 选择对应模板输出
+4. 生成后立即自检（见下方自检清单）
 
 ---
 
@@ -247,7 +225,7 @@ plan_level: light
 light 计划的约束：
 - **禁止**生成 Mermaid 图
 - **禁止**估时
-- **禁止**泛泛风险 分析（如"需要充分测试"）
+- **禁止**泛泛风险分析（如"需要充分测试"）
 - **禁止**放实现细节（函数签名、代码示例）
 - 来源/目标直接引用已有文档，不重新生成
 - 如果存在 decisions.md，所有当前版本 D-xxx@vN 必须在 Tasks 或覆盖矩阵中出现
@@ -339,16 +317,10 @@ full 计划的约束：
 5. 保存到变更目录下的 plan.md（路径格式：\`.sillyspec/changes/<change-name>/plan.md\`，其中 <change-name> 是变更目录名，直接使用，不加子目录。正确路径示例：\`.sillyspec/changes/2026-05-28-agent-log-streaming/plan.md\`）
 **plan_level 为 none 时生成最小 plan.md（占位），不生成完整蓝图。**
 
-### 输出
-plan_level + 计划内容（none 级别输出建议操作）`,
-    outputHint: '计划内容',
-    optional: false
-  },
-  {
-    name: '自检总览',
-    prompt: `根据 plan_level 检查对应的计划质量。
+---
+
+### 自检（生成后立即执行，不另开步骤）
 
-### 操作
 读取上一步的 plan_level 分类结果，按级别执行对应的自检：
 
 #### plan_level = none
@@ -390,213 +362,18 @@ plan_level + 计划内容（none 级别输出建议操作）`,
 - [ ] 没有泛泛风险分析（如"需要充分测试"）
 
 ### 输出
-自检通过/不通过（附 plan_level）`,
-    outputHint: '自检结果',
-    outputHint: '自检结果',
-    optional: false
-  }
-]
-
-// 固定后缀步骤
-export const fixedSuffix = [
-  {
-    name: '重排 Wave（基于 depends_on）',
-    prompt: `根据蓝图的 depends_on 字段重排 Wave 分组，更新 plan.md。
-
-### 操作
-1. 读取所有 tasks/task-NN.md 的 frontmatter，提取每个任务的 depends_on 列表
-2. 拓扑排序：无依赖的任务 → Wave 1，依赖 Wave 1 的 → Wave 2，依此类推
-3. 检查是否存在循环依赖，如有则报错暂停
-4. 用重排结果更新 plan.md：
-   - Wave 分组（含 checkbox 列表）
-   - 任务总表的 Wave 列
-   - 依赖关系图（Mermaid）
-   - 关键路径
-5. 如果 Wave 分组与原始 plan.md 一致，只需确认一致即可，不需要重写
-
-### 规则
-- **Wave 是执行单元，同 Wave 内任务必须无依赖（可并行）**
-- 有 depends_on 关系的任务必须在不同的 Wave
-- depends_on 为空的任务放 Wave 1
-- 取决于拓扑排序的最大深度决定 Wave 编号
-
-### 输出
-重排后的 Wave 分组摘要（如果与原 plan.md 一致则说明一致）`,
-    outputHint: 'Wave 重排结果',
-    optional: false
-  },
-  {
-    name: '审查一致性',
-    prompt: `审查所有 task-N.md 的一致性。
-
-### 操作
-1. 读取所有 tasks/task-NN.md
-2. 检查：
-   - 文件路径有没有冲突（两个任务改同一个文件）
-   - 依赖关系和 plan.md 的 Wave 分组是否一致
-   - 验收标准和 plan.md 的全局标准是否矛盾
-   - 接口定义是否自洽
-5. **生产接线路径检查**（Critical）：
-   - 读取 design.md，搜索以下关键词：
-     - 注入 / inject / 构造 / constructor / 初始化 / init / 启动路径 / startup / main / cli / entrypoint / daemon start / bootstrap
-     - 如果命中，提取提到的具体文件名（如 "在 cli.ts 中"、"main.ts 中实例化"、"Daemon 构造函数"）
-   - 收集所有 tasks/task-NN.md 的 frontmatter 中 \`allowed_paths\` 列表
-   - 检查：design 中提到的生产入口文件是否在某个 task 的 allowed_paths 中？
-   - 如果 design 提到了入口文件但所有 task 的 allowed_paths 都不含该文件：
-     - **这是 plan contract 失败**
-     - 列出具体矛盾：\`design says: X 实例化 Y，但 allowed_paths 不含 Z\`
-     - **不自动修复**，暂停等待用户决定
-   - 如果 design 明确说"不需要改入口文件"并给出了理由，视为通过
-   - 调用：\`sillyspec run plan --wait --reason "生产接线路径检查失败" --options "修改 allowed_paths,修改 design,确认不需要改入口" --output "矛盾清单"\`
-6. **符号影响面检查**（Critical）：
-   - 对每个 task 涉及的文件，检查是否修改了构造函数、接口、DTO、API client 方法签名
-   - 如果是，搜索所有调用点：
-     \`\`\`bash
-     rg "new <ClassName>" src/
-     rg "<methodName>" src/ --type ts --type js
-     \`\`\`
-   - 对比调用点与 plan.md/task 的 allowed_paths
-   - 发现调用点不在任务范围内 → **plan contract 失败**
-   - 调用：\`sillyspec run plan --wait --reason "符号影响面检查发现遗漏调用点" --options "扩展 allowed_paths,添加新任务,确认不需要改" --output "遗漏调用点清单"\`
-3. 发现问题 → 列出问题清单，暂停等待用户决定
-   - 调用：\`sillyspec run plan --wait --reason "审查发现一致性问题" --options "自动修复,手动修复,忽略并继续" --output "问题清单"\`
-   - **绝对禁止**：自己决定修复方向然后自动修复
-4. 无问题 → 正常完成
-
-### 输出
-一致性审查结果`,
-    outputHint: '审查结果',
-    optional: false
-  },
-  {
-    name: '保存并更新进度',
-    prompt: `确认所有文件已保存，更新进度。
-
-### 操作
-1. 确认 plan.md 和所有 tasks/task-NN.md 已存在
-
-### 输出
-文件列表 + 下一步命令`,
-    outputHint: '文件列表',
-    optional: false
-  }
-]
-
-/**
- * 解析 plan.md 获取任务数量
- */
-function parseTaskCount(planContent) {
-  if (!planContent || typeof planContent !== 'string') return 0
-  const matches = planContent.match(/^[-*]\s*\[[ x]\]\s*task-\d+/gm)
-  return matches ? matches.length : 0
+plan_level + 计划内容 + 自检结果（一次输出）`,
+  outputHint: '计划内容 + 自检结果',
+  optional: false
 }
 
-/**
- * 生成单个任务的蓝图写作 prompt
- */
-function buildTaskPrompt(taskNum, taskName, changeDir) {
-  const num = String(taskNum).padStart(2, '0')
-  return `编写任务蓝图 tasks/task-${num}.md
-
-当前时间：<now-datetime>（frontmatter 的 created_at 使用此值）
-当前用户：<git-user>（frontmatter 的 author 使用此值）
-
-### 任务
-${taskName}
-
-### 文件路径
-\`.sillyspec/changes/<change-name>/tasks/task-${num}.md\`
-
-### 格式要求（必须严格遵守）
-\`\`\`markdown
----
-id: task-${num}
-title: ${taskName}
-priority: P0
-estimated_hours: N
-depends_on: []
-blocks: []
-requirement_ids: [FR-01]
-decision_ids: [D-001@v1]
-allowed_paths:
-  - 允许修改的路径范围
----
-
-# task-${num}: ${taskName}
-
-## 修改文件（必填）
-- 精确到文件路径，列出所有需要新增或修改的文件
-
-## 覆盖来源
-- Requirements: FR-xx（来自 requirements.md）
-- Decisions: D-xxx@vN（如存在 decisions.md）
-
-## 实现要求
-1. 具体做什么，写清楚
-2. ...
-
-## 接口定义（代码类任务必填）
-写方法签名、数据结构、控制流伪代码。AI executor 应能照着直接编码。
-
-## 边界处理（必填）
-- null/空值行为
-- 兼容旧行为（brownfield：未配置新功能时行为不变）
-- 异常不静默吞掉（明确返回值或抛出）
-- 不修改传入参数
-- 歧义/冲突场景的处理策略
-
-## 非目标（本任务不做的事）
-- 明确列出边界，防止 scope creep
-
-## 参考
-- 已有代码可参考的模式
-- 相关的 CONVENTIONS.md 条目
-
-## TDD 步骤
-1. 写 XxxTest，覆盖场景 A/B/C
-2. 运行 <test-cmd> 确认测试失败
-3. 实现 Xxx
-4. 运行 <test-cmd> 确认测试通过
-5. 运行全量测试确认无回退
-（纯配置/文档类任务简化为：1. 实现 2. 验证）
-
-## 验收标准
-| # | 验证步骤 | 通过标准 |
-|---|---|---|
-| AC-01 | 具体操作 | 期望结果 |
-| AC-02 | ... | ... |
-\`\`\`
-
-### frontmatter 元数据说明
-- \`priority\`: P0（必须）/ P1（重要）/ P2（可选）
-- \`estimated_hours\`: 预估工时，单个 task ≤ 8h
-- \`depends_on\`: 依赖的前序 task 编号列表
-- \`blocks\`: 被本 task 阻塞的后续 task 编号列表
-- \`requirement_ids\`: 本任务覆盖的 FR-xxx 列表
-- \`decision_ids\`: 本任务覆盖的当前版本 D-xxx@vN 列表；无 decisions.md 时可为空数组
-- \`allowed_paths\`: AI executor 可以修改的文件路径范围（安全边界）
-
-### 关键规则
-- task-N.md 必须独立完整，execute 子代理只读这一个文件就能干活
-- 不要依赖其他 task-N.md 的内容
-- 接口定义写到"搬砖工照着做"的程度
-- 边界处理至少覆盖 5 条规则
-- 验收标准用表格格式，每条可点击验证，禁止"功能可演示"类笼统表述
-- 如果存在 decisions.md，不允许丢失当前版本 D-xxx@vN；无法覆盖的 D-xxx@vN 必须写入非目标或剩余风险
-- 写完后保存到文件
-
-### 操作
-1. 读取 design.md 和 plan.md 了解上下文
-2. 读取相关源文件了解现有代码
-3. 编写任务蓝图
-4. 保存到 tasks/task-${num}.md
-
-### 输出
-任务蓝图内容摘要`
-}
+// ═══════════════════════════════════════════════════════════════
+// 第 3 步（LLM）：生成紧凑 TaskCard（子代理并行）
+// ═══════════════════════════════════════════════════════════════
 
 /**
- * 构建任务蓝图协调器步骤（单步，子代理并行写蓝图）
+ * 构建紧凑 TaskCard 协调器步骤（单步，子代理并行写卡片）
+ * 每个 task 生成 20~40 行紧凑可执行卡片
  */
 export function buildCoordinatorStep(changeDir, taskNames) {
   const taskList = taskNames.map((name, i) => {
@@ -615,76 +392,54 @@ export function buildCoordinatorStep(changeDir, taskNames) {
 
 操作：
 1. 读取 ${changeDir}/design.md 和 ${changeDir}/plan.md 了解上下文
-2. 读取相关模块文档（如存在）：
-   - \
-ls .sillyspec/docs/*/modules/_module-map.yaml 2>/dev/null\
-   确认模块划分，读取涉及模块的 \
-ls .sillyspec/docs/*/modules/*.md 2>/dev/null\
-3. 读取相关源文件了解现有代码
-4. 按以下格式编写任务蓝图并保存到 ${changeDir}/tasks/task-${num}.md：
+2. 读取相关源文件了解现有代码
+3. 生成紧凑 TaskCard（20~40 行），格式如下：
 
 ---
 id: task-${num}
 title: ${name}
-priority: P0/P1/P2
-estimated_hours: N
-depends_on: [task-XX]
-blocks: [task-XX]
+author: <git-user>
+created_at: <now-datetime>
+priority: P0
+depends_on: []
+blocks: []
 requirement_ids: [FR-XX]
 decision_ids: [D-XXX@vN]
 allowed_paths:
-  - ...
+  - frontend/src/lib/errors.ts
+goal: >
+  一句话说明这个 task 要做什么、为什么。
+implementation:
+  - 具体步骤 1
+  - 具体步骤 2
+  - 具体步骤 3
+acceptance:
+  - 可验证的验收条件 1
+  - 可验证的验收条件 2
+  - 可验证的验收条件 3
+verify:
+  - cd frontend && pnpm exec tsc --noEmit
+constraints:
+  - 边界约束 1（如：不加测试）
+  - 边界约束 2（如：不修改传入参数）
 ---
 
-# task-${num}: ${name}
-
-## 修改文件（必填）
-- 精确到文件路径
-
-## 覆盖来源
-- Requirements: FR-xx
-- Decisions: D-xxx@vN（如存在）
-
-## 实现要求
-1. 具体做什么
-
-## 接口定义（代码类任务必填）
-方法签名、数据结构、控制流伪代码
-
-## 边界处理（必填）
-- null/空值行为
-- 兼容旧行为（brownfield：未配置新功能时行为不变）
-- 异常不静默吞掉（明确返回值或抛出）
-- 不修改传入参数
-- 歧义/冲突场景的处理策略
-
-## 非目标（本任务不做的事）
-- 明确边界，防止 scope creep
-
-## 参考
-- 可参考的模式
-
-## TDD 步骤
-1. 写测试 → 2. 确认失败 → 3. 写代码 → 4. 确认通过 → 5. 回归
-
-## 验收标准
-| # | 验证步骤 | 通过标准 |
-|---|---|---|
-| AC-01 | ... | ... |
-
-关键规则：
-- 必须独立完整，execute 子代理只读这一个文件就能干活
-- 不要依赖其他 task-N.md 的内容
-- 接口定义写到"搬砖工照着做"的程度
-- 边界处理至少 5 条
-- 验收标准用表格，禁止笼统表述
-- 如果存在 decisions.md，不允许丢失当前版本 D-xxx@vN；无法覆盖的 D-xxx@vN 必须写入非目标或剩余风险
+TaskCard 格式规则（必须严格遵守）：
+- 总长度 20~40 行，不要写成长文档
+- frontmatter 只含必要字段，不加 estimated_hours
+- goal: 一句话，用 > 多行字符串
+- implementation: 列表，每条一个具体步骤
+- acceptance: 列表，每条可独立验证（不是表格）
+- verify: 列表，实际可执行的命令
+- constraints: 列表，明确边界（含 brownfield 兼容、异常处理）
+- 不需要：修改文件章节、覆盖来源章节、接口定义章节、TDD 步骤章节、参考章节
+- 如果存在 decisions.md，无法覆盖的 D-xxx@vN 在 constraints 中标注
 - 写完后用 Write tool 保存到文件
 \`\`\``
   }).join('\n\n')
 
 
-  const prompt = `为 plan.md 中的每个任务生成独立蓝图文件。
+  const prompt = `为 plan.md 中的每个任务生成紧凑 TaskCard。
 
 ## 任务清单
 ${taskList}
@@ -695,7 +450,7 @@ ${taskList}
 
 ## 执行方式（必须严格遵守）
 
-**你必须使用 Agent tool 启动子代理来写每个蓝图，不要自己写。**
+**你必须使用 Agent tool 启动子代理来写每个卡片，不要自己写。**
 
 1. 确认 \`${changeDir}/tasks/\` 目录存在（不存在则创建）
 2. 为每个任务启动一个独立子代理（Agent tool），可并行启动多个
@@ -708,20 +463,67 @@ ${taskList}
 
 ${subagentPrompts}
 
-## 验收
+## 验收（生成后自查，不另开步骤）
 - 每个 task-N.md 文件存在且非空
-- 包含 YAML frontmatter（id、title、priority、depends_on、blocks、requirement_ids、decision_ids、allowed_paths）
-- 包含所有必要章节：修改文件、覆盖来源、实现要求、接口定义、边界处理（≥5条）、非目标、TDD 步骤、验收标准（表格格式）
-- 边界处理覆盖：null/空值、兼容性、异常处理、参数不可变、歧义场景`
+- frontmatter 包含：id、title、author、created_at、priority、depends_on、blocks、allowed_paths
+- body 包含：goal、implementation、acceptance、verify、constraints
+- 每个 task 总长度 20~40 行
+- **一致性自查**：
+  - allowed_paths 有无冲突
+  - depends_on 与 plan.md Wave 分组是否一致
+  - 如发现矛盾，列出问题清单，不要自动修复`
 
   return {
-    name: '生成任务蓝图（子代理并行）',
+    id: 'generate_blueprints',
+    name: '生成 TaskCard（子代理并行）',
     prompt,
-    outputHint: '蓝图生成结果',
+    outputHint: 'TaskCard 生成结果',
     optional: false
   }
 }
 
+// ═══════════════════════════════════════════════════════════════
+// 第 4 步（noAI）：Wave 重排 + 一致性校验 + 保存（合并原 ⑧⑨⑩，全代码化）
+// 核心逻辑已迁移到 plan-postcheck.js，此处只保留步骤定义
+// ═══════════════════════════════════════════════════════════════
+
+/**
+ * noAI postcheck 步骤：Wave 重排 + 一致性校验 + 可行性校验 + 保存确认
+ * 核心逻辑见 plan-postcheck.js
+ */
+export function buildPostcheckStep(changeDir) {
+  return {
+    id: 'postcheck',
+    name: 'Wave 重排与可行性校验',
+    prompt: '', // noAI 步骤不需要 prompt
+    outputHint: 'Wave 重排 + 校验结果',
+    optional: false,
+    noAI: true,
+    _cliAction: 'planPostcheck'
+  }
+}
+
+// ═══════════════════════════════════════════════════════════════
+// 向后兼容：导出 fixedPrefix / fixedSuffix（供 run.js 切片用）
+// ═══════════════════════════════════════════════════════════════
+
+export const fixedPrefix = [stepClassify, stepGeneratePlan]
+
+export const fixedSuffix = [] // postcheck 是动态生成的（需要 changeDir）
+
+// ═══════════════════════════════════════════════════════════════
+// 工具函数（保持导出兼容）
+// ═══════════════════════════════════════════════════════════════
+
+/**
+ * 解析 plan.md 获取任务数量
+ */
+function parseTaskCount(planContent) {
+  if (!planContent || typeof planContent !== 'string') return 0
+  const matches = planContent.match(/^[-*]\s*\[[ x]\]\s*task-\d+/gm)
+  return matches ? matches.length : 0
+}
+
 /**
  * 从 plan.md 解析任务名列表
  */
@@ -737,6 +539,8 @@ function parseTaskNames(planContent) {
 
 /**
  * 动态构建 plan 步骤列表
+ * 新架构：3 个 LLM 步骤 + 1 个 noAI 步骤 = 4 阶段
+ *
  * @param {string|null} changeDir - 变更目录路径
  * @param {string|null} planContent - plan.md 内容（可选，用于解析任务数）
  * @returns {Array} 步骤列表
@@ -754,9 +558,10 @@ export function buildPlanSteps(changeDir = null, planContent = null) {
     }
   }
 
-  // 没有任务数则用固定步骤（兼容旧流程）
+  // 没有任务数则用固定步骤（兼容旧流程，无蓝图步骤无 postcheck）
   if (taskCount === 0) {
-    return [...fixedPrefix, ...fixedSuffix]
+    const postcheck = changeDir ? [buildPostcheckStep(changeDir)] : []
+    return [...fixedPrefix, ...postcheck]
   }
 
   // 解析任务名
@@ -770,7 +575,8 @@ export function buildPlanSteps(changeDir = null, planContent = null) {
     }
   }
 
-  // 生成单个协调器步骤（子代理并行写蓝图）
+  // 生成协调器步骤（TaskCard 生成）+ postcheck
   const coordinatorStep = buildCoordinatorStep(changeDir, taskNames)
-  return [...fixedPrefix, coordinatorStep, ...fixedSuffix]
+  const postcheckStep = buildPostcheckStep(changeDir)
+  return [...fixedPrefix, coordinatorStep, postcheckStep]
 }