-
队列与调度（§五.1）： - 下达任务不再因「公司已有 active root run」吃 409，改为建 queued run + queued task 排队；出队走 updateRunStatus 的 CAS + BEGIN IMMEDIATE 准入事务，触发挂在 transitionRun 这个唯一漏斗上，60s sweep 兜底。 - 依赖已不可能满足的排队任务就地推导成 blocked，且每次 tick 重算不落死，上游重跑 成功后能原路解开。 恢复路径（批 3 复核 F1/F2）：三条恢复转换的 from 全在活跃集之外，撞坑满时退回队列而不是 永远躺在 blocked；退不回去的裸 run 干净拒绝，不留半截状态。 控制台三处可见性修复 —— 症状全是纯视觉、不报错、git status 干净： 1. 顶栏墙钟恒 `now - started_at`，没有终点。一条昨晚就 blocked 的 run 第二天还在涨到 「16h 58min」，而那是页面上唯一的时间信号 —— 「已经停了等人处置」被显示成了 「还在跑再等等」，这两件事需要的动作相反。终点改取 run.updated_at，并标「已停」。 2. 越界日志只报「留下 N 处改动」，文件清单躺在 timeline.ndjson 里翻不到。判罚就是按 这份清单下的，而人要判断「这真是 agent 写的吗」唯一的依据就是路径（并行的开发会话 改宿主仓库会被算到当时在跑的节点头上，那是误判，看一眼就知道）。改为列出 entries。 3. run 收敛成 blocked 时只把 task 写成 blocked、不写原因，任务列表那一行只剩一个橙色 的「挂起」，必须逐层点进 org 图 → work 图 → 节点详情才知道发生了什么。改为把 「卡在哪个节点 + 什么 fail_reason + 判词摘要」写进 tasks.blocked_reason。 原因绝不带 UPSTREAM_BLOCK_PREFIX —— 带了会被调度器当成依赖推导出的 blocked 自动 推回 queued，而这类 blocked 本来就等着人处置（守卫在 task-blocked-reason.test.js）。 测试：126 文件 / 1201 用例全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
测试 786/786 全绿（76 文件，起点 760/72），未改任何既有断言。 ## 本轮三件新东西，全部经真 CLI 验证 W12 补完 · 失败原因四环打通 - 引擎自判的失败（executor 抛异常、边界越界、子 run 无归因）现在也落 graph_run_nodes.fail_reason，不再只有 agent 归因产出的才有值 - 概览 tab 展示「[引擎判定] boundary_escape」+ 终端样式 excerpt， 取不到 fail_reason 时回落 output_excerpt，并标明来源 - 真跑实查：两行 fail_reason='boundary_escape' 都在库里， 产生→传递→落库→读回四环在真 CLI 下走通 W13 · 运行态文件根治（守卫误判的根因） - 17 个 todo.md / plan.md / scheduled_tasks.json git rm --cached + gitignore； 源码（agent.md/config.json/soul.md/tools.md）一个未碰，模板本体仍跟踪 - _registry.json 的 usedCount 挪进已忽略的 data/template-usage.json - 真跑验收：整轮（agent-creator、Master 各一次真 CLI、3 次 hire）结束时 worktree git status 与基线逐字相同，_registry.json 零 diff 单步进度感 · 真 CLI 一个节点 3-7 分钟 - 画布卡片秒表 + 详情面板常驻条「运行中 2m40s · 最近事件 …（2m40s 前）」 - 不做假进度条：引擎不知道 agent 还要多久 - 顺手修 NodeDetailPanel 不跟 SSE 走（否则秒表也不会动） W9 失败上下文进提示词、W10 跨层地址两半、W11 Hot Swap 显式告警同批完成。 ## 真跑结论：链路更长，但「work 节点 → success」仍未跑到 走到：orggraph-planning 落图自雇 → agent-creator 补定义 → workgraph-planning 真跑规划 + **先雇后提交**（W5/W6 再次成立）→ 子 run 起来 → work 节点 RUNNING → 7m19s 后 fail。两层原因叠加，都与 W1-W14 无关： 1. **新缺陷**：agent-manager.js:324 把 idleTimeoutMs 硬编码 120s， readme-writer 通读源码静默超 2 分钟被掐死（动笔前就死了）。 同进程 ClaudeCliProtocol 早把自己的 idle 上限放到 24h， stream-executor 的 JSDoc 默认值写的是 30 分钟 —— 这里把两者都压掉一个数量级； 且 ...options 透传的 idleTimeoutMs 会被下一行覆盖，调用方无法覆写。 2. **并行 agent 污染**：retrain-watchdog 每 5 分钟唤起的 Master 在同一工作树里 改了两个源文件，被守卫 git status 差集算到该节点头上 → 额外署 boundary_escape。 这是 W3「拦不住」第 5 条第一次真实发生。 顺带记一笔：这一轮任务是 **LemonBoss 自己的 Master 自主下的单**， 走的正是 POST /api/company/:id/tasks，它还自行诊断出了上面那个 idle timeout 并动手改（引用了未定义的常量，是坏的）。 ## 已知未修（下一轮） - idleTimeoutMs 硬编码 120s —— 「work 节点 → success」跑不通的唯一技术原因 - W7 在**零边最小图**上失效：判据③要求存在 active org_graph_edges， 零边图上三条判据全落空，work 层本体被写进 org_graph_nodes。 服务层那 9 例测试造的都是有边的成型图，正好绕开这个形状 - 前端 ACTIVE_RUN 含 blocked、后端 ACTIVE_ROOT_RUN_STATUS 不含： 一家公司只要失败过一次，控制台上就再也下不了第二个任务（后端其实放行） - 真跑期间工作树里不能有第二个 agent 活动，否则守卫判罚不可信 —— 应写进真跑规程 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>