-
泄漏被修过一次(310a2b2 / 3e718aa),修完照样漏。第二次排查发现原因不是修错了,而是: 系统里有两个互相独立的会话池,上一次只修了其中一个;而被修的那个,还漏了一条分支。 池 A routes/agent-chat.js 的 sessions ← /api/agent/:id/chat,含两路心跳 池 B src/core/session-pool.js 的 SessionPool ← AgentManager.callAgent,图执行 / DevLoop 两者没有任何共享代码,回收逻辑各写各的。这个结构性事实此前没有任何一处记着, 所以第二个人查到同一个症状时会重走一遍全程 —— 这份文档就是为了让第三个人不必再走。 正文八节,除了两个洞各自的成因与修法(b0b2b62 / 2092a2e),有三处是排查方法而非结论: §三 按 cwd 第三层判断孤儿归属的对照表。两个池子都把 cwd 下沉到运行态目录, `_global` / `_no-task` 是 agent-locator 的保留缺省值、两边都会出现,不能靠它区分。 §四 为什么上一版守卫是瞎的。dropSession 和 closeSession 都会让会话从池子里消失, 黑盒探针两种情况都返回 false —— 差别只在子进程死没死,而那是探针看不见的维度。 选探针要问的不是「能不能测出正确行为」,而是「能不能区分正确行为和这个具体的错误行为」。 §八 三步定位脚本,外加一条:先确认跑着的服务器进程是什么时候启动的,再去看代码。 本次排查中,正在跑的实例比修复 commit 早 18 秒启动,代码里有的修复它并没有。 线上验证(PID 63099,13 分钟窗口两轮心跳):触发 5 / 完成 5 / 回收 5,峰值子进程 3、稳态 0。 17:13:32 那个 3 正是泄漏时代的签名(cto+coo+qa-judge 同秒触发),清理前那批孤儿一个都不回收, 现在 30 秒内全部释放。窗口内没有失败心跳,所以 2092a2e 那条 catch 路径是靠单测的变异检验 保证的、不是靠线上观察 —— 文档 §六 里写明了,没算成已验证。 docs/README.md 同步加索引条目(no-dead-path-references 守卫 4 条全绿)。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
用户授权清理 system/templates/ 的过期引用。全仓库核了 34 处, 结论与预期相反:没有该删的死代码,但有两处正在静默失效。 真正坏掉的(demo-harness-company.js): path.join(ROOT, 'system/templates/base/agent.md') → system/agents/_base/ path.join(ROOT, 'system/templates/base/config.json') → system/agents/_base/ 两处都包在 fs.existsSync() 里,所以目录消失后**不报错**,只是 静默跳过 base 本体的挂载 —— demo 跑出来的 agent 没有四段式骨架, 但脚本照常打印成功。又一个静默降级。 顺带:real-pm-smoke.js 的提示文案、migrate-agent-naming.js 里 已失效的遍历项、docs/README.md 的 qa-judge 落点。 CLAUDE.md 目录速查表原来只有 `system/templates/devloop-*/` 一行, 连 system/agents/ 都没列。换成两行并写清三个容易踩的点:目录才是 数据源头(seedAgents 直接扫目录)、_registry.json 只补 benchmark_score、_ 前缀是保留 id 会被跳过。 **刻意不动的**:server/tests/ 下 30 处引用。它们分两类,都得留 —— ① 记录迁移过程的注释;② 断言目录已不存在的守卫 (`expect(git(['ls-files','--','system/templates'])).toBe('')`、 `expect(fs.existsSync(...)).toBe(false)`)。删掉后者等于删掉 「迁移已完成」的证明。legacy_path 那几个测试夹具同理,是历史数据形态。 验证:三个脚本 node --check 通过;改后的四个路径实测存在。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
按 docs/README.md 既有约定(done/ 放「已实现/当前有效」),把两份已落地的 阶段设计文档移入 done/system-design/: - 27-p1-virtual-reference.md P1 虚拟引用寻址,commit 226489d - 27-p2-org-graph.md P2 Org Graph,70a4727 + f20d0d8,真实建公司端到端验证过 用 git mv 保留历史(R098 / R087)。移动断掉的 33 处相对链接已全部修复: moved 文件内的出向链接改 ../../todo/system-design/,todo/ 下 6 个文件的入向链接 改 ../../done/system-design/。全 docs/ 扫描无断链。 README 此前严重过时——只列了 2 份 27 文档,实际已有 11 份。本次补全 todo/ 表格, 每份标注状态与作用(总纲 / 需求源头 / 命名规范 / 端到端 / 参考场景 / P3+P4 已实现 / 验收契约 / P4 设计中),并在 done/ 表格补上 P1、P2 两行。 ■ 刻意没有移动 27-p3-p4-work-graph-console.md 它虽然已实现(c3abf4a),但文档正被另一进程持续修改(工作区 M 状态)。 移动会打断它的编辑路径,等它收尾后再归档。 ■ 三份文件的链接修复留在工作区未提交 27-naming-conventions.md / 27-p3-p4-work-graph-console.md / 27-requirement.md 里,我的链接修复与另一进程的在途编辑混在同一文件中,单独拆分风险大于收益。 工作区内容是正确的(链接已指向新路径),会随它下次提交一并带上。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
- New docs/README.md indexes the tree: done/ (shipped features + reference manuals), todo/ (current focus — Graph Agent architecture), todo/future/ (deprioritized roadmaps: FDE pipeline todo list, stale v1.1 milestones, harness engineering proposal — orthogonal to the Graph Agent work, not blocking it) - Move completed/reference docs into docs/done/ (LEMONBOSS-SYSTEM-DESIGN, architecture-v5, claude-code-cron, open-api-manual, qa_judge_req, task_timeline_design, user-guides/, system-design/01-26 minus the three moved to todo/future/) — verified against actual code (qa-judge template, Task Timeline route/service/view) before filing as done - Fix the two TOC links in LEMONBOSS-SYSTEM-DESIGN.md that would otherwise point at the old paths after the move - docs/todo/system-design/27-graph-agent-architecture.md: add the P2 Org Graph doc link in the roadmap table and 关联文档 section - Add docs/todo/system-design/27-p2-org-graph.md (P2 requirements & design, drafted in parallel while P0/P1 landed) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>