-
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AWsH2YBwBWTsQggPaPbsKJ
-
51 号文档阶段 A 上线后发现：CEO 心跳自主立项建出的草稿（split:false）其实自动带 1 条 draft task，dispatch 技术上立刻能跑，原以为的"零 task 闸门"并不存在——安全性曾经完全靠 ceo/tools.md 里"不许自己调 dispatch"这一句提示词约束，没有代码层面的东西挡着。 POST /goals/:goalId/dispatch 新增判断：created_by==='ceo' 且 updated_at===created_at （自建成后从没被 PATCH 过）直接 409。复用既有时间戳字段代理"有没有人碰过"，不加新列—— 已知简化（ponytail 注释标了天花板：分不清"真审过"和"随手碰一下"，精确区分需要专门的 reviewed_at 列，留给阶段 B）。 task-queue-routes.test.js 新增两条用例：未审阅的 ceo 草稿 dispatch 409、PATCH 一次后放行； human/未填 created_by 的草稿不受影响。相关四个测试文件 84 条用例 + 全量 unit 套件跑过， 无回归（4 个不相关的预存在失败：工作区不干净的环境闸门 + 两个与本次改动无关的仓库卫生检查）。 51 号文档 §四/七/八、docs/README.md 索引同步更新。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AWsH2YBwBWTsQggPaPbsKJ
-
公司没有任何 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
-
DevLoop 本质是 loop workflow（L1/L2/L3 三层嵌套，PM→Architect→Coder→Tester→ Integrator→Triager 六个固定角色），已被 27 号系列的 graph workflow（org graph + work graph，graph-engine.js）严格覆盖——loop 只是 graph 的一个退化形状。 用户评估 27 号总纲原计划的 P6（DevLoop 收编）后拍板：不做迁移，直接整体退役。 决策记录、评估过程、退役范围与保留项详见 docs/done/system-design/52-devloop-retirement.md。 删除： - 后端：routes/devloop.js、src/core/devloop/、services/devloop/ 下除 path-resolver.js/doc-store.js 外的全部文件、src/tools/devloop/、 server/public/devloop-status.html、两个 server 入口的 /api/devloop 挂载 - 前端：views/DevLoop*.vue（4）、components/devloop/（12）、router 里的 4 条路由 - system/agents/devloop-{pm,architect,coder,tester,integrator,triager}/（6 个本体） + _registry.json 对应条目 - server/tests/devloop/（21 个测试文件）+ 1 处跨文件断言（route-auth-gate.test.js） - fixtures/devloop-mock/ 下 DevLoop 专属 fixture + fixtures/devloop-mock-scenarios/ - 8 个 DevLoop 专属人工验证脚本（phase1-5-verify.js 等）→ 归档 - package.json 的 spec:extract/spec:check、scripts/git-hooks/pre-commit （唯一职责是校验已归档的 docs/prd/newfunction） 保留（仍被 27 号系列现役代码依赖，文件顶部已加说明）： - server/services/devloop/path-resolver.js（graph-engine.js 项目根分配用） - server/services/devloop/doc-store.js（hashContract 被 graph-engine.js/ goal-contract.js 复用） - fixtures/devloop-mock/ 目录本身（graph-engine 真实链路测试共用这批 fixture） 归档到 docs/_archive/devloop-prd-2026-09-17/：docs/prd/ 整站、build-manifest.json、 5 个 PRD 抽取脚本、8 个人工验证脚本。 顺带修正：work-graph-skeletons.test.js 的占位符不再依赖已删除的 devloop-* 本体； CLAUDE.md/docs/README.md 全面同步；no-dead-path-references.test.js 揪出的两处 死链接（brace-expansion 写法、历史路径未加归档说明）已修。 全量 vitest（1403 passed，3 条与本次改动无关的既有失败）、web:build、真实 server 启动（含 graph-seed 自愈：自动清理了库里残留的 devloop-* system_agents 行） 均已验证。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU
-
前一提交（c03ae10b）的 git add 因命令里混了一个已失效的 pathspec 而整体失败， 只有此前单独 git mv 出去的改名部分被记录下来，实际的引用修正全部漏提交。 补上：docs/README.md 索引（todo 表挪到 done 表 + 顶部状态行）、其余 27 系列 文档里指向该文档的相对链接（todo/ 与 done/ 下深度不同，分别处理）、 system/agents/*/agent.md 与 tools.md 里 cwd 深度 3 的 ../../../../../ 相对引用 （agent-md-refs.test.js 会校验这些链接真实可解析到文件）、_registry.json 的 description 字段、work-graph-templates/README.md、server/ 源码里的设计文档路径注释。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU
-
Conflicts: system/agents/ceo/agent.md system/agents/ceo/soul.md
-
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
-
由 dream 机制自动提炼跨公司经验并刷新 ceo 的 agent.md/soul.md 经验区块， 本次内容涵盖：状态字段自相矛盾判读、预算耗尽假阳性识别、批量阻塞告警回溯 依赖链、已知问题重复告警的处置、协作方专属工具越权代劳的边界、父任务终态 汇总缺陷的识别模式。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H9Mq8rViHp8xuj6zTy76hh
-
Conflicts: system/agents/ceo/agent.md system/agents/ceo/soul.md
-
- 7 个 soul.md/agent.md 的 dream 受管区块更新（agent-creator/ceo/master/orggraph-planning），2026-09-02 跨公司经验沉淀 - h3-video-prompt agent v6 轮次训练产物（hunt/digest/evolve）+ SKILL.md/agent.md 同步更新 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SRecw8oLkoFkEUEsx229hC
-
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
-
真实回归暴露"认领后没有触发源"的真问题，讨论后发现"认领"（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
-
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>
-
新增两条经验：阻塞任务事件驱动唤醒需周期性兜底扫描、校验失败重试边应指回产出方而非上游规划方。 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
-
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
-
实现路径：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
-
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
-
之前几轮全量跑一直有 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>
-
冲突在 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> -
Conflicts: system/agents/innovator-evolver/agent.md system/agents/innovator-evolver/soul.md system/agents/master/agent.md system/agents/master/soul.md system/agents/org-innovator/agent.md system/agents/org-innovator/soul.md
-
第 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> -
排查「前端刷新不及时/没有打字机效果」发现现状已是 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
-
- system/agents/deep-research/: 新 Agent 本体（agent.md/prompt.md/soul.md/config.json） 及 train/hunt 调研结论（knowhow_v1 + sources_v1.json，含 sha256 信源母本） - h3-video-prompt: train/digest、train/hunt、train/evolve 的 v2/v3/v4 全套训练产物， SKILL 升级 v0.5.0（习语甲/乙分轨 + prompt/block/clarify 三轨计分） - org-innovator: docs/ SKILL 模板库与 soul.md 更新（外网访问 SOP R1-R5、lark-cli 能力） - master / innovator-digest / innovator-evolver / innovator-hunt: 本体文件更新 - packages/agent-core/base/common/tools-base.md: 收录 lark-cli 入口与「搜得到≠读得到」边界 - bin/lark-cli: 飞书 CLI 入口脚本（wrapper） - .gitignore: 排除 .pnpm-store/、.env.bak*（防密钥入库）、train/hunt/sources_raw/ 与 train/evolve/_v*_artifacts/（中间产物沿用既有裁决，只留磁盘） Co-Authored-By: Claude <noreply@anthropic.com>
-
dream-distiller/dream-screener 定时任务的自动产出，全部落在 <!-- dream:begin/end --> 受管 区块内，区块外内容未改动。覆盖 agent-creator/coo/cto/innovator-digest/innovator-evolver/ innovator-hunt/org-innovator/orggraph-planning 共 8 个本体，纯新增无删改。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
独立试验节点（parent_id: null，不接入任何真实公司/图，不碰生产 system/agents/unit-tester/）， 四段式训练全部完成：真实基线 32.2 分（不合格）→ Hunt 挖出 7 条现状缺口 → Digest 建出 7 维度 benchmark_v1.md → Evolve 产出可执行操作手册 SKILL.md，独立样本压力测试拿到 94.4 分， 超过 80 分目标线。 追加一轮 Round 2 复测（round2_verification.md）：Evolve 阶段两处修正（D2 固定模板要求"不采信" 锚点词、D5(a) 可复现性核对）落到 SKILL.md 之后从未重新打分，94.4 分测的其实是被淘汰的 Round 1 草稿。复测拿两份样本验证：①对已用过的样本做假设性套用，98.0 分，确认 D2 修正干净有效，同时 发现 D5(a) 有 rubric 自身的结构性天花板（"全新任务非中断恢复"场景最高只能到 4 档，与修正力度 无关）；②对一份此前从未打过分的真实样本做非假设性打分，90.4 分（优秀档），过程中还纠正了上一轮 一处未经核实的事实错误（误判某样本缺配套 _research.md/_plan.md，实际齐全）。 按用户明确要求本轮不做 Deploy：config.json 的 status 仍是 training、benchmark_score 仍是 null， 生产 system/agents/unit-tester/ 未被触碰，训练产物等待人工审查后决定是否合并。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
三者是 heartbeat-service 里唯一 enabled=true 的系统级 Agent 本体， 不管有没有公司雇佣都会挂心跳定时器（每 5/10 分钟打一次），跟公司数据无关。 当前没有实际公司在运作，先关掉避免空转。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
- Hunt→Digest→Evolve→Deploy 全流程，8场景测试均分98.71/最低97，status enabled - 飞书标杆文档访问受阻(登录墙)，改用 MiniMax 官方 GitHub 仓库原文替代，如实记录在 train/fde_report.md Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
coder/config.json 长期停在 status:training，从没真正毕业，也从没做过 FDE 训练——是这次 "哪些 agent 该训"排序里排第一的节点，因为它是实际写代码、决定最终产品质量天花板的执行节点。 独立试验 coder-methodology-trial 训练产出（89.6/100，及格线65/目标线80）已手工合并进 agent.md 四段式生命周期：RESEARCH 阶段新增两张必建清单（接口契约锚点表 + SDD明确禁止清单）； EXECUTE 阶段新增"三支自问"机械动作（踩中禁止项/SDD未提及/引入新标识符，各自怎么处理写死）； VERIFY 阶段新增信号词检查（判定依据出现"代码走查/规则推导"等字样即不算数，必须真跑命令）+ 可重放性三要素检查 + 一页纸自检表。全部配了真实历史反例：p-cgfdcr 的 currentScrollTarget 状态变量偏离 SDD 却未留痕、p-v82tpc 独立验证时新发现的 header→nav 语义标签改动未标注。 诚实说明（agent.md 开头 + soul.md 原则7/8 都写了，别在别处混说）：89.6 是这套操作手册的 文本质量分，训练全程没有真的把 SKILL.md 喂给一次真实 coder 会话跑任务再打分，回答的是 "手册写得够不够具体"，不回答"照做真的能拿多少分"——这是训练报告自己指出的方法论局限， 不是自谦，照抄保留，避免后续把这个数字误用成"已验证的执行可靠性分"。 coder-methodology-trial 完整训练材料（agent.md/soul.md/SKILL.md/train/{hunt,digest,evolve}） 随本次一并提交。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
org-planner/agent.md 原来固定要求 workgraph-planning 只能画 brd/prd/sdd/benchmark/ validator 五节点链，不管任务是不是需要外部信息支撑。现在把"必须交出 brd/prd/sdd/ acceptance 四份"重新定义为交给 org-coder 的固定契约，但产出这四份东西的中间步骤不再 写死——按信号词（调研/竞品分析/市场行情 → web-search/deep-research 类节点；视频/广告 投放素材 → video-search 类节点；对接XX API/拉取实时数据 → api-integration 类节点） 明确授权在 brd 之前插入调研类节点，产出喂给 brd/prd/sdd。 顺手删掉了一段从未被真正执行过的死代码：文件里原有"四段式生命周期 RESEARCH→PLAN→ EXECUTE→VERIFY / task transition 命令行流转"的执行脚本，是把 org-planner 当成会被 直接派单执行的单体 agent 来写的，跟当前"org 层节点永远是 nodeKind:'subgraph'，实际 由 workgraph-planning 规划子图执行"的架构对不上，从来没跑过。 真实测试验证：给一个"调研竞品YouTube广告 + 对接定价API拉实时数据 + 产出竞争分析报告" 的任务，workgraph-planning 真的规划出了 7 节点图（比标准 5 节点多两个调研节点）， 其中 pricing-api-integrator 是全新按 hired_from_base 分支现场造的本体，经 agent-creator + FDE 训练流水线异步补全（96.00分），随本次一并提交。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
code-planner：status training→enabled，benchmark_score 96.35（行业基准82+14.35）， 六节输出模板与53判据写作规则落进 SKILL.md。 sdd-planning：benchmark_score 89.3，新增两处「深挖」小节——接口契约的可独立复现性 四类雷区（自证式验收/结论句代替实测值/风格描述无上限/占位内容也能通过）+ data_shapes 字段约束与业务术语映射规则，随附完整 hunt/digest/evolve 训练材料。 goal-benchmark：补一条自查项——pass_threshold 落档不能和 rubric 里"不达标"的文字 描述用同一个分数区间，否则及格线形同虚设（2026-08-23 抽查 3/5 样本命中此模式）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
独立试验节点，不接入任何真实公司/图。真实 Hunt→Digest→Evolve 训练"planner.json 五节点该不该裁"这类元规划判据，2 轮收敛 100/100（真实基线 34 分不合格，同义反复式 判据 15 分反而更低）。训练自验证时发现两处真实结构漏洞（裁 brd 遗留失效 backward 边、 S5 复用门在当前仓库数据下无法触发），均已如实记录并给出兜底方案。判定表已手工套进 生产 workgraph-planning/agent.md（见上一条提交）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
在 agent.md Step 4 加了具体的裁剪判据（对应训练出的 SKILL.md：S1-S5 五个复杂度信号 + G2/G3 两道门 + planner.json 五节点逐个判定表），替换掉之前只有"你可以裁剪"这句孤立授权 （真实回归验证过只打 34/100，不合格）。同时补上训练自验证时发现的真实结构漏洞——裁掉 brd 会留下一条指向不存在节点的失效 backward 边，连带修正清单写进了裁剪判据里。 Step 5 的规划记录模板新增"1.5 复杂度信号取值"一节，为 G3 复用门积累历史数据（当前 仓库还没有任何历史记录标注过信号取值，这道门会一直走 fallback，直到开始积累）。 soul.md 加一条对应工作原则：裁剪判据要具体，同义反复式判据（"任务简单就裁"）训练 验证过反而只有 15 分，比不判断还糟。 1411/1414 测试通过（3 个失败是其他自主进程遗留、与本次改动无关的既有问题）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>