宜博 / lemonboss

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

对照 Google Antigravity「Teamwork」多智能体框架博客文章，产出两份设计
讨论文档（均标注"不代表已拍板"）：

- 49号：纠正27号P4「真并行」现状认知（阶段A/B/C早已实现，又一次「文档
  落后于代码」）；给验证严谨度问题提两个方向——benchmark段证据要求泛
  化（建议推进）、陷阱注册表落点定案为独立文件 known_pitfalls.md；实地
  核实"验收路径引导到test_script段"的工作量后结论是不做，撞上
  test_script.path 解析根不含项目根的结构性冲突。

- 50号：竞争候选+对抗批评+综合的详细设计草稿，critic/synthesis 强制
  分离的依据是仓库真实事故（qa-judge 早期评判+判决合一导致过一次无限
  循环，20次调用/31分钟才熔断）；量化了N路候选的预算超支风险。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UP1omSsXkyGhopHvWeSnyy

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

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

冲突在 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>

上一条 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

核心修复：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 号设计文档落地 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

服务器地址、/opt/lemonboss 部署拓扑（docker 容器 lemonboss、bind mount）、
git pull + docker restart 的具体上线步骤，来自实地登录核查，避免下次重复问。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

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>

远程部署前置需求：登录鉴权 + 公司级多租户隔离。后端 auth.js/jwt-auth.js（注册/登录/
JWT-cookie/OAuth）本来就已经可用，这次只是把它接到前端。

- scripts/seed-admin-user.js（npm run seed:admin）：幂等种子脚本，建出 admin/hex1234，
  role=admin。
- web/src/composables/useAuth.js + views/Login.vue：登录态 + 登录页。
- router/index.js 全局 beforeEach：未登录跳 /login?redirect=...，登录后带着原目标跳回。
- main.js 全局 401 拦截器：cookie 中途过期同样兜住，不止页面切换那一刻。
- AppNav.vue：显示用户名 + 退出登录。
- 顺手修：App.vue 原来无条件渲染 MasterChatDrawer，登录页也会露出这个悬浮入口，
  改成登录且非登录页才显示。

业务路由还没加锁（Phase 1 的事），登录后依然能看到现状全部数据，符合这一阶段的验收边界。
真实浏览器走过一遍全部流程（跳转/登录/跳回/直接刷新受保护路由/退出），npm run build 通过。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

现状 org graph 按 company_id 单例（27-P2 标题原文即"公司级"），塞不下 HR/财务/市场这类
跟"交付流水线"无关的公司常设职能——system/agents/hr/（"招·留·管·退"）本体已存在却从没
被装进任何图，全靠 fire-and-forget chat 招聘，没有图执行那一套断点续跑/审计轨迹。

提议把作用域从 company_id 升级为 (company_id, department_id)，一家公司可装配多张部门图，
每张仍保持人工固定/慢变/可审计——不是把角色图变成动态生成，只是允许公司持有的图从 1 变成 N。

全仓库调用点扫描（fork）结论：改造面是最初估算的 4 倍。真正的单点真相在
work-graph-db.js:readDefGraph 的裸 SQL 不变式（graph_id === company_id，写进了 §四.A.2
设计文档），坐在 graph-engine.js 执行引擎的热路径上，不在 org-graph-service.js 那层服务
API；另外还有两个易混淆的服务文件（org-graph-service.js / graph-service.js）共同维护一份
必须字节级一致的重复唯一索引、独立的 graph-seed-service.js 对账子系统（8 处裸 SQL）、
company-hire-org-layer.test.js 专属测试套件、orggraph-planning/task-planning 两份 agent
人设文档把"只有一张图"写进了自我认知——都需要一并改。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

在 prd-planning/agent.md 加了「描述性语言扫描」+「内容深度下限」+「业务度量翻译」三段
具体操作（对应 36 号文档训练出的 SKILL.md Step 4/5），soul.md 加一条对应工作原则。
用同一个 e2e-demo 首页任务重新跑了一次端到端回归验证：新 PRD 把"大图/简洁大气"等形容词
逐条翻译成量化规则，最终产出的 index.html/style.css 精确对应这些数值（视觉元素
min-height:320px、区块间距 96px/56px 等），文案不再卡在"非空"这条线——训练效果在
真实任务里得到验证。

回归过程中发现一个新的、独立于本次改动的引擎缺陷：org-coder-test 被反向打回后产出
「建议重跑 org-coder-validator」的诊断文件，引擎把诊断文件里的 infra_flake 标记当成
了这个节点自己的执行结果，导致原地重跑但从不路由到诊断建议的目标节点，陷入没有熔断线
的确定性死循环。记进 30 号文档，留待后续修复。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

