-
控制台原先只能看引擎的事件轨（stream.log / timeline.ndjson），里面是结构化事件、 自由文本还被截断到 600 字；引擎更是根本不消费流式 chunk（onAcpEvent 只取 session/result 的 usage）。所以 LLM 的逐字输出从来不在它的轨道上。 新端点 GET /api/graph-runs/:id/nodes/:nodeRunId/transcript **惰性读** Claude CLI 自己的会话文件：不进 SSE、不进节点行、不落第二份库 —— 那正是引擎当初决定不存全文的 三条理由要避免的（输出无上限而 getRunState 每次轮询 SELECT * 全量回传 / 产物已有 output_ref 这个唯一真相源 / fail_reason 是选边匹配键不能掺自由文本）。 这里没有推翻那个设计，只是多开一个读取入口。 目录推导与条目规范化抽到 server/services/agent-transcript.js， scripts/tail-agent.js 改为复用它 —— 一份实现两个入口。今天已经修过三次 「两份必须保持一致的实现漂了」，不想制造第四次。 ## 界面上明说的三个前提（不藏） 1. transcript 按 (公司, 角色) 分、**不按节点分**，只能用节点 started_at/completed_at 截时间窗口 —— 近似而非精确对齐，窗口边界原样显示。 2. <env_status>（harness 每轮注入的环境块，几 KB 机器噪音）服务端剥掉， 但**剥了几处如实显示**。静默删内容比留噪音更坏。 3. 默认只看 agent 说的话；喂进去的内容（提示词全文、工具返回）要勾选才出来 —— 提示词里有写入边界与公司上下文，不默认摊开，但可以看。 subgraph 节点不给这个 tab（它自己不调 agent，活在子图里）—— 给了就是个空 tab， 而空 tab 会被读成「没记录」。正在跑的节点靠「刷新」取最新，**不轮询** （整份会话几百 KB，跟着 run 状态轮询太贵）。 ## 三处「看着对、实际错」都有用例钉住 ① listRoles 的目录前缀差一个 '-'：path.join 丢掉空的最后一段，切出来的角色名 全带前导 '-'（实测 '-sdd-planning'）。我是靠肉眼看输出发现的，所以补回归测试。 ② 路由取本体取错层：本体绑在定义层节点上，graph_run_nodes 只有 def_node_id， 第一版直接读运行时行 → SqliteError: no such column。 ③ 找不到文件时回 ok:false + 期望目录，不回空列表 —— 空列表会被读成「这个 agent 没说过话」，而真相是「我们没找到文件」。 另外测试当场抓到我自己那个诚实机制的漏洞：整条正文都是 env_status 的条目会被剥空， normalize 早返回 null 导致它剥掉的那一处**没计入总数** —— 号称如实回报却少报。 改成 parts 空但剥过东西时仍返回，由 readEntries 先记账再决定入不入列表。 ## 验证 880 全绿（88 文件）。3 处变异精确变红后逐字还原。 运行中的实例上走查过：org-planner-sdd 的原文逐条带时间戳显示， 第一条就是它去读上游 prd.md / contract.json —— R-19 那条链路被 agent 真的用上了。 subgraph 节点（org-planner）确认没有这个 tab。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
## 为什么加 「输入输出」tab 把产物的绝对路径摆出来了，但那是服务器本地路径 —— 浏览器里点不开， 走查时只能靠肉眼确认「路径长得对」，而真正要确认的是「这份 brd.md 里写了什么、 下游读到的是不是它」。 ## 前端 新增 web/src/components/graph-console/FilePreviewModal.vue，输入/输出两处路径 改成可点按钮。渲染三档：.md 走 marked（已是既有依赖，没新增包）、.json 重新缩进、 其它原文。两处刻意的选择： - .json 解析失败时**退回原文**并说明，不替它藏起来 —— 产物 json 写坏了本身就是要看的信息 - 超过 512KB 时后端回 truncated，界面如实说「不是完整内容」，不装作读全了 output_ref 那一行不做成可点：它是目录不是文件。 后端没有新造端点：复用现成的 GET /api/company/:cid/files/content，它的根目录正是 data/companies/<cid>，而 graph_files.rel_path 本来就是相对公司根的，正好对上。 ## 修掉六处路径越界（真漏洞） company.js 里 3 个 GET + 3 个 PUT（templates / company / workspace）用的是同一个写法： if (!absPath.startsWith(safeBoundary)) → 403 「一个目录名是另一个的前缀」时它会放行： cid = co-a，path = ../co-a-evil/company.json → abs = .../data/companies/co-a-evil/company.json → startsWith('.../data/companies/co-a') === true → 放行 于是公司 co-a 能读 co-a-evil 的文件；PUT 那三处是同一缝隙上的跨公司**写**。 抽 resolveInside() 用 path.relative 判断，六处共用一份（复制六份判据迟早会漂）。 新增 7 条用例走真 HTTP 验，PUT 那条断言的是**文件没被改**而不只是响应码。 ## 顺带修掉一个被你的实际使用触发的 bug 跑全套时 graph-seed-service 的对账用例红了，报 `org_graph_nodes WHERE company_id='mycompany' expected 10 / actual 9`。 不是并发偶发 —— 单跑也红。原因：seedCompanyAgents 对 type='meta-bootstrap' 的角色 是 continue（既不落 org_graph_nodes 也不落 system_agents），而 verifyCounts 复算期望值时把 agents[] 全算进去。mycompany 的 10 个角色里 orggraph-planning 正是 meta-bootstrap → 差 1。 也就是说：**界面上点一遍新建公司就会踩到**。这条缺陷上一轮就被预告过 （当时那个 agent 说「不在我的独占文件里」没修），今天被真实使用兑现了。 修法是让 verifyCounts 复用同一个 isMetaBootstrap 判据，不复制那个 type 判断。 新增独立测试文件（不并进 graph-seed-service.test.js —— 往它的 hermetic 夹具里 加角色会连带改既有断言），用 GRAPH_SEED_ROOT 自建最小夹具。 那个文件里第二条用例是刻意的：只断言「对账干净」时，seed 一个都没种也会“通过”， 两种原因症状相同。第一版就是这么错的 —— 我误以为 runStartupSeed 会种公司角色 （它只做 reconcile + 全局 agent + 模板），是第二条断言把「夹具没种」和 「过滤没生效」分开的。 ## 验证 871 全绿（87 文件）。3 处变异精确变红后逐字还原 （startsWith 回退 → 精确打红跨公司读/写两条；verifyCounts 去掉过滤 → 打红对账条）。 拿运行中的实例 + 用户真实公司 mycompany 走查过：读到真实 brd.md 内容， `../idearun/company.json` 与 `/etc/hosts` 均 403。web:build 通过。 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> -
测试 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>
-
界面走查（真 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>