-
前一提交（c03ae10b）的 git add 因命令里混了一个已失效的 pathspec 而整体失败， 只有此前单独 git mv 出去的改名部分被记录下来，实际的引用修正全部漏提交。 补上：docs/README.md 索引（todo 表挪到 done 表 + 顶部状态行）、其余 27 系列 文档里指向该文档的相对链接（todo/ 与 done/ 下深度不同，分别处理）、 system/agents/*/agent.md 与 tools.md 里 cwd 深度 3 的 ../../../../../ 相对引用 （agent-md-refs.test.js 会校验这些链接真实可解析到文件）、_registry.json 的 description 字段、work-graph-templates/README.md、server/ 源码里的设计文档路径注释。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU
-
## 病症：blocked 和墙钟预算互相拆台 墙钟按 `now - spent.started_at` 算，而 started_at 是「第一次花钱的绝对时刻」。 blocked 的定义恰恰是**挂起等人工** —— 预算耗尽、节点判罚都会把 run 打到 blocked。 于是：人隔夜来处置 → 等待那段被算成「已用」→ 一起跑就报 wallclock_ms 耗尽 → 再 blocked → 再等人。**一条过夜的 run 从此永远醒不过来。** 而且报出来的原因具有误导性：写着 wallclock_ms（跑太久），实际是等人等太久。 真事：run_9168bd24f46c（e2e-demo 做官网）08-18 15:48 起跑、16:19 判 blocked， 只花了 7/100 次调用、69,961/5,000,000 tokens —— **预算用掉不到 2%，两天没能重跑**。 它正是 27-p3c-batch3-handover §五 那条「还没解决的原始问题」。 ## 修法 spent 里改记 `active_ms`（累计活跃时长），started_at 退化成「当前这一段的起点」， 不在 running 时为 null。已用 = active_ms + 当前段。 起止结算挂在 graph-run-sse.afterRunTransition 这个**单一漏斗**上，不去枚举 「哪些地方会让 run 停下来」—— 枚举漏一条就是静默少算。 ⚠️ 钩子必须放在那个 early return **之前**：进 running 既不是收敛、也不空坑， 两个条件都不满足，放后面就变成「只结算停下来、从不开始计时」， 症状是 active_ms 恒 0、墙钟形同虚设，而且照样全绿。守卫里专门有一条钉这个位置 （反向验过：把钩子注释掉，那一条立刻红）。 spendBudget 不再兼职锚墙钟 —— 一个事实一处持有者。 ## 存量行 active_ms 缺失的行：旧锚点里混着等待时间，真实活跃时长复原不出来， 按 0 起算、一笔勾销。有意为之 —— 另外两维（调用次数 / tokens）是精确的且没受影响， 真正兜住花钱的是那两维，墙钟只是跑飞保护。所以那条卡住的 run 不需要动库， 重试进 running 时自动重新锚定。 ## ponytail 只认 running 一个态。manual 模式下两次点击之间 run 也停在 running， 那段人类思考时间仍会计入 —— 上限已知，比原来跨天累计小几个数量级。 要更准得按 agent 调用的起止配对计时，那是另一套账。 ## 顺带 goal-task-acceptance 两条用例原先 deepEqual 整个 budget 对象，现在剥掉 spent 只比申报的额度 —— 它守的是「用户填的额度没被静默换成默认值」， 跟运行期账本长什么样无关；账本另有断言（起跑那一刻 agent_calls/tokens 仍是 0）。 全量：137 文件 / 1284 测试全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
队列与调度（§五.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>
-
把「人类提的一个需求」与「机器执行的一件活」拆成两级。这不是新概念： 27-NAMING §四 早就定义了 goal 1 : task N，graph_runs.goal_id / task_id 两列从 P3 起就一直在写，却没有任何表接得住 —— 本次补上那两张缺席的表。 ## 交付 - goals / tasks 两张表 + CRUD + depends_on 环检测 + ID 生成器 T-{base36}-{4hex}：原格式同毫秒必撞，而 tasks.id 是主键， 「一个 goal 拆 N 条 task」是循环建行，撞了就是 500 - goal / task 全套端点；POST /:cid/tasks 向后兼容（不带 goal_id 自动 建 goal）；退役 /api/goals 与 /:cid/goals 两个 OKR 别名（零调用方） - 终态回写 + goal 收敛 + OKR 写一次：钩子挂在唯一漏斗 graph-run-sse.transitionRun 上，而不是枚举路径 —— stopRun 与 「预算耗尽 → blocked」两条最常见的释放路径都不走 settleRun， 枚举一次漏一次。goal 收敛用 CAS 闸门，并行完成的 N 个 task 只有 一个赢家做不可重放的副作用（写 OKR / 唤醒上级） - blocked 在 task/goal 两层都不是终态：它是「挂起等人介入」， 与 completed/failed/cancelled 不同类。否则预算耗尽后加预算恢复、 跑完，两次条件更新静默命中 0 行，最终 run=completed 而 task=blocked/goal=failed/OKR=failed 永久对不上（实跑复现过） - goal 级是唯一汇报出口：删掉 run 级 reportRunOutcome（零其它调用方）， 1 goal:1 task 形态下它会把上级 agent 就同一件事唤醒两次 - dispatch 挑第一条可跑的 draft，而不是恒取 seq 最小那条 —— 否则「第 1 条依赖第 2 条」这种合法输入会让 goal 永远下达不了 - 路径缺陷：writeTaskGoalArtifact 不认 GRAPH_RUNS_DIR 而读侧认， 设了 env 就写进 A 处、从 B 处读，describeTask 拿到 null 后静默退回 兜底文案「执行图节点任务」；三处模块加载时快照改为调用时读 - 存量回填脚本（幂等 + --dry-run）：不做的话批 1 反而让历史任务 更看不见 —— 正是本批要修的问题的反向放大 ## 过程 三轮多 agent 编排 + 每轮对抗复核，共报出 19 条缺陷（10 条首轮实现的、 4 条第二轮修复引入的、5 条判定为非问题）。全部已修并有用例覆盖。 新增测试 4 个文件，含不变式测试 runs-root-single-holder（凡是声明了 GRAPH_RUNS_DIR 覆盖的模块，该覆盖必须真的被用到）。 全量：116 文件 / 1057 测试全绿。 ## 未做（属批 2-5） task-planning 与 goal 级 org-validator 验收（批 2）、调度器与 run_status='queued'（批 3）、并行（批 4）、两套任务体系统一（批 5）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
界面走查（真 server + HTTP + 真 AgentManager，底层 mock 协议）已把 manual 模式全流程点通：org 节点起子图 → 下钻 work graph → 单步 → 第 3 步触发回退（徽标 0/3→1/3、run 级 1/5 双层计数同时可见）→ 归因记录与 remediation_note 完整送达 → 收敛后父节点结算、左栏前移。 mock 侧补两处缺失接线（都是「四环漏一环」，非新功能） - ClaudeCliProtocol._sendMockPrompt 按 agent 类型查 fixture：图执行侧的 agent 名带公司前缀（resolveAgentName 返回 {cid}:{id}），fixture 不该 按公司复制一份。DevLoop 侧名字不含冒号，行为不变 - graph-engine.defaultAgentExecutor 接住 mock/files 事件：此前只有 DevLoop 的 loop-controller 接，图执行侧没接，于是 mock 下 readNodeProduct 永远找不到 attempt-{n}.json，validator 系节点恒 blocked。 写入限制在节点产物目录内，越界丢弃并留痕 新增 5 份 P3 fixture（workgraph-planning / prd-planning / sdd-planning / coder-validator / validator-triager），coder-validator 用 sequence 演示 一次回退。图必须放 chunks 不能只放 result——callAgent 的 output 来自 流式 chunks，session/result 的文本不进 output。 控制台入口：CompanyDashboard 加「🕸️ 执行控制台」按钮（路由早已注册， 此前无任何入口，只能手敲 URL）。 scripts/p3-demo-setup.js：手工测试准备脚本（雇人+写图+起 run），头部 写明它是两个已知缺口的绕行，缺口修好后第 1 步即可删。 _registry.json 补齐 6 条本体登记（brd/prd/sdd-planning、goal-benchmark、 benchmark/testdata-validator）——同轮新增的 template-refs 防线测试正是 因为缺这 6 条而变红，防线抓到了「交付与报告不符」。 文档 - 27-REQ R-18：招聘归 workgraph-planning（方案 a）、停用 mock 改真 CLI - 27-P3B 真实运行前置（新增）：11 个工作项分三批，含现状核实 10 条证据 （seedTemplates 无运行时调用方、10 条悬空 company_hired 行、 FAILING_VERDICTS 不含 "fail" 导致验收假放行等） 测试 719/719 全绿（66 文件）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
按 27-p3-p4-work-graph-console.md v0.3 实现，三轮开发+校验后测试全绿 （693/693，P2 26/26、DevLoop 230/230 未被打破，web:build 干净）。 服务层 - work-graph-db.js 定义层(work_graph_*) + 运行时层(graph_runs/graph_run_nodes/ graph_run_loop_records) 五张表；状态转换表照 unit-registry 模式； 复用 org-graph-service 四项校验 + 新增第五项 fail-fallback-edge - graph-engine.js advanceOne 幂等原语；agent_call / subgraph 两种 executor； 手动与自动共用同一原语；双层熔断（单边 loop_count + 按 root_run_id 共池的 backward_count）；任务级预算挂 root run；三层暂停/停止级联； 重试按 contract_hash unchanged 判据 - graph-run-sse.js 按 run_id 广播，状态转换+timeline+SSE 三者原子化 - goal-contract.js 验收契约格式与执行器（R-15.6 验收先行） 引擎泛化（R-15.4）：org graph 与 work graph 走同一套 advanceOne， 定义层两套、运行时层一套，三层下钻用 parent_run_id 链。 R-16 失败归因：validator-reflection 专职归因节点；fail_reason 多边路由 （精确匹配→兜底边→死路）；子 run 收敛透传 success/fail + fail_reason + remediation_note 三值；infra_flake 不烧任何计数。 路由 / 前端 / 模板 - routes/graph-run.js 八个端点；company.js 任务入口 - WorkGraphCanvas.vue 扩展 UnitsDAG（subgraph 角标、backward 虚线曲线、 N/3 循环徽标、异常流程视觉降权）；GraphConsole.vue 三栏 + 四 tab 详情 - 五个新 agent 模板：validator-reflection / org-validator / planner-validator / coder-validator / workgraph-planning 命名统一（R-15.3 + NAMING §三）：org 节点改为 org-{职能}， 三个 org-graph 模板末节点收敛到 org-validator；org_graph_edges 加 fail_reason 列并把唯一索引补上该列（避免精确边与兜底边互相吞掉）。 三轮校验修掉的主要缺陷：subgraph 重跑不起新子 run 导致永久死锁； SSE/timeline 零调用方；org 侧 fail_reason 写入被丢弃；fail-fallback-edge 只做了一层；backward_count 跨 run 树重置架空熔断外层； seedEntryNodes 误点亮只有 fail 入边的节点。 已知缺口见后续提交：remediation_note 仅在 backward 边落库、 total_tokens 预算维度无生产方。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>