-
界面走查（真 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> -
命名轴从「业务领域」({domain}-{职能}) 改为「所在图的层级」： org graph 节点 org-{职能} org-planner / org-coder / org-validator work graph 节点 {父 org 节点全名}-{职能} org-coder-validator 三个模板因此首尾同名，只有中段职能不同——规划和验收本身不分领域： dev org-planner → org-coder → org-validator content org-planner → org-writer → org-validator ops org-planner → org-monitor → org-validator ■ NAMING §三 补上此前完全缺失的一条轴：节点名 ≠ 本体名 R-15.3 指出的关键区分。禁止裸用 validator 的理由是「一家公司内两个节点不能 重名」，该理由针对节点、不针对本体。本体若被迫带前缀，coder-validator 会复制成 org-coder-validator / content-coder-validator 多份，与 P1「同一份本体、多处引用、 各自私有语境」直接冲突。落到 schema 上就是 node_name / system_agent_id 两个字段。 同时写入 §3.3（三个 validator 是三个独立本体，验的东西本质不同，与 §八bis 「不特化」原则不冲突）与 §3.4（存量 agent 归位：innovator→org-innovator、 hunter→innovator-hunt、digester→innovator-digest、evolver→innovator-evolver， 依据是 retrain-pipeline.js 里三者就是 innovator work graph 的三阶段）。 §3.4 顺带解决 27 号文档 §七 挂了很久的 6 个命名冲突 id。 ■ 代码层已改 system/org-graph-templates/{dev,content,ops}.json + README、 system/templates/orggraph-planning/{agent.md,tools.md} ■ 代码层未改（已在 §3.4 末尾标注） §3.4 的四个存量 agent 重命名需要单独一次迁移（目录改名 + system_agents 表 + retrain-pipeline.js 等引用点），本次未做。 验证：三张模板图改名后实跑 validateGraph 仍全部通过四项校验； npm run test:unit 676 全绿；test-company-e2e 114/114。 未触碰 27-p3-p4-work-graph-console.md（另一进程正在做 P3 开发，且其中命名已符合 R-15.3）与 27-requirement.md（原文照搬文档）。 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>