-
公司没有任何 active/draft/planning goal 时，CEO 心跳原本会在第一步查询就拿到空列表、 直接回复"心跳正常"，永久停摆、没有信号升级给人类。心跳清单加一步空转检测，命中后走 使命前置闸门（company-context.md 的"公司使命"是"待定义"就拒绝立项、转人工）+ 去重 + POST /goals(split:false, created_by:'ceo') 建草稿，CEO 到此为止、不自己调 dispatch。 起服务实测（不只是读代码）推翻了设计草稿阶段的两处判断：GET /goals 不支持逗号分隔多状态 查询、也不支持按 created_by 过滤（改客户端过滤）；split:false 建出的草稿其实自动带 1 条 draft task、dispatch 技术上立刻能成功，不存在"零 task 逼人工审批"这道代码闸门——阶段 A 的安全性因此完全押在 tools.md 里"不许自己调 dispatch"这条提示词约束上，是当前最脆弱的 一环，见 51 号文档 §四。 未改任何路由/服务层代码，纯 agent 人设文档改动。阶段 B（CEO 自动 dispatch + guardrail + 公司级开关）留白未实现。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AWsH2YBwBWTsQggPaPbsKJ
-
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
-
真实回归暴露"认领后没有触发源"的真问题，讨论后发现"认领"（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
-
真实事故：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
-
按 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
