-
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
-
真实起 org-coder → org-validator 跑完 46号文档 Phase 3 v2 当初卡死的那条 轻量图链路（重新建了一条全新任务，subtask-planning 真实分解、真实 enqueue）， org-validator 最终判词 fail_reason=null，确认不再 input_underspecified。 过程中撞见两个纯属验证方法论本身（非代码）的坑：①没起真实 API 服务导致 org-coder 的 CLI 工具调用连续 infra_flake；②agent 子进程与驱动脚本不同源， LEMON_INTERNAL_TOKEN 对不上导致 401。两次都被真实 agent 自己的诊断日志 准确点破根因。最终把驱动脚本改成同进程内 require server/index.js 解决。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
subtask-planning 每个 step 新增 acceptance 字段（benchmark 段格式），createTask 强制 decomposed_work 子任务必须带验收契约并用 goal-contract.validateContract 校验， enqueueTaskRun 起轻量图前把契约落进新 run 的 artifacts/acceptance.json——解决 46号文档 Phase 3 v2 真实回归撞见的 org-validator 死锁（轻量图没有 org-planner 产出契约，退无可退）。 真实起 subtask-planning agent 验证时发现设计稿的字段形状假设有误（真实产出是 benchmark 段本身，不是三段式 wrapper），已按真实产出修正代码与文档，并用那次 真实调用的原始输出跑通完整链路验证。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8
-
承接46号文档 Phase 3 v2 真实回归发现的 org-validator 死锁：验收契约 产出被硬绑在"公司完整 org graph 一定会跑到 org-planner"这个假设上， 轻量子任务图不满足这个假设就退无可退。 讨论收敛：消费端（validator 只认结构化契约、不自由判断）保持硬约束， 产出端从"锁死在 org-planner 一个角色"改成"每个 task/subtask 创建时 1:1 必须带一份验收契约"（tasks 表新增字段 + createTask 统一校验）。 本轮范围收在 subtask-planning/decomposed_work 这条链路，task-planning/ org-planner/人类快速派单三条创建路径留到以后单独讨论。 盘点了完整的验收契约生态（acceptance.json vs acceptance.md vs goal-benchmark.json 三者的区别、11 个相关 agent 里谁真正产出谁只消费） 和需要改动的 agent/代码清单。46号文档、docs/README.md 索引同步更新。 只是设计文档，未写代码。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8
-
真实 CEO 心跳发现并派发 decomposed_work 子任务，递归防护、依赖阻塞都 验证生效。org-coder 在没有 brd/prd/sdd 的轻量图里产出质量真实达标 （正确的单位换算实现 + 完整边界测试），但 org-validator 卡在硬依赖的 acceptance.json 上（只有 org-planner 会产出）——轻量图执行没问题， 验证这一半有真实的结构性缺口，摆了三个方向留给下一步讨论。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8
-
标记 v1 详细设计/实现记录为废弃（原样保留，不删——是决策过程的第一手 记录：真实回归暴露认领没有触发源的真问题，才推翻重来）。补 Phase 3 v2 章节：CEO push 派发的讨论过程、落地清单、一条没有真实验证过的假设 （org-coder/org-validator 在轻量图里没有 brd/prd/sdd 上游产物时表现 如何）、还没做真实端到端回归的说明。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8
-
真实公司走完完整链路（物化→认领CAS→/task/report 状态转正确），机制本身 工作正常。但发现：①认领后没有任何触发源通知 org-coder，纯数据库状态 变更，没人会主动发现/认领可认领子任务；②/task/report 不是干净的状态 回写端点，会自动触发 selfChat 回调唤醒 to 指定的 agent（真实起一个带 文件读写工具的新 CLI 会话），且它是与 org/work graph 完全独立的非 graph 协议（agent-chat.js 的 /task/dispatch↔/task/report），不挂在任何图节点上。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8
-
记录落地清单、必须同步改的坑（settleNode 闸门收窄）、认领后复用 executor='agent' 派单闭环这处化简确认按设计落地。如实记一次意外：排查 SQL 模板字符串反引号语法错误时，一句没设 GRAPH_DB_PATH 的 node -e require 顺手对本地 data/graph.sqlite 跑了一次批 6 迁移——核实过是纯增量 ALTER ADD COLUMN，102 条既有行无损，但记下来提醒自己语法检查也该走隔离 环境。真实端到端回归（尤其认领后 org-coder 自己怎么干这一段）还没做， 留给用户后续决定。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8
-
跟用户对齐关键架构决定：可认领子任务复用 tasks 表（新增 subtask_kind 字段区分 'acceptance_item'/'claimable_work'，不新开表）。 设计中定位两处要点： - 必须同步改的坑：settleNode 的 SUBTASKS_INCOMPLETE 硬闸门要收窄成只查 subtask_kind='acceptance_item'，否则新物化的 claimable_work 行会让所有 开了 subtask-planning 的 task 验收判定失控。 - 重要化简：认领成功后直接复用现成的 executor='agent' 派单闭环（认领人 自己搞定、自己 /task/report 上报），不需要给 graph-engine.js 加认领 调度层，比文档原先设想的"改动面最大的一条"轻得多。 只是设计，未写代码。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8
-
46 号文档 Phase 2 真实端到端回归（真实公司 p2verify0902 + 真实 goal/task/ Claude CLI）第一次跑就复现一个真缺陷：原始打分用「交集计数、>0 就算命中」， 一条长任务描述几乎必然跟经验库里的高频工程词汇偶然重合几个 bigram，导致 一个贪吃蛇任务被"验证修复要重新触发流程"这类无关的工程经验污染成 reasoning_source=memory，压过了本该触发的 deep research 分支。 改成 containment ratio（命中词数 / 经验块自身词数，对经验块归一化而不是 对查询归一化），阈值用真实噪音案例（~3%-4%）和合成相关案例（~16%-32%） 校准。补回归测试固定复现这次真事故场景。修完重启服务用第二条真实任务 （Markdown 转 HTML 工具）重新验证：reasoning_source 正确变成 deep_research，两轮调用（subtask-planning → org-hunt → subtask-planning） 真实跑通，全程零残留 CLI 子进程。46 号文档补了真实回归记录，包括一个 如实记录的局限：org-hunt 那次调用没有工具调用痕迹，更接近"多问一个角色 的第二意见"而非真的做了外部检索。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8
-
subtask-planning 改成两段式：先查 experience-lookup（扫已雇 agent 的 dream 沉淀经验，关键词打分）拼进提示词，agent 自评 confidence；经验为空或 confidence low 时触发 deep-research（图外直接调用 org-hunt 轻量提示词， 不套用其训练场景三件套契约，默认关闭，需 ENABLE_DEEP_RESEARCH=1）。 reasoning_source/experience_refs/research_used 增补进 subtask-plan.json， 向后兼容旧注入桩。 范围收窄：不做"历史同类 goal 检索"（需要语义检索基础设施）；Phase 3-5 （任务池认领/子任务预算/看板 UI）涉及核心调度引擎范式级改动，另起设计。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8
-
47号：itemized 子任务物化在当前 workgraph-planning 常见子图形状下因 acceptance.md 永远产不出来而形同虚设；maybeMaterializeItemizedSubtasks 新增兜底，缺失时改读 已被 44 号文档证实稳定产出的 goal-benchmark.json 的 dimensions[]。 46号 Phase 1：新 agent subtask-planning，钩在 enqueueTaskRun（显式 opt-in，只在 goal 批量下达/单条 task 下达两处触发，保住 quick task 零 LLM 调用的既有保证）； 产物写共享 artifacts/subtask-plan.json，复用 R-19.3 任务级共享索引对接下游。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
真实事故：h3video 公司 h3-story-draft 节点卡在 status=running，背后 CLI 会话已死但服务器 进程没重启，开机一次性孤儿扫描/goal-task 巡检/wallclock 看门狗均看不到，ceo 被转发问题后 绕过引擎自己拉会话，陷入死循环。 - sweepStaleRunningAgentCalls + startStaleAgentCallWatchdog：运行时长超阈值（默认 25 分钟） 的 agent_call 节点判 infra_flake 原地重跑，5 分钟一次巡检，挂进 server/index.js - ceo/tools.md 补 force-fail 端点（已有，未改代码）的使用文档 + 禁止自拉会话的规则 - ceo/heartbeat.md 同步更新"不用管的"一节 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WjFL1nfPDqZnJeuskYHwvs
-
Snapshot-then-stop race in stopRun() left child runs created after the snapshot outside the stop scope; add auto-mode guard rejecting manual /next on execution_mode='auto' runs (source of the concurrent-advance race). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
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
-
43 号文档补上 Phase 0-4 的实现记录，含一处架构订正（org-planner 在 org 层永远是 subgraph，真跑数据核实后钩子改成扫子 run 全节点）。 44 号文档是真实回归验证 43 号文档时意外发现的独立缺陷：goal-benchmark 按设计把产物写进 root run 共享 artifacts/ 目录，产出闸门只查节点私有 目录，writesArtifacts:true 这个字段全仓库零代码读取——这条契约在当前 实现下结构性地打不过，不是偶发。很可能正是 snakegame-co 参考任务里 goal-benchmark/planner-validator 显示 skipped 的真实原因。只记录诊断， 未修复，留了两条候选修法。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
-
回应"org-planner 出 brd/prd/sdd 后，任务看板能不能展示成 task/sub-task 树，coder-validator 按清单逐条开发验收"。原话照搬 + 结构化复述 + 现状调研（parent_task_id 只服务于 Agent Chat 派单流程、task-planning 人设明确拒绝按检查项拆 task、org-planner 没有建任务工具）。 三轮讨论定案：goal→task 流水线自建父子机制、先只拆验收（开发仍整体 完成）、要不要拆交给 task-planning 判断、任一子任务 fail 父任务即 fail、子任务复用 tasks.status 状态语义。 技术实现计划 Phase 0-4 逐条核实代码形态，含两处订正（org-validator/ coder-validator 是不同 agent；org-planner 产出的验收清单是 acceptance.md 不是 acceptance.json）和一个待验证风险（acceptance.md 在真实回归里 从未被用上，Phase 2 落地前需先确认可靠性）。尚未开工。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
-
昨晚做完 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
-
org-coder 等 9 个角色（含 _base 骨架模板）的四段式阶段流转靠调 bin/lemon.js task transition，打到 agent-chat.js 的 /task/transition—— 这个端点靠自己的 sessions Map 找会话，work graph 节点场景下找不到， 阶段流转静默跳过，中间产物不进任何跨节点共享的轨迹。 调研确认范围后选了最保守的实现：不改 bin/lemon.js 的 CLI 签名、不碰 agent-chat.js（当天正被另一个并行会话实时编辑，风险太高）。关键发现 是 --artifact 参数本来就是 .../runs/{rootRunId}/nodes/{nodeRunId}/... 形状的路径，两个 ID 已经现成编码在里面，不需要给子进程塞新环境变量， 不需要改一个字的 agent.md 提示词。 bin/lemon.js 在原有调用之外 best-effort 追加一次 POST /api/graph-runs/phase-note，新端点从 artifact 路径解出两个 ID， 校验 run 真实存在后调 emitEvent() 追加 timeline 记录，只追加不碰 graph_run_nodes/graph_runs 任何一行——不影响 needs/produces 契约。 P0 拦截/OKR 更新两段旧逻辑维持原样，新端点是独立的第二条路径，不是 迁移。 新增测试 4 例，全量测试 1503/1506，零回归（剩余失败全部来自另一个 并行会话进行中、还未提交的工作）。42 号文档 Phase 1-4 全部完工。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9 -
39 号文档 P5 落地的是"配了 company.json.target_dir 就生效"这一半， "人怎么把这两个字段填进去"此前只能手工编辑 company.json。 复用已存在的 PUT /api/company/:companyId（companyService.update()）， 没有新建端点。新增 target_dir/target_mode 分支，校验直接调 path-resolver.validateLinkedTarget（39 号文档 P5 抽出来的共享函数， 和 graph-engine.js 运行时校验同一份判据）：合法路径写入成功、敏感 路径黑名单拒绝、linked-new 非空目录拒绝、linked-existing 不存在拒绝， 校验失败路由层转 400；传空字符串清空配置；不传 target_mode 默认 linked-existing，与 graph-engine.js 的 readCompanyTargetConfig 同口径。 前端：CompanyDashboard.vue 概览 tab 加一张配置卡片，本地表单状态 不直接双向绑定 selectedCompany，保存失败不会冲掉用户刚打的字。 新增测试 8 例，npm run web:build 编译通过。**未做真实浏览器点击 验证**——服务器上有其它并行会话真实在跑的 agent 进程，这次没有重启 服务器（42 号文档 §二记过一次"重启杀掉别人真实进程"的教训），文档 里标记了这个已知缺口。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
39 号文档 §四.4 拍板"ceo 全权自主 enqueue，但 max_parallel_tasks / DEFAULT_TASK_BUDGET / goal 级 org-validator 这几道闸门必须照样拦住 它"，落地时没补这条测试。这次补上，走 ceo 实际会用的通路（draft:true + created_by:'ceo' → /enqueue），不抄近道直接摆数据库行： 1. 坑满时 ceo 建的任务排队，不插队。 2. 预算给 0，checkBudget 照样判耗尽，created_by 不改变结果。 3. ceo 建的两条 task 挂同一个 goal，全 completed 后 goal 级验收只调一次。 全量测试 1486/1490，零回归。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
冲突在 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> -
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>
-
服务器重启会杀死正在跑的 graph 节点背后的真实进程，但 graph_run_nodes. status 永远停在 running（ceo 的两条唤醒路径都只认 blocked，对这个状态 完全不可见）——39 号文档真跑复盘撞出来的坑，这次补上。 1a：graph-engine.js 新增 sweepOrphanedRunningNodes(cutoffIso)，复用 routeFailure 的 infra_flake 分支（不发明新状态），server/index.js 在 本次进程启动时刻挂一次开机扫描，排在其余「补一次全量扫描」钩子之前。 1b：新增 forceFailNode() + POST /:id/nodes/:nodeId/force-fail，补上 retry 端点管不到 running 节点这个缺口——人工/ceo 判定"这个真的救不 回来了"时的手动出口，转 fail 后交给既有失败路由处理，不发明新路径。 新增测试 12 例（graph-engine-orphan-sweep.test.js 4 例、 graph-run-force-fail.test.js 8 例），全量测试 1483/1487，零回归。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
上一条 commit 只带了纯改名（git rename detection），文件内标题、 39 号文档的两处引用、docs/README.md 的索引更新都漏提交了（git add 命令里混了一个已经改名走的旧路径，报错后整条 add 没生效）。这次补全。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
两份文档文件名不同、内容不冲突，但编号巧合容易读混。改名 + 更新 39 号文档里的两处引用 + 补 docs/README.md 索引（39 号状态同步成 已实现，42 号补一条索引）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
P1-P5 落地后做了一次真实端到端测试（建公司→下 goal→ceo 监督→真实跑出 一个 Playwright 验证 5/5 通过的贪吃蛇游戏）。1469 个单测全绿，这次真跑 却测出至少三个单测没覆盖到的真问题：服务器重启会让 in-flight 节点变 僵尸且无人能自动发现、graph-run.js 鉴权缺口（已在另一个 commit 修过）、 规划/反思轨迹没有统一可追溯位置。 39 号文档新增「七、真跑复盘」记录技术缺口和过程教训；41 号文档把复盘 沉淀的待办拆成四个 phase 的开发计划（卡住恢复闭环 → 闸门穿透性回归 测试 → target_dir 配置入口 → timeline 承接规划轨迹），按优先级排开工 顺序。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
- writeGraph() 的乐观锁缺失此前误标"已修复"，实际只是后续实验绕开没再撞它，改回开放 TODO 并补上修法思路（CAS 式版本校验）。 - company.js 的 requireAuthOrInternal 401 缺口、boss agent 巡检设计，均已被另一并行会话 实际修复/实现（14cbaf5、39 号文档 P1-P5），核实代码后删掉这两条过期 TODO，指向正确出处。 - 新增一条未拍板的可选项：org-hunt/digest/evolve 这套"元 agent 复刻成 graph 原生副本"的 操作模式要不要沉淀进 org-graph-templates/README.md 供以后参考。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
第 11 轮真跑：给 org-evolve 规划验收节点时，按名字语义匹配选了 benchmark-validator （"对评分结果做验收判决"），但该本体硬编码读 artifacts/goal-benchmark.json（只有 planner.json 的 goal-benchmark 节点才产），Hunt→Digest→Evolve 链路里没有这个节点， 两轮都判 blocked。benchmark-validator / testdata-validator / validator-triager 不是 通用验收工具，是 validator.json 骨架专属、绑定任务级共享契约文件的本体。 workgraph-planning/agent.md 加第三条硬规则：判据从"名字像不像"改成"这条链路里有没有 节点产 goal-benchmark.json/acceptance.json"。deliverable.json 的 whenToUse 补上"自带 自评分收敛逻辑的节点也不需要外部验收节点"例外条款并点名这次事故。 第 12 轮真跑验证：org-evolve 的规划记录原文引用新条款选中 deliverable.json， backward_count=0，评分 83/行业均线 78 收敛，全流程干净跑完。41 号文档收尾—— 11 轮真跑挖出的 6 个独立缺陷全部修复并逐条验证生效。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
核心修复：indexNodeOutputs() 此前只扫节点私有目录，不扫项目根——但引擎自己的写入边界 明确允许交付物写项目根，导致内容型交付物节点（产出写进项目根时）永远进不了 R-19 产物 索引，下游 needs 声明永远查不到实例。新增 readDeclaredProduces()：agent 可在 contract.json 里显式声明 produces:{kind: 绝对路径}，校验（绝对路径/落在项目根或私有目录内/ 文件真实存在）通过才登记，不满足就整个 kind 判「没产出」，不静默放过。全局提示词 （describeArtifactContract）同步更新，所有 org/work 节点自动学到这个新字段。 新增 org-hunt / org-digest / org-evolve 三个 graph 原生 agent（方法论抄 innovator-hunt/digest/evolver，协议原生兼容 graph 引擎），配套新增 work-graph-templates 的 deliverable.json（内容型交付物骨架，不引入验证 agent）。11 轮真实试跑挖出并修复 5 个 独立缺陷（详见 41 号文档问题 7）：建公司自动规划与手写图的竞态、work-graph 模板库缺内容型 交付物骨架、验收节点任务描述范围溢出、两个规划 agent（orggraph-planning/workgraph-planning） 的路径口径写错、以及上述 R-19 索引缺口。最终产出与原生 FDE 对比：内容骨架可迁移、质量不 打折，但可靠性差距悬殊。 补充说明：system/agents/{ceo,innovator-evolver,master,org-innovator}/{agent,soul}.md 是 本会话开始前已存在的 dream 自编辑改动，随本次提交一并收进去，不属于本次改动范围。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
39 号文档地基 0 当时只改了 company.js（goals/tasks 端点），graph-run.js （run 的 start/stop/retry/budget 控制端点）漏了同一处修复，还是纯 requireAuth。真实端到端测试里 ceo 被唤醒后能读写 goal/task 板，但调 /api/graph-runs/* 处理卡住的 run 时精确撞上 401——ceo 自己在对话记录里 诊断出这一点并写出了人工需要跑的 curl 命令，间接验证了这条修复的必要性。 两个挂载点（router + companyRouter）都改成 requireAuthOrInternal，两处 :companyId/:id 的 param 中间件加了与 company.js 一致的 req.user?.internal 旁路。route-auth-gate.test.js 同步更新断言。全量测试 1469/1473，零回归。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
排查「前端刷新不及时/没有打字机效果」发现现状已是 SSE，不需要换 WebSocket， 真正缺的是三件独立的事： - 打字机平滑：后端把 ACP chunk 按 10 字符切片再发 SSE，前端用定时器队列 （agentChatEvents.js 的 createTypewriterQueue）匀速吐出，抹平网络突发。 - 打断并发送：执行中解锁输入框，新增 ⤴ 按钮与 ⏹ Stop 视觉区分；stop 端点 改为轮询确认 agentChatLocks 真正释放（3 秒预算）再返回 cleaned 字段， 前端据此决定直接发送还是走"强制发送"兜底。顺手修了一个真实并发漏洞： 同一 agentId + 同一 convId 的并发请求过去完全没有闸门，只是一直靠前端 textarea 的 disabled 属性侥幸没被触发。 - 串台加固：把 handleEvent 分发逻辑抽成不依赖组件实例的纯函数 （agentChatEvents.js），补上 9b1c3f1 那条不变式的回归测试。 已用真实 Claude CLI 会话（非 mock）在浏览器里验证打字机效果、打断并发送 全流程、以及纯 Stop 无回归。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HDtmdnE6pay9BhwZDAKK6M
-
按 39 号设计文档落地 ceo 常驻监督：company.js 的 goals/tasks 端点 放行内部令牌自环调用，POST /tasks 支持 draft 模式（agent 自主提任务 不再立刻烧预算），ceo 补雇进公司创建流程；task-settle 新增事件驱动 唤醒 + 30 分钟兜底轮询；graph-engine 的回退熔断收敛时顺手回写一条 draft task，形成"卡住 → 自动/ceo 判断 → 重新规划"闭环。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
docs/README.md 索引条目同步从 todo/（当前主线）表格挪到 done/ 表格，路径改指 done/system-design/。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
验证阶段真查出一个 Phase 1/2 都没顾上的真实漏洞：agent-chat.js（/api/agent/*）一直靠 :agentId 里的 "companyId:role" 命名空间前缀（locator.companyStateDir 解析）区分会话 属于哪家公司，但这个文件从只挂了 requireAuthOrInternal（登录即可），没有归属校验。 curl 验证：任意登录用户对 GET /api/agent/{别人的companyId}:{role}/conversations 依然 200，能跨租户读别家公司的 agent 会话。 修法跟 company.js 同一套思路：router.param('agentId', ...) 解析 : 前的 companyId 段， 过 canAccessCompany。三个例外：①没有 : 前缀的全局 agent（master/org-innovator 等， 落 _global）不做归属校验，本来就全系统共享；②内部自环调用（req.user.internal）直接 放行，招聘/训练自动流水线要能打到任意公司名下；③admin 不受限制。 新增 agent-chat-company-gate.test.js：直接拿 Express 暴露的 router.params.agentId[0] 单测这个 param handler，覆盖同公司放行/跨公司404/admin不受限/公司不存在404/全局agent 放行/内部自环放行六种情况。顺带修好一个连带失败的既有测试文件 （agent-chat-tenant-isolation.test.js，zz-tenant-alpha/beta 同样是从没真正建过的 虚构公司 id）。 验证：curl 复测跨租户读会话从 200 变 404，owner/admin 依然 200，全局 agent 不受影响； 真实浏览器用全新账号确认 CompanyDashboard.vue 对"没有可用公司"已有现成空状态，不需要 新写前端代码。全量 vitest 1433 passed，3 个无关既有失败不受影响。 至此 38 号文档 Phase 0/1/2/3 全部完成。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
company-service.js：company.json 加 ownerId（无 SQL 表，纯 JSON 字段）；create() 接收 ownerId；list({ user }) 按传入用户过滤，不传就不过滤（company-heartbeat-service.js 等 系统内部巡检要看全部公司）；新增 canAccessCompany(company, user) 作为全仓库唯一一份 归属判据（admin 不过滤，判负一律 404 不是 403，不暴露"这个 id 存在只是不是你的"）。 company.js 用 router.param('companyId', ...) 统一收口（约 50 条路由，含 okrPath() 系列 动态路由）。graph-run.js 的两个挂载点参数形状不一样，设计阶段的描述不准确，实现时才 发现：companyRouter 唯一路由是 /:companyId/graph-runs 直接查；主 router 全部路由是 /:id/...，:id 指的是 run 不是公司，改成先查 run 的 company_id 再判断，run 不存在或 公司不是你的统一回"run 不存在"。devloop.js 用 :pid 反查 company_id；POST /projects 单独校验 body 里的 company_id（放在基本字段校验之后，避免归属检查打乱输入校验的错误 优先级）；GET /projects 按归属过滤列表。 okr.js 最终没有按原计划接入 companyId 归属校验——实现前查证发现 OkrDashboard.vue 挂载的 /okr 页面全站没有任何导航入口指向它，是个孤儿页面，给访问不到的页面建"选公司" 前端交互不划算，改成 requireAdmin（跟 dream.js 同款），先堵住直接拼 URL 看到跨公司 聚合数据的口子。真正在用的公司级 OKR（company.js 的 /:id/okr）已随 company.js 一起隔离。 存量数据迁移：scripts/backfill-company-owner.js（npm run backfill:company-owner）， 两家存量公司已划给种子账号，幂等验证过。 8 个既有测试文件用的公司 id 都是从没真正建过的字符串标签，挂锁后集体 404——新增共享 helper server/tests/helpers/ensure-test-company.js 修复；两处原有的"跳过已有 company.json 的目录，那是真公司"防御逻辑，判据从"有没有 company.json"改成"ownerId 是不是 -1 这个测试专用标记"，否则新出现的测试夹具会被误判成真公司永远不清理。 验证：真实 curl 走过（admin 看到全部存量公司、新用户看到空列表、新用户拼 URL 访问 别人的公司 404、新建公司 ownerId 精确落在创建者、admin 和创建者都看得到其他人看不到）； 全量 vitest 1427 passed，3 个无关既有失败不受影响。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
给此前完全零防护的 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>