新建独立试验节点 prd-methodology-trial，走真实 Hunt→Digest→Evolve 训练 PRD 撰写方法论：
2 轮 Small Loop 提前收敛（96/97 分，真实基线 50 分），用三个真实历史项目反推验证方法论
有效，Deploy 范围限定在该独立节点，未触碰生产 prd-planning。结论：FDE 对方法论类角色
确实管用，但收敛速度/验收严谨度依赖任务书里显式写明的自纠正要求，非免人工黑盒。

过程中连带修复同一个 2026-08-16 改名批次（innovator→org-innovator 等）遗留的 5 处死链：
company.js 两处硬编码调用、CompanyDashboard.vue「重新训练」按钮，以及四个本体各自
config.json 内部 id 字段从未随目录改名同步更新，导致 /api/agent/list 展示层用假 id
显示成死卡片。顺手修了 AgentScaffold 默认 tools.md 模板一处裸相对路径缺陷（对应
agent-md-refs.test.js 里已登记多时的已知缺陷）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

补记 commit fadb6fa 的实现记录：证据闸门选了"拦截"不是"降级"（降级等于还是采信
了分数，只是换个说法）；goal-benchmark.json schema 完全不用改，evidence 早就是
benchmark-validator/agent.md 教的既有字段，只是从没被 goal-contract.js run 读过，
让 runBenchmark 多看一眼姊妹判词文件即可，没有发明新格式；C 的实现只更新了真正
写分数/证据的 benchmark-validator，不是最初以为的 coder/unit-tester。

§三推进顺序标注全部完成，并记录了样本量不足的遗留风险（只有一次真实回归验证过
证据闸门，关键词表覆盖度与拦截后的连带影响都还没有大量数据支撑）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

补记 commit bab675c 的实现记录：按"第一版先做前者"落地（blocked 等人工，
装配自愈留后续），以及中途把测试套件炸穿 75 个用例又收窄回来的完整过程——
根因是 missingBodyDefinition 查真实文件系统，测试夹具的假 systemAgentId
天然"缺失"，改法是借用已有的 boundaryGuardApplicable 判据（只在真实执行器
下生效），不是发明新判据。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

用户问"任务结果差是 agent 能力、架构、还是 graph workflow 问题"，这份文档是
书面复盘：按发生顺序分四类——图/模板设计缺陷（31/33 号，已修）、招聘装配可靠性
bug（32 号已知问题的新样本）、一个复盘时新发现的架构缺口（missingBodyDefinition
完整性闸门只在招聘路径上调用，graph-engine.js 的执行核心路径 advanceOne 一次
都没查，本体不完整时没有第二道防线，静默拿空提示词跑真实 LLM）、agent 能力
（不是问题，两次订正过"没工具做不到"的误判，且有正面即兴发挥的例子）。

结论：主要是架构问题 + 一个具体可靠性 bug，不是模型能力问题。

提出两档改进方案供讨论：
  低成本（建议直接做）——把完整性闸门接进图执行前置检查（提案 A）、
    控制台展示验收证据可见性（提案 B，纯 UI 不改行为）
  大改动（建议先讨论优先级）——标准化视觉验收工具（提案 C）、
    引擎级证据闸门（提案 D）

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

§5.1 原来断言"没有浏览器工具，物理上做不到"，复盘时对照 p-bkhylu 的 org-coder
（同样只有 bash/read_file/str_replace(+write_file)，没有专门的浏览器工具）却
真跑出了 Playwright + headless Chromium 测试，才发现这个判断错了：仓库自带
playwright 依赖，bash 里 `node verify.mjs` 沿目录树能 require 到仓库根的
node_modules，这条路今天的 coder/unit-tester 同样走得通。

真正的差异不是工具权限，是 unit-tester 的 agent.md 从未填充过（32 号文档那类
问题）、没有任何角色指导，而 org-coder/coder-validator 都是正常填充过的成熟
本体。根因从"平台缺工具"改判为"这次没有指导 agent 主动想到"，是一个不一样、
也更能采取行动的结论。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

对比 e2e-demo 现有的三个项目根：
  p-v82tpc（今天的回归任务）—— 静态正则解析文本，零浏览器
  p-bkhylu（"做一个 lemonai 官网"）—— 真实 Playwright + headless Chromium：
    六档视口量 scrollWidth/clientWidth、getComputedStyle 量字号、手算 WCAG 对比度、
    禁 JS/reduce-motion 验证、整体挪到 /tmp 用 file:// 重开验证可移植性
  p-v1mpcl（31 号文档那条原始卡住任务）—— 无验证，任务在验收前就被取消

p-bkhylu 的 DELIVERY.md 里那句"未采信自证脚本，符合 SDD §0/§2 I-4 验收独立性
要求"，搜遍 system/、docs/ 都找不到这条规则——它是那次任务的 sdd-planning 会话
自己写进那次 SDD 的，不是仓库级别的通用约束。也就是说三条任务里，要不要认真
验证、认不认自证脚本，完全取决于哪次任务规划时 agent 会话恰好这么想，没有系统
保证。这就是 34 号文档 §三"影响面"判断的实锤：任务显示"已完成"与"真的达成
原始需求"之间的落差，目前只能靠运气。

