@ghyper9023/pi-dev-workflow 0.4.2 → 0.5.0

package/.pi-dev-output/pi-plans/20260521-230000-fix-timeout-display-loopcount-gitdiff.md

@@ -1,253 +0,0 @@
-# 修复超时时间显示位置、循环次数计数与 git diff 解析 — 实施计划
-
-## 概述
-
-修复三个独立问题：
-
-1. **超时时间显示位置错误**：当前超时时间（如 `超时时间60m`）被显示在步骤主行（step 行），而非子代理行（sub-step 行）。预期行为是 `|__ worker · (52.6s/超时时间60m )`。
-2. **循环次数（loopCount）计数不显示**：上次 commit (01413c9) 修改了 loopCount 显示逻辑，导致 loop-group 启动后 `第 1 次循环` 不再显示。原因为 commit 中 `buildWidgetLines` 删除了 `isRunning` 状态下显示循环次数的逻辑，但 `executeLoopGroup` 中的 `updateWidgetStep` 调用在 loopCount 更新后未在 widget UI 上正确体现。
-3. **getGitDiffChanges 中 git diff 解析使用正则而非简单 string 拆分**：当前正则 `^([MAD])\s+(.+)$` 在解析 `git diff --name-status` 的输出（格式为 `M\t.gitignore` 或 `M       .gitignore`）时，可能因不匹配制表符而丢失变更。实际输出非常规整，应使用简单的字符串拆分。
-
-## 文件清单
-
-### 修改文件
-
-| 文件路径 | 改动描述 | 风险等级 |
-|---------|---------|---------|
-| `extensions/ui-helpers.ts` | 修改 `buildWidgetLines` 中的子代理行渲染，在 `status` 图标和 agent 名称后添加 `(当前计时/超时时间Xm)`；恢复步骤行中 `isRunning` 状态下 `loopCount` 的显示逻辑 | 低 |
-| `extensions/workflow-engine.ts` | 修改 `getGitDiffChanges` 中 `git diff --name-status` 和 `git status --porcelain` 的解析逻辑，用简单字符串拆分替代正则匹配 | 低 |
-
-## 实施步骤
-
-### 步骤 1：修复子代理行的超时时间显示位置（ui-helpers.ts）
-
-- **前置条件**：无
-- **改动文件**：`extensions/ui-helpers.ts`
-- **改动内容**：
-
-  **1a. 在 `buildWidgetLines` 的子代理渲染循环中，在 agent 行后添加计时和超时信息。**
-
-  当前子代理行渲染（ui-helpers.ts ~第539行）：
-  ```
-  lines.push(`${agentIndent}${agentConnector} ${subIcon} ${sub.agent} ·`);
-  ```
-
-  需要修改为：
-  ```
-  let subDurStr = "";
-  let subTimeoutStr = "";
-  // 计算 sub-step 的当前时长
-  if (sub.startedAt) {
-    const elapsedMs = Date.now() - sub.startedAt;
-    subDurStr = dim(theme, ` (${formatDurationFull(elapsedMs)}`);
-  } else if (isSubRunning) {
-    subDurStr = dim(theme, ` (0s`);
-  }
-  // 从 sub.detail 提取超时信息（detail 已在 runAgentWithProgress 中设置为 "超时时间60m"）
-  if (sub.detail) {
-    subTimeoutStr = dim(theme, `/${sub.detail}`);
-  }
-  const subDurClose = subDurStr ? dim(theme, ")") : "";
-  
-  lines.push(`${agentIndent}${agentConnector} ${subIcon} ${sub.agent} ·${subDurStr}${subTimeoutStr}${subDurClose}`);
-  ```
-
-  **1b. 步骤行中的超时时间移除/调整**
-
-  当前步骤行（step 行）有 `durStr + timeout + durClose`，对于 loop-group 步骤，`timeoutMs` 在 workflow-engine.ts 中已被设置为 `undefined`（`step.type === "loop-group" ? undefined : step.timeoutMs`），所以步骤行不会显示超时——这部分逻辑保持不变。
-
-  但对于非 loop-group 步骤，步骤行仍显示 `(1m59s/超时时间15m)`，这是正确的行为，无需改动。
-
-  **关键设计决策**：让子代理行显示 `(当前计时/超时时间)`，步骤行对于 loop-group 不显示超时（因为 loop-group 的超时已在子代理级别体现）。
-
-- **验证方式**：运行 `node tests/test-loopcount-timeout-fix.mjs`，确认现有测试全部通过；手动检查 widget 渲染逻辑。
-
-### 步骤 2：修复循环次数（loopCount）显示（ui-helpers.ts）
-
-- **前置条件**：步骤 1 完成
-- **改动文件**：`extensions/ui-helpers.ts`
-- **改动内容**：
-
-  **2a. 在 `buildWidgetLines` 中，恢复 `isRunning` 状态下显示循环次数的逻辑。**
-
-  当前代码（ui-helpers.ts ~第471行）：
-  ```typescript
-  if (s.loopCount != null && s.loopCount > 0) {
-      loopStr = dim(theme, ` · 第 ${s.loopCount} 次循环`);
-  } else if (s.maxLoops != null) {
-      // 仅在 pending 时显示"第 0 次循环"
-      // running 状态时 loopCount 应由 executeLoopGroup 通过 updateWidgetStep 更新
-      if (isPending) {
-          loopStr = dim(theme, ` · 第 0 次循环`);
-      }
-  }
-  ```
-
-  这里的问题是：当 loop-group step 处于 `isRunning` 状态且 `loopCount` 已通过 `updateWidgetStep` 设置（如 `loopCount=1`）时，`s.loopCount != null && s.loopCount > 0` 条件应匹配，所以 `第 1 次循环` **应该**显示。但实际运行中，`updateWidgetStep` 在 `executeLoopGroup` 中的调用可能没有被正确触发。
-
-  排查 `executeLoopGroup` 中的代码（workflow-engine.ts ~第1250行）：
-  ```typescript
-  loopCount++;
-  // 立即更新 UI 显示当前循环次数
-  state.loopCount = loopCount;
-  updateWidgetStep(stepIndex, step.label, "running", {
-      loopCount,
-      maxLoops: step.maxLoops,
-      startedAt: _widgetSteps[stepIndex]?.startedAt || Date.now(),
-  });
-  ```
-
-  这里 `updateWidgetStep` 被调用时传入了 `"running"` 状态和 `loopCount`。调用 `updateWidgetStep` 会触发 `refreshWidget()`，然后 `buildWidgetLines` 读到的 `s.loopCount` 应为刚刚设置的值（例如 1），因此 `s.loopCount != null && s.loopCount > 0` 应成立，`第 1 次循环` 应显示。
-
-  **根因分析**：问题在于 `updateWidgetStep` 的 `extra` 参数展开覆盖了 step widget state 中的 `loopCount`。在 `updateWidgetStep` 函数中：
-  ```typescript
-  _widgetSteps[index] = {
-      ...existing,
-      label,
-      status,
-      ...extra,
-  };
-  ```
-
-  这里 `extra` 包含 `{ loopCount, maxLoops, startedAt }`，这会将 `loopCount` 设置到 widget step 上。所以 `s.loopCount` 是有的。理论上代码是正确同步的。
-
-  但实际行为中，`executeLoopGroup` 的 `while` 循环中，**在 `loopCount++` 和 `updateWidgetStep` 执行之前**，reviewer 的 `runAgentWithProgress` 内部调用了 `refreshWidget()`（通过 `setWidgetSubStepStatus`），这意味着在第一次循环中，widget 在 loopCount 更新前被渲染了。但 `updateWidgetStep` 紧随其后就会更新。
-
-  **真正的 bug**：在 `executeLoopGroup` 中，第一次循环的 `updateWidgetStep` 调用在 `loopCount++`（从 0 变为 1）之后。因此第一次循环完成后，`loopCount=1`，这能在 widget 上显示 `第 1 次循环`。但是，**当进入下一轮循环时**，`setWidgetSubStepStatus(stepIndex, step.loopAgentName!, "pending")` 和 `setWidgetSubStepStatus(stepIndex, step.reviewAgentName!, "pending")` 被调用，这些调用触发 `refreshWidget()` 但**不会**更新 `loopCount`，所以 `loopCount` 仍然是上一次循环的值（如 1），所以在第二次循环的 worker 运行时，UI 显示的还是 `第 1 次循环`。
-
-  但实际上，根据需求描述："第 0 次循环只在排队时候显示了，等 loop 组开始工作连第 1 次循环的提示都不见了"。这意味着 **完全看不到循环计数**。
-
-  更可能的原因是：**在 `executeLoopGroup` 中，第一次循环的 `updateWidgetStep` 调用位置不正确**。注意 `executeLoopGroup` 中执行流程：
-
-  1. `while (loopCount < maxLoops)` — 进入循环，`loopCount=0`
-  2. 重置 sub-step 为 pending
-  3. 运行 worker agent
-  4. 运行 reviewer agent
-  5. `loopCount++`（变成 1）
-  6. `state.loopCount = loopCount;`（设置为 1）
-  7. `updateWidgetStep(...)` — 这里设置 `loopCount=1`
-
-  在第 3 步运行 worker 期间，`runAgentWithProgress` 会多次调用 `refreshWidget()`（通过 `setWidgetSubStepStatus`、`addWidgetSubStepTool` 等）。这些 refresh 中，widget step 的 `loopCount` 是 **未定义**（`undefined`）的，因为 `updateWidgetStep` 还未被调用。所以在 worker 运行期间，`buildWidgetLines` 读到 `s.loopCount == null`，只看到 `s.maxLoops != null`，然后因为 `isRunning` 为 true，老的代码逻辑（在 commit 01413c9 之前的代码）会显示 `第 1 次循环`，但 commit 01413c9 删除了这个逻辑——**导致整个 worker/reviewer 运行期间 loopCount 完全不可见**。
-
-  也就是说，在 commit 01413c9 中，这部分代码被删除：
-  ```
-  -            if (isRunning) {
-  -                // Immediately show 第 1 次循环 when loop-group starts
-  -                loopStr = dim(theme, ` · 第 1 次循环`);
-  -            }
-  ```
-
-  移除这个逻辑的意图是"让 `executeLoopGroup` 通过 `updateWidgetStep` 管理 loopCount"。但当 worker/reviewer 运行时（第 3、4 步），`updateWidgetStep` 还未被调用（它在第 7 步才调用），所以 widget 没有 loopCount，也没有显示任何循环计数。
-
-  修复方案：**恢复 `isRunning` 状态下显示 `第 1 次循环` 的逻辑**（当 `s.loopCount` 为 null/undefined 时），或者更精确地说，在 `isRunning` 状态下，如果 `s.loopCount == null` 但 `s.maxLoops != null`，也显示 `第 1 次循环`。
-
-  同时，移除 `isRunning` 状态的限制条件：
-  ```typescript
-  if (s.loopCount != null && s.loopCount > 0) {
-      loopStr = dim(theme, ` · 第 ${s.loopCount} 次循环`);
-  } else if (s.maxLoops != null) {
-      if (isRunning) {
-          // 当 loop-group 开始运行时，即使 loopCount 尚未通过 updateWidgetStep 设置，
-          // 也显示"第 1 次循环"（第 0 次循环仅用于 pending 状态）
-          loopStr = dim(theme, ` · 第 1 次循环`);
-      } else if (isPending) {
-          loopStr = dim(theme, ` · 第 0 次循环`);
-      }
-  }
-  ```
-
-  这样，当子代理刚刚开始运行时，即便 `loopCount` 还未更新，也能立即显示 `第 1 次循环`。
-
-- **验证方式**：运行 `node tests/test-loopcount-timeout-fix.mjs`；阅读修改后的代码确认逻辑正确
-
-### 步骤 3：修复 `getGitDiffChanges` 中的 git diff 解析逻辑（workflow-engine.ts）
-
-- **前置条件**：无
-- **改动文件**：`extensions/workflow-engine.ts`
-- **改动内容**：
-
-  **3a. 修改 `git diff --name-status` 的解析。**
-
-  当前使用正则：
-  ```typescript
-  const match = trimmed.match(/^([MAD])\s+(.+)$/);
-  ```
-
-  `git diff --name-status` 的实际输出格式为 `M\t.gitignore`（即 `status + 制表符 + 文件路径`）。上面的正则中 `\s+` 可以匹配制表符，**实际上不会有匹配问题**。但是根据用户反馈，正则会"识别出来一些无关东西，判断不出来是哪里来的"。
-
-  更健壮的方案：直接按制表符或空格拆分，取第一个字符为 status，其余为文件路径：
-  ```typescript
-  // Format: "M\tpath/to/file" (tab-separated) or "M       path/to/file" (spaces)
-  const firstSpace = trimmed.indexOf("\t");
-  if (firstSpace < 0) {
-    // Try multiple spaces
-    const statusChar = trimmed[0];
-    if (statusChar === "M" || statusChar === "A" || statusChar === "D") {
-      const rest = trimmed.slice(1).trim();
-      if (rest) {
-        changes.push({ status: statusChar as "M" | "A" | "D", path: rest });
-      }
-    }
-  } else {
-    const status = trimmed.slice(0, firstSpace).trim();
-    const path = trimmed.slice(firstSpace + 1).trim();
-    if (status && path && !seen.has(path)) {
-      seen.add(path);
-      changes.push({ status: status as "M" | "A" | "D", path });
-    }
-  }
-  ```
-
-  **更简单的方案**：由于 `git diff --name-status` 的输出格式保证是 `X\tfilepath\n`，最简单的做法是按 `\t` 拆分：
-  ```typescript
-  // git diff --name-status 输出格式：X\tfilepath\n
-  // 直接按制表符拆分，X 是第一个字符，filepath 是第二部分
-  const parts = trimmed.split("\t");
-  if (parts.length === 2) {
-    const status = parts[0]!.trim();
-    const filePath = parts[1]!.trim();
-    if (filePath && !seen.has(filePath) && (status === "M" || status === "A" || status === "D")) {
-      seen.add(filePath);
-      changes.push({ status: status as "M" | "A" | "D", path: filePath });
-    }
-  }
-  ```
-
-  **3b. 修改 `git status --porcelain` 的解析。**
-
-  同理，`git status --porcelain` 的输出格式为 `XY filepath\n`（如 ` M .gitignore`、`?? newfile.ts`、`A  filepath`）。可以用字符串拆分：
-
-  ```typescript
-  // git status --porcelain 格式：XY filepath (e.g., " M .gitignore", "?? newfile.ts")
-  // 前两个字符是状态，后面的空格分隔，然后是文件路径
-  const statusPrefix = trimmed.slice(0, 2); // e.g., "??", " M", "A "
-  const filePath = trimmed.slice(3).trim(); // after "?? " or " M "
-  if (filePath && !seen.has(filePath) && (statusPrefix === "??" || statusPrefix === "A " || statusPrefix.startsWith("A"))) {
-    seen.add(filePath);
-    changes.push({ status: "A", path: filePath });
-  }
-  ```
-
-  **注意**：`git status --porcelain` 的前两个字符格式是固定的 `XY`（X 是 index 状态，Y 是 working tree 状态）。`??` 表示 untracked，`A ` 表示 staged new，` M` 表示 modified in working tree 等。
-
-  但当前代码只关心 "??" 和 "A "（以 "A" 开头），所以直接检查前两个字符即可。
-
-- **验证方式**：运行 `node tests/test-loopcount-timeout-fix.mjs`
-
-## 依赖关系
-
-- 步骤 1、2 修改同一文件（`ui-helpers.ts`），但改动在不同位置，可独立实施
-- 步骤 3 修改不同文件（`workflow-engine.ts`），完全独立于步骤 1、2
-- 三个步骤可以按任意顺序实施，互不依赖
-
-## 测试策略
-
-- 运行现有测试 `node tests/test-loopcount-timeout-fix.mjs`，确保所有通过
-- 手动审查相关代码路径，确认改动正确
-
-## 注意事项
-
-- **超时时间在子代理行的显示**：当前的 `sub.detail` 已在 `runAgentWithProgress` 中设置为 `超时时间60m`（具体为 `` 超时时间${formatTimeout(timeoutMs)} ``）。但要注意，`sub.detail` 的显示位置需要调整——当前逻辑是在 `childItems` 为空时才显示 `sub.detail`，作为子项。需要改为直接在 agent 行末尾显示 `(当前计时/${sub.detail})`。同时需要注意：当 sub-step 有 tools/outputs 时，`sub.detail` 不应再作为子项出现（避免重复）。
-- **show detail change**: 当前 `sub.detail` 只在 `childItems.length === 0` 时显示为子项。修改后，`sub.detail` 应被解析为超时信息拼接到 agent 行末尾，而不作为独立的子项。因此需要修改子代理行的渲染逻辑。
-- **子代理超时时间的 data flow**: 当前 `runAgentWithProgress` 已在 sub-step 的 `detail` 字段写入 `超时时间60m`。这个 detail 可以直接重用。但需要区分：`detail` 目前既被当做"超时时间文本"使用，也被当做"其他详情文本"（当没有 tools/outputs 时）。修改后，如果 `detail` 包含 "超时时间"，则应解析到 agent 行；否则仍作为普通子项。
-- 更简单的做法是：**直接在内置渲染中为 sub-step 添加超时时间字段**，或者将超时时间单独存为一个字段。但为了最小改动，直接利用现有的 `detail` 字段（已在 `runAgentWithProgress` 中设置为 `超时时间60m`），在 agent 行渲染时拼接。

package/.pi-dev-output/pi-plans/20260521-230500-esc-double-press-confirm-workflow.md

@@ -1,137 +0,0 @@
-# [fix] Esc 双击确认停止工作流 — 实施计划
-
-## 概述
-
-修复工作流运行期间，一次 Esc 键就立即中断工作流的问题。改为：
-- 第一次按 Esc：显示提示 "再次按下 Esc 键，停止 Workflow"
-- 两次 Esc 间隔 < 5s 才退出
-- 超过 5s 后重置状态，重新监听
-
-**改动范围极小**，只修改 `workflow-engine.ts` 中 `runWorkflow` 函数内的 `onTerminalInput` 回调逻辑。
-
-## 文件清单
-
-### 修改文件
-| 文件路径 | 改动描述 | 风险等级 |
-|---------|---------|---------|
-| `extensions/workflow-engine.ts` | Esc 处理逻辑：增加二次确认、5s 时间窗口、提示显示 | 低 |
-
-### 新增文件
-无
-
-### 删除文件
-无
-
-## 实施步骤
-
-### 步骤 1：修改 Esc 处理逻辑（二次确认 + 5s 时间窗口）
-
-- **前置条件**：无
-- **改动文件**：`extensions/workflow-engine.ts`
-- **改动内容**：
-
-定位到 `runWorkflow` 函数末尾的 `onTerminalInput` 回调（当前第 1709-1718 行）：
-
-```typescript
-// ── Register terminal input handler (Esc to cancel) ──
-if (ctx.hasUI) {
-    _terminalInputUnsubscribe = ctx.ui.onTerminalInput((data) => {
-        if (!matchesKey(data, Key.escape)) return undefined;
-        if (_workflowRunning && _workflowAbortController && !_workflowAbortController.signal.aborted) {
-            ctx.ui.notify("⏹️ 用户取消工作流", "warning");
-            cancelWorkflow();
-            return { consume: true };
-        }
-        return undefined;
-    });
-}
-```
-
-**改为**（关键改动）：
-
-```typescript
-// ── Register terminal input handler (Esc to cancel, with double-press confirmation) ──
-if (ctx.hasUI) {
-    let _lastEscPressTime = 0;
-    _terminalInputUnsubscribe = ctx.ui.onTerminalInput((data) => {
-        if (!matchesKey(data, Key.escape)) return undefined;
-        if (_workflowRunning && _workflowAbortController && !_workflowAbortController.signal.aborted) {
-            const now = Date.now();
-            if (_lastEscPressTime > 0 && now - _lastEscPressTime < 5000) {
-                // Second Esc press within 5s → confirm cancel
-                ctx.ui.notify("⏹️ 正在停止工作流...", "warning");
-                cancelWorkflow();
-                _lastEscPressTime = 0;
-                return { consume: true };
-            }
-            // First Esc press (or expired) → show hint
-            _lastEscPressTime = now;
-            ctx.ui.notify("再次按下 Esc 键，停止 Workflow", "warning");
-            return { consume: true };
-        }
-        return undefined;
-    });
-}
-```
-
-- **改动说明**：
-  1. 引入 `_lastEscPressTime` 变量（函数块作用域），记录上一次 Esc 按下的时间
-  2. 第一次按 Esc → 记录时间并显示提示 "再次按下 Esc 键，停止 Workflow"
-  3. 在 5s 内再次按 Esc → 执行取消操作
-  4. 超过 5s 后按 Esc → 重置为第一次状态（因为 `_lastEscPressTime > 0` 但差值 >= 5000，被视为过期，走到 `_lastEscPressTime = now` 分支重新计时）
-
-- **验证方式**：
-  1. 手动测试：启动工作流，按一次 Esc → 应看到提示，工作流继续
-  2. 手动测试：5s 内再按一次 Esc → 工作流取消
-  3. 手动测试：按一次 Esc，等待 5s+，再按一次 Esc → 相当于第一次，显示提示
-  4. 确保原有取消功能在二次确认后正常运作（清理 widget、保存 checkpoint、归档）
-  5. 确保 Esc 在其他非工作流场景的行为不受影响（只修改了 `_workflowRunning` 为 true 时的分支）
-
-### 步骤 2：清理 `_lastEscPressTime` 状态
-
-- **前置条件**：步骤 1 完成
-- **改动文件**：`extensions/workflow-engine.ts`
-- **改动内容**：
-
-在 `cleanupWidget()` 函数中，确保 `_lastEscPressTime` 在 cleanup 时会被自然重置。但由于 `_lastEscPressTime` 是 `onTerminalInput` 回调闭包内的局部变量，当 `_terminalInputUnsubscribe()` 被调用时，闭包和 `_lastEscPressTime` 都会自然被 GC 回收。
-
-**不需要额外改动**——`cleanupWidget()` 中已有的逻辑：
-```typescript
-if (_terminalInputUnsubscribe) {
-    _terminalInputUnsubscribe();
-    _terminalInputUnsubscribe = null;
-}
-```
-已经在工作流结束时正确地解除了监听器注册。下次 `runWorkflow` 被调用时，会新建一个闭包和新的 `_lastEscPressTime` 变量。
-
-- **验证方式**：
-  1. 运行工作流，按 Esc 两次确认取消
-  2. 确认所有 cleanup 逻辑正确执行
-  3. 启动新的工作流，测试 Esc 逻辑从头开始工作
-
-## 依赖关系
-
-- 步骤 2 是验证步骤，不涉及代码改动
-- 仅需修改一个函数回调中的逻辑
-
-## 测试策略
-
-1. **人工测试（主要方式）**：
-   - 启动一个工作流（如 `/dev-feat` → 快速链式）
-   - 按 Esc → 验证显示提示 "再次按下 Esc 键，停止 Workflow"
-   - 工作流继续正常运行
-   - 5s 内再按 Esc → 工作流取消，widget 消失
-   - 重新启动工作流，按 Esc，等 5s+，再按 Esc → 显示提示（重置为第一次）
-
-2. **单元测试** ：
-   - 因 `onTerminalInput` 回调直接依赖 `ctx.ui` 和终端环境，不方便做纯单元测试
-   - 可考虑在 `tests/` 目录下新增测试文件对回调逻辑进行隔离测试（mock `matchesKey`、`_workflowRunning` 等）
-
-## 注意事项
-
-- **最小改动原则**：只修改 `runWorkflow` 内的 `onTerminalInput` 回调，约 15 行代码
-- **性能**：无影响，仅增加一个 `Date.now()` 调用和简单比较
-- **并发安全**：`_workflowRunning` 是整个模块级别的标志，`_lastEscPressTime` 是闭包局部变量，不存在竞态问题
-- **不要影响其他 Esc 处理**：其他地方的 Esc 处理（如 `uiSelect`、`uiConfirm` 中的 `onEscape` 回调）完全不受影响，它们由不同的 TUI 组件管理
-- **不要破坏工作流的正常运行**：第一次 Esc 只是显示提示、不执行任何取消操作，工作流步骤继续执行
-- **不要改变 notify 行为**：使用已有的 `ctx.ui.notify()` API，与代码库中其他通知一致

package/.pi-dev-output/pi-plans/20260521-235000-fix-gitdiff-loopcount.md

@@ -1,258 +0,0 @@
-# 修复 git diff 解析与循环计数 Bug — 实施计划
-
-## 概述
-
-修复两个 Bug：
-1. **git diff 解析**：`f98799d` commit 中将 `getGitDiffChanges()` 的 git diff 解析从正则改为简单的 `split("\t")`，导致无法正确处理非 tab 分隔的输出（如 space-padded 格式），且 agent 输出文本被错误解析为文件路径（如 `checkpoint-${planId}.json`、`[],\t\t\toutputs:`）。
-2. **循环计数偏移**：`executeLoopGroup` 中 `loopCount++` 在 reviewer 完成后才执行，导致第二次循环开始时 widget 仍显示旧的 loopCount，造成 "第 1 次循环" 重复出现。
-
-## 文件清单
-
-### 修改文件
-| 文件路径 | 改动描述 | 风险等级 |
-|---------|---------|---------|
-| `extensions/workflow-engine.ts` | 修复 `getGitDiffChanges` 解析逻辑；修复 `loopCount` 更新时机 | 中 |
-| `extensions/ui-helpers.ts` | 修复 `buildWidgetLines` 中循环计数的 fallback 逻辑 | 低 |
-
-## 实施步骤
-
----
-
-### 步骤 1：修复 `getGitDiffChanges` 中 git diff 输出的解析
-
-- **前置条件**：无
-- **改动文件**：`extensions/workflow-engine.ts`（函数 `getGitDiffChanges`）
-- **改动内容**：
-
-  **问题**：`f98799d` 将原来健壮的正则解析 `/^([MAD])\s+(.+)$/` 改为简单的 `split("\t")`。Git 的 `--name-status` 输出格式在不同环境/版本中可能使用 space-padded 格式（如 `"M       path/to/file"`），此时 `split("\t")` 只能得到 `parts.length === 1`，导致解析失败。结果文件变更不会被检测到。
-
-  **修复方案**：将解析改回使用正则 `^([MAD])\s+(.+)$`，同时保留 tab split 作为后备（兼容两种格式）：
-
-  ```typescript
-  // 原来的正则方式（健壮）：
-  // git diff --name-status output format: X\tfilepath or "X       filepath"
-  const statusMatch = trimmed.match(/^([MAD])\s+(.+)$/);
-  if (statusMatch) {
-      const status = statusMatch[1]!.trim();
-      const filePath = statusMatch[2]!.trim();
-      if (filePath && !seen.has(filePath) && (status === "M" || status === "A" || status === "D")) {
-          seen.add(filePath);
-          changes.push({ status: status as "M" | "A" | "D", path: filePath });
-      }
-  }
-  // 后备：tab split（兼容部分 git 版本输出的 tab 格式）
-  else if (trimmed.includes("\t")) {
-      const parts = trimmed.split("\t");
-      if (parts.length === 2) {
-          const status = parts[0]!.trim();
-          const filePath = parts[1]!.trim();
-          if (filePath && !seen.has(filePath) && (status === "M" || status === "A" || status === "D")) {
-              seen.add(filePath);
-              changes.push({ status: status as "M" | "A" | "D", path: filePath });
-          }
-      }
-  }
-  ```
-
-  同时修复 `git status --porcelain` 部分：当前代码用 `trimmed.slice(0, 2)` 和 `trimmed.slice(3)`，但 `--porcelain` 格式是固定的 2 字符状态码 + 1空格 + path。需要更健壮的处理：
-
-  ```typescript
-  // 原来：statusPrefix = trimmed.slice(0, 2); filePath = trimmed.slice(3).trim();
-  // 改为正则（更健壮）：
-  const statusMatch2 = trimmed.match(/^(..)\s+(.+)$/);
-  if (statusMatch2) {
-      const statusPrefix = statusMatch2[1]!.trim();
-      const filePath = statusMatch2[2]!.trim();
-      if (filePath && !seen.has(filePath) && (statusPrefix === "??" || statusPrefix === "A " || statusPrefix.startsWith("A"))) {
-          seen.add(filePath);
-          changes.push({ status: "A", path: filePath });
-      }
-  }
-  ```
-
-- **验证方式**：手动执行 `git diff --name-status` 验证输出格式，确认正则能够正确解析。
-
----
-
-### 步骤 2：修复 agent 输出文本刮取逻辑中的脏数据
-
-- **前置条件**：无
-- **改动文件**：`extensions/workflow-engine.ts`（函数 `runAgentWithProgress` 中的文本刮取部分）
-- **改动内容**：
-
-  **问题**：五个 `filePatterns` 正则过于宽松，会从 agent 的自然语言输出中误匹配脏数据。具体来说：
-
-  1. Pattern `/(?:^|\n)\s*(?:edit|new|delete|read|modify|create|update|add|remove)\s*[:：]\s*([^\n]+\.[a-zA-Z0-9_]+)/gim` 可以匹配 agent 文本中类似：
-     - "M   [],\n\t\t\t\toutputs:"（遇到 "M" 不匹配，但 "remove"或其他匹配？不，这个 pattern 需要前面的动词）
-     - 实际上，agent 的输出中可能有类似这样的文本：
-       ```
-       modify: [],\n\t\t\t\toutputs: ...
-       ```
-     或进度消息中的其他文本片段。
-
-  2. 标记代码块的 pattern `` /`([^`]+\.[a-zA-Z0-9_]+)`/g `` 可能匹配到 `` `checkpoint-xxx.json` `` 或 `` `checkpoint-${planId}.json` `` 这样的模板字符串。
-
-  **修复方案**：在 `filePatterns` 的每个匹配结果后添加更严格的过滤器，排除明显不是文件路径的字符串：
-
-  ```typescript
-  // 在 filePath 验证后添加额外过滤
-  // 过滤器：排除包含不合法路径字符或模板表达式的字符串
-  if (filePath.includes("${") || filePath.includes("\\n") || filePath.includes("\\t")) continue;  // 排除模板字符串和转义字符
-  if (filePath.includes("[]") || filePath.includes("{}")) continue;  // 排除数组/对象字面量
-  if (filePath.match(/^[\s,;)\]}]+$/)) continue;  // 排除纯符号
-  ```
-
-  关键修改位置：`runAgentWithProgress` 函数中，`const filePath = m[1]!.trim()` 之后的验证逻辑块。
-
-- **验证方式**：用包含 `checkpoint-\${planId}.json` 和 `[],\n\t\t\t\toutputs:` 等脏数据的测试文本运行逻辑，确认不会产生误匹配。
-
----
-
-### 步骤 3：修复循环计数偏移
-
-- **前置条件**：步骤 1 和 2 完成
-- **改动文件**：`extensions/workflow-engine.ts`（函数 `executeLoopGroup`）和 `extensions/ui-helpers.ts`（函数 `buildWidgetLines`）
-- **改动内容**：
-
-  **根本原因**：`executeLoopGroup` 中的循环计数更新顺序有误。当前的顺序是：
-
-  1. 进入 while 循环（此时 `loopCount` 还未递增）
-  2. 重置 sub-step 为 pending
-  3. 执行 worker agent
-  4. 执行 reviewer agent
-  5. `loopCount++` 并 `state.loopCount = loopCount`
-  6. 检查是否需要继续循环
-
-  当 reviewer 发现 critical 问题需要再次循环时，`loopCount` 已经在步骤 5 增加为 1，所以在第二次循环开始时 widget 显示的是 "第 1 次循环"（因为 `state.loopCount = 1`），但实际上用户期望看到的是 "第 2 次循环"（即将开始第 2 轮）。
-
-  更准确地说，期望的显示行为是：
-  - Pending 时：`第 0 次循环`（表示尚未开始）
-  - 第 1 次循环执行中：`第 1 次循环`
-  - 第 1 次循环完成，需要第 2 次循环，第二次循环执行中：`第 2 次循环`
-  - ...
-
-  **修复方案 A（推荐，最小改动）**：在 while 循环**开始处**（进入新的一轮循环之前）更新 loopCount。
-
-  将 `loopCount++` 和 `state.loopCount = loopCount` 从 reviewer 完成之后**移到 while 循环最开头**。这样：
-
-  ```typescript
-  while (loopCount < maxLoops) {
-      loopCount++;  // 递增计数，表示"即将开始第 N 次循环"
-      state.loopCount = loopCount;
-      
-      // 立即更新 UI
-      updateWidgetStep(stepIndex, step.label, "running", {
-          loopCount,
-          maxLoops: step.maxLoops,
-          startedAt: _widgetSteps[stepIndex]?.startedAt || Date.now(),
-      });
-      
-      // 重置 sub-step 状态
-      setWidgetSubStepStatus(stepIndex, step.loopAgentName!, "pending");
-      setWidgetSubStepStatus(stepIndex, step.reviewAgentName!, "pending");
-      // ... 后续逻辑 ...
-  }
-  ```
-
-  同时需要移除原来 reviewer 完成后的 `loopCount++` 和 `state.loopCount = loopCount` 部分（在 `if (reviewSummary?.maxSeverity === "critical" ...)` 判断之前）。
-
-  **注意**：由于 `loopCount` 现在从 1 开始递增（而不是原来的从 0 开始，在 reviewer 完成后才 ++），所以需要同步修改 `buildWidgetLines` 中的 fallback 逻辑：
-
-  ```typescript
-  // 在 ui-helpers.ts 的 buildWidgetLines 中：
-  if (s.maxLoops != null) {
-      if (isRunning) {
-          // 当 loop-group 开始运行时，loopCount 已经通过 executeLoopGroup 在循环开头设置了，
-          // 所以不需要 fallback 显示"第 1 次循环"
-          // 直接使用 s.loopCount 的值
-          if (s.loopCount == null || s.loopCount === 0) {
-              // 安全 fallback（理论上不会走到这里）
-              loopStr = dim(theme, ` · 第 1 次循环`);
-          }
-      } else if (isPending) {
-          loopStr = dim(theme, ` · 第 0 次循环`);
-      }
-  }
-  ```
-
-- **验证方式**：
-  1. 启动工作流，观察 loop-group 的循环计数显示
-  2. 验证第 1 次循环显示 `第 1 次循环`
-  3. 当 reviewer 触发再次循环时，验证显示 `第 2 次循环` 而不是 `第 1 次循环`
-  4. 验证第 3 次循环显示 `第 3 次循环`
-
----
-
-### 步骤 4：同步修改 loadCheckpoint 恢复时的循环计数
-
-- **前置条件**：步骤 3 完成
-- **改动文件**：`extensions/workflow-engine.ts`（`runWorkflow` 函数中恢复 checkpoint 的逻辑）
-- **改动内容**：
-
-  由于 `loopCount` 的语义发生变化（从"已完成次数"变为"当前正在进行的轮次"），需要确保从 checkpoint 恢复时，`loopCount` 能正确恢复。
-
-  当前 checkpoint 中的 `loopCounts[step.id]` 存储的是已完成次数（即原来的语义）。如果 loopCount 现在从 1 开始，则恢复时需要确保：
-  
-  - 如果 checkpoint 中 `loopCounts[step.id] = 1`（已完成 1 次），恢复后应显示 `第 1 次循环` 但不重新执行已完成的工作。
-  
-  但检查代码逻辑：checkpoint 恢复时会跳过 `status === "done"` 的步骤，所以 `loopCounts` 只对**未完成**的 loop-group 步骤有效。对于未完成的步骤，`loopCounts` 为 0 或上一次退出时的值。
-
-  **实际上不需要修改**，因为 `loopCounts[step.id]` 只作为 `while` 循环的起始值（`let loopCount = loopCounts[step.id] ?? 0;`）。在步骤 3 中，我们将 `loopCount++` 移到了 while 开头，所以：
-  
-  - 恢复后 loopCount = previous_loopCount（已完成次数）
-  - while 开始执行时立即 ++，变成 previous_loopCount + 1（当前轮次）
-  
-  这恰好是正确的行为。
-
-- **验证方式**：从 checkpoint 恢复工作流，确认循环计数正确。
-
----
-
-## 依赖关系
-
-- 步骤 1 和 2 相互独立，可并行实施
-- 步骤 3 独立于步骤 1、2
-- 步骤 4 依赖步骤 3
-
-## 测试策略
-
-### 单元测试（手动验证）
-
-1. **git diff 解析测试**：
-   - 用以下格式模拟 git diff 输出：
-     - `M\tpath/to/file.ts`（tab 分隔）
-     - `M       path/to/file.ts`（空格分隔，多空格）
-     - `A\tnewfile.ts`
-     - `D\tdeletedfile.ts`
-   - 验证所有格式都能正确解析
-
-2. **文本刮取过滤器测试**：
-   - 用以下文本测试 `filePatterns` 匹配：
-     - `checkpoint-${planId}.json`
-     - `[],\n\t\t\t\toutputs:`
-     - `edit: src/main.rs`（应匹配）
-     - `I've modified src/main.rs`（应匹配）
-     - `try`（不应匹配）
-   - 验证过滤器正确排除脏数据
-
-3. **循环计数测试**：
-   - 模拟 loop-group 执行流程：
-     ```
-     pending → 第 0 次循环
-     running 第一次循环 → 第 1 次循环
-     running 第二次循环 → 第 2 次循环
-     running 第三次循环 → 第 3 次循环
-     ```
-   - 验证显示值正确
-
-### 集成测试
-
-1. 运行一个实际工作流，观察 UI 显示
-2. 手动触发 reviewer 发现 bug，观察再次循环时的显示
-
-## 注意事项
-
-1. **最小改动原则**：只修改有 bug 的逻辑，不重构其他部分
-2. **向后兼容**：checkpoint 文件格式不变，`loopCounts` 字段语义变化需要确保从旧 checkpoint 恢复时行为正确
-3. **git diff 解析**：改回正则解析的同时保留 tab split 后备，兼容多种 git 输出格式
-4. **文本刮取**：添加的过滤器不应影响正常文件路径的匹配（如 `src/main.rs`、`extensions/workflow-engine.ts` 等）