-
队列与调度（§五.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> -
设计见 docs/done/system-design/28-agent-registry-unification.md。 改造前 Agent 本体散在三处（system/agents/ 11 个、system/templates/ 50 个、 data/companies/{id}/agents/ 17 个），同一个 AgentScaffold 被三个 baseDir 实例化。 后果是同一角色在 N 家公司下有 N 份互不相干的副本，模板更新不会同步； org-coder / org-planner 这类走 hireFromBaseMetaAgent 造出来的本体 legacy_path 指回自己公司目录，永远无法被第二家公司复用。 本次： - G1 单一注册表：system/templates/ 整体并入 system/agents/，base → _base。 7 个同名 id 逐个裁决，被丢弃的一份归档到 docs/_archive/ 而非删除。 source_kind(template/global_agent/company_hired) → origin(builtin/created)。 - G2 运行态下沉：CLI 的 cwd 从本体根改为 system/agents/{aid}/{cid}/{taskId}/。 memory / conversations 落公司态 {aid}/{cid}/，按公司隔离不串。 sessionPool 的 key 含 (companyId, taskId)，两家公司调同一 agent 不复用会话。 - G2b 产物不下沉：交付物仍落 data/companies/{cid}/，system/agents/ 只留运行痕迹。 写入边界按链路分叉——graph 节点走节点私有目录（被 indexNodeOutputs 索引）， chat 走公司 workspace，同一提示词里不再出现两条互斥指令。 - G3 公司只存引用：data/companies/{id}/agents/ 删除，新增 company_agents 关联表。 不复用 org_graph_nodes——后者是执行流图，work 层本体被雇时不写它，天生覆盖不全。 - G4 缺则创建：本体缺失时从 _base 复制骨架进 system/agents/{id}/， agent-creator 填 agent.md/soul.md 后才从 draft 转 active（哨兵判据， 骨架未填时哨兵仍在，不许被 hire）。产物即刻是全系统可复用的本体。 新增 server/services/agent-locator.js 收编原先散在 6 处的寻址逻辑。 边界守卫（graph-engine）的豁免从「本体根上五个文件名」放宽为整棵 system/agents/： 新本体的骨架本来就要进 git，gitignore 挡不住 ?? system/agents/{newId}/， 旧判据会把一个真正成功的招聘节点判成 boundary_escape fail。 存量迁移见 scripts/migrate-agent-registry.js（幂等，备份到 data/_migration-backup-*）。 真 Claude CLI E2E 已验证：新建公司 → orggraph-planning 自动规划 → 自动招聘 org-planner/org-coder/org-validator 三节点流水线； data/companies/{cid}/agents/ 不存在，company_agents 4 行， system_agents 56→56（零新建私有本体，纯复用），git status 零增量。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
第六次真 CLI 冒烟 gapClosed=true：org 层契约落库 4 行（此前恒 0）， 且那段文字真的进了 workgraph-planning 收到的提示词（52677 字节，第 746 行起）。 ## workflow 四路并行的产出 - **org 层两半一起接**（关键顺序）：先接读回方 buildPlanningPrompt 的 ③bis 段 （org 边入边 → 上游绝对路径；出边 produces → 「你规划的子图必须有节点产出这些」）， 再接声明方 orggraph-planning 模板。只补模板的话就是又一次「声明了没人读」—— org 图节点全是 subgraph，而 describeInputs 对 subgraph 直接返回空。 resolveInboundLines 从 describeInputs 抽出共用，两侧口径物理上不可能漂移。 - **清掉 404 死路径**：模板三处教的 POST /api/company/:id/work-graphs 从未注册。 真跑复验：agent 侧零调用，改为按新 Step 7 写项目根绝对路径，还自己 require validateWorkGraph 预检了一遍才交回，round=1 一次过。 - **四张骨架补 produces/needs**：从「靠模板文字施压」变成结构保证，每张过规则 6。 真跑里 agent 照抄了 planner.json 并跟着任务删掉 sdd 节点——是改编不是复制。 - **graph-seed 顺序依赖**：靠生产代码里已有的 GRAPH_SEED_ROOT 缝隙指向冻结快照。 不是「跑几次都绿」结案：构造了原先必红的 churn，修前 12 次 3 红、修后 15 次 0 红。 ## 我自己收的 4 条 major + 1 条 minor（都在 graph-engine.js） 复验挖出「引擎自己拼的提示词在教 agent 做模板明令禁止的事」，同一条提示词里对立： 1. 「已自行落库成功时回一行 workGraphId: wg_xxx」vs 模板「你永远拿不到真的 wg_ id， 永远别写」。agent 没有任何受支持的落库途径，写出来必是编的，而 extractPlannedGraph 优先匹配那个形状、查库查不到就整轮作废。删掉邀请，保留引擎解析真实 wg_ 的能力。 2. 内联图示例的边一个 produces 都没有——agent 唯一见过的「边长什么样」是零声明的。 3. 「端点尚未上线」暗示将来会上线，于是它还想去试一次。改成「不存在、也不会上线」。 4. indexNodeOutputs 收集 declared 不按 role 过滤，把出边的 needs 当成本节点的产出。 Chrome 走查实测：产品需求文档.md 落成 artifact，下游 prd 输入变 ⚠️。 更坏的一面是错标（brd_notes.md 命中中继 needs[brd] → 归因给错的产出方）。 1ea9efa 加的 role 列，这里正是它存在的理由。 5. (minor) contract.prev.json（retryNode 的契约快照）被索引成 artifact 噪声。 新增 guard：引擎提示词不许与模板对立（静态读源码，剔掉注释行—— 第一版把「解释为什么不许说某句话」的注释也扫进去了，量错了对象）。 测试 850 全绿（83 文件），既有断言未改。5 处变异精确变红后逐字还原。 Chrome 走查确认控制台正常分支（此前只验过降级分支）：契约药丸、绝对路径、 needs 中继说明、tab 上的 ⚠️ 计数全部渲染，零 console 报错。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
第五次真 CLI 冒烟（gapClosed=true）暴露的两条，都是「这轮成立是侥幸」型。 1) indexNodeOutputs 靠文件名定 kind 真跑成立纯属 brd 节点恰好把文件命名成 `brd.md`。换写 `业务需求文档.md` 就落成 kind=artifact → 下游入边声明的 brd 查不到实例 → 提示词退化成 「⚠️ 索引里查不到实例」，即刚关掉的断点换个形式重现。agent 给产物起中文名 是完全正常的行为，不该由它决定索引对不对。 改成两遍：先按文件名认领，再在**一对一无歧义**时（还差一个 kind 没人产、 正好还剩一个认不出的文件）按声明认领。有歧义不猜 —— 猜错比留 artifact 更坏， 错的 kind 让下游读到一份不是它要的文件，artifact 只是查不到、会如实报 ⚠️。 2) describeInputs 任务级共享不去重 真跑里 brd 与 prd 两个节点各写了一份 contract.json，都是 kind=contract， 于是往后每个节点的提示词里「contract（任务级共享）」逐个累加。节点一多是噪声， 且给 agent 两个同类路径等于把一个我们自己都没定的选择推给它。 按 kind 保留最新那份，与沿边那一半的 byKind.set 同口径。 ponytail 标了根因（节点私有目录的文件也会按文件名落成 task-shared 的 kind） 与真正的修法（任务级产物只认 tasks/{taskId}/），后者要动 R-9.3 现有语义， 归到那条线一起定。 测试 829 全绿（+3），既有断言未改。4 处变异精确变红后逐字还原。 含 verify agent 回填的 §4.6「第五次真 CLI 冒烟」小节。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
R-19.A 把 declareEdgeContract 的调用方补上之后，inboundContracts 终于非空， 「沿边传递」这类数据流在真跑里生效了（真实规划 agent 自己在边上写出了 produces/needs 声明）。本次收掉它留下的三个缺口。 1) role 落库（第 14 次「四环漏一环」） normalizeContracts 产出 role，declareEdgeContract 入参没有它、表也没这列 —— 产生 → 传递(丢) → 落库 → 读回。后果不止是控制台不精确：规则 6（data-contract） 靠「有人 needs 但没人 produces」判错，只存 kind 就没法从库里重算，而 patchGraph 第 5 步的重新校验读的正是库 —— 增量 PATCH 又恰恰是 「此前满足的 needs 失去产出方」的唯一发生地，校验偏偏在最该生效的通道上失效。 - graph_edge_contracts 加 role 列（CHECK + 老库 ALTER 后回填 produces： NULL 在规则 6 里既不算产出也不算需求，会误拒一张合法的图；闸门宁可漏判不可错拦） - 两层调用点透传 role；readGraph 把 contracts 读回来并递进 validateGraph 2) 控制台三字段（前端在、后端没喂） GET /api/graph-runs/:id 补 edges[].contracts / companyRoot / taskFiles， 否则 R19-C 那三块界面整块降级：声明和索引都在库里，界面上看不见。 contracts 只在非空时出现，与 failReason 同一个约定。 3) 收拢 companyRootDir/taskDirRel 镜像 goal-contract.js 里那份镜像靠注释约定「与 graph-engine 逐字同构」维持， 控制台路由成为第三个调用方时这个约定就不成立了。抽到 company-paths.js， GRAPH_RUNS_DIR 改为调用时读（原先两个模块各自在加载时快照， 加载顺序不同会算出不同的根）。goal-contract 那条「镜像漂了就报警」的用例 按其自身预告改成比函数返回值。 测试 826 全绿（+11：role 8 / 路由 3），既有断言未改。 11 处变异逐一验证精确变红后逐字还原；其中一条断言初版在 fixture 上永远自洽 （图里没有无声明的边），补了一条无声明的边才真正有判别力。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
第四次真跑的断点：org-planner-prd 失败，它自己的归因原话是 「不是上游没产出，是它的产出**结构上到不了我手上**」。核实属实 —— 上游 brd.md / contract.json 落在**节点私有目录**，prd 的提示词只有它自己的私有目录 + 只读 artifacts/，而 brd--success-->prd 这条边**不携带任何文件引用**。 边一直只承载控制流（condition/edge_kind/fail_reason），R-4 要的「边的输入输出」 被落成了从 output_ref **推断**的 UI 展示、没有实体，而推断的那一端下游读不到。 ## 定案（27-REQ R-19） - 建 sqlite 表而不是 files.json：JSON 会重演 _registry.json 的并发重写与 git 冲突 （本轮刚被它咬过，W13 只能把 usedCount 挪去另一个被 ignore 的文件） - **两类数据流都要**：纯边绑定表达不了 R-9.3 的「planner 生成、validator 执行」—— org graph 是 planner→coder→validator，acceptance 跳过 coder，这两点之间没有边 - workspace 根**代码推导不入库**：存绝对路径会烂，W13 清的那 10 条 legacy_path 悬空行就是这个病。表里只存相对公司根的路径 - 路径走 tasks/{taskId}/，不走 workspace/：后者语义是「Agent 自治领地、框架不干预」 （06-沙盒自治），与「框架管着、可检索的交付物区」是两种所有权 - 契约(kind)与实例(path)分规划时/运行时两阶段 → 引擎可在节点跑之前校验 「你声明要吃 brd，但上游没人产 brd」，这类图结构错误此前只能等跑到那步才发现 ## 实现 work-graph-db：graph_files（实例）+ graph_edge_contracts（契约）两张表。 graph_files 的当前版本走**部分唯一索引** WHERE superseded_by IS NULL —— 与 idx_org_graph_nodes_company_role_active 同一模式：要「同键只有一个活的」 又要留历史，条件得写进索引而不是靠删行。API：recordFile / findFiles / declareEdgeContract / edgeContracts / inboundContracts / rebuildFilesFromNodes。 graph-engine 两侧都接： - 输入侧 describeInputs：按**入边声明的 kind** + **本 task 共享产物** 查实例， 把绝对路径拼进提示词。声明了却查不到的**明说缺哪个 kind**，不静默省略。 刻意不是「注入一句『索引在某文件，自己去检索』」—— 那仍靠 agent 自觉拼路径， 真跑已证明它拼不出来；引擎直接递到手上，不给它猜的机会 - 产出侧 indexNodeOutputs：节点 success 时登记落盘文件，kind 先看出边声明、 再按文件名兜底；attempt-*.json 是引擎自读的归因文件，不当产物登记 文档：27-REQ 新增 R-19（四条，含两段原话）；27-P4 §4.6 按定案重写 （原「公司根一个 files.json」作废）。 测试 788/788 全绿。后续（下一轮）：规划侧声明契约、goal-contract 路径归并、 前端「输入输出」tab 展示解析结果、真 CLI 复验 prd 能拿到输入。 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>
-
## 1. 子 run 转终态不回写父节点 → 任务永久卡死（界面走查发现） 复现：org 节点的子 work run 第一次失败 → 父节点判 fail → 入口节点没有 fail 出边 → blocked → 用户在中栏把子 run 修好跑到 completed → **父节点仍钉在 blocked， root run 也钉住，org 层永远推不下去**。唯一人工出路是对 org 节点点「重试」， 而那会把整张子图重置到下一个 attempt，刚跑完的成果全丢。 根因：propagateToParent 的幂等守卫写的是 `parentNode.status !== 'running' → return`， 判据用错了维度——它想防「同一个结果被结算两次」，实际拦掉的是「子 run 换了个结果」。 subgraph 节点的状态本来就是从子 run 派生的，子 run 换了终态就该重新派生。 修法：新增 reviveParentFromChild，只认「转好」（fail/blocked → success）， 且要求 parentNode.child_run_id 正是这个子 run。恢复走 **blocked → ready → running → success 三步合法转换**，而不是给全局放宽 NODE_TRANSITIONS——转换表是给所有调用方的 安全网，不该为一条恢复路径把 blocked → success 对外开放；三条 node.status 事件 也让「这个节点是被救回来的」在 timeline 上看得见。 补测试时才暴露的第二半：父 run 多半也钉在 blocked，而 RUN_TRANSITIONS 没有 blocked → completed，settleRun 在转换非法时是**静默跳过**的。所以复活时要先把 父 run 从 blocked 拉回 running（这条合法），否则节点复活了 run 还是卡着。 ## 2. 边界守卫把并行 agent 的写算到当前节点头上（真 CLI 冒烟的断点） 真跑实测：招聘模板库里没有的角色走 hired_from_base，自动流水线起 agent-creator， 而它的 CLI workDir 就是 system/agents/agent-creator/——一个被 git 跟踪的目录。 它在里面重写自己的 todo.md、删一条 scheduled_tasks，被整仓 git diff 扫到， 归属算到当时正在跑的 work 节点，一个**真正成功**的节点被判 fail。 只要这些运行态文件还被 git 跟踪，每次含 hired_from_base 的招聘都稳定复现。 修法：splitUnattributable 把 agent 运行态文件（todo.md / plan.md / memory.md / _lessons.md / .claude/scheduled_tasks.json）从越界证据里摘出去，单独记一条 unattributable，不参与判罚。摘除范围刻意窄——同目录下的 agent.md / config.json 等源码仍然算越界。 路径提取按「首个空白之前」切而不是固定偏移：diffRepoStatus 已去掉前导空格， porcelain 状态位长度不定（修改类 "M path" 1 字符、未跟踪类 "?? path" 2 字符）， 固定 slice(3) 恰好对**修改类**失效——而 agent-creator 改自己 todo.md 正是修改类。 这条单独立了一个回归用例。 ponytail: 这是缓解不是根治。根治要把运行态文件从 git 移出去（27-P3B W13）， 本次只保证守卫不再冤枉节点；同一次招聘里 agent 若写了运行态文件之外的源码， 仍会算到当前节点头上。 测试 760/760 全绿（72 文件，起点 753/71）：新增 graph-engine-revive-parent.test.js 4 条 + graph-boundary.test.js 3 条。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
真 CLI 冒烟（worktree 隔离，PORT 3010）九轮来首次把 work 节点跑起来： orggraph-planning 真跑 3 分钟自主裁成单 org node 零边图 → workgraph-planning 第 1 轮产出合法图 → **自己按 Step 6 把 brd-planning / planner-validator 雇进公司** （W5/W6 核心验收成立，且 W7 判据生效、两者都没写进 org_graph_nodes）→ 第一个 work 节点 brd-planning 真起 CLI 子进程，产出 brd.md / contract.json / attempt-0.json 全部落在 run 目录内。图内预算仅 2 次调用 / 13998 tokens（上限 15）。 W5/W6 · workgraph-planning 自雇：撤掉「你不招人也不辞人」，Step 6 加招聘环节， 写死「先雇、再提交图」的顺序，给出失败分级与幂等要求 W7 · work 层招聘不写 org_graph_nodes：按 type 与 work graph 骨架点名两条判据区分层级， P2 「hire org 角色 → org graph 出现该节点」的语义保持不变 W8 · 控制台「规划组织结构」按钮（抽成 ReplanOrgGraphButton.vue，带过渡态与秒表）， 接 POST /:companyId/org-graph/replan（该端点此前无任何前端调用方）； 新增 fixtures/devloop-mock/orggraph-planning.json W12 · 节点失败留痕：node.output 带 output_excerpt、新增 node.error 事件。 真跑当场救场——守卫误判那条归因正是靠它才查得出来， 换成之前看到的只有「节点 fail、无原因、无痕迹」 测试 753/753 全绿（71 文件，起点 736/68）。 已知未修（下一轮）：子 run 转终态不回写父 node_run 导致任务永久卡死； applyBoundaryGuard 用整仓 git diff 判归属会把并行 agent 的写算到当前节点头上； W12 的 fail_reason 未落库（概览 tab 仍为空）；POST /:cid/tasks 无前端调用方。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
测试 736/736 全绿（68 文件，起点 719/66，净增 17 条，未改任何既有断言）。 W1 · seed 接进启动流程 + 悬空行回收 - server/index.js 与 agent-server.js 均在 listen() 前调 runStartupSeedSafely() （幂等、失败降级记日志、不挡服务启动） - seedTemplates() 此前**没有任何运行时调用方**，只有测试与手动脚本引用， 于是 system/templates/ 新增本体永远进不了 system_agents，而 work_graph_nodes.system_agent_id 是指向该表的外键 - 占位 id 回收：legacy_path 已失效的 company_hired 行改为可被 template 就地转正， 保留行 id 以保外键。此前 seedTemplates 遇占用即 skip，导致污染不可逆： lookupSharedAgentMd 恒 null → hire 静默退回全量拷贝 → 模板改动对已雇公司不生效 - 生产库实查：company_hired 0 行（原 10 条悬空全清）、template 45、 verifyCounts().ok=true、foreign_key_check 空 W2 · 项目根分配（四环闭合） - ensureProjectRoot 复用 path-resolver.allocateProjectRoot（sandbox 模式） - 分配 → 进 agent_call 与 planning 两处提示词 + callAgent metadata → 落 artifacts/project-root.json（wx 独占）→ readProjectRootRecord 读回 - 子 run 经 createRun 继承 root_run_id，跨层共享同一项目根 - 核实 data/companies/ 在 .gitignore 内，故项目根内的合法写入不会被 W3 守卫误报 W3 · 产出边界守卫（部分，文档如实标注） - 真 CLI 是子进程直接写盘，引擎拦不住，守卫只能拒收结果、不能回滚 - 7 条「拦不住」的情形逐条列明；文档自述「在 cwd 隔离做掉之前， 真跑仍应在可丢弃的工作副本里做」 W4 · 修验收 fail-open（性质严重） - benchmark-validator / testdata-validator 的 Step 表教 agent 写 verdict:"fail"， 而引擎 FAILING_VERDICTS={attributed,inconclusive} 不含它 → 契约非法的产物 被判 success 放行。失效方向是放行不是拦截 - org-validator 的审计字段 verdict → audit_verdict：它与 work 层判词写同一路径 （nodes/<nodeRunId>/attempt-<n>.json），此前只靠「该节点恰好是 subgraph」 才没被 readNodeProduct 当判词读，属隐患藏在巧合里 - 新增防线 template-verdicts.test.js，从 graph-engine.js 源码取 FAILING_VERDICTS / ATTRIBUTION_REASONS 扫全部模板；经三次变异验证有效 （改回 "fail" / 改回 verdict / 造 "ok" 均变红并报精确行号） 真 CLI 冒烟未执行，两条理由（终验 agent 自行判断，符合任务给的门槛）： ① W3 按其自身文档明确「不是沙箱」且要求真跑在可丢弃副本里做，而当前是主仓库、 持有未提交交付物、且有并行 agent 在写，W3 自述的误判项必然触发； ② 断点已零成本静态证明：getAgentConfig 解析裸名只查 system/agents/、 从不查 system/templates/，resolveAgentName 不做按需 hire，实测 prd-planning / sdd-planning / benchmark-validator / testdata-validator / validator-triager / org-validator 全部 throw「Agent not found」。花 $3-8 复现已知断点无意义。 故「做完这四件就能真跑」不成立，真跑挪到 W5/W6 之后。 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>