34 号文档 §四 checklist 全部查完，状态行同步更新。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

34 号文档追加调查（§五）：
- coder-validator（预置 active 本体）的 agent.md 通篇是代码/契约正确性验证协议
  （npx vitest run + 抓假绿五件套），压根不涉及视觉/交互检查；这次任务新招的
  coder/unit-tester 两个本体 toolPolicy 都只有 bash/read_file/str_replace，
  没有浏览器/截图工具——goal-benchmark.json 的 evidence_hint 要求"打开浏览器"，
  在给定工具权限下物理上做不到，不是 agent 偷懒。
- 但也不是纯粹空手套白狼：data/companies/e2e-demo/projects/p-v82tpc/tests/
  unit-tester.check.js 是一份真实可运行的零依赖静态断言脚本，对维度 1-3 的检查
  （字号比例真解析 CSS clamp() 算出数字、三个卖点区块标题顺序、锚点跳转/平滑滚动）
  与浏览器版本基本等价甚至更精确；维度 4/5（响应式断点、资源完整性）的静态版本
  明显更弱，会放过断点内样式写错、本地资源路径错误这类情况。

顺带发现：这份脚本很可能是 unit-tester 在提示词完全没有测试方法论指导的情况下
自己想出来的——它的 agent.md 还是没填充过的 _base 原始骨架（隔壁 coder 正常填充
过），是 32 号文档"招聘装配没填充完"那类问题的又一个真实样本（发生在方案 B
修复提交 6a18379 落地前 1 小时，是旧行为的证据，不是新机制的回归；新机制下
会不会正常完成，仍未验证）。32 号文档 §四追加第 6 条记录这次样本。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

用户反馈：控制台原来只能逐个节点点「输入输出」tab 看产物，缺一个全局入口。
新增 TaskFilesPanel.vue，挂在页头，跨节点/跨 run 一次性列出这个任务的全部产物。

做的时候发现分两类、且第二类之前完全没覆盖：
  · 节点产出索引（graph_files，按 company+task 检索）——规划笔记/日志/契约快照
  · 项目根（W2 ensureProjectRoot，data/companies/{cid}/projects/{pid}/）——
    真实交付物代码写的地方，跨节点共享，indexNodeOutputs 从不扫它

后端补 readProjectRootRecord 导出 + GET /api/graph-runs/:id 挂 projectRoot 字段；
项目根的文件列表复用已有的 GET /:companyId/files（此前零调用方），不新开列目录端点。
新增 graph-run-route-io.test.js 两例（分配前 null、分配后原样透传 + 幂等）。

顺带订正 34 号文档：当时断言"index.html 从未被写出来"是错的——真实网站文件
其实在项目根里，只是没查那个目录。34 号文档 §零 记录了订正过程，问题收窄成
"validator 有没有真的做过浏览器级检查"（仍未解决，留待下次）。

全量单测 1000/1000 通过。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

真实回归任务 T-mt2r6fz0-125b 走到 completed 后回查产出，发现 org-coder-impl
从未写出任何 HTML/CSS/JS 文件（只有 _plan.md/_research.md/coder.log），但
org-coder-validator 给六个维度全打了 100 分。goal-benchmark.json 的
evidence_hint 里五个维度明确要求"打开 index.html/浏览器开发者工具检查"，
这份评分显然没有真的执行过这些检查——是一次没有证据支撑的评分，不是
"查过但判错"。

不是 31/33 号修复引入的新问题，是那两次修复让这条本会一直卡死的任务真的跑到
completed 之后，才把这个一直存在的验收缺口暴露出来。只记现象与证据，根因
（提示词缺前置检查？validator 没有可用的浏览器/文件工具？是不是这次新招聘
本体特有的一次性现象）留给下次调查，这次不深挖。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

org-coder-validator 在真实回归任务里被 missing_required_input 反复误判 blocked：
executor.json/executor-fanout.json 的 test/integration→validator 边声明
produces:["log"]（required 默认 true），但 test 类节点从不写出能被 indexNodeOutputs
认作 kind=log 的文件（coder.log 实际属于 impl，test 自己的 _plan.md/_research.md
认不出 kind 也没有一对一无歧义可猜），这个 kind 因此永远不会被索引到，
requiredInputsMissing 每次都判缺失——不是时序问题，是结构性、每次重试都复现的硬伤。

改成 { kind: 'log', required: false }，对齐 validator.json 已有的写法（它的
needs:artifact 早就标了 required:false）。真正必需的 needs:artifact 不变，
仍受硬闸门保护。

