@ghyper9023/pi-dev-workflow 0.4.1 → 0.4.2

package/.pi-dev-output/pi-review/md/review-20260521-140000.md

@@ -0,0 +1,191 @@
+# 代码审查报告: Workflow loopCount UI 同步 & 超时时间分离修复
+
+**审查日期**: 2026-05-21
+**审查范围**: `extensions/workflow-engine.ts`, `extensions/dev-prompts.ts`, `extensions/ui-helpers.ts`, `tests/test-loopcount-timeout-fix.mjs`
+**git diff**: 已实现的功能修复（3 个文件修改 + 1 个测试文件新增）
+
+## 总体评价
+
+代码改动整体方向正确，核心功能修复已实现。但发现 2 个中等严重程度的问题和 2 个低优先级问题。
+
+---
+
+## M1. 在运行 `initWidget` 初始化所有步骤时（第 1629 行），loop-group 步骤的 `timeoutMs` 被传入 widget
+
+**严重度**: medium  
+**文件**: `extensions/workflow-engine.ts`  
+**位置**: 第 1628-1631 行
+
+```typescript
+updateWidgetStep(i, steps[i]!.label, isDoneState ? "done" : "pending", {
+    maxLoops: steps[i]!.maxLoops,
+    timeoutMs: steps[i]!.timeoutMs,  // <-- loop-group 步骤的 timeoutMs 被传入
+});
+```
+
+**问题描述**:
+根据设计评审第 8 问的决策，"loop-group 行不显示超时时间，在 worker 和 reviewer 的 sub-step 中分别显示各自的超时时间"。但 `initWidget` 阶段对所有步骤（包括 loop-group）迭代调用了 `updateWidgetStep`，且传入了 `timeoutMs`。
+
+虽然在 `executeWorkflowBackground` 的 running 和 done 状态更新中已经修复了（使用 `step.type === "loop-group" ? undefined : step.timeoutMs`），但初始 pending 状态的设置没有过滤 loop-group 步骤。这意味着 widget 面板在启动瞬间（步骤还未开始执行时），loop-group 行会短暂显示超时时间。
+
+**影响**:
+- 用户启动工作流后，在步骤进入 running 状态之前，会看到 loop-group 行有超时显示
+- 这与设计意图不一致
+
+**修复建议**:
+```typescript
+updateWidgetStep(i, steps[i]!.label, isDoneState ? "done" : "pending", {
+    maxLoops: steps[i]!.maxLoops,
+    timeoutMs: steps[i]!.type === "loop-group" ? undefined : steps[i]!.timeoutMs,
+});
+```
+
+---
+
+## M2. loopCount 的"第 1 次循环"在 `buildWidgetLines` 中存在隐藏的重复逻辑
+
+**严重度**: medium  
+**文件**: `extensions/ui-helpers.ts`  
+**位置**: 第 462-471 行
+
+```typescript
+let loopStr = "";
+if (s.loopCount != null && s.loopCount > 0) {
+    loopStr = dim(theme, ` · 第 ${s.loopCount} 次循环`);
+} else if (s.maxLoops != null) {
+    if (isRunning) {
+        // Immediately show 第 1 次循环 when loop-group starts
+        loopStr = dim(theme, ` · 第 1 次循环`);
+    } else if (isPending) {
+        loopStr = dim(theme, ` · 第 0 次循环`);
+    }
+}
+```
+
+**问题描述**:
+这个 `else if (isRunning)` 分支原本是修复前的"硬编码显示第 1 次循环"的残留。虽然代码逻辑在实现层面并无错误，但在已实施第 1 轮修复（`executeLoopGroup` 中 `loopCount++` 后立即 `updateWidgetStep`）之后：
+
+1. 当步骤第一次进入 running 状态时，`executeWorkflowBackground` 先调用 `updateWidgetStep` 将 `loopCount` 设为 `undefined`（初始调用没传 `loopCount`）
+2. 紧接着 `executeLoopGroup` 的 while 循环中，`runAgentWithProgress` 运行结束后 `loopCount++` 并调用 `updateWidgetStep` 传入 `loopCount: 1`
+
+因此在第 1 步与第 2 步之间的短暂时间窗口，UI 确实会通过 `else if (isRunning)` 分支显示"第 1 次循环"——但这**恰好是正确的**。
+
+然而问题是：**如果 `loopCount` 已通过 `updateWidgetStep` 传入**（即 `s.loopCount` 不为 null），那么这段 `else if` 分支永远不会被执行，因为它走的是上面的 `if (s.loopCount != null && s.loopCount > 0)` 分支。
+
+真正的风险在于：**假如 `updateWidgetStep` 因为某种竞态条件（race condition）没有及时更新 `s.loopCount`**，这个 `else if` 分支会掩盖问题，让错误很难调试。它相当于一个静默的"兜底"逻辑，可能隐藏真实的 loopCount 同步 bug。
+
+**影响**:
+- 降低可调试性：掩盖了可能的同步问题
+- 代码可读性降低：混合了修复前和修复后的逻辑
+- 与"直接从 `s.loopCount` 读取显示"的设计决策不完全一致
+
+**修复建议**:
+移除 `else if (isRunning)` 分支，完全依赖 `s.loopCount`。修改为：
+
+```typescript
+let loopStr = "";
+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 次循环`);
+    }
+}
+```
+
+这样可以让 running 且 loopCount 尚未更新时的短暂窗口不显示循环次数（或者显示空字符串），给 `updateWidgetStep` 一个可观察的时间窗口来更新。
+
+---
+
+## L1. 测试断言不够健壮 —— 使用字符串包含检测而非 AST 解析
+
+**严重度**: low  
+**文件**: `tests/test-loopcount-timeout-fix.mjs`  
+**位置**: 多处
+
+**问题描述**:
+测试大量使用 `assertIncludes` 进行字符串包含检测。例如：
+
+```javascript
+assertIncludes("1.1 executeLoopGroup 中有 loopCount++ 后立即更新 UI", weContent, "// 立即更新 UI 显示当前循环次数");
+```
+
+这种方式有几个问题：
+1. 如果注释文本被修改（拼写修正、翻译等），测试会假阴性（false negative）
+2. 容易被注释中的无关字符串匹配到意外命中
+3. 无法验证代码的实际执行流——只验证了源代码文本存在
+
+更严重的是：测试检测的是**注释文本**而非实际代码。注释修改不影响功能，但测试会失败。
+
+**修复建议**:
+- 对于注释检测，改为检测更独特的代码模式（如 `updateWidgetStep(stepIndex, step.label, "running", {`）
+- 或直接检测变量名模式，例如 `loopCount,\n.*maxLoops:` 等
+- 对于接口定义检测，使用正则匹配 AST 级别模式（如 `reviewTimeoutMs`/`WorkflowStepDef` 上下文）
+
+---
+
+## L2. `setWidgetSubStepStatus` 重置后，sub-step 的 `detail` 字段未清除
+
+**严重度**: low  
+**文件**: `extensions/workflow-engine.ts`  
+**位置**: 第 1186-1187 行
+
+```typescript
+setWidgetSubStepStatus(stepIndex, step.loopAgentName!, "pending");
+setWidgetSubStepStatus(stepIndex, step.reviewAgentName!, "pending");
+```
+
+**问题描述**:
+每次循环开始时，sub-step 的状态被重置为 `"pending"`。但 `setWidgetSubStepStatus` 只更新 `sub.status` 字段，不清除 `sub.detail`、`sub.tools`、`sub.outputs` 等字段。
+
+查看 `setWidgetSubStepStatus` 的实现：
+```typescript
+function setWidgetSubStepStatus(stepIndex: number, agentName: string, status: WorkflowSubStepWidgetState["status"]): void {
+    const step = _widgetSteps[stepIndex];
+    if (!step) return;
+    const sub = step.subSteps?.find(s => s.agent === agentName);
+    if (sub) {
+        sub.status = status;
+        refreshWidget();
+    }
+}
+```
+
+当第二次循环开始时：
+- sub-step 状态变成 `"pending"`
+- 但在 `buildWidgetLines` 中，`isSubPending` 为 true，因此 `childItems` 只显示 `"正在排队"`——这恰好正确，因为待机状态不显示 `detail`
+- 当 sub-step 再次进入 running 状态时，`runAgentWithProgress` 会重新设置 `detail`
+
+所以当前的 bug 不严重，**UI 显示是正确的**。但如果未来修改了 `buildWidgetLines` 中 pending 状态的渲染逻辑（例如显示 sub-step 的 detail），就可能显示上一轮循环的超时信息。
+
+**修复建议**:
+在 `setWidgetSubStepStatus` 中增加可选清除 detail 的功能，或在 `executeLoopGroup` 重置时显式清除：
+
+```typescript
+function resetWidgetSubStep(stepIndex: number, agentName: string): void {
+    const step = _widgetSteps[stepIndex];
+    if (!step) return;
+    const sub = step.subSteps?.find(s => s.agent === agentName);
+    if (sub) {
+        sub.status = "pending";
+        sub.detail = undefined;
+        sub.tools = [];
+        sub.outputs = [];
+        refreshWidget();
+    }
+}
+```
+
+---
+
+## 总结
+
+本次修复正确地解决了三个核心问题：
+1. ✅ **loopCount UI 同步**：`executeLoopGroup` 中 `loopCount++` 后立即调用 `updateWidgetStep`
+2. ✅ **reviewer 独立超时**：`WorkflowStepDef` 新增 `reviewTimeoutMs` 字段，reviewer 使用独立超时
+3. ✅ **默认超时值**：worker=30min, trimmer=20min, reviewer=15min
+4. ✅ **loop-group 行不显示 timeout**：在 running/done 状态更新中过滤了 loop-group 步骤
+
+发现的中等问题（M1, M2）不会导致实际功能错误，但可能影响 UI 一致性和可维护性。

package/.pi-dev-output/pi-review/md/review-20260521-190000.md

@@ -0,0 +1,189 @@
+# 代码审查报告: Esc 双击确认停止工作流
+
+**审查日期**: 2026-05-21
+**审查范围**: `extensions/workflow-engine.ts`（Esc 处理逻辑）
+**审查变更**: `git diff HEAD` — 仅 `extensions/workflow-engine.ts` 第 1706-1726 行
+
+## 总体评价
+
+本次改动代码方向正确，实现了任务要求的"第一次 Esc 显示提示、5s 内第二次 Esc 才确认取消"的功能。
+代码量极小（约 15 行改动），符合"最小改动"原则。
+但发现 **1 个严重问题（critical）** 和 **2 个低优先级问题**。
+
+---
+
+## 🔴 严重问题
+
+### C1. cancelWorkflow() 回调中重新订阅的 terminal input 未解绑
+
+**严重度**: critical
+**文件**: `extensions/workflow-engine.ts`
+**位置**: 第 1698-1702 行（cleanup 定时器设置）/ 第 1709-1727 行（onTerminalInput 订阅）
+
+**问题描述**:
+
+`cancelWorkflow()` 的执行路径如下：
+
+1. 用户第二次按 Esc → `cancelWorkflow()` 被调用
+2. `cancelWorkflow()` → `_onCancelWorkflow?.()` → 回调执行：
+   - `_workflowAbortController?.abort()` — 中止工作流
+   - `_workflowRunning = false`
+   - 保存 checkpoint
+   - 设置 `_cleanupTimer = setTimeout(() => { cleanupWidget(); }, 5000);`
+
+3. 5 秒后 `cleanupWidget()` 执行：
+   - 清理 `_terminalInputUnsubscribe()`
+   - `_terminalInputUnsubscribe = null`
+
+**问题在于**：在第 2 步中 5 秒的清理延迟期间，`_terminalInputUnsubscribe` **仍然有效**，回调依然能触发。虽然 `_workflowRunning = false` 阻止了进入 Esc 处理分支（第 1714 行的 `if (_workflowRunning && ...)` 为 false），所以不会造成错误取消，但存在一个**更隐蔽的问题**：
+
+如果用户在 5 秒延迟窗口内**重新开始一个新的工作流**（通过 `runWorkflow` 另一个调用），第 1711 行会创建一个新的 `_lastEscPressTime` 闭包变量，并重新赋值 `_terminalInputUnsubscribe`：
+
+```typescript
+// 新工作流
+let _lastEscPressTime = 0;  // 新的闭包变量
+_terminalInputUnsubscribe = ctx.ui.onTerminalInput((data) => { ... });  // 覆盖旧的
+```
+
+旧的回调**永远不会被解绑**（因为旧的 `_terminalInputUnsubscribe` 引用被覆盖了，且 `cleanupWidget` 还没运行）。这意味着旧定的 5 秒计时器到期后，`cleanupWidget` 运行时会：
+- 调用已经过期的 `_terminalInputUnsubscribe`（指向新工作流的订阅）
+- 新工作流的 Esc 监听被错误解绑！
+
+**根因分析**：
+`setWorkflowCancelCallback` 的回调中使用 `setTimeout(() => cleanupWidget(), 5000)` 延迟清理，而新工作流可能在延迟期间启动，导致 `_terminalInputUnsubscribe` 被覆盖。这不是此改动引入的新问题——它是整个 `setTimeout` 延迟清理设计本身就存在的竞态问题。
+
+但在没有此改动前，这个问题较少暴露，因为旧代码中单次 Esc 就立即取消了。现在加了双击确认后，用户可能在第一次 Esc 提示后**无意中触发这个竞态**：
+
+1. 工作流 A 正在运行
+2. 用户按一次 Esc → 显示提示
+3. 用户等了一段时间，又按了一次 Esc（但已超过 5s，重置为第一次）
+4. 用户再按一次 Esc（第二次，仍在工作流 A）
+5. 工作流 A 被取消，状态设为 `_workflowRunning = false`，等待 5s 清理
+6. 用户立即启动工作流 B
+7. 工作流 B 的 `_terminalInputUnsubscribe` 覆盖了旧的
+8. 工作流 A 的 5 秒定时器到期，`cleanupWidget()` 解绑了工作流 B 的 Esc 监听
+9. 工作流 B 运行时无法通过 Esc 取消
+
+**影响**：竞态条件触发的概率较低（需要在特定时间窗口内快速操作），但一旦触发，后一个工作流将失去 Esc 取消功能。
+
+**修复方案**：
+
+**方案一（推荐，最小改动）**：在 `setWorkflowCancelCallback` 的回调中立即清理 Esc 监听，而不是等到 5 秒后。
+
+在第 1661 行附近，`_cleanupTimer = setTimeout(() => { ... cleanupWidget(); }, 5000)` 之前，立即执行：
+
+```typescript
+// 在 cancel 回调中立即清理 Esc 监听，避免竞态
+if (_terminalInputUnsubscribe) {
+    _terminalInputUnsubscribe();
+    _terminalInputUnsubscribe = null;
+}
+```
+
+这将确保：
+- cancel 后 Esc 监听立即解绑
+- 5 秒后 `cleanupWidget()` 中再次调用 `_terminalInputUnsubscribe?.()`（此时已是 null，安全）
+- 新的工作流不会受到旧监听器残留的影响
+
+**方案二（更强健）**：使用独立的 `_cancelPending` 标志，在 `onTerminalInput` 回调中检查并跳过已经取消的工作流的残留事件。但方案一更简单且是本改动即可独立修复的。
+
+**注意**：此问题虽然是修改前就存在的（延迟清理设计），但本次改动增加了用户使用 Esc 交互的次数（第一次 Esc→提示，第二次 Esc→确认），从而**增加了进入上述竞态时间窗口的概率**。因此将其标记为严重等级。
+
+---
+
+## 🟢 低优先级问题
+
+### L1. 超过 5s 后按 Esc，提示内容不会再出现
+
+**文件**: `extensions/workflow-engine.ts` 第 1711-1726 行
+
+**问题描述**:
+需求描述为："俩次ecs间隔<5s才退出，5s之后，提示内容"再次按下ecs键，停止Workflow"去掉，需要重新监听ecs按下和重新计时。"
+
+当前实现中，超过 5s 后再次按 Esc 的逻辑是这样的：
+1. `_lastEscPressTime` 有旧值（5s 前的）
+2. `now - _lastEscPressTime >= 5000` 为 true
+3. 由于 `_lastEscPressTime > 0` **且** `now - _lastEscPressTime < 5000` 为 false
+4. 走 else 分支：`_lastEscPressTime = now; ctx.ui.notify(...)`
+
+**这实际上是正确的**——超过 5s 后按 Esc，会重新记录时间并显示提示。所以功能上没有问题。
+
+但边界情况是：如果 `now - _lastEscPressTime` 恰好等于 5000ms（即用户在最后一次提示后刚好 5.000 秒按了 Esc），则 `< 5000` 的检查不通过，但 `_lastEscPressTime > 0` 仍然成立。代码会走到 else 分支，重置时间并显示提示——这符合"重新监听"的语义，**正确无误**。
+
+**结论**: L1 不是问题，移除该条目。
+
+### L2. notify 消息中英文混合
+
+**文件**: `extensions/workflow-engine.ts` 第 1725 行
+
+**问题描述**:
+提示消息为 `"再次按下 Esc 键，停止 Workflow"`，其中 `Workflow` 是英文单词，其余为中文。该代码库中其他消息使用统一中文化（如 `"⏹️ 用户取消工作流"`）。
+
+建议统一为："再次按下 Esc 键，停止工作流"（将 Workflow 改为中文）。
+
+这仅是一个风格建议，不影响功能。
+
+**建议**: 将 `"Workflow"` 改为 `"工作流"`。
+
+### L3. 测试覆盖缺失
+
+**文件**: 无对应测试文件
+
+**问题描述**:
+现有 7 个测试文件中，没有任何测试覆盖 Esc 双击确认逻辑。无法验证该功能在代码重构或未来改动时不被破坏。
+
+**建议**:
+在 `tests/` 下新增测试文件（如 `test-esc-double-press.mjs`），至少覆盖以下场景：
+1. 首次 Esc → 不取消，显示提示（检查 notify 调用）
+2. 5s 内第二次 Esc → 取消（检查 cancelWorkflow 调用）
+3. 超过 5s 后按 Esc → 重置（检查 notify 再次调用）
+4. 工作流非运行状态时 Esc → 无操作
+5. 连续 Esc 时 _lastEscPressTime 的时间戳更新逻辑
+
+由于 `onTerminalInput` 回调依赖 `ctx.ui`，可隔离测试回调的纯逻辑部分（mock `matchesKey`、`_workflowRunning`、`_workflowAbortController` 等）。
+
+---
+
+## 变更的正确性验证
+
+### ✅ 功能正确性
+- 首次 Esc → 记录时间、显示提示、`return { consume: true }`（阻止默认行为） ✅
+- 5s 内第二次 Esc → 调用 `cancelWorkflow()`、重置时间 ⏰ ≪-- C1 竞态风险
+- 超过 5s 按 Esc → 重置为首次状态 ✅
+- 非工作流运行时的 Esc → `return undefined`（不消费事件，允许其他处理） ✅
+- `_lastEscPressTime` 是函数块级 `let` 变量，作用域正确 ✅
+- 回调使用 `_workflowRunning + _workflowAbortController` 双重守卫 ✅
+
+### ✅ 与实施计划的一致性
+- ✅ 引入 `_lastEscPressTime` 变量（函数块作用域）
+- ✅ 第一次按 Esc → 记录时间并显示提示
+- ✅ 在 5s 内再次按 Esc → 执行取消操作
+- ✅ 超过 5s -> 重置为第一次状态
+- ✅ 修改仅限于 `runWorkflow` 函数内的 `onTerminalInput` 回调
+- ✅ 约 15 行改动量
+
+### ⚠️ 与需求的一致性
+- ✅ "再次按下ecs键，停止Workflow" 提示显示
+- ✅ 两次 Esc 间隔 < 5s 才退出
+- ⚠️ 5s 之后，提示内容消失，重新监听 — 功能实现正确
+- ⚠️ 不能破坏原有功能 — 需要确认 C1 竞态问题
+
+### ✅ 回归测试
+- `node tests/test-workflow-engine-bugs.mjs` — **50/50 通过** ✅
+- `node tests/test-workflow-engine.mjs` — **74/75 通过**（1 个 pre-existing `deleteCheckpointFile` 失败，非本次改动导致） ✅
+
+---
+
+## 严重等级汇总
+
+| 等级 | 数量 | 说明 |
+|------|------|------|
+| 🔴 critical | 1 | cancelWorkflow 回调延迟清理导致的竞态 |
+| 🟡 medium | 0 | — |
+| 🟢 low | 2 | 中英文混合、测试覆盖缺失 |
+
+---
+
+## 总结
+
+本次 Esc 双击确认功能实现正确，核心逻辑符合需求。唯一严重问题是 `cancelWorkflow` 回调中的 5 秒延迟清理设计（第 1698 行）与 `_terminalInputUnsubscribe` 的覆盖之间存在竞态条件，可能导致后启动的工作流失去 Esc 取消功能。建议在 cancel 回调中立即清理 Esc 监听器，而不是等 5 秒后的 `cleanupWidget()` 再做。（此问题虽在改动前已存在，但本次改动增加了进入竞态时间窗口的概率。）

package/.pi-dev-output/pi-review/md/review-20260521-204500.md

@@ -0,0 +1,241 @@
+# 代码审查报告
+
+**审查时间**: 2026-05-21 20:45  
+**审查范围**: commit `01413c9` 对 `extensions/ui-helpers.ts` 和 `extensions/workflow-engine.ts` 的修改  
+**功能需求**: 修复超时时间显示位置、循环次数计数、git diff 解析
+
+---
+
+## Critical 问题
+
+### C1. `executeLoopGroup` 中 `loopCount` 更新后调用 `updateWidgetStep` 但 UI 在 sub-step 运行期间仍不显示循环次数
+
+**严重等级**: critical  
+**文件**: `extensions/workflow-engine.ts`（executeLoopGroup） & `extensions/ui-helpers.ts`（buildWidgetLines）  
+**根因分析**:
+
+在 commit `01413c9` 中，`buildWidgetLines` 的 `isRunning` 分支（原本显示"第 1 次循环"）被删除，并改为"由 `executeLoopGroup` 通过 `updateWidgetStep` 管理 loopCount"。
+
+然而 `executeLoopGroup` 的流程是：
+1. `while (loopCount < maxLoops)` — 进入循环，`loopCount=0`
+2. 重置 sub-step 为 pending
+3. 运行 worker agent（耗时较长）
+4. 运行 reviewer agent（耗时较长）
+5. `loopCount++`（变为 1）
+6. `updateWidgetStep(...)` 设置 `loopCount=1`
+
+**问题核心**：在第 3-4 步（worker/reviewer 运行期间），`runAgentWithProgress` 内部会多次调用 `refreshWidget()`（通过 `setWidgetSubStepStatus`、`addWidgetSubStepTool` 等）。但这些 `refreshWidget()` 调用时，widget step 的 `loopCount` 仍为 `undefined`，因为 `updateWidgetStep(loopCount=1)` 还没执行到。
+
+因此在整个 sub-step 运行期间（这是 UI 可见时间最长的阶段），**用户完全看不到任何循环次数提示**。只有等 sub-step 全部完成后才更新 loopCount，但此时 UI 已经准备进入下一轮了。
+
+**影响**: 用户在整个 worker/reviewer 执行过程中完全看不到"第 N 次循环"提示，这是严重的用户体验 bug。
+
+**修复方案**: 在 `executeLoopGroup` 中，**在运行 worker agent 之前**（而不是之后）就更新 loopCount 到 widget。
+
+```typescript
+// 在 while 循环开始处，运行 agent 之前
+loopCount++;
+state.loopCount = loopCount;
+updateWidgetStep(stepIndex, step.label, "running", {
+    loopCount,
+    maxLoops: step.maxLoops,
+    startedAt: _widgetSteps[stepIndex]?.startedAt || Date.now(),
+});
+
+// 然后运行 worker agent
+const loopTask = buildTaskForStep(step.loopAgentName!, contextPrompt, planFileRelPath, _workflowCwd);
+let agentResult = await runAgentWithProgress(loopAgent, loopTask, stepIndex, step.loopAgentName!, step.timeoutMs);
+```
+
+这样在 sub-step 开始运行前，widget 上已经显示正确的 `loopCount`，后续所有 `refreshWidget()` 都能读取到正确的值。
+
+同时应保留 `buildWidgetLines` 中 `isRunning` 状态的 fallback 逻辑（`第 1 次循环`）作为兜底。
+
+### C2. `buildWidgetLines` 中超时时间在步骤行和子代理行显示逻辑冲突
+
+**严重等级**: critical  
+**文件**: `extensions/ui-helpers.ts`（buildWidgetLines）  
+**根因分析**:
+
+当前代码中：
+- **步骤行（step line）**: 对于 loop-group 步骤已移除了 `timeoutMs`（`step.type === "loop-group" ? undefined : step.timeoutMs`），所以步骤行不会显示超时。
+- **子代理行（sub-step line）**: 通过 `sub.detail`（内容如 `超时时间60m`）在 agent 行末尾显示。
+
+但当前子代理行的渲染代码（`buildWidgetLines` 中的 sub-step 渲染部分）**已经实现了** 功能需求要求的显示格式：
+
+```
+|__ ✓ worker · (52.6s/超时时间60m)
+```
+
+代码中已有的逻辑（查看 ~Line 539-545）：
+```typescript
+if (sub.detail && sub.detail.includes("超时时间")) {
+    subTimeoutStr = dim(theme, `/${sub.detail}`);
+}
+```
+
+**问题在于**：当前 `sub.detail` 已在 `runAgentWithProgress` 中设置为 `超时时间${formatTimeout(timeoutMs)}`，所以这部分功能本身是**已实现**的。功能需求中描述的超时显示位置问题可能存在于旧的代码版本，commit `01413c9` 已经修复了这部分。
+
+但在审查过程中确认：**当前代码中 sub-step 的超时时间显示逻辑是正确的**，不应再改动。需要重点关注的是**确保 detail 中的"超时时间"文本不被作为独立的子项重复显示**。
+
+当前代码（~Line 554-556）：
+```typescript
+if (childItems.length === 0 && sub.detail && !sub.detail.includes("超时时间")) {
+    childItems.push(sub.detail);
+}
+```
+
+这个逻辑是正确的：`sub.detail` 包含"超时时间"时不会被作为子项重复显示。
+
+---
+
+## Medium 问题
+
+### M1. `getGitDiffChanges` 中 `git status --porcelain` 解析存在潜在 bug
+
+**严重等级**: medium  
+**文件**: `extensions/workflow-engine.ts`（getGitDiffChanges）  
+**根因分析**:
+
+当前代码已按实施计划中的方案改用了字符串拆分而非正则：
+```typescript
+const parts = trimmed.split("\t");
+if (parts.length === 2) {
+    const status = parts[0]!.trim();
+    const filePath = parts[1]!.trim();
+    ...
+}
+```
+
+但 `git status --porcelain` 的解析仍有问题：
+```typescript
+const statusPrefix = trimmed.slice(0, 2);
+const filePath = trimmed.slice(3).trim();
+```
+
+`git status --porcelain` 的实际输出格式为：
+- `?? newfile.ts` — untracked (2 字符状态 + 空格 + 路径)
+- ` M modified.ts` — working tree 修改 (空格 + M + 空格 + 路径)
+- `A  staged.ts` — staged 添加 (A + 空格 + 空格 + 路径)
+- `M  staged-mod.ts` — staged 修改 (M + 空格 + 空格 + 路径)
+
+前两个字符是 `XY`（index 状态 + working tree 状态），后面跟**一个空格**再跟路径。所以 `trimmed.slice(0, 2)` 取到的是完整的 2 字符状态码，`trimmed.slice(3)` 取到的是路径（跳过了第 3 个字符即空格）。
+
+**但问题在于**：`trimmed` 是通过 `line.trim()` 得到的，**这已经去掉了首尾空格**。对于 ` M modified.ts`（首字符为空格），`trim()` 后变成了 `M modified.ts`，此时 `statusPrefix = "M "`（"M" + 空格），**但原始的 git porcelain 输出中 "M" 前面有一个空格表示 working tree 状态**，trim 后丢失了这个信息。
+
+修复方案：**不要对 line 做 `trim()`**，或者使用 `line` 而非 `trimmed` 来解析状态码。
+
+```typescript
+// 正确的解析方式
+for (const line of statusOutput.split("\n")) {
+    if (!line.trim()) continue;
+    // 前两个字符是状态
+    const statusPrefix = line.slice(0, 2); // 直接使用原始 line，不 trim
+    const filePath = line.slice(3).trim();
+    // "??" 表示 untracked/new
+    // "A " 或 "AM" 或 "M " 表示 tracked 文件被修改
+    if (statusPrefix === "??") {
+        // untracked = new
+        ...
+    } else if (statusPrefix === "A " || statusPrefix.startsWith("A")) {
+        // staged new
+        ...
+    }
+    ...
+}
+```
+
+### M2. `executeLoopGroup` 中异常退出重试逻辑可能导致无限循环
+
+**严重等级**: medium  
+**文件**: `extensions/workflow-engine.ts`（executeLoopGroup）  
+**根因分析**:
+
+在 `executeLoopGroup` 中，当 agent 异常退出（非零退出码且非超时）时：
+
+```typescript
+while (agentResult.exitCode !== 0 && !isTimeoutResult(agentResult)) {
+    if (mode === "full-auto") {
+        throw new Error(...);
+    } else {
+        const choice = await uiSelect(ctx, ..., [
+            "1. 重新执行", "2. 跳过此步骤", "3. 取消工作流",
+        ]);
+        ...
+        agentResult = await runAgentWithProgress(loopAgent, `[RETRY]\n\n${loopTask}`, ...);
+    }
+}
+```
+
+这里使用了 `while` 循环而非 `if`，但每次重试都会创建新的 `agentResult`。如果 agent **持续**异常退出，理论上用户每次都选"重新执行"就会无限循环。不过用户有选择跳过或取消的权力，所以实际风险较低。
+
+建议改为 `do-while` 或加一个最大重试次数限制，但功能需求要求最小改动，可标记为观察项。
+
+---
+
+## Low 问题
+
+### L1. `updateWidgetStep` 中 `startedAt` 回退逻辑可能导致时间错误
+
+**严重等级**: low  
+**文件**: `extensions/workflow-engine.ts`（executeLoopGroup）  
+**根因分析**:
+
+在 `executeLoopGroup` 中的 `updateWidgetStep` 调用：
+```typescript
+updateWidgetStep(stepIndex, step.label, "running", {
+    loopCount,
+    maxLoops: step.maxLoops,
+    startedAt: _widgetSteps[stepIndex]?.startedAt || Date.now(),
+});
+```
+
+如果 `_widgetSteps[stepIndex]?.startedAt` 为 `0`（理论上不可能，但类型上 permit），`||` 会回退到 `Date.now()`，这没问题。但如果 `startedAt` 已经有一个较早的值，每次循环都复用同一个 `startedAt` 会导致累计时间异常——步骤行显示的时间是**工作流开始到当前的总时间**，而不是本轮循环的开始时间。
+
+然而 `loop-group` 步骤的步骤行显示的是从 `stepStartTime` 开始到现在的总运行时长（因为 step 级别只有一个 `startedAt`），而 sub-step 有自己的 `startedAt`。所以这个行为是预期的，不构成 bug。标记为低优先级观察项。
+
+### L2. `buildWidgetLines` 中 `isRunning` 状态检测逻辑冗余
+
+**严重等级**: low  
+**文件**: `extensions/ui-helpers.ts`（buildWidgetLines）  
+**根因分析**:
+
+当前代码：
+```typescript
+const isRunning = s.status === "running" || isCurrent;
+```
+
+`isCurrent` 定义为 `i === state.currentStepIndex && state.status === "running"`。所以 `isRunning` 的检测等价于 `s.status === "running" || (i === currentStepIndex && state.status === "running")`。
+
+实际上，如果 `i === currentStepIndex` 且 `state.status === "running"`，那么 `s.status` 应该已经是 `"running"`（由 `updateWidgetStep` 设置）。所以 `isCurrent` 部分通常是冗余的。
+
+但在初始状态或过渡状态中可能存在短暂的不一致。保留作为容错是可以的，但可考虑简化。
+
+### L3. 测试文件中 `extractLoopGroups` 函数解析逻辑脆弱
+
+**严重等级**: low  
+**文件**: `tests/test-loopcount-timeout-fix.mjs`  
+**根因分析**:
+
+`extractLoopGroups` 函数通过逐行扫描和花括号深度来解析 loop-group 配置块，这种方法很脆弱：
+1. 它假定 `type: "loop-group"` 所在行是配置块的开始
+2. 它通过 `}` 后跟 `,` 或 `;` 来检测结束
+3. 如果配置格式稍有变化（如多行注释、属性换行等），解析就会失败
+
+实际测试运行发现当前能正确解析所有 7 个 loop-group 配置（断言 `>=6`），但未来修改配置格式时需要同步更新测试解析器。
+
+---
+
+## 总结
+
+| 等级 | 数量 | 说明 |
+|------|------|------|
+| Critical | 2 | loopCount 在 sub-step 运行期间不显示（时序问题）；超时显示逻辑需验证 |
+| Medium | 2 | `git status --porcelain` 解析 bug；重试可能无限循环 |
+| Low | 3 | startedAt 回退、运行状态检测冗余、测试解析脆弱 |
+
+## 推荐修复优先级
+
+1. **修复 C1**: 在 `executeLoopGroup` 中，将 `loopCount++` 和 `updateWidgetStep` 移到运行 worker agent 之前
+2. **修复 M1**: 修正 `git status --porcelain` 解析中 `line.trim()` 导致的状态码丢失问题
+3. 其他问题可在后续迭代中优化