• 给此前完全零防护的 company.js/okr.js/tasks.js/devloop.js/graph-run.js(两个挂载点)/
    arena.js/config.js/evolution.js/whatsapp-auth.js 挂 requireAuth;dream.js 挂 requireAdmin
    (系统级经验汇流视图,只有 admin 能看)。open-api.js(自己一套 OPEN_API_KEYS)/auth.js
    自身/health 端点按计划排除。这一步只挡"没登录",公司归属过滤留到 Phase 2。
    
    agent-chat.js 不能直接挂 requireAuth:company.js(自动建公司/招聘后自动训练)、
    task-settle.js(goal 汇报回调)三处服务端自环调用会 fetch 自己的 /api/agent/* 端点,
    拿不到任何用户 cookie,直接挂锁会打断这几条核心自动化链路。新增 requireAuthOrInternal +
    jwt-auth.js 的进程内 INTERNAL_TOKEN(启动时随机生成,只活在内存里):自环调用带上
    x-internal-token 头放行,其余情况仍要求真实登录;三处调用点同步改造。
    
    17 个既有测试文件、67+ 处用例直接拿 supertest 打这些路由,从没设过登录 cookie(测的是
    业务逻辑不是鉴权)。没有逐个补登录态,改为 requireAuth/requireAdmin 在 NODE_ENV=test
    时默认放行,除非显式 FORCE_REAL_AUTH=1;新增 route-auth-gate.test.js 在放行关闭状态下
    做结构检查(router.stack 里中间件是否真的排在所有路由前面),确保"锁真的挂上了"这件事
    有测试兜底,不被业务测试的默认放行悄悄掩盖。
    
    验证:真实 curl 走过全部路由(无 cookie 401、admin 登录全通、非 admin 能看公司但
    dream.js 403);手工删过一行 requireAuth 确认守卫测试真的会红;全量 vitest 1427 passed,
    另 3 个失败与本次改动无关(stash 验证过改前改后一致,系仓库并发工作遗留)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse File »

  • company.js 的 hire 路由原来用一发 fetch(...).catch(...) 回环自己去触发 agent-creator
    填新角色的定义文件——fire-and-forget,.catch 只接网络层错误,agent-creator 撞车时
    (另一次调用正占着它)/api/agent/:agentId/chat 返回 429,被原样当成"成功"吞掉。
    新角色因此永久停在 base 空壳 + status=training,唯一痕迹是一行 console.error(且这行
    在 429 场景下根本不会触发)。
    
    新增两个模块:
    - agent-session-lock.js:从 agent-chat.js 抽出的共享互斥锁存储(纯数据结构,Map +
      超时常量),agent-chat.js 的路由与 hire 路由现在用同一把锁。不能各起一把——
      SessionPool.getOrCreate() 不检查上一次调用有没有跑完,两条路径分开维护锁的话,
      各自都以为自己没有并发,会把第二轮 prompt 发进一个还在处理中的 CLI 会话
      (未定义行为,比现在的"被拒绝丢弃"更危险,见 32 号文档 §二方案 B)。
    - agent-body-filler.js:同进程直接调 AgentManager.callAgent,替掉 HTTP 回环。
      拿到锁才发起调用,锁被占用时等一等重试(最多 3 次,5s/15s 退避),重试耗尽在
      本体目录写一个哨兵文件 .body_fill_failed.json(不动 system_agents.status /
      config.json.status——那两个字段还有 draft→active 毕业逻辑在读,改取值域风险
      大于收益)。
    
    company.js 的 hire 路由第 1 步从 fire-and-forget 换成 await,顺带让第 2/3 步
    (技能注入、5 秒后触发 Innovator 训练)拿到"agent-creator 真的写完了"这个保证——
    第 3 步原来的 setTimeout(5000) 靠的是"假设 5 秒内写完",现在这个假设不再需要,
    但没有顺手删掉那个 setTimeout(不在这次修复范围内,留着无害)。hire 接口本身
    仍是异步的,调用方还是立即拿到 training 状态,没有改成同步等待完成。
    
    agent-chat.js 的锁声明改成从共享模块 require,行为逐字不变——用现有 5 个
    agent-chat 相关测试文件(36 条)验证过零回归。
    
    新增 agent-body-filler.test.js(6 条):首次成功、重试后成功、锁被占用时等待
    重试、重试耗尽写失败标记、成功后清掉上一轮的失败标记、只释放自己抢到的锁
    (不误删第三方在途期间抢到的新锁)。用 vi.useFakeTimers() 控制重试等待,
    不用真等 5s/15s。
    
    全量 npx vitest run:151 文件 / 1384 用例,零回归。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse File »

  • 28-followups §3.3。`PUT /api/agent/:agentId/heartbeat`(前端 Agent 详情页走的就是它)
    用 `getBodyDir(id)` = `bodyDir(parseAddress(id).agentId)` 把公司段丢掉,
    然后**整份重写本体 config.json**。
    
    两个后果,都不报错:
    ① 跨租户串写:co-a:ceo 改心跳,co-b:ceo 跟着变(同一份本体);
    ② 一旦该 (agent, 公司) 有了公司态文件,读侧优先取公司态 →
       **这个端点的写入对它变成静默无效**。界面收到 {success:true},
       实际在跑的还是旧值;GET /info 同理报的是本体缺省,不是在跑的那份。
       症状是「界面写 30 分钟、调度器按 15 分钟在跑」,两边都不报错。
    
    company.js 那三个端点在 28 号已经修好了,这个入口漏了 —— 同一个 bug 的第二扇门。
    
    ## 改
    
    读写都走 heartbeat-service 的 readHeartbeatConfig / writeHeartbeatConfig,
    与心跳挂载读的是同一个答案。入参校验归服务(intervalMinutes 直接进 setInterval,
    NaN / 0 / 负数会让定时器退化成每 tick 触发一次,而每次 tick 真起一轮 LLM),
    非法值在写盘前抛,端点翻成 400。
    
    顺带:404 闸门也改走服务的寻址。`cid:role` 里冒号后面是**角色名**,未必等于本体 id
    (company_agents 的映射)—— 拿角色名当本体 id 判存在性,凡是角色名 ≠ 本体 id 的
    都会被判成「agent 不存在」,而写侧其实找得到。**判 404 和写入必须问同一个问题。**
    
    ## 守卫
    
    heartbeat-company-scoped.test.js 补 3 例(放进同一个 describe 而不是另起一个:
    夹具共用,另起的话上面那个 afterAll 会先把 server 关掉,实测 ECONNREFUSED):
    · 写公司态、本体字节不动,且**写完立刻能从读侧读回来** —— 这条才是「静默无效」的精确形态;
    · GET /info 报的是在跑的那份,不是本体缺省;
    · 非法 intervalMinutes → 400 且旧值还在。
    反向验过:把端点退回旧写法,这 3 条立刻红。
    
    ## 记一条没修的
    
    GET /info 的 404 闸门仍是 `getBodyDir(id)`,对 `cid:role` 会直接 404 ——
    那是 /info 整体寻址的既有缺口(它还要按同一个目录读 identity / agent.md / cron),
    不在心跳这一条的范围内。测试里用裸 agent id 绕开,并在注释里写明别当成修过了。
    
    全量:138 文件 / 1292 测试全绿。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse File »
  • 主体由另一个会话完成(其会话已关闭,由我接手核对并提交),我补了两处修复
    与一条守卫。
    
    ## 它修的是什么
    六处「服务端自己给某个 agent 发一条 chat」各自写死
    `hostname:'localhost', port: systemConfig.port`(3010)。单测把路由挂到
    `app.listen(0)` 的临时端口上,回调却照样打进**线上 3010** —— 每跑一次汇报
    用例就给真 CEO 发一条 chat、起一个常驻 claude CLI 子进程、留一个
    callback-T-* 会话目录。症状完全静默:测试全绿,只有进程数和内存在涨。
    
    (这条是被我在批 5 新加的 task-dispatch-store 用例触发出来的:那之前没有
    任何测试会走到汇报回调。)
    
    抽成 selfChat:端口从 req.socket 取(收到这条请求的那个监听端口,天然就是
    「我自己」),测试环境整体短路。
    
    ## 我接手时发现并修掉的两处
    `task/transition` 的两个调用点删掉了 `const chatReq` / `const postData` 的
    声明,**却留下了 `chatReq.write(postData); chatReq.end();` 两行**。
    `node --check` 照样通过 —— 那是运行时 ReferenceError 不是语法错;而它在
    `setImmediate` 里抛就是未捕获异常,**直接杀进程**。
    
    真起服务打了一遍 POST /api/agent/ceo/task/transition:200,服务仍在。
    修之前这条路必炸。
    
    ## 守卫:server/tests/unit/self-chat-callbacks.test.js
    1. chatReq / postData 只许出现在 selfChat 函数体内 —— 「删了声明留下调用」
       这类改造残留,语法检查和单测都抓不到,只有真跑到那条路径才炸;
    2. 不许再有第二处自己拼 http.request 打 systemConfig.port(分叉的开始);
    3. 测试环境必须短路。
    
    第一版守卫把 selfChat 上方那段**注释**里引用的写法当成漏改报了红 ——
    那是文档不是代码,已跳过注释行。
    
    全量:135 文件 / 1272 测试全绿。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse File »
  • **本文件除了 saveTaskMeta / loadTaskMeta 的内脏和两处扫目录,其余一行没动。**
    /task/dispatch 与 /task/report 的 URL、请求体、响应体形态全部原样 —— 它们
    印在 packages/agent-core/base/common/tools-base.md 里,是所有 agent 的工具
    说明,改一个字等于同时改所有 agent 的提示词。
    
    ## 换掉文件存储的三个理由
    - 去重要「readdirSync 整个 tasklog + 逐个 JSON.parse」,任务一多就是 O(n) 次
      磁盘读,且没有索引可用
    - 派单任务在库里看不见 —— 控制台任务列表读 tasks 表,派单那套是平行世界
    - 同一个 T- 前缀两套 id 体系,读日志时分不清
    
    ## 落点
    - saveTaskMeta / loadTaskMeta 变成 tasks 表的适配器(upsert + 反向映射),
      meta 的形状一个字段不少:调用方按字段名取值,形状变了就是契约变了
    - 去重与父任务推断改成带索引的 SQL(idx_tasks_assignee),**判据一个字没改**,
      换的只是从哪儿把候选捞出来。查不动时留声不静默 —— 静默跳过等于去重形同虚设
    - 加 summary / execution_conv_id 两列(用户选的方案 A)
    - sourceConvId **删掉**:全仓零读取方,正是本仓库反复立案的「实现在、零调用方」,
      不往新表里再搬一份
    - objectiveId 不单独存:它恒等于 okr node id 的首段(OkrService.parseNodeId 与
      reportRunOutcome 同一口径),且两处读取方都是 `if (objId && meta.nodeId)`
    
    ## 真打过一遍,不只是测试绿
    照 tools-base.md 印的请求体原样 POST:200 + 老形态响应;再打一次 → 409 且
    existingTaskId 正确;落库 executor='agent' / assignee=qa-judge / status=running,
    自动建的 goal 标题「来自 ceo 的派单」、okr_node_id 落对;/task/report 之后
    status→completed、summary 与 finished_at 都在;loadTaskMeta 往返出来的形状与
    老 JSON 逐字一致,objectiveId 从 nodeId 首段推出 O-001;system/tasklog/ 不再
    产生新文件(仍是回填前那 4 个)。
    
    守卫:server/tests/unit/task-dispatch-store.test.js(4 例,盯的是「形状没变」)
    
    全量:132 文件 / 1255 测试全绿。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse File »

  • 310a2b2 / 3e718aa 把「正常跑完的对话」补进了回收路径,但 catch 分支没跟上:
    
        } catch (err) {
            dropSession(key);      // 只摘出池子,不杀子进程
        } finally {
            if (kind?.[2]) closeSession(key, ...);   // 池子里已经没了,返回 false,空转
            else armSessionIdle(key);
        }
    
    dropSession 的语义是「子进程已经自己死了」,可这里子进程活得好好的 —— 错的是它背后的
    API 调用(529 / DNS / 证书),CLI 一个都不会自己退。于是会话先被摘出池子,再也没人
    杀得掉它:一个既没有引用、也没有回收路径的孤儿进程。
    
    实测:一个跑了 23 小时的实例攒下 45 个孤儿 / 9.6 GB RSS,其中 38 个是心跳。抽查泄漏的
    convId,status **无一例外**是 failed;对照 cto 最近 60 次心跳是 55 completed / 5 failed
    —— 8% 的失败率,一次漏一个,数字对得上。成功的心跳一个都没漏,说明 310a2b2 本身是对的。
    
    改法:catch 里 dropSession → closeSession。可观测行为完全不变(两者都把会话摘出池子、
    都让下一轮冷启动),只是多杀一个本该死的进程。
    
    守卫:agent-chat-session-reclaim.test.js 新增一条。这里必须说清楚为什么破例去 spy
    disconnect —— **旧探针对这个 bug 是瞎的**:dropSession 和 closeSession 都会让会话从
    池子里消失,`/chat/:convId/stop` 两种情况都返回 success:false,差别只在子进程死没死。
    上一版修复正是因此漏过了这条路径。用 vi.spyOn 让 sendPrompt reject 来复现「CLI 活着、
    API 挂了」,再断言 disconnect 被调过。做过变异检验:退回 dropSession 后该用例转红。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse File »

  • 承接 310a2b2 的两个遗留:
    
    ① 四类被错标成心跳
       company-heartbeat-service._sendAgentChat 给五类调用(心跳巡检 / Pipeline 步骤 /
       日程 / 告警 / 日报)无差别打 isHeartbeat:true,于是对话列表里全都显示成
       「⏱️ 自主心跳巡检」、meta.type 一律 'heartbeat'。改成显式传 kind,五类各自标注。
       isHeartbeat 仍然发,但只对真心跳为真,老消费方行为不变。
    
    ② 310a2b2 让 Pipeline 重试变成了冷启动
       Pipeline 步骤的 convId 是 `pipeline-{runId}-step-{i}`,被驳回重做时**复用同一个**。
       310a2b2 按 isHeartbeat 一刀切回收,等于每次重试都要走 buildPrompt 场景 C 重注入历史。
       现在回收策略挂在 CALL_KINDS 表上,判据只有一条:**convId 会不会被下一轮复用** ——
       会复用的(pipeline / 人类对话)留着走 TTL,不复用的(心跳 / 日程 / 告警 / 日报)跑完即回收。
       不按「是不是后台调用」分:五类后台调用里 pipeline 就是要留的那一类。
    
    守卫补到 12 条(原 3 + kind 标注 5 + 回收策略 4)。对 310a2b2 跑过:8 红 4 绿。
    convId 一律用固定字面量而非拼时间戳 —— 撞上 test-id-stability 那道防线后按它的判据改的,
    固定之后第二次跑还顺带走了「复用已有对话」那条分支。
    
    文档:
      - CLAUDE.md 注意事项加一条(新增会话创建路径时必须同时定回收路径,附症状与守卫位置)
      - 28-followups 守卫清单补第五条,并把「前四条守单一持有者」与第五条「守资源生命周期」
        的形状差异写明;顺手修掉表格已有 4 行、结尾却仍写「这三条」的失配
      - .env.example 补 AGENT_SESSION_IDLE_MS
    
    全量单测 667/667 绿。重启后 /api/health 正常,心跳照常挂载。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse File »
  • sessions 里存的是**常驻**的 claude CLI 子进程(stream-json 模式,不是一次性的
    `claude -p`),此前只有四条回收路径:协议 error / 子进程 disconnected / 手动删对话 /
    手动 stop —— 「正常跑完的对话」不在其中。
    
    而两路心跳都用一次性 convId 打进 /api/agent/:id/chat:
      - heartbeat-service:`heartbeat-${Date.now()}`,cto / coo 各 5 分钟一次
      - company-heartbeat-service:_sendAgentChat 的五个调用点(CEO 巡检 / Pipeline 步骤 /
        日程 / 告警 / 日报)convId 也全是一次性的,且无差别带 isHeartbeat:true
    
    于是每次心跳新起一个进程且永不释放。实测单次运行 2h43m 攒到 82 个进程 / 17.5 GB RSS。
    
    改法:
      - 心跳会话跑完立刻 closeSession(一次性 convId,会话复用对它零价值)
      - 普通对话上空闲 TTL(默认 30 分钟,AGENT_SESSION_IDLE_MS 可覆盖),复用 engine/idle-timer
      - 计时器只在「没有在途请求」的间隙走:getOrCreateProtocol 命中复用时 cancel,请求结束时
        重新上弦。所以再长的单次生成也不会被 TTL 打断,比在流式回调里 touch() 少一个调用点
      - 删对话 / stop 两处手抄的 disconnect+delete 收敛到 closeSession,否则它们不停表
    
    守卫:agent-chat-session-reclaim.test.js 用现成的 /chat/:convId/stop 当黑盒探针
    (查得到会话才返回 success:true),不为测试加导出口。对 HEAD 版本跑过:2 红 1 绿 ——
    两条回收断言修前失败,「普通对话保留会话」修前修后都绿,证明复用能力没被顺手砍掉。
    
    线上验证:重启后第一轮心跳 2 触发 / 2 回收,server 名下 claude 子进程数 0。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    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 »

  • 测试 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>
    yibo authored
     
    Browse File »

  • 命名轴是「节点在哪一层图里」,把散落的老 agent 归到它实际所处的层级:
    
      innovator → org-innovator      type='cxo',是 org graph 层的节点
      hunter    → innovator-hunt     innovator work graph 第 1 阶段
      digester  → innovator-digest   第 2 阶段(输入是 hunt 产出)
      evolver   → innovator-evolver  第 3 阶段
    
    依据:retrain-pipeline.js 的 stepConfigs 就是按 hunter → digester → evolver 顺序
    跑的,行 231 明写 steps: ['re_hunt','re_digest','evolve'] —— 这三个本来就是
    innovator 的 work graph 三阶段,只是名字没体现出来。
    
    ■ 迁移(scripts/migrate-agent-naming.js,--dry-run + 幂等可重跑)
    - 8 个目录(system/agents/ + system/templates/),用 git mv 保留历史
    - system_agents 表 4 行的 id 与 legacy_path
    - 公司实例目录与 company.json.agents[](本次无公司雇过这四个,实际 0 条)
    
    ■ 代码引用点(5 处,手工改)
    - retrain-pipeline.js: stepConfigs 的 agent 字段 ×3、agentToStep 映射的 key ×3、
      call_sub_agent 的 evolver 判断
    - agent-chat.js: agent 列表过滤里的 innovator
    - company.js: 模板训练触发的 agentId
    
    ■ 刻意不动的三类同形异义(改了会坏)
    1. skill 内部子目录名 {skillDir}/hunter/knowhow.md —— 那是 hunt/digest/evolve
       三阶段的产物目录约定,与 agent 名同形但不同义。涉及 open-api.js:402、
       retrain-pipeline.js:148/374、evolution-loop.js:178、sync-skills.js 的 INTERNAL_DIRS
    2. skill 命名空间白名单 —— skill-dir-manager.js 的 CORE_SKILLS、
       migrate-trained-skills.js 的 SYSTEM_SKILLS,那里的 'innovator' 指同名 skill
    3. conversations/ 与 system/tasklog/ 下的历史记录 —— 运行态数据,不改写历史
    
    evolver-youtube-crawler 按 §3.4 列为待定,迁移脚本按精确目录名匹配,未误伤。
    
    这四个重命名顺带解决了 27 号文档 §七 挂了很久的 6 个命名冲突 id —— 重命名后
    system/agents/ 与 system/templates/ 下不再有同名目录(只剩 agent-creator 与
    evolver-youtube-crawler 两个,前者是基础设施角色按规则不改名)。
    
    验证:npm run test:unit 693 全绿(64 files);test-company-e2e 114/114;
    迁移脚本二次执行 dirs=0 dbRows=0 skipped=8(幂等)。
    
    未触碰另一进程正在进行的 P3 文件(graph-engine.js / graph-run-sse.js /
    work-graph-db.js / 27-p3-p4-work-graph-console.md / 27-requirement.md)。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse File »

  • 代码层:
    - server/services/goals.js → okr-service.js;GoalsService → OkrService
      · this.goalsDir → okrDir,目录 goals/ → okr/
      · ID 前缀 G- → O-;落盘文件 goal.json → objective.json
      · updateGoal → updateObjective,_nextGoalId/_saveGoal 等同步改名
      · parseNodeId 层级名 ['Goal','Objective','KeyResult','SubTask']
        → ['Objective','KeyResult','SubTask','SubTask'](OKR 无 Goal 这一层)
    - server/routes/goals.js → okr.js;:goalId → :objectiveId
    - 7 处调用点同步:index.js / agent-server.js / agent-chat.js / company.js /
      company-heartbeat-service.js / prompt-builder.js / test-company-e2e.js
    - 前端 OkrDashboard.vue / CompanyDashboard.vue 切到 /api/okr(前后端命名终于一致)
    - bin/lemon.js 新增 okr create/add-node/list/status
    
    向后兼容(不破坏任何现有调用方):
    - /api/goals/* 与 /api/company/:cid/goals/* 全部保留为别名,与新路径同时挂载
    - task dispatch/report 同时接受 objectiveId(新) 与 goalId(旧),写入时两字段都留
    - bin/lemon.js 保留 goal * 命令别名
    
    迁移脚本 scripts/migrate-goals-to-okr.js(npm run okr:migrate):
    - 目录 data/{,companies/*/}goals/ → okr/;条目 G-xxx → O-xxx
    - 改写 objective.json 的 id / nodes 的 key / children 数组、_index.json、
      progress.json 的 goalId、history.log 文本、system/tasklog/*.json 的 goalId+nodeId
    - --dry-run 预演;幂等;迁移前自动备份为 *.bak-goals(已加入 .gitignore)
    - 处理一个反直觉边界:OkrService 构造函数会自动 mkdir 目标目录,"okr/ 已存在"
      不等于"已迁移过"——只要服务被 require 过一次就留下空壳。用 isEmptyOkrDir()
      区分空壳与真实数据,空壳移除后继续迁移。这个 bug 是在 fixture 上验证时发现的。
    - 同样在 fixture 上发现并修掉:nodeId 的值漏改写、tasklog 迁移不幂等
    
    验证:新增 server/tests/unit/okr-service.test.js(7 例,覆盖新命名工作正常 +
    迁移纯函数的 ID 改写);全量 npm run test:unit 652 例全绿。
    
    范围说明:NAMING §五 的 benchmark 三分(skill-/agent-/goal-)本轮未动代码——
    该节自身的建议就是存量保持现状、只对新增代码强制前缀,因为 benchmark_runs 等表
    服务于线上 Arena 排行榜,改表名/路由是另一次独立迁移。
    §二-四 的新 agent id 尚不存在实体,待 P2/P3 实现时按规范创建。
    
    已知遗留(非本次引入):server/scripts/test-company-e2e.js 早已失效——它按
    data/{id}/ 找公司,而 company-service 用的是 data/companies/{id}/,在 HEAD 版本
    同样全部断言失败。本次只同步了其中的 OKR 命名,未修这个路径问题。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse File »
  • …_DIR move, stray files
    
    - CLAUDE.md: document DevLoop subsystem (spec-first workflow, project root/git-vault,
      mock mode, L1 loop, unit layout, audit trail) and add missing test commands
    - server/routes/agent-chat.js, server/services/task-service.js: TASK_META_DIR moved
      from system/agents/.tasks to system/tasklog
    - system/agents/master/.claude/scheduled_tasks.json: scheduled task state update
    - remove stray memory/daily/2026-04-02.md and a garbled-filename artifact left under
      system/agents/digester-youtube-crawler/
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse File »

  • 1. Evolver agent.md: Added token budget rules
       - No re-reading unchanged files between iterations
       - Use head/grep instead of cat for large files
       - Concise output only (scores + diff summary, no full SKILL.md)
       - Cap at 5 iterations per session (was 10)
       - Early stop if score change < 2 points for 2 consecutive rounds
    
    2. agent-chat.js: System prompt size guards
       - MAX_PROMPT_FILE_SIZE = 15KB per file (auto-truncate with warning)
       - MAX_TOTAL_PROMPT_SIZE = 100KB total (safety net)
       - Prevents runaway files from inflating context ever again
    yibo authored
     
    Browse File »
  • When a task completes and triggers a callback to the parent agent,
    previously it always created a new convId (callback-{taskId}), spawning
    a fresh CLI process with full system prompt re-injection.
    
    Now it checks the sessions pool for an existing connected session of the
    target agent and reuses its convId. This avoids creating a new CLI
    process and saves the system prompt overhead (~30K tokens for master).
    
    Falls back to creating new session if no active one exists.
    yibo authored
     
    Browse File »
  • Layer 1 (P0): Per-agent session mutex
    - heartbeat-service.js: skip heartbeat if previous session still active (30min safety valve)
    - agent-chat.js: reject concurrent /chat requests for same agentId with different convId (429)
      Multi-turn conversations on same convId still work normally
    
    Layer 2 (P1): Advisory file lock utility
    - server/utils/file-lock.js: O_EXCL-based .lock file mechanism
      Auto-cleanup stale locks, graceful degradation on timeout
    
    Root cause: HeartbeatService creates new convId per heartbeat, spawning
    independent Claude CLI processes that concurrently write config.json and
    SKILL.md, causing rollbacks and FRAUDULENT scores.
    yibo authored
     
    Browse File »







  • 1. 根治所有模板 Agent残留的过往公司(LemonV)私人记忆,使其诞生即为全新白纸状态。
    2. 提取出统一的 `methodology.md` 基类 Prompt,通过 `agent-chat.js` 强力注入。
    3. 从 Master 到各路 Agent 都将强制遵循【从大脑到小脑】的不硬编码理念。
    4. 全面引入统一的基础方法论(Harness):学习(Research) -> 规划(Planning) -> 执行(Execute) -> 验证(Verify)
    yibo authored
     
    Browse File »
  • 修复 Claude CLI 遇到严重 API 错误 (如 Http 429) 时,输出的不是合法 JSON,而是像
    'MiniMax 检查失败: HTTP 429: {...}' 这样的纯文本行。
    旧版本在 JSON.parse 失败后直接忽略。
    新版本增加 fallback,匹配非 JSON 行中的错误关键字并强制中断死等和前端展示。
    yibo authored
     
    Browse File »
  • - 当底层模型 (MiniMax等) 抛出 API 错误时,Claude CLI 不会崩溃也不会输出 stderr,而是通过 stdout 输出 event.type='error' 的 JSON 块。
    - 未处理该事件导致协议层无法等到 result 事件,引发 Promise 永久挂起。
    - 修复:在_handleStreamEvent 拦截 error 块,主动抛出错误打断等待链,前端即可正常展示 ❌ API 请求失败。
    yibo authored
     
    Browse File »
  • - ClaudeCliProtocol: stderr 检测 rate_limit/429/401 等致命错误时自动 reject sendPrompt Promise
    - agent-chat.js: 监听 stderr/disconnected 事件并通过 SSE 推送到前端
    - AgentChat.vue: error 事件停止 thinking 状态 + ACP 日志面板显示错误
    yibo authored
     
    Browse File »
  • - System agents: 只保留 master (data/system/agents/master)
    - Templates: 所有可复用 agent 模板 (data/system/templates/)
    - Companies: 公司创建时自动部署 5 个元 Agent (innovator/hunter/digester/evolver/agent-creator)
    
    路径修复:
    - agent-chat.js: /list 扫描路径修正 (system/agents + companies/*/agents)
    - agent-manager.js: 动态 agent 查找路径修正
    - skill-config-loader.js: 修正 agents root
    - pipeline-service.js: pipelines 输出到 companies/{id}/pipelines/
    - billing.log: 移至 companies/{id}/logs/ 下
    
    Skills 标准化:
    - 所有 template agent 建立 .claude/skills/main_skill/SKILL.md
    - company-service._copyTemplate() 新增 .claude/ 目录复制
    - innovator SKILL.md v3.0: 移除旧 l3-hunt/l2-digest 命名
    - 清理重复 agent_creator, 统一为 agent-creator
    
    清理:
    - 移除 data/agents, data/workspace, data/logs, data/goals 旧目录
    - 清除所有未使用的 DATA_DIR 声明
    - 清除 template 中的 conversations/logs/memory 运行态数据
    yibo authored
     
    Browse File »
  • - Add task transition CLI and API for Context Flush & Hot Swap
    - Enforce strict bash-only tool policy for Base Agents
    - Inject  into system prompt for self-retrying loop
    - Implement Goal node updates on transitions
    - Add P0 Execute pre-approval block (Human-in-the-loop)
    - Track token metrics to billing.log
    yibo authored
     
    Browse File »