-
验证 46 号文档 Phase 3 v2（CEO 心跳发现并派发子任务）时，触发 CEO 心跳 直接撞上 401——company-heartbeat-service.js 的 _sendAgentChat 和 heartbeat-service.js 的 _triggerHeartbeat 都在自环调用 POST /api/agent/:agentId/chat（agent-chat.js 挂了 requireAuthOrInternal）， 但两处都没有带 INTERNAL_TOKEN_HEADER——company.js/task-settle.js 的同类 自环调用早就在带，这两处漏了。 失败只落一行 console.warn，界面上什么都看不出来，影响的不只是 CEO 心跳： 两套心跳系统（per-agent 的 heartbeat-service 和公司级的 company-heartbeat-service，含它驱动的 pipeline/schedule 触发）都受影响。 按现成模式补上内部令牌头。全量单测 1189 passed（唯二失败与本次改动 无关），修完真实验证 CEO 心跳能正常跑完整段推理会话。 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
-
真实回归暴露"认领后没有触发源"的真问题，讨论后发现"认领"（pull，CAS 抢占）要解决的"多方竞争同一条任务"场景根本不存在——只有 CEO 一个人拍板 要不要派、派给谁。CEO 心跳统一发现+直接派发（push）成本更低，还能顺带 控制派发节奏，不需要认领。 删除：claimSubtask/unclaimSubtask（work-graph-db.js）、POST /claim、 POST /unclaim（company.js）、CLAIMABLE_WORK_ROLES 白名单、 claimable/claimed 两个 status 值、claimed_at 列。 改名：subtask_kind 的 'claimable_work' → 'decomposed_work' （materializeClaimableSubtasks → materializeDecomposedSubtasks）， "认领"这个词不再准确，物化出的行现在就是普通 draft task。 新增： - triggerSubtaskPlanning 加递归防护（task.parent_task_id 非空直接跳过） ——设计 v2 时发现的真实漏洞：CEO 对子任务调 /enqueue 会默认 withSubtaskPlanning=true，不挡会对已经是"第几步"粒度的子任务再拆一层。 - createDecomposedWorkGraph：现造一张两节点轻量 work graph （impl=org-coder、validate=org-validator，agent_call 不是 subgraph）， 跳过公司完整 org graph 的 brd/prd/sdd 规划仪式——subtask-planning 已经 把"怎么做"拆到这个粒度了，再走一遍纯属重复劳动。含一条没有真实验证过 的假设（org-coder/org-validator 裸调用会不会读不到预期上下文），如实 写在代码注释和文档里。 - enqueueTaskRun 按 subtask_kind 选图：decomposed_work 走轻量图， 普通 task 行为不变（回归测试覆盖）。 - ceo/heartbeat.md、tools.md 补了巡检 decomposed_work 草稿 + 判断节奏 + 调用现成 /enqueue 的指令。 测试：删除 task-pool-claim.test.js（随 v1 代码作废），新增 task-decomposition-dispatch.test.js（12 条），更新 task-decomposition-validator-gate.test.js 措辞。全量单测 1191 条， 1189 passed（唯二失败与本次改动无关），零残留 CLI 子进程。 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'，区分 43 号 文档的验收条目物化和 Phase 3 的可认领工作项物化，共用一张表不新开）+ claimed_at 列（批 6 迁移，ALTER ADD COLUMN，纯增量向后兼容）。 - work-graph-db.js：createTask 新增 subtaskKind/status 参数 + 校验； claimSubtask/unclaimSubtask 是全仓库第一个真正的"认领（pull）"CAS 写入 （之前 assignee_agent_id 全部写入点都是"派发 push"，没有先例可抄，照抄 claimQueuedTask 的 changes 判据）；materializeClaimableSubtasks 把 subtask-planning 的 steps[] 物化成可认领子任务，两阶段建法处理 depends_on_hint 的前向引用，幂等，与 acceptance_item 物化互不干扰。 - graph-engine.js：settleNode 的 SUBTASKS_INCOMPLETE 硬闸门收窄成只查 subtask_kind='acceptance_item'——这是必须同步改的一步，不收窄的话新物化 的 claimable_work 行会让所有开了 subtask-planning 的 task 验收判定失控 （已用回归测试固定住这个场景）。maybeMaterializeItemizedSubtasks 的 createTask 调用同步打上 subtask_kind='acceptance_item'。 - subtask-planning.js：triggerSubtaskPlanning 写完 artifact 后立刻物化 claimable_work 子任务，不等 org-planner 跑完。 - company.js：taskView 补 subtaskKind/claimedAt；GET /tasks 加 subtaskKind 过滤（?subtaskKind=claimable_work&status=claimable 就是可认领池查询）； 新增 POST .../claim、POST .../unclaim 两个端点，角色白名单先写死 ['org-coder']（不做能力匹配，系统里没有结构化角色能力字段）。认领成功 同时把 executor 改成 'agent'，复用既有的 executor='agent' 派单闭环 （/task/report 上报生命周期），不需要碰 graph-engine 的调度模型。 新增 task-pool-claim.test.js（23 条：DB 层校验/CAS/物化 + 路由层白名单/ 并发/放弃）；task-decomposition-validator-gate.test.js 补一条回归测试 （claimable_work 子任务不影响 acceptance_item 的验收判定）+ 更新既有用例 显式打 subtaskKind；task-decomposition-materialize.test.js 补 subtask_kind 落库断言。全量单测 1202 条，1200 passed（唯二失败与本次改动 无关、改动前即存在）。 本轮明确不做：依赖顺序强制、能力匹配、graph-engine 调度模型改动、 Phase 4 的独立开发验证循环、Phase 5 看板 UI。 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
-
reopenRunForRetry 与 _reapStaleRunningNodes（开机孤儿清扫 + 45号文档持续性存活 扫描共用）把 run 从 blocked/ready 拉回 running 走的是裸 admitOrRequeue，不是 startRun，只改了状态从没重新挂上 runAuto 自驱动循环——手动/自动重试推一步后没人 接着推，agentRunId 仍是 null，backward 重试每次都在这里再卡一次。两处都补上 startRun 收尾那段逻辑：真的推成 running 且 execution_mode==='auto' 才挂 driver。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
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>
-
新增两条经验：阻塞任务事件驱动唤醒需周期性兜底扫描、校验失败重试边应指回产出方而非上游规划方。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
System Agents/Task Logs/Quota/Dream 及公司上下文的 Overview/Team/Workspace/ SOP/任务看板/Files/Messages 共 11 处导航链接原是 <a target="_blank">，改成 router-link 保持在当前页跳转。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013aQrCrnXcYEz5GdQ6fnPZm
-
GraphChatBar.vue 里"context 变了才拼说明、没变不重复"这条逻辑原来直接写在 <script setup> 里，脱不开组件测不了。照抄 agentChatEvents.js 的先例抽成 chatContextInjection.js 的纯函数（buildOutgoingMessage/contextKey），配一份 不用挂载组件就能跑的单测，锁住这条不变式。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YCd5WFjL1m31FaJXKx1j7Z
-
38 号文档 Phase 2 把 /api/okr 收紧成 admin-only，agent 走 CLI 调用必 401； 公司级正确入口是 POST/GET /api/company/:id/goals（requireAuthOrInternal）。 新增 --company / LEMON_COMPANY 兜底，缺省给出明确提示而非裸 401。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKPAmaoRGb6UdGwPbStCwJ
-
graph-console 页面底部新增可展开/收起的聊天条（GraphChatBar.vue，仿 MasterChatDrawer.vue 写的自包含最小聊天组件），直接跟公司 ceo agent 对话，不用跳去 AgentChat 整页。会话持久化在 localStorage（按 companyId 区分），刷新页面自动拉历史消息恢复。 发消息时若当前选中的 task/goal 跟上次发送时不同，会在实际发给后端的文本前拼一行上下文说明， agent 不用用户手动复述在看哪个任务；聊天气泡里展示的仍是用户输入的原文，不被这行说明污染； 上下文不变时不重复注入。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YCd5WFjL1m31FaJXKx1j7Z
-
真实事故：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
-
与 TaskBoard 页头的「执行控制台」链接对称，方便两页互跳。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XFEiaAAG79HrW2Avqrq2Xs
-
之前排队等待（上条改动）期间前端只有通用的"思考中"，最长可能等到 60s 都看不出 是在排队还是在正常生成，容易让人以为卡死了。 - agent-session-lock.js 新增 isLockBusy(agentId)：判断此刻是不是真被占着（僵尸锁 不算），供路由层在真正排队前 peek 一眼。 - agent-chat.js 的 /:agentId/chat：锁被占用时提前建立 SSE 连接、先发一个 queued 事件（activeConvId + waitBudgetMs），前端能精确显示"排队等待中"；没被占用的 常见路径完全跳过这段，不引入多余的建连时机差异。头一旦按 200 SSE 发出去就不能 再改状态码，排队超时也改用 queue_timeout 事件收尾，不再是独立的 429 JSON 响应 （没被占用、一开始就抢到锁的路径不受影响，仍是普通 SSE）。 - agentChatEvents.js 的 handleEvent 认识这两个新事件类型：queued 把 thinkingText 换成带等待预算的提示；queue_timeout 跟 error 分支一样落一条可见的助手消息， 不会像原来的静默 429 那样挂在界面上没反应。 - 相应更新 agent-chat-interrupt.test.js（断言 SSE 里真的有 queued/queue_timeout 事件，超时分支状态码从 429 改为 200）+ agentChatEvents.test.js 新增两条用例。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CwGcvMfUcgCcweN5vjhTkn
-
- agent-session-lock.js 新增 acquireLockWithWait：锁被占用时按 pollMs 轮询排队等待 AGENT_CHAT_QUEUE_WAIT_MS 预算（默认 60s），check-and-set 之间无 await，天然原子； 等到锁释放就正常执行，等满预算仍抢不到才 429，不再"撞上就立刻拒绝"。 内部自唤醒（TaskCallback/TaskDispatch 等 selfChat 调用）是 fire-and-forget，之前 429 等于这次唤醒直接消失，只能靠别处巡检兜底；排队等待让大多数几秒到几十秒的 短暂碰撞能自然衔接上。 - AgentChat.vue 的 handleSend() 之前拿到 fetch 响应后不检查 r.ok 就直接当 SSE 流读， 非 200 响应体是普通 JSON，逐行解析全部匹配不上 event/data 前缀，被静默当空流吞掉—— 用户发的消息挂在界面上，没有任何回复也没有报错。现在先判 r.ok，非 200 时读 JSON 错误体，429 显示"Agent 正忙，请稍后重试"，其他状态显示带状态码的错误提示。 - agent-chat-interrupt.test.js 相应更新：原来断言"并发第二个请求立刻 429"的用例 改为断言"预算内排队等待、等到就正常执行、两次调用不重叠"，另加一条"预算耗尽仍 抢不到锁时返回 429"的回归。 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
-
GoalTaskPane.vue（GraphConsole 左栏）按 parentTaskId 分层渲染，子任务 只读展示（没有独立 run，不接操作菜单）；TaskTable.vue（TaskBoard，当天 另一个并发 session 重写的表格视图）用一行「↳ 子任务·属于「…」」指回 父任务，不强行画树——它是可排序表格，硬套树形会跟排序打架。 taskView() 已在上一个提交里补上 parentTaskId/acceptanceMode 字段输出。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
-
实现路径：task-planning 判断是否 itemized（硬规则 5 开例外让 LLM 写这 一个字段）→ org-planner 收尾把 acceptance.md 物化成子任务 → coder-validator 用新工具 task subtask-result 逐条上报，settleNode() 新增闸门强制核对 子任务全部 completed 才认这一轮 success。 - work-graph-db.js: tasks 加 acceptance_mode 列，createTask 支持 parentTaskId（复用既有列），新增 settleSubtaskResult 条件更新 - graph-engine.js: maybeMaterializeItemizedSubtasks（org-planner 结算 success 后物化子任务，agent_call/subgraph 两种形态都认，subgraph 场景 扫子 run 全节点找 acceptance.md，找不到优雅降级不阻塞主产出）； coder-validator 判 success 前新增子任务完整性闸门 （ENGINE_FAIL_REASONS.SUBTASKS_INCOMPLETE） - task-planning.js / company.js: acceptance_mode 字段透传链路 - bin/lemon.js: 新增 task subtasks / task subtask-result 两个子命令 - coder-validator/agent.md、task-planning/agent.md: 对应提示词更新 真实回归验证过（新建公司走完整链路），过程中发现两个跟本次改动无关的 预存在问题：一次瞬时的 produces_missing 误判（重试即愈）、一个结构性的 writesArtifacts 产出闸门不匹配 bug（另立 44 号文档记录，未修复）。 全量单测 1120/1123 通过，3 个失败与本次改动无关（git stash 验证过）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
-
原来的 /task-board 挂的是 GoalTaskPane（折叠式目标→任务列表），字段少、 没有搜索筛选排序、点任务是整页跳转。GoalTaskPane 同时被 GraphConsole 左栏复用，原地重写会连带改掉那边，所以新做 TaskTable + TaskDetailModal 两个组件只给 TaskBoard 用。 - TaskTable：表格列（状态/描述/所属目标/负责Agent/优先级/创建·开始·结束 时间），搜索框 + 状态/目标/负责人筛选 + 点表头排序 - TaskDetailModal：点一行弹出详情，可编辑 + 增删改查（复用既有 taskActions()/PATCH/POST/DELETE 端点，没加新接口） - taskView() 补上 assigneeAgentId 字段（DB 列早就有，只是没读侧暴露） 已用真实登录态跑通端到端验证（建临时测试公司+任务，搜索/筛选/排序/ 增删改查全走了一遍，控制台零报错），确认 GraphConsole 侧栏未受影响。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XUvQ2xSFk7YoavE5SQENdw
-
回应"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
-
run 撞墙钟/调用次数/token 上限 blocked 时，之前界面上没有入口， 只能开发者工具手搓 fetch 调 POST /:id/budget。加一个按钮 + 小弹窗， 三维增量（留空不追加）+ 追加后立即启动，复用现有的 act() 提交入口 与 confirmAuto 同款 modal 样式。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
-
test/integration 类节点从不产出一个能被 indexNodeOutputs() 认作 kind='log' 的文件（落盘的都是 coder.log/test.log，归入 kind='artifact'）， required 的 log 契约永远无法满足，把节点卡进 missing_required_input 死循环。33 号文档修过一次模板文件，但 workgraph-planning agent 实际 照抄的是 tools.md 里一份没同步更新的旧范例，同一个坑复现（snakegame-co T-mtfh2kuf-7c31）。这次把底线收到 declareEdgeContract 唯一落库口， 不再依赖每个模板/每次 LLM 规划都记得写对；顺带同步 tools.md 范例。 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 -
原来场景 C 固定只回放最近 20 条、单条截断到 500 字，ACP 进程重启/空闲超时 后早于窗口的历史会静默丢失。改成按 token 预算（默认按 1M 上下文的一半， AGENT_MODEL_CONTEXT_TOKENS 可覆盖）从最新往最老收，装得下就整段注入。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XUvQ2xSFk7YoavE5SQENdw
-
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
-
之前几轮全量跑一直有 3 个失败，当时判断是环境耦合/pre-existing、跟本次改动无关就没细查， 这次逐个真查了一遍，三个都是真 bug： - system/agents/sdd-planning/SKILL.md：Evolve 训练产出从 train/evolve/SKILL.md 提升到 生产位置时，"训练依据"引用的相对路径没跟着调整（少了 train/ 前缀），指向了不存在的 system/agents/hunt/、system/agents/digest/；真实文件其实在同一个 agent 自己的 train/hunt/、train/digest/ 下，补前缀即可。 - graduation-criteria-reality.test.js：断言死等 code-planner 的状态回到 'active'，但 该本体的 config.json 早已从曾经踩坑的 "training" 改成了真正毕业态的 "enabled"—— seedAgents() 把 DB 同步成 'enabled' 是设计如此（同为毕业态，不是降级），不该被判失败。 改成用 isUngraduatedStatus() 判断"没被打回未毕业域"，不再钉死具体状态值；顺手把 graph-seed-service.js 里那句会随源码变化过期的注释也改成不点名具体值。 - graph-engine-extend-budget.test.js：一颗时间炸弹——用硬编码绝对时间戳 '2026-08-23T05:23:52.886Z' 模拟"卡住很久了"，但被测代码真的调 Date.now() 算经过时长， 写这条用例时"经过时长"确实超过 2h 上限、又低于追加后的 6h 上限；现在真实时间已经过去 178 小时，连追加后的上限都超了，测试注定要红，跟被测代码毫无关系。改成 Date.now() - 3小时 相对计算，不再随时间推移漂移。 全量 vitest 131/131 文件、1089/1089 用例通过。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>