• 44 号:writesArtifacts 节点产出闸门永远打不过
    - goal-benchmark 按设计把产物写进 root run 共享 artifacts/ 目录(三个节点合成同一份
      acceptance.json,天然不可能落在某节点私有目录),但 unsatisfiedRequiredProduces 的
      R-19 逃生口 readDeclaredProduces 的 allowedRoots 只认节点私有目录 + 项目根,够不到
      共享区——这条契约在当前实现下无论 agent 表现多好都无法通过。
    - 修法(44 号文档方案 1,改动面最小):allowedRoots 加入 runRootDir(run)/artifacts/;
      goal-benchmark 的 agent.md/tools.md 补上"写完共享产物后在自己节点私有目录声明一份
      contract.json"这一步。
    - 回归:graph-files-index.test.js 新增用例 ⑭。
    
    41 号:routeFailure 的 infra_flake 分支完全无视 target_node
    - 30 号文档记录过一次真实死循环:节点自称 infra_flake 并点名 target_node,引擎原来
      一律原地重跑该节点自己,从不看 target_node。
    - 修法(最保守方案,用户确认):新增 infraFlakeTargetEdge——target_node 只有在图上
      真有一条从本节点出发的 backward fail 边指向那个节点时才生效,命中就改走正常的
      backward 边路由(计入 backward_count/双层熔断),不再享受"原地重跑、只受
      infra_flake_count 约束"的免账本待遇;没命中维持原有行为。
    - 重要澄清:这条修复堵不住 30 号文档那次真实事故——事故里点名的目标是下游节点,
      而 org-graph-service.js 规则 4(backward-labeled)从图结构上就不允许 backward 边
      指向非祖先,那次事故本来就不是"有边不认",是"诊断内容在打图结构不允许表达的
      主意",已经靠 INFRA_FLAKE_HARD_CAP 熔断收敛,不在这条修复范围内。
    - 回归:graph-engine.test.js 的 infra_flake describe 块新增两条用例。
    
    44 号文档移入 done/,41 号清单项相应更新,43 号文档的交叉引用一并修正。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01CwGcvMfUcgCcweN5vjhTkn
    yibo authored
     
    Browse File »

  • 设计见 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>
    yibo authored
     
    Browse File »