中途走了一段弯路：最初以为该改 inboundContracts() 按 role 过滤只留 needs，
改完单测炸了 9 个用例——大多数边只声明 produces（无配对 needs），这条链路
正是 T-mt25ecbd 产出闸门依赖的数据源，按 role 过滤会静默削弱那次修复。
已撤回（work-graph-db.js 这次只加注释，没有逻辑改动），细节记在 33 号文档。

新增回归用例 graph-files-index.test.js ⑪：produces required:false 且该 kind
从未被索引到时不拦下游成功，同边 needs:artifact(required:true) 依旧受保护。
全量单测 998/998 通过。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

用真实 LLM 起了一条新任务（G-mt2r62ia-73af/T-mt2r6fz0-125b）回归验证 83afecb 的修
复：org-planner-sdd 自判失败后沿新补的兜底边自动回退 3 次、零人工介入，最终收敛到
completed，补上 31 号文档 §六此前用确定性测试代替的那步真实验收证据。

顺带在 org-coder 子图撞见一个独立的新 bug：inboundContracts()/requiredInputsMissing()
不按 role 过滤 graph_edge_contracts，把同一条边上声明的 produces（源节点自己产出什么）
也当成目标节点的必需输入，导致 org-coder-validator 被 missing_required_input 反复假阳
性 blocked（agent 自己判定 passed，引擎却强改成 fail）。已定位根因、写清复现证据与建议
修法，记在 33-needs-gate-role-filter-bug.md，留给下次实施。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

planner 骨架（brd→prd→sdd→goal-benchmark→validator）复现：三个 planning 节点
声明了 produces 却没真落盘，executor 没抛异常就被引擎判 success；goal-benchmark
的入边 needs:[brd,prd,sdd] 只用来拼提示词里的 ⚠️ 提示，agent 视而不见照样产出
合法 acceptance。下游 validator 永远读不到三份文档，backward 重试撞循环硬顶后
只能人工兜底。

settleNode 判 success 之前新增两道闸门（均只对 agent_call 节点生效，subgraph/org
节点的契约由子 work run 自己的节点过闸）：
- unsatisfiedRequiredProduces：声明的 required produces 一个候选文件都没落盘 →
  fail_reason=produces_missing，不再放行
- requiredInputsMissing：声明的 required needs 在 graph_files 里查不到实例 →
  fail_reason=missing_required_input，不采信 agent 自报的 success

两者都只判「有没有」，不判「分类对不对」——ambiguous 归类留给下游 ⚠️ 提示词处理，
避免把「写了东西但引擎猜不出对应哪个 kind」误判成没执行。

包含此前已完成但未提交的 27-P4 T3（graph_runs.max_concurrency 落库）及配套
advance-batch 测试。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

只做了这一件事，没有跟着做「dream 改成 org/work graph 来跑」——两者被
单独评估过：org/work graph 是单公司作用域（org graph=公司级 workflow，
work graph=公司内某任务的节点图），dream 却是跨公司扫描，套进去要么破坏
作用域假设要么得新开图类型；且 graph 引擎自带的验收机制（goal-contract
benchmark/test-script）判的是「产物过没过验收脚本」，对「经验提炼得对
不对」这种自由文本判断没有对应机制——不管套不套 graph 都得单独设计
rubric，是同一件事。用户明确只要 REST/控制台这一半。

## REST（server/routes/dream.js，挂 /api/dream）

路由本身没有新业务逻辑，全部委托给已测过的 dream-service.js：
GET /agents（总览）、GET /agents/:id（详情，含定义文件可写性 + 经验
审计）、POST /agents/:id/run（手动跑一次，dryRun 只看有没有新原料不
起 LLM）、POST /sweep + GET /sweep/status（全量扫描后台跑 + 轮询，内存
态并发锁防止连点两下）。

## 控制台（web/src/views/DreamConsole.vue，路由 /dream）

一个表格 + 两个弹窗：本体列表（详情/跑一次/dry-run）+ 全量扫描按钮
（15 秒轮询状态）。导航栏加 🌙 Dream 入口。

## 验证

server/tests/unit/dream-routes.test.js 4 例，monkeypatch 掉
dream-service 导出对象上的六个函数（不走真文件系统，不误扫真仓库
76 个本体），只验路由层自己的逻辑：端点接线、sweep 并发锁状态机。

真起服务器打了真数据：GET /agents/innovator-evolver 正确报
SKILL.md 因没进 git 历史而不可写、经验审计吐出上次真跑沉淀的 4 条
经验及原文；dry-run 正确报 no-new-material，没多花一次 LLM 调用。
浏览器里走了一遍列表→详情→dry-run，与直接打 API 结果一致。

955 个单测全绿。

文档：29-dream-design.md §5.7 记录实现与「为什么不做 graph 化」的
理由；28-followups.md / docs/README.md 同步更新 dream 现状。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>