-
2026-08-28 把本地 mycompany/innovator-fde-trial 同步到生产时手搓合并脚本踩过两个坑： 本地库和生产库同名字段的物理列序可能不同（SELECT * 位置对齐会静默写错列)，以及 graph_runs/graph_run_nodes 循环外键的回填 UPDATE 必须给关联子查询加表别名。 把手搓版本整理成 scripts/sync-company-to-graph-db.js（按列名对齐 + 支持 --dry-run）， 并在 graph-db.js migrate() 和 production-deploy.md 里记下这两个坑，供下次同步复用。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UpkWPa2CmuWJFJZksqvxWB
-
28-followups §3.1。**审计结论与那条待办原来的写法不一样，两列要分开处理。** ## source_kind：删 与 origin 一一映射（global_agent↔builtin / company_hired↔created）， 实查生产库 76 行零例外。全仓唯一读侧是 migrate() 里那条 origin 回填， 而那是给「origin 列出现之前写下的行」用的一次性迁移。 顺序：**先回填、再删列**，两步都用 hasColumn 守着（幂等）。反过来做不报错 —— 库能开、测试能过，只是那几行 origin 悄悄是错的。守卫 source-kind-drop-migration.test.js 走存量库重启那条路，专门钉这个顺序， 反向验过：弄反立刻红。 写侧散在 3 处生产 INSERT + 35 个测试文件。批量改的时候正则误伤了 4 处 （吃掉了 JS 默认参数、位置占位符、ON CONFLICT 的赋值行），逐个修回并复查了 diff —— **这种跨几十个文件的机械改动，靠「全量跑一遍」兜底比靠正则写得对更可靠**。 ## legacy_path：不能删，它还没死 原待办说「所有读取点都已改成从 id 推导」——那半句对新行成立，对存量行不成立： · 新行 legacy_path 恒等于 system/agents/{id}（确实冗余）； · **存量行里存着批次 4 之前的公司侧路径**，而 graph-seed-service 判「悬空行 / 孤儿行」 靠的正是这个路径指向的目录还在不在。从 id 推导出来的路径永远指向 system/agents/， 那条判据会整个失效。 实查生产库：76 行里还有 2 行是老路径（org-planner / org-coder 指着已不存在的 data/companies/mycompany/agents/）—— 正是这条判据要认出来的那种行。 退出条件写进了 graph-db.js 的建表注释（不只留在文档里）： 库里不再有 legacy_path <> 'system/agents/' || id 的行。 ## 顺带记一条：getDb() 会就地迁移生产库 删列那次，生产库的列是被一条**查状态用的**一行 node -e 删掉的 —— 服务当时没重启，人也没打算迁移。结果是对的（幂等；与备份逐行核对 76 行一致、 origin 全部按映射回填正确），但「读一下状态」不该顺手改 schema 这件事值得知道。 闸门只挡测试进程，故意不挡普通脚本（挡了服务自己也起不来）。 注释里给了只读的正确姿势。 全量：140 文件 / 1299 测试全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
## 病症 agent-chat-tenant-isolation.test.js 每跑一次，往共享生产库 data/graph.sqlite 落 2 条 goal + 2 条 task。实测 29→31。库里 31 条 goal 里 **22 条是它的残留**， 测试期间一直全绿。 根因是批 5 的存储迁移留下的半截清理：/task/dispatch 的元数据从 system/tasklog/*.json 换进了 tasks 表，而这个用例的 afterAll 只会清那个目录 —— 清理代码还在、清的东西已经不在那儿了。 ## 这是第四次，但换了个方向进来 前三次（BENCHMARK_DB_PATH / USERS_DB_PATH / SKILLS_DIR，记在 test-isolation-env.test.js 文件头）都是「设了 env，生产代码不读」。 那条守卫查的正是这个形态。 这次是**一个字都没设** —— 没有可查的东西，守卫自然查不出来。 静态扫源码也判不出「这个测试会不会开库」（要跨 require 链推导）。 ## 修法 1. 用例自己开一次性库（fs.mkdtempSync + GRAPH_DB_PATH），afterAll 连目录删掉。 赋值必须在 require 路由**之前** —— graph-db.js 的 DB_PATH 是模块级 const。 2. graph-db.getDb() 加运行期闸门：VITEST 为真且没设 GRAPH_DB_PATH → 抛， 报错里点名 env、点明「要在 require 之前设」。 放在 getDb() 不放模块顶层：只为取常量而 require 是合法用法 （goal-task-model.test.js 就这么用），顶层抛会误伤。真正开库才是越界那一刻。 3. 守卫 graph-db-prod-guard.test.js，4 例：撞库要抛且报错可照做、设了 env 要能开、 没有 VITEST 时不生效（防止把生产一起锁死）、样本非空。 反向验过：注释掉闸门那一行，第 1 例立刻红。 ## 顺带修一条 flaky（我自己上一版留下的） agent-docs-port.test.js 先 walk 出文件清单再逐个读，中间别的用例把 zz-* 夹具的 运行态目录清掉 → ENOENT。**报错长得像端口违例，其实跟端口无关**，实测 8 次跑中 2 次红。 只放过 ENOENT 一种（文件没了），其它读错误照抛 —— 一律 try/catch 吞掉的话， 权限错、编码错会被当成「无违例」。 ## 存量清理 删掉生产库里 created_by LIKE 'zz-tenant-%' 的 22 goal + 22 task （备份 /tmp/graph.sqlite.bak-c3a5d46）。零 run 引用它们。 其余 9 条 goal 是真实数据，一条没动。 全量：136 文件 / 1276 测试，连跑 8 次全绿（改之前 8 次里红 2 次）。 跑完后生产库行数零增量。 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>
-
测试 788/788 全绿（76 文件，起点 786），未改任何既有断言。 ## 1. idleTimeoutMs 硬编码 120s（「work 节点 → success」跑不通的唯一技术原因） agent-manager.js 里 `this.config?...?.idleTimeout || 120_000`，且 `...options` 摊在前面被下一行覆盖，两个后果叠加： - 默认 120 秒，比 stream-executor 自己 JSDoc 写的 30 分钟（1_800_000）小一个数量级， 也和同进程 ClaudeCliProtocol 早已放到 24h 的 idle 上限完全对不上 - 调用方**无法覆写** —— 传了 options.idleTimeoutMs 也会被盖掉 真 CLI 下的后果：任何「先读几千行源码再动笔」的节点都在动笔前被杀 （readme-writer: idle timeout: no stream data for 120000ms）。 改成 调用方 > agent 配置 > DEFAULT_IDLE_TIMEOUT_MS(30min)，并把常量真的定义出来 —— 上一轮 Master agent 自己诊断出这个问题也动手改了，但引用了未定义的 DEFAULT_IDLE_TIMEOUT_MS，跑起来是 ReferenceError。 ## 2. W7 判据在零边最小图上失效 判「org graph 成型了没有」原先看**边数**，理由是「节点 hire() 自己就会造， 拿节点数当信号会废掉『连雇两个人第二个不入图』」——理由成立，但边只是 「writeGraph 跑过」的代理，而真跑里 orggraph-planning 裁出过一张**零条边的单节点图**， 代理当场失效：三条判据全落空 → work 层本体被写进 org_graph_nodes， 下一次下达任务时被 advanceOne 当成 org 节点执行。 改成记录**来源**而不是猜：org_graph_nodes 加 authored_by（idempotent ALTER）， writeGraph 写 'planner'、hire 写 'hire'，判据看有没有 planner 写下的节点。 hire 先记的行随后被 planner 纳入时升格，反向不降级。 存量行 authored_by 为 NULL，回落到原来的边数代理，行为不变。 新增两条用例（既有 9 例造的全是有边的成型图，正好绕开这个形状）， 并做过变异验证：把判据改回纯边数，两条精确变红，还原后逐字一致。 ## 3. 前后端「能不能下达任务」的规则各写一份且不一致 前端 ACTIVE_RUN 含 blocked、后端 ACTIVE_ROOT_RUN_STATUS 不含（唯一索引 idx_graph_runs_one_active_root 里也没有）。后果：一家公司只要失败过一次， 控制台上就再也下不了第二个任务，而后端其实放行。 规则只留服务端一处：GET /graph-runs 返回 canDispatch / activeRootRunId， 前端照抄结果，不再自己复述取值域。字段缺失时保守放行，交给端点 409 兜底。 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>
-
用 9 个并行 agent 按「文件独占」划分实现 P2 的 T1-T9（T0 已于 2255f09 完成）。 详见 docs/todo/system-design/27-p2-org-graph.md §五。 阶段 A · 数据层 - graph-db.js: org_graph_nodes 加 status/reports_to_node_id（PRAGMA 探测后 ALTER， 幂等）；全量唯一索引换成 WHERE status='active' 的部分索引，使「fire 后重新 hire 同角色」可行；org_graph_edges 重建为执行流边（condition/edge_kind/status） - graph-service.js: ensureOrgGraphNodeIndex 同步改建部分索引，且 upsertOrgGraphNode 的 ON CONFLICT 必须写成 ON CONFLICT(company_id, role_name) WHERE status='active' —— SQLite 的冲突目标要与部分索引谓词逐字对应，否则整条 INSERT 直接失效 - org-graph-service.js（新）: validateGraph 四项校验 + writeGraph/patchGraph/ getGraph/removeNode，事务化，节点软删除级联失效相关边 - routes/company.js: 四个端点 POST/PATCH/GET /org-graph + POST /org-graph/replan； /create 接入自动招聘 orggraph-planning + 异步触发（失败降级为空壳公司）； /fire 接入节点软删除 阶段 B · 自动生成 - system/org-graph-templates/{dev,content,ops}.json + README：三张三段式骨架 （规划→执行→验收，验收失败回退到执行节点），角色名遵循 {domain}-{职能} - system/templates/orggraph-planning/：新 system agent（type='meta-bootstrap'）， 含 §4.1 八步工作流 - company-service.js: 模板不存在时从 system/templates/base/ 元 agent 继承骨架 （自动带 RESEARCH→PLAN→EXECUTE→VERIFY 四段式）+ agent-creator 填充， 新建 agent scope='company'。这是 27-E2E §八bis 元 agent 继承的落地点 阶段 C · 展示 - CompanyDashboard.vue: 组织流程拓扑链渲染 + 空态降级 + 环深度保护 并行编排中发现并修复的三处（均不在原任务划分内）： - AppNav.vue 建公司表单缺 goal 输入框 —— T0 只改了后端，前端表单没同步， company-goal 实际传不进来。这是上一轮 T0 的遗漏 - graph-seed-service.js 会把 type='meta-bootstrap' 的 orggraph-planning 塞回 org graph，与 hire() 的 guard 不一致 - graph-agent-p1-acceptance.test.js: hire 未知角色的返回从 needs_training 改为 hired_from_base（T5b 的行为变更），断言同步 验证（独立复核，非 agent 自述）： - npm run test:unit 676 passed / 63 files（基线 652，+24 为新增的 org-graph 用例） - npm run web:build 通过 - 三个模板 JSON 实跑 validateGraph 全部通过；四类非法图各自被对应 rule 拒绝； writeGraph→getGraph→removeNode 级联验证通过（删中间节点后 3 条边全部失效） Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
Adds server/services/graph-db.js (new data/graph.sqlite: system_agents, org_graph_nodes, org_graph_edges) and graph-seed-service.js, which scans system/agents/, system/templates/, and data/companies/*/company.json into seed rows without touching company-service.js's existing hire/copy path. Real repo data diverged from the design doc's original estimates (8 not 10 global agents; 39 not 34 template dirs; system/agents/ and system/templates/ turn out to share 6 ids describing the "same" agent from two different files) — documented in docs/todo/system-design/27-graph-agent-architecture.md section 7 for P1/P2 to resolve. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>