-
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
-
承接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>