• 用一个全新 goal(三个独立字符串工具函数)补跑,拿到了此前唯一缺的直接证据:
    两条子任务真实 completed 后,父任务被 settleParentTaskIfAllChildrenDone 正确
    自动结算成 completed;同一批里两条无依赖子任务再次被观察到真实并发运行。
    
    至此 Phase 4 四项机制(父任务让位/预算均分/父子终态汇总/同父并发坑位)全部
    在真实条件下拿到过直接证据,不再只是单测覆盖。
    
    顺带清理:测试公司 p2verify0902 里此前两次因回归脚本 bug 失败留下的旧数据
    (G-mtn5q2r7-786b、G-mtn5tvih-bed4)已通过正式归档接口清理,本轮新数据保留
    作为最新证据。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01H9Mq8rViHp8xuj6zTy76hh
    yibo authored
     
    Browse Dir »

  • 46 号文档 Phase 4:decomposed_work 子任务的父子生命周期管理。
    
    - 父任务被 subtask-planning 成功拆分后让位给子任务(新状态 decomposed),
      取消自己排队中的完整 org graph run
    - 父任务预算按拆出的步数均分给每条子任务
    - 父子终态汇总(settleParentTaskIfAllChildrenDone),子任务全部完成后
      自动结算父任务并联动 goal 收敛
    - 同父子任务独立并发坑位(上限 3),判据钉在 updateRunStatus 的唯一准入
      事务里,不占用公司级 max_parallel_tasks 槽位
    - 前端(Phase 5):decomposed 状态样式 + 子任务进度展示,复用已有的
      parentTaskId 通用树形逻辑,未改后端接口
    
    真实回归当场撞出一个几乎必现的真缺陷:markTaskDecomposed 原本只认父任务
    还是 queued,但 task-scheduler 抢坑是毫秒级、subtask-planning 是数十秒的
    真实 LLM 调用,等它拆完时父任务几乎必然已经 running,接管必然失败,而
    stopRun 依然会把真实在跑的 org graph 取消掉。已修复(接管条件放宽 +
    调整先接管再取消的顺序)并用真实公司数据验证;同父并发坑位也用真实数据
    确认生效(两条子任务真实同时 running 20+ 分钟)。
    
    回归过程中牵出一个独立缺陷:org-validator 对同一种 benchmark 契约判断
    不稳定(5 次里 1 次误把源码路径当 --target 判 target_not_json,反手把
    责任推给 subtask-planning)。根因是 decomposed_work 轻量图当时只有一条
    前进边、没有失败边,validator 判 fail 后无路可退。已补 validate --fail-->
    impl 退回边(复用引擎已验证过的 backward_count 双层硬顶 + remediation_note
    反思闭环),新增 3 条单测覆盖边形状、真实退回重试、硬顶熔断三个场景。
    
    全量单测 1229/1231 通过(2 个失败改动前即存在、与本次无关)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01H9Mq8rViHp8xuj6zTy76hh
    yibo authored
     
    Browse Dir »
  • 由 dream 机制自动提炼跨公司经验并刷新 ceo 的 agent.md/soul.md 经验区块,
    本次内容涵盖:状态字段自相矛盾判读、预算耗尽假阳性识别、批量阻塞告警回溯
    依赖链、已知问题重复告警的处置、协作方专属工具越权代劳的边界、父任务终态
    汇总缺陷的识别模式。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01H9Mq8rViHp8xuj6zTy76hh
    yibo authored
     
    Browse Dir »

  • 48 号文档补做收口:调研另外三条任务创建路径(task-planning/
    org-planner 的 acceptance_item 物化/人类快速派单)是否需要同款
    acceptance_contract 强绑定,结论是不需要——都走完整 org graph,
    workgraph-planning 的 benchmark 节点"不可裁"约定已天然保证契约存在,
    强行加会与 task-planning 的极简边界、快速派单的零 LLM 定位冲突。
    
    顺带梳理 todo/system-design 下已完成的文档,移入 done/:
    31/32/34/43/45/47 号(含此前漏收录进索引的 32 号文档),并修正
    因搬家产生的相对路径死链(44号/46号 对 43/47 号的引用)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01UP1omSsXkyGhopHvWeSnyy
    yibo authored
     
    Browse Dir »

  • 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 Dir »
  • 昨晚做完 42 号文档 Phase 2-4 之后忘了同步 docs/README.md 索引,还停在
    "Phase 1 已实现,Phase 2-4 待开工"。这次一并把两份文档从 todo/ 挪进
    done/(39 号 P1-P5、42 号 Phase 1-4 均已实现,符合仓库自己的归档约定),
    索引表挪到对应位置,两处过期描述改成完工状态。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »

  • 冲突在 docs/README.md:并行会话在真实端到端测试里发现 boss agent(39 号文档)还有
    三个单测没覆盖的真问题,把 39 号重新留在 todo/ 并拆出 42 号跟进文档;与我这边把
    39 号挪进 done/ 的判断冲突——采纳对方判断(39 号文档物理路径挪回 todo/system-design/,
    докс/README.md 用对方更新的行 + 补 42 号一行),因为他们是基于更新的真实测试结果。
    
    顺带把 29-dream-design.md 这次会话移到 done/ 后遗漏的引用修掉:
    system/agents/{dream-distiller,dream-screener}/agent.md、
    server/{routes/dream.js,services/dream-service.js}、
    server/tests/unit/dream-routes.test.js 六处 docs/todo/system-design/29-dream-design.md
    路径改成 docs/done/system-design/29-dream-design.md(no-dead-path-references.test.js /
    agent-md-refs.test.js 两条守卫测试之前没扫到这几处,这次真跑测试才暴露)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 29-dream-design / 33-needs-gate-role-filter-bug / 35-validation-rigor-and-body-readiness-proposal /
    39-boss-agent-task-supervision / 40-agent-chat-streaming-interrupt 逐份核实状态确认已完成
    (后两份状态行本身滞后于代码,已在上一提交订正),按维护说明从 docs/todo/system-design/
    挪到 docs/done/system-design/,docs/README.md 的 todo/done 两张表同步更新。
    
    顺带修复 4 处指向这 5 份文档的相对路径引用(28-followups / 31-work-graph-fail-fallback-coverage /
    34-validator-scored-without-real-deliverable / 41-graph-vs-fde-reliability-discussion),
    文件搬家后原来的同目录相对链接会失效,改成 ../../done/system-design/ 的正确相对路径。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »

  • 2026-08-28 把本地 mycompany/innovator-fde-trial 同步到生产时手搓合并脚本踩过两个坑:
    本地库和生产库同名字段的物理列序可能不同(SELECT * 位置对齐会静默写错列),以及
    graph_runs/graph_run_nodes 循环外键的回填 UPDATE 必须给关联子查询加表别名。
    
    把手搓版本整理成 scripts/sync-company-to-graph-db.js(按列名对齐 + 支持 --dry-run),
    并在 graph-db.js migrate() 和 production-deploy.md 里记下这两个坑,供下次同步复用。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01UpkWPa2CmuWJFJZksqvxWB
    yibo authored
     
    Browse Dir »



  • ## 移进 done/
    
    · 27-p3c-goal-task-model.md —— 五批实施完毕,§15.5 / §16.8 的后续项也全部收掉。
      新增 **§十七**:欠账清单对账、边界守卫从「乱扣帽子」改成「留证据不判罚」、
      测试污染生产图库(第四次踩同一族,但换了个方向进来)、那条卡了两天的 run,
      以及 **§17.5 真跑验收** —— org-planner-sdd/benchmark/validator 全 success、
      work run completed、父节点自动拉回、org-coder 起实现层子图、
      org-coder-validator 判 fail 走回退边打回 impl(loopCount 1)。
      **返工闭环第一次由真 agent(不是注入的假 executor)走通。**
    
    · 27-p3c-batch3-handover.md —— 四条复核结论全修完、§五 那条 run 已解开,
      §七 待办全部打勾。从待办转为**事故记录归档**:§六 那几条多会话协作规则是真踩出来的。
    
    两份的相对链接都已重指(done/ ↔ todo/ 跨目录),no-dead-path-references 守卫通过。
    
    ## 留在 todo/ 的,状态说清楚
    
    · 27-graph-agent-architecture.md —— 状态行校准。那一行是别人判断「能不能搬 done」的依据。
    · 27-p3b-real-run-runway.md —— 加状态行:验收 7 ⛔ 真跑不成立(readme-writer 混进
      org graph,**未修**)、2/4/8/9 未在干净环境验。缺陷② 的**根因**今天修了,
      但特意写明「**根因修了不等于验收点验了**」—— 不然下一个人会照着状态行当成验过。
    · 27-p3-p4-work-graph-console.md —— 在索引里写明留 todo 的原因:
      §十 那笔「真实路径 smoke 进 CI」的欠账未还。
    · 28-followups.md —— §3.3 标已修(含「GET /info 的 404 闸门仍没修,别当成修过」);
      §五 守卫表加两行(graph-db-prod-guard / heartbeat-company-scoped),
      并补第七条的来历。
    
    ## docs/README.md
    
    索引补上新增的 done 条目与 P3B / 28-followups 行,主线说明改成
    「当前未完成的是哪几件」——原来只说完成了什么,读的人得自己推。
    
    全量:138 文件 / 1292 测试全绿。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »

  • 起因是「全量测试偶发挂一条」。查下来既不是回归、也不是那 45 个孤儿进程(它们 CPU 早归零、
    不再写任何东西),而是**还活着的心跳在测试扫描 system/agents/ 的同时往里建目录**:
    
        locator.taskDir() 的落点是 system/agents/<agent>/<companyId>/<taskId>,
        运行态目录落在本体目录里属既定设计;但心跳每 5 分钟建一个新的
        (cto/_global/ 已 263 个子项且在涨),于是扫描 system/agents/ 的守卫测试
        (no-dead-path-references 那一类)会撞上瞬时竞态:列到了目录名,进去时那一层还没写完。
    
    症状是偶发假失败、重跑就好 —— 这类最费人,因为第一反应总是去怀疑自己刚改的代码。
    
    改法:server/index.js 启动的那个 setTimeout 块里,恰好装着全部「会自己起 agent 的东西」
    (两处中断恢复 + 任务队列扫描 + 两路心跳),所以一条早退就够,不必在五个地方各加一个判断。
    
        DISABLE_BACKGROUND_AGENTS=1 bash start.sh
    
    实测:127 文件 / 1226 用例全绿,跑前跑后 cto/_global 子项数都是 263。
    
    **验证它生效不能只看日志里的 ⏸** —— 那只证明代码走到了早退。硬判据是目录数前后相等,
    也就是真的没有东西在写。文档 §七 把这条写成了可粘的三行。
    
    排掉的两个坑,都记在文档和 .env.example 里:
    
    1. `.env` 里不能给这个键赋空值。start.sh 是 `set -a; source .env` 加载的,.env 里只要
       存在同名键(哪怕空的)就会盖掉命令行传进来的 =1,而且不报错。所以 .env.example 里
       它只以注释形式出现 —— 一个「示例文件顺手写全」的习惯会直接让开关失效。
    
    2. 开关生效后 `[TaskQueue] 🚀 已启动` 仍会打印,那是另一个模块:services/task-queue.js
       (ArenaSK 时代 /api/claude-chat 的队列,routes/claude-chat.js 模块加载时起),
       和批 3 的 services/task-scheduler.js 同名不同物。它的心跳只扫内存里的 this.tasks,
       不碰 system/agents/,不是干扰源。名字撞车,容易误判成开关没生效。
    
    文档同步:
      - docs/done/claude-cli-session-leak.md §七 重写(原文写的是「得让测试隔离,或跑前停心跳」,
        现在后者已实现,改成开关的用法 + 硬判据 + 上面两个坑);原第 2 条降为 §七之二
      - CLAUDE.md 测试命令块加一行(这是找「怎么跑测试」的人真正会看的地方)
      - docs/README.md 索引行补上开关
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 泄漏被修过一次(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>
    yibo authored
     
    Browse Dir »

  • 主文档新增 §11.4b,记 dd319bb 那轮清掉的内容与「不清会怎样」:
    四份本体提示词、三个 skill js、两份图模板 README 的 CI 防线规则、
    DevLoop PRD 13 份 HTML(连带重生成的 52 份 _spec + manifest + search-index)。
    
    其中两条值得单独记:
    - innovator-hunt/collect_seed.js 是真 bug 且已发作过 —— 裸相对路径相对 cwd 解析,
      在 agent 自己目录下造出一棵野生嵌套树。
    - DevLoop PRD 写的 system/templates/devloop-pm.md 根和形状都错
      (实际是 system/agents/{agentName}/prompt.md),由此推出一条方法论:
      批量替换字符串时,替换的正确性取决于替换后的整体是否成立,
      而不是被替换的那一段是否过期。
    
    同时订正两处早于本次改造就已过期的内容(「6 个命名冲突 id」清单里四个 id
    根本不存在;orggraph-planning 被告知的真相源仍是 company.json.agents[]),
    并写明刻意不动的三类:历史说明 / 迁移完成的证明 / 运行态记录。
    
    followups 新增 §五,登记本轮立起来的三条不变式测试
    (agents-root-single-holder / no-stale-templates-path / repo-hygiene),
    写明它们共有的「样本非空」前置断言为什么不能省,以及改动它们前要想清楚的事。
    §四 那条「脚本路径需要跟着更新」已在 cd2066a 完成,改成实跑结论。
    
    交付状态从「未 commit、未 push」更新为已推送(ca468ab..dd319bb)。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 设计见 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 Dir »

  • 按 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>
    yibo authored
     
    Browse Dir »

  • - 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>
    yibo authored
     
    Browse Dir »