README.md
34.1 KB
docs 索引
文档按状态分为三个目录：
done/— 描述已实现 / 当前有效的架构与功能的文档（含长期参考手册）。todo/— 当前正在推进的路线图/设计草案。todo/future/— 尚未实现、但不是当前重心的待办（暂缓，等主线腾出手再回来处理）。
判断依据：文档正文的显式「状态」标记（✅ 已完成 / 已实现 vs 📝 设计中 / 未实现）、未勾选的 checklist，以及与代码库实际实现的交叉核对（见各条目备注）。
当前主线：Graph Agent 架构重构（27-graph-agent-architecture.md）。 该系列已完成的阶段文档（P1 / P2 / P3+P4 执行控制台 / P3 收尾 P3C / P3B / P4）移入
done/，其余非主线待办在todo/future/。 当前未完成的是：28-followups。P3B 九条验收已于 2026-09-08 全部验完；P4 已于 2026-09-08 收口；P3/P4「真实路径 smoke 进 CI」的欠账已基本还清，只剩真 LLM（本质限制）与按需 hire 未覆盖。
done/
| 文件 | 说明 |
|---|---|
| LEMONBOSS-SYSTEM-DESIGN.md | 系统设计主索引 v2.0，含 27 章 system-design/ 的总目录 |
| architecture-v5.md | v5.3 架构方案，Phase 1-6 已完成（Phase 7 认知架构条目单独见 todo/） |
| claude-code-cron.md | Claude Code 原生 Cron 调度功能参考手册 |
| claude-cli-session-leak.md | 常驻 CLI 子进程泄漏排查手册 — ✅ 已修复（b0b2b62 + 2092a2e）：系统里有两个互不相干的会话池（routes/agent-chat.js 的 sessions / src/core/session-pool.js），各漏各的。含按 cwd 判断孤儿归属的方法、变异检验为什么必要、三步定位脚本，以及 DISABLE_BACKGROUND_AGENTS=1 —— 跑全量测试前关掉后台驱动的开关 |
| open-api-manual.md | ArenaSK Open API 外部调用手册 |
| production-deploy.md | 生产部署环境与上线流程 — 服务器地址、/opt/lemonboss 部署拓扑、Docker 容器、git pull + 重启的具体步骤 |
| qa_judge_req.md | QA Judge Agent 需求文档 — 已在 system/agents/qa-judge/ 落地 |
| task_timeline_design.md | Task Timeline View 设计文档 — 已实现（server/routes/tasks.js、server/services/task-service.js、web/src/views/TaskTimeline.vue） |
| user-guides/08-base-agent-4-phase-guide.md | Base Agent 四阶段使用指南 |
| system-design/27-p1-virtual-reference.md | P1 虚拟引用寻址 — ✅ 已实现（commit 226489d，server/services/graph-service.js）：agent.md 不再逐公司拷贝，改为 config.json.systemAgentRef 引用 + company-context.md 承载公司语境 |
| system-design/27-p2-org-graph.md | P2 Org Graph — ✅ 已实现（70a4727 + f20d0d8）：org graph 定位为 company 级 workflow（执行流边），orggraph-planning agent 建公司时自动规划并招聘。真实建公司端到端验证通过 |
| system-design/27-p3-p4-work-graph-console.md | P3+P4（原 P4 回退+Loop-Validator 已并入）图执行引擎与执行控制台 — ✅ 2026-09-09 已彻底收口，移入 done/（c3abf4a 起七轮实现）。§十「四条硬规矩」第 2 条欠账已还清：graph-real-chain-smoke.test.js（零注入、只换掉真 CLI 子进程）进 CI，覆盖 agent_call/subgraph 两支 + 多节点/回退边/双层熔断三种形状；按需 hire（resolvePlanningAgentName）用隔离 worktree + 真 Claude CLI 探针跑通，workgraph-planning 真的被按需雇进了一家没预雇过它的真实公司。唯一剩下的是真 LLM 本身进不了 CI 这条本质限制（要额度、分钟级、输出不确定），不算欠账，只能靠隔一段时间人工真跑核实 |
| system-design/27-p3c-goal-task-model.md | P3 收尾 goal / task 两级模型 + 控制台任务列表 — ✅ 已完成（2026-08-20）：五批实施 + §十七 清尾。含队列 / 并行槽位、task-planning、两套任务体系统一、墙钟预算改「只算活跃时长」。§17.5 是真跑验收 —— 返工闭环第一次由真 agent（不是注入的假 executor）走通 |
| system-design/27-p3c-batch3-handover.md | 批 3 交接 —— ✅ 已收口（2026-08-20）。事故记录归档：一份未经复核的代码被第三方会话提交进 main。留着是因为 §六 那几条多会话协作规则是真踩出来的 |
| system-design/38-auth-multi-tenant-isolation.md | 登录鉴权 + 公司级多租户隔离 —— ✅ Phase 0/1/2/3 全部完成（2026-08-25）。种子账号 admin/hex1234 + 登录页；全站挂 requireAuth（agent-chat.js 用 requireAuthOrInternal 放行三处服务端自环调用）；company.json 加 ownerId，canAccessCompany 是全仓库唯一归属判据，company.js/graph-run.js/devloop.js 分别接入（graph-run.js 双挂载点参数形状不同，设计阶段描述不准确，实现时才发现）；okr.js 因是零导航入口的孤儿页面改挂 requireAdmin 而非归属校验。Phase 3 验证阶段真查出一个漏洞：agent-chat.js 靠 :agentId 的 "companyId:role" 前缀区分会话归属却从没做过归属校验，任意登录用户可跨租户读别家公司会话，已修复。全量 vitest 1433 passed |
| system-design/01-26 | 系统设计正文 01～26 章（14、25-harness-engineering-improvements 例外，见 todo/future/；27 例外，见 todo/），各章节状态见文内「状态」标记 |
| system-design/29-dream-design.md | dream（经验汇流）— ✅ 已实现。定时整理所有 agent 在所有公司的记忆，提炼后跨公司沉淀（不泄漏公司信息）。四条取舍已拍板并实现：去敏独立判定、四落点分层写入（经验/SKILL.md/soul.md/agent.md，受管区块+三道闸门）、每日定时（串行+空转保护）、引用真伪自动查、REST+控制台入口（/api/dream/*、/dream）。innovator-evolver 真 CLI 跑通一次。仍缺的：「结论对不对」只能人抽查；「套进 org/work graph 来跑」评估后用户选了不做（作用域不匹配，见文内 §5.7） |
| system-design/31-work-graph-fail-fallback-coverage.md | work graph 兜底边覆盖不全 — ✅ 已完成（除入口节点外强制兜底边，planner.json/executor-fanout.json 补 6 条边），978/978 单测通过；2026-08-21 又用真实 LLM 起了一条新任务做端到端回归验证，org-planner-sdd 自判失败后自动打回 org-planner-prd（3 次，零人工介入），修复确认生效 |
| system-design/32-hire-body-fill-reliability.md | 招聘装配的时间窗——✅ 方案 B 已实施（2026-08-21，评估与实施同一天，提交 6a18379）。承接 30 号文档 §2.1：招聘时的本体异步装配没有任何可靠性保证，写侧比读侧更严重——"这个角色永久卡死，没人知道"。agent-session-lock.js/agent-body-filler.js/company.js/agent-chat.js 改动落地，§四「风险/未决问题」1/2/3 三条已在实施时逐条拍板 |
| system-design/33-needs-gate-role-filter-bug.md | ✅ 已修复。executor.json/executor-fanout.json 里 produces:["log"] 声明了一个 test/integration 类节点永远不会被索引到的 kind，导致 org-coder-validator 被 missing_required_input 反复误判 blocked；改成 required:false（对齐 validator.json 既有写法）。文档记录了一条走过的弯路（按 role 过滤 inboundContracts 会削弱 T-mt25ecbd 的产出闸门，已撤回），发现于 31 号文档的真实回归验证过程中，与兜底边问题无关 |
| system-design/34-validator-scored-without-real-deliverable.md | 📝 调研记录，checklist 已查完，结论已被 35 号文档吸收为改进提案并实施。最初以为 org-coder-impl 从未产出任何 HTML/CSS，后来发现真实网站其实存在于 graph_files 索引不覆盖的「项目根」目录（已顺手修：控制台「产物」面板现在会展示项目根）。追加查清 validator 有没有真的做浏览器级检查——中途自我订正一次：不是"没工具做不到"（bash 能走到仓库自带的 Playwright，另一条对照任务证明可行），是没人教它这么做；抽查另外两个项目根后发现验证严谨度完全不稳定（同类任务有的做了真实 Playwright 级验证、有的只做静态正则、有的没验证就被取消），根因很可能是新招聘的 unit-tester 本体撞上了 32 号文档 那类"装配没填充完"的真实样本，不是平台工具限制 |
| system-design/35-validation-rigor-and-body-readiness-proposal.md | 📝 复盘 + 改进方案，四条提案全部已实施。承接 31/32/33/34 号的复盘结论：任务结果差主要是架构问题（完整性闸门 missingBodyDefinition 只在招聘时查、图执行侧完全没有第二道防线——新发现）+ 一个具体的招聘装配可靠性 bug，不是 agent 能力问题。提案 A：本体不完整时图执行前置判 fail_reason=body_not_ready，不扣预算。提案 D：goal-contract.js 的 evidence_hint 命中浏览器类关键词的维度必须有证据支撑，否则判不过。提案 C：新增 scripts/visual-acceptance-check.mjs 复用检查工具。提案 B：控制台「验收证据」小节展示每个维度有没有证据支撑 |
| system-design/40-agent-chat-streaming-interrupt.md | ✅ 已实现（commit 4d23f50，2026-08-30）。回应"前端刷新不及时/没有打字机效果，要不要把 SSE 换成 WebSocket"——排查后结论是传输层不是瓶颈（对照 hermes-webui/hermes-agent/deepseek-harness 三个参考实现，全部走 SSE，不用 WebSocket）。三个独立缺口全部补上：① 打字机不流畅→后端按字符数切片 + 前端 createTypewriterQueue 匀速吐出；② 执行中无法打断并接上新消息→stop 端点改轮询确认锁真正释放，前端据此直接发送/强制发送兜底，顺带修了服务端对同 convId 并发缺闸门这个真实 bug；③ 串台加固→handleEvent 抽成纯函数并补齐 9b1c3f1 那条不变式的回归测试。已用真实 Claude CLI 会话在浏览器验证 |
| system-design/39-boss-agent-task-supervision.md | ✅ P1-P5 全部已实现（2026-08-30，a00590a/5108d67/d967ac0/14cbaf5）。boss agent（复用 ceo）监督 goal/task 看板闭环：draft task 回写、事件驱动+低频兜底唤醒、独立任务看板页、公司级 target_dir。真实端到端测试（建公司→下 goal→跑出一个 Playwright 5/5 验证通过的贪吃蛇游戏）撞出并记录了三个单测没覆盖的真问题，见文内「七、真跑复盘」；沉淀的待办已在 42-org-work-graph-reliability-followups.md 全部收口 |
| system-design/42-org-work-graph-reliability-followups.md | ✅ Phase 1-4 全部已实现（2026-08-30，6ae1f76/2a60fe1/ae7650e/2a0ffb8）。39 号文档真跑复盘沉淀的四 phase 可靠性收尾：① 卡住恢复闭环（服务器重启僵尸节点检测 + 强制判失败端点）② ceo 自建 task 的闸门穿透性回归测试 ③ target_dir 的 API/UI 配置入口（Phase 3 前端缺一次真实浏览器点击验证，见该节说明，是唯一已知缺口）④ timeline.ndjson 承接 planning/reflection 轨迹——--artifact 路径本身编码 rootRunId/nodeRunId，不用改任何 agent.md 或塞新环境变量 |
| system-design/43-task-decomposition-granularity.md | ✅ Phase 0-4 全部已实现（2026-08-31）。回应"org-planner 出 brd/prd/sdd 后，任务看板能不能展示成 task/sub-task 树，coder-validator 按清单逐条开发验收"。tasks 加 acceptance_mode/parent_task_id（后者复用既有列）；task-planning 判断要不要拆（硬规则 5 开例外让 LLM 写这一个字段）；org-planner 收尾把 acceptance.md 物化成子任务；coder-validator 新增 task subtask-result 工具逐条上报，settleNode() 新增闸门强制核对子任务全 completed 才认 success；看板加子任务展示。落地时订正了一处原计划想岔的架构假设：org-planner 在 org 层永远是 subgraph 节点（不是 agent_call），真跑数据显示它当前展开成的 planner.json 5 节点子图里，goal-benchmark/planner-validator 两节点常被 skip，acceptance.md 未必真的产出——钩子已改成扫子 run 全节点、找不到就优雅降级为 holistic，不阻塞主产出，但"子任务一定会长出来"这件事目前是尽力而为不是保证，见文档"实现记录"一节的遗留风险说明。全量单测 1120/1123 通过（3 个失败与本次改动无关，本次改动前即存在） |
| system-design/44-writes-artifacts-produces-gate-mismatch.md | ✅ 已修复（2026-08-31）。43 号文档真实回归中发现：writesArtifacts:true 节点（goal-benchmark）写进共享 artifacts/ 目录的产物，产出闸门只查节点私有目录，永远判「没产出」。修法：readDeclaredProduces 的 allowedRoots 纳入共享区 + goal-benchmark 补一份 contract.json 显式声明 |
| system-design/45-graph-run-node-liveness-recovery.md | ✅ Part A/B/C 已实现（2026-08-31），Part D 有意延后。真实事故：h3video 公司一个 agent_call 节点卡在 status=running、背后 CLI 进程已死，服务器主进程没重启——心跳（纯 LLM 驱动）、开机一次性孤儿扫描、goal/task 巡检（判据是 blocked 不是 running）、wallclock 看门狗（按预算不按存活）四层机制全盖不到；ceo 被转发问题后自己绕过引擎拉会话，陷入死循环。Part A：调查发现 SessionPool 是每次调用现造即回收的一次性对象，没有可查询的存活注册表，原设计不可行，改用「运行时长超阈值（默认 25 分钟）+ 只扫 agent_call 节点」，新函数 sweepStaleRunningAgentCalls/startStaleAgentCallWatchdog（graph-engine.js），5 条新单测。Part B：force-fail 端点（42 号文档已实现）本身就够用，零新后端代码，只在 ceo/tools.md 补了使用文档 + 明确禁止绕过引擎自拉会话。Part C：ceo/heartbeat.md 同步更新。Part D（节点补显式心跳字段，消除 Part A 阈值判据的误伤局限）未做，见文内「实现记录」的理由 |
| system-design/47-itemized-subtask-materialization-goal-benchmark-fallback.md | ✅ 已修复（2026-09-02）。46 号文档 Phase 0 真实回归坐实：acceptance.md 在当前 workgraph-planning 常规划出的 org-planner 子图形状（prd/sdd/goal-benchmark/planner-validator）下结构性产不出来，itemized 子任务物化 0 命中。修法：物化逻辑新增兜底，acceptance.md 缺失时改读已被 44 号文档证实稳定产出的 goal-benchmark.json 的 dimensions[]。task-decomposition-materialize.test.js 5 条全过（2 条新增，用真实回归捕获的产物做测试数据） |
| system-design/48-task-acceptance-contract-binding.md | ✅ 已实现并完成真实端到端回归，已收口（decomposed_work 链路 2026-09-02/回归补于 2026-09-03，剩余三条路径调研收口于 2026-09-03）。承接 46 号文档 Phase 3 v2 真实回归发现的 org-validator 死锁：验收契约的产出被硬绑在"公司完整 org graph 一定会跑到 org-planner"这个假设上，不满足这个假设的执行路径（如轻量子任务图）无契约可读、退无可退。方案：消费端（validator 只认结构化契约、不自由判断）保持硬约束不变，产出端改成"每个 decomposed_work 子任务创建时必须 1:1 带一份验收契约"（tasks.acceptance_contract + createTask 统一校验 + enqueueTaskRun 落盘），真实 org-coder→org-validator 全程跑通验证。收口时追加调研：task-planning/org-planner 的 acceptance_item 物化/人类快速派单三条创建路径经核实不需要同款强绑定——都走完整 org graph，workgraph-planning 的 benchmark 节点"不可裁"约定已天然保证有契约，强行加会跟 46 号文档保护的 task-planning 极简边界、快速派单"零 LLM"定位冲突。真正残留风险是"org graph 一定含 org-planner"目前只是提示词约定非代码强制，属于 org 拓扑保证问题，不在本文档范围。安全网（发现时就地补契约）按设计仍只留原则，decomposed_work 链路已被主力机制完全覆盖，不为不可达场景写代码 |
| system-design/27-p4-parallel-and-artifacts.md | P4（回收编号）并行执行与产物索引 — ✅ 2026-09-08 已彻底收口，移入 done/（阶段 A/B/C 全部完成，含本轮补齐的同 agent 多实例隔离生产接线 + advanceTree 兄弟子 run 并发）。T5 账户欠费门本身已实现（可插拔桩子），只差接一个真实计费接口——用户拍板暂缓，见 todo/future/ |
| system-design/27-p3b-real-run-runway.md | P3 收尾之真跑跑道（从 mock 走到真 Claude CLI）— ✅ 2026-09-08 全部收口，移入 done/。§六「九条验收」全部验完（验收 9 见 §六quater：2 节点 org 图故意跳过 org-coder，org-validator 真实读项目根、四维度全判 0 分，engine 真实沿 org 层 fail 边把 org-planner 重置重跑，15 次真调用/218,887 tokens）；正文里 W5/W6/W7/W8/W9 等更细粒度小项也已逐条核对——大半此前就被后续真跑验过、只是没回填，真正之前从未验过的只有 W8（重新规划组织按钮），本轮用隔离 worktree + 真 Claude CLI + 真实浏览器点击补验（详见「W8 浏览器真跑验收」，该节末尾记了一个真跑中顺手发现、尚待排查但不影响验收本身成立的前端细节：insertNode 重规划成同名角色时复用同一行 id，与文档里"每次换新 id"的旧设计假设不一致）。⛔/🟡 的历史段落读之前先看头部状态行 |
| system-design/46-mandatory-planning-and-task-decomposition.md | ✅ 已收口（2026-09-07）。Phase 0-5 全部实现。Phase 1：新 agent subtask-planning，钩在 enqueueTaskRun（显式 opt-in），产物写共享 artifacts/subtask-plan.json。Phase 2：经验检索 + 按需 deep research（默认关闭）。Phase 3 v2：CEO 心跳直接发现+派发（push），子任务走轻量 work graph（org-coder+org-validator 两节点）。Phase 4：父任务被拆分后让位给子任务（新状态 decomposed）、预算按步数均分、父子终态汇总（settleParentTaskIfAllChildrenDone）、同父子任务独立并发坑位（上限 3，不占公司级槽位）——四项机制全部用真实数据验证过，包括最后补跑的父子终态汇总（两个真实子任务全部 completed 后父任务被正确自动结算成 completed）与第二次并发确认。过程中撞出并修复一个几乎必现的真缺陷（markTaskDecomposed 原本只认父任务还是 queued，但 task-scheduler 抢坑是毫秒级、subtask-planning 是数十秒的真实 LLM 调用，等它拆完时父任务几乎必然已经 running，接管必然失败）。Phase 5：看板加 decomposed 状态样式 + 子任务进度展示，父子树形复用已有通用逻辑，未改后端接口。回归过程中还牵出一个独立缺陷——org-validator 对同一种 benchmark 契约判断不稳定（5 次里 1 次误把源码路径当 --target 判 target_not_json，反手倒退归因给 subtask-planning）——已定位根因（decomposed_work 轻量图当时只有一条前进边，没有失败边，validator 判 fail 后无路可退）并修复（补 validate --fail--> impl 退回边，复用引擎已验证过的 backward_count 双层硬顶 + remediation_note 反思闭环，新增 3 条单测），详见文末补跑记录 |
todo/（当前主线）
Graph Agent 架构重构（27 系列）。已完成的阶段文档已移入 done/（P1、P2、P3+P4、P3C、P3B、P4），下面是仍在推进或长期有效的部分。
| 文件 | 说明 |
|---|---|
| 27-graph-agent-architecture.md | 总纲。P0-P6 分阶段路线图与整体架构。P0-P3+P4 已实现，P4（新）/P5/P6 待做 |
| 27-requirement.md | 需求源头。用户原话照搬（R-1..R-16）+ 需求→设计落点速查。其余文档都是对它的转述，出现分歧以此为准 |
| 27-naming-conventions.md | 命名规范。{作用域}-{职能}；图节点按层级轴命名；节点名 ≠ 本体名；三种 benchmark 消歧；OKR 正名。新增 agent id / 表名 / 字段名前必读 |
| 27-e2e-task-execution-flow.md | 端到端流程总览：建公司 → 下达任务 → org graph 逐节点执行 → work graph 规划与循环 → 验收收敛。含与 DevLoop 既有实现的对应关系分析 |
| 27-example-dev-company-walkthrough.md | 参考场景走查（虚构的「配图工厂」），把架构跑一遍具体的数：各阶段 JSON 形态、成本估算、断点清单 |
| 27-goal-contract-format.md | 验收契约格式（goal-benchmark / goal-test-data / goal-test-script 的产物形态与跨节点传递） |
| 28-followups.md | 28 号（Agent 注册表统一）的遗留清单 — 主文档已在 done/，这份装没做完的：dream 机制（设计见 29 号，已实现，见下）、source_kind（✅已删）/legacy_path（不能删）删列、三项「已实施未验证」。任务态清理（✅已实现，见下）。§五 是已立起来的守卫清单（别重复造，也别删） |
| 30-task-delegation-reliability-gaps.md | 任务委派可靠性现状— 📝 调研记录，非设计方案。DevLoop runUnit、Company 招聘装配、Graph 执行三条链路核对结论一致：都是「失败预算耗尽 → 停等人工」，没有「卡住了主动通知人」这一层；DevLoop 当前还默认走 mock，真实 CLI 成功率无实证数据。2026-08-23 追加真实实例并已修：infra_flake 原地重跑没有熔断线，真撞上过一次确定性死循环（节点把诊断结论误判成自己的执行结果，反复重跑却从不路由到诊断建议的目标节点）；已加 infra_flake_count 列 + 硬顶 3 次熔断，连续判 infra_flake 超过硬顶就改判 blocked 交给人工 |
| 41-graph-vs-fde-reliability-discussion.md | 📝 讨论记录 + 落地实测，非设计方案。org/work graph 与 master-Innovator-FDE 两套工作流的稳定性对比：根因是"拓扑运行时生成 vs 写死"。问题 7 是真实执行记录——新建 org-hunt/digest/evolve（graph 原生协议，方法论抄 innovator-hunt/digest/evolver）跑 Hunt→Digest→Evolve，11 轮真跑中挖出并修复 5 个独立缺陷（建公司自动规划竞态、work-graph 模板库缺内容型交付物骨架、验收节点任务描述越权、两个规划 agent 的路径口径写错、R-19 产出索引 indexNodeOutputs() 不覆盖项目根——最后一条改了 graph-engine.js 核心逻辑，加 contract.json 的 produces 显式声明机制，全局生效，补了 2 条守卫测试）。最终产出与原生 FDE（prd-methodology-trial）对比：内容骨架可迁移、质量不打折，但过程严谨度不如原生 FDE，可靠性差距悬殊（原生一次跑通，graph 版 11 轮才稳定）。routeFailure 的 infra_flake 分支绕过跨层寻址（target_node）这个口子已按最保守方案补上（2026-08-31，见文内清单）——但堵不住 30 号文档记录的那次真实事故，那次事故点名的目标是下游节点，图模型本身就不允许 backward 边指向非祖先，属于修复范围之外 |
| 37-org-graph-department-scoping.md | 📝 设计讨论，调用点扫描已完成，尚未立项实现。现状 org graph 按 company_id 单例（27-P2 标题原文即"公司级"），塞不下 HR/财务/市场这类跟"交付流水线"无关的公司常设职能——system/agents/hr/（"招·留·管·退"）本体已存在却从没被装进任何图，全靠 fire-and-forget chat 招聘、无图执行审计轨迹。提议把 org graph 作用域从 company_id 升级为 (company_id, department_id)，一家公司可装配多张部门图，每张仍保持人工固定/慢变/可审计。全仓库调用点扫描结论：改造面是最初估算的 4 倍——真正的单点真相在 work-graph-db.js:readDefGraph 的裸 SQL 不变式（不在服务层），还牵涉两个易混淆服务文件间必须字节级一致的重复唯一索引、独立的 graph-seed-service.js 对账子系统、company-hire-org-layer.test.js 专属测试、orggraph-planning/task-planning 两份 agent 人设文档的自我认知改写 |
| 36-prd-agent-methodology-training-feasibility.md | 📝 调研 + 阶段一/二均已完成。回应"落地页太单薄是不是该用 Innovator 先训练专业 agent、再用 Dream 持续迭代"——认同方向。阶段一：graph-engine.js 结算节点后把 success/fail:<reason> 写进本体 memory.md（此前只有人类对话路径会写，Dream 天天空转）。阶段二：新建独立试验节点 prd-methodology-trial 走真实 Hunt→Digest→Evolve，2 轮收敛（96/97 分，真实基线 50 分），三个真实历史项目反推验证方法论有效；过程中连带修复同一个 2026-08-16 改名批次遗留的 5 处 innovator→org-innovator 死链（后端两处硬编码、前端"重新训练"按钮、/api/agent/list 展示 id 来源的四个 config.json），以及 AgentScaffold 默认模板一处裸相对路径缺陷。结论：FDE 对方法论类角色确实管用，但收敛速度/验收严谨度依赖任务书显式写明的自纠正要求，非免人工黑盒。环节 3（训练产物 → 雇佣本体转换）尚未开工 |
| 49-antigravity-inspired-parallel-verification-proposal.md | 📝 设计讨论，不代表已拍板（2026-09-04）。对照 Google Antigravity「Teamwork」多智能体框架博客文章，给 27 号 P4「真并行」与 34/35 号「验证严谨度不稳定」两个议题出的方案草稿。先纠正一个前提：重读 27-P4 全文后发现阶段 A/B/C 早已全部实现（又一次「文档落后于代码」），当时判断真并行只剩 T2/role 列/advanceTree 兄弟子 run 并发三件小事——2026-09-08 收口时又发现这个判断本身有两处误判（role 列其实早就落库、T1 的✅遗漏了 scope 参数的生产接线），三件小事（连同两处误判一起）已全部核实/补齐，见 27-P4。新提案 A：借鉴长证明模式的「竞争候选+对抗批评+综合」，区别于现有 executor-fanout.json 的分解型 fan-out——需要先有真实场景验证价值，不建议凭空立项，详细设计见 50 号文档。新提案 B：把 35 号提案 D「浏览器关键词命中才要证据」泛化成 benchmark 段全维度默认要求执行级证据（唯一建议现在推进的部分）；实地核实过把验收路径引导到 test_script 段的工作量后结论是不做——撞上 test_script.path 解析根不含 org-coder 实际写代码的项目根这个结构性冲突，改造面远超预期；新增「陷阱注册表」，把 validator 判卷失败的结构化原因喂回 Dream 机制，落点已定案为独立文件 known_pitfalls.md（不复用 memory.md，避免语义混淆）。建议推进顺序：陷阱注册表最低成本先做，证据泛化次之，竞争候选需要真实场景才立项 |
| 50-competing-candidates-critic-synthesis-design.md | 📝 设计草稿，不代表已拍板（2026-09-04）。49 号文档提案 A 的展开：竞争候选骨架 JSON 形状草稿（candidate-council.json，未定案）、命名（按 27-NAMING 节点带前缀/本体不带前缀两轴）、workgraph-planning 选型判据方向。关键设计约束：critic（评判）与 synthesis（择优/融合）必须拆成两个节点，依据是仓库真实事故——qa-judge 早期"评判+终态判决合一"设计导致过一次无限循环（20 次调用/31 分钟才熔断，记录在 deliverable.json 的反模式说明里），新骨架延续 validator-triager/benchmark-validator 已验证的"归因/打分/判定三者分离"范式。预算风险量化：N 路候选并行消耗 N 倍预算，且 checkBudget 只在批量拾取前查一次，实际可能超支到 maxConcurrency-1（默认最多多花 4 次调用）才被拦下，候选数 N 目前代码层没有硬顶 |
| 51-ceo-autonomous-goal-refill-design.md | 📝 设计草稿，不代表已拍板（2026-09-09）。回应"公司能否 7×24 自转"的提问——核实执行层（存活扫描/僵尸 goal 收口/CEO 阻塞任务兜底心跳）已经扎实，真正缺口在决策层：ceo/heartbeat.md 与 tools.md 的"该提新任务"判断全部要求先有一个 goal/task 存在，没有一条覆盖"公司没有任何 active/draft/planning goal"这种完全空转场景；且 CEO 目前没有创建 goal 的工具（tools.md 对 /goals 只有 GET 示例），POST /:companyId/goals 端点存在于路由层但从未暴露给它。设计方案：心跳查询为空时进入"立项模式"，先查公司使命（company-context.md，默认"待定义"时拒绝立项、转人工）作为立项锚点，用 created_by:'ceo' + split:false（避免草稿阶段就烧 task-planning token）建草稿 goal，去重后停在 draft 等人工 /dispatch——分两阶段放权，阶段 B（CEO 自动 enqueue + guardrail）本文档只给方向不实现 |
todo/future/（暂缓，非当前重心）
| 文件 | 说明 |
|---|---|
| architecture_todo_list.md | FDE Pipeline 架构待办清单（Judge 系统 / 反馈闭环等五大维度）。与 Graph Agent 架构基本正交，其中第 4 点「版本回滚」与 27 号文档 P5 阶段的 git 版本化 memory.md 有部分重叠，P5 落地后可回来划掉 |
| system-design/14-milestones.md | 早期里程碑规划（v1.1，checklist 未勾选）。已被后续实际实现大幅绕过，主要留作历史存档，不建议优先处理 |
| system-design/25-harness-engineering-improvements.md | Harness Engineering 改进提案（单 Agent 上下文管理），Phase 3-5 未落地。与 Graph Agent 架构（多 Agent 组织/图执行）维度不同，互不阻塞 |
| 27-P4 T5：账户欠费门接真实计费接口 | 桩子已实现并上线（setBillingGate 注入模式，graph_runs.block_reason='billing-arrears' + 自动恢复触发器 resumeBillingClearedRuns()，见 27-P4 §五 T5 记录），只差接一个真实计费系统的余额/欠费查询接口——2026-09-08 用户拍板暂缓，非本仓库能单方推进 |
未纳入整理的目录
以下目录本身是活跃系统的一部分（不是静态文档），保持原位不动：
prd/— DevLoop 的 PRD/SDD 规格站点源文件。prd/newfunction/*.html由npm run spec:extract读取生成prd/newfunction/_spec/*.md，是代码依赖的机器可读规格，不是待归档的说明文档。create-drama/— 独立的 Skill 工具子项目（含自身package.json/node_modules），不是设计文档。
维护说明
新增文档时，先判断它描述的是已实现的能力（放 done/）、当前正在推进的重心（放 todo/），还是尚未开始且非当前重心（放 todo/future/）。功能落地后，将对应文档从 todo/（或 todo/future/）移到 done/ 并更新本索引与 LEMONBOSS-SYSTEM-DESIGN.md 中的链接；当主线切换时（比如 Graph Agent 架构完成后），把 todo/future/ 里优先级提升的条目挪回 todo/。