-
回应"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
-
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 -
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
-
39 号文档 §四.4 拍板"ceo 全权自主 enqueue，但 max_parallel_tasks / DEFAULT_TASK_BUDGET / goal 级 org-validator 这几道闸门必须照样拦住 它"，落地时没补这条测试。这次补上，走 ceo 实际会用的通路（draft:true + created_by:'ceo' → /enqueue），不抄近道直接摆数据库行： 1. 坑满时 ceo 建的任务排队，不插队。 2. 预算给 0，checkBudget 照样判耗尽，created_by 不改变结果。 3. ceo 建的两条 task 挂同一个 goal，全 completed 后 goal 级验收只调一次。 全量测试 1486/1490，零回归。 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>
-
服务器重启会杀死正在跑的 graph 节点背后的真实进程，但 graph_run_nodes. status 永远停在 running（ceo 的两条唤醒路径都只认 blocked，对这个状态 完全不可见）——39 号文档真跑复盘撞出来的坑，这次补上。 1a：graph-engine.js 新增 sweepOrphanedRunningNodes(cutoffIso)，复用 routeFailure 的 infra_flake 分支（不发明新状态），server/index.js 在 本次进程启动时刻挂一次开机扫描，排在其余「补一次全量扫描」钩子之前。 1b：新增 forceFailNode() + POST /:id/nodes/:nodeId/force-fail，补上 retry 端点管不到 running 节点这个缺口——人工/ceo 判定"这个真的救不 回来了"时的手动出口，转 fail 后交给既有失败路由处理，不发明新路径。 新增测试 12 例（graph-engine-orphan-sweep.test.js 4 例、 graph-run-force-fail.test.js 8 例），全量测试 1483/1487，零回归。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
上一条 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
-
两份文档文件名不同、内容不冲突，但编号巧合容易读混。改名 + 更新 39 号文档里的两处引用 + 补 docs/README.md 索引（39 号状态同步成 已实现，42 号补一条索引）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
P1-P5 落地后做了一次真实端到端测试（建公司→下 goal→ceo 监督→真实跑出 一个 Playwright 验证 5/5 通过的贪吃蛇游戏）。1469 个单测全绿，这次真跑 却测出至少三个单测没覆盖到的真问题：服务器重启会让 in-flight 节点变 僵尸且无人能自动发现、graph-run.js 鉴权缺口（已在另一个 commit 修过）、 规划/反思轨迹没有统一可追溯位置。 39 号文档新增「七、真跑复盘」记录技术缺口和过程教训；41 号文档把复盘 沉淀的待办拆成四个 phase 的开发计划（卡住恢复闭环 → 闸门穿透性回归 测试 → target_dir 配置入口 → timeline 承接规划轨迹），按优先级排开工 顺序。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
- writeGraph() 的乐观锁缺失此前误标"已修复"，实际只是后续实验绕开没再撞它，改回开放 TODO 并补上修法思路（CAS 式版本校验）。 - company.js 的 requireAuthOrInternal 401 缺口、boss agent 巡检设计，均已被另一并行会话 实际修复/实现（14cbaf5、39 号文档 P1-P5），核实代码后删掉这两条过期 TODO，指向正确出处。 - 新增一条未拍板的可选项：org-hunt/digest/evolve 这套"元 agent 复刻成 graph 原生副本"的 操作模式要不要沉淀进 org-graph-templates/README.md 供以后参考。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
第 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> -
39 号文档地基 0 当时只改了 company.js（goals/tasks 端点），graph-run.js （run 的 start/stop/retry/budget 控制端点）漏了同一处修复，还是纯 requireAuth。真实端到端测试里 ceo 被唤醒后能读写 goal/task 板，但调 /api/graph-runs/* 处理卡住的 run 时精确撞上 401——ceo 自己在对话记录里 诊断出这一点并写出了人工需要跑的 curl 命令，间接验证了这条修复的必要性。 两个挂载点（router + companyRouter）都改成 requireAuthOrInternal，两处 :companyId/:id 的 param 中间件加了与 company.js 一致的 req.user?.internal 旁路。route-auth-gate.test.js 同步更新断言。全量测试 1469/1473，零回归。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
排查「前端刷新不及时/没有打字机效果」发现现状已是 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
-
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> -
之前把这条 run 手动 patch required=0 + 重试推到 completed 那次操作，其实就是 "用真实回归任务验证 org-coder-validator 不再假阳性 blocked" 这条的证据，回来补记 （唯一没走到的是"由 workgraph-planning 全新规划一张图"这一环，端到端证据仍缺）。 复查了 validator.json 的 needs:[{kind:'artifact',required:false}]：不是同类潜伏 问题，是刻意设计——它验的 artifact 由另一张图产出，靠任务级共享索引找， 不依赖这条边的声明，required:false 与 33 号的 log 声明成因完全不同。 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>