-
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
-
- 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
-
company.json 新增 target_dir/target_mode，graph-engine 的项目根分配 读到配置后不再逐 run 分配新 sandbox，同公司所有 run 解析到同一个固定 路径（复用 path-resolver 的 linked-new/linked-existing 校验逻辑， 抽出 validateLinkedTarget/resolveFixedTarget 共享）；未配置时零回归。 配了 target_dir 的公司 max_parallel_tasks 强制钉 1，避免多任务并发 写同一个仓库。按 39 号设计文档 §二 P5 落地。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
新增 /:id/task-board 路由，复用 GoalTaskPane/goal-task-model 的既有 逻辑铺满整页；废弃 /okr 路由与 OkrDashboard.vue，清掉 CompanyDashboard 里挂着"goals"名字、实际渲染旧 OKR 树的那个 tab；导航入口换成 "任务看板"。按 39 号设计文档 §二 P2 落地，后端 OKR 子系统本次不动。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
按 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
-
2026-08-28 清理僵尸公司 mycompany（company.json 已丢失导致界面永远不可见）时， 发现 org-coder/org-planner 这类按角色名生成 id 的本体会被多家公司共用同一行 system_agents，owner_company_id 只代表最后一次雇它的是谁——直接按它删会删断 其他公司仍在用的外键，脚本已加"仍被引用就跳过"保护，本地/生产 dry-run 验证过。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UpkWPa2CmuWJFJZksqvxWB
-
2026-08-28 把本地 mycompany/innovator-fde-trial 同步到生产时手搓合并脚本踩过两个坑： 本地库和生产库同名字段的物理列序可能不同（SELECT * 位置对齐会静默写错列)，以及 graph_runs/graph_run_nodes 循环外键的回填 UPDATE 必须给关联子查询加表别名。 把手搓版本整理成 scripts/sync-company-to-graph-db.js（按列名对齐 + 支持 --dry-run）， 并在 graph-db.js migrate() 和 production-deploy.md 里记下这两个坑，供下次同步复用。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UpkWPa2CmuWJFJZksqvxWB
-
- 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>
-
Master Agent 固定置顶，其余 agent 可通过卡片右侧"⋯"菜单手动置顶/取消置顶 （状态存 localStorage）。置顶的 agent 渲染成独立的框，跟下方可滚动列表分开， 避免了 sticky 定位下其他条目从底下滑过的观感问题。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CRNPSJBNTPa77fzM1mZo9z
-
AgentChat.vue 之前把 sending/streaming/streamContent/thinkingText/ thinkingContent/subAgents/acpLog/messages/activeConvId 全部做成页面级单例 ref， 不区分是哪个 agent 的。切 agent 时既不取消上一个还在跑的读流循环，也不重置这些 状态，导致三个连环症状：①思考中/等待回复横幅带着切过去；②只要有任意一个 agent 在跑，所有 agent 的输入框都被同一个 sending 锁成"等待回复中"；③A 流式输出时切去 看 B，A 的内容被当成 B 的渲染，A 说完那句话直接被 push 进 B 的消息列表。 改为按 agentId 存一份 reactive Map（chatStates），模板读"当前选中 agent"那一份 slice；handleSend/handleEvent 认发起时捕获的 requestAgentId 写自己的 slice，不认 "用户现在选中的是谁"。switchAgent 不再无条件清空目标 agent 状态——只有它空闲时 才去刷新/定位会话，正在生成就原样展示缓存，回切能看到完整后台进度。真机验证： 向 Master 发消息流式生成期间切到另一个 agent，输入框未被锁定、无状态污染，切 回 Master 能看到完整正确的输出。 顺带把已经在这个文件里的一处未提交小改动（agent 列表排序：Master 置顶）一并 收进这次提交，不是本次改动的一部分。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
router.use(requireAuthOrInternal) 之后，agent-chat.js 自己的 selfChat() helper （TaskDispatch/TaskCallback/TaskTransition ×2/TaskReject/HumanRequest 共 7 处 调用）一直在用裸 http.request 自己打自己的 /api/agent/:id/chat，没带 x-internal-token，全部被 401 挡住——而且 chatRes 回调之前不看 statusCode， 401 也照样打印"✅ 已唤醒"，症状是静默的（跟 claude-cli-session-leak.md 一个模式）。 实测复现：真实 dispatch 一个任务给 org-innovator，目标 agent 从未收到消息， 任务卡在 dispatched 状态没人执行。 修法：selfChat 加 x-internal-token header（跟 company.js/task-settle.js 的 自环调用同一套机制），并且真的检查 chatRes.statusCode，非 2xx 打日志说明失败， 不再假装成功。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
commit b7b5096 给 agent-chat.js 挂 requireAuthOrInternal 后，只顾了「同进程内 require 拿 INTERNAL_TOKEN」这一种自环调用（company.js/task-settle.js），漏了 bin/lemon.js——它跑在 agent 的 claude CLI 子进程里，不共享内存，没法拿到这个 token，导致所有 agent 的 task report/dispatch 全部 401，没法自行汇报完成状态。 修法：jwt-auth.js 生成 INTERNAL_TOKEN 时顺带写进 process.env.LEMON_INTERNAL_TOKEN ——spawn 默认把 process.env 整份传给子进程，免费传给所有后代进程（claude CLI → Bash 子进程 → bin/lemon.js）。bin/lemon.js 读到就带上 x-internal-token header。 顺带把硬编码的 API_BASE 端口改成可用 LEMON_API_BASE 覆盖，方便测试。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
ANTHROPIC_BASE_URL/API_KEY/MODEL 是 docker run -e 时固化进容器配置的， 改 .env + docker restart 不生效，必须重建容器；顺带记录当前已切到 智谱 GLM-5.3-Flash（此前是 DeepSeek deepseek-v4-flash）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
服务器地址、/opt/lemonboss 部署拓扑（docker 容器 lemonboss、bind mount）、 git pull + docker restart 的具体上线步骤，来自实地登录核查，避免下次重复问。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
之前 invoke 端点只把结果落 job（.data/jobs-openapi.json），从不生成 conv-* 会话、也不写 meta.json/history.json，导致网页 AgentChat 看不到任何 API 调用产生的对话记录。现在复用 agent-chat.js 的会话存储函数，写到同一份 system/agents/{agentId}/_global/conversations/{convId}/ 下。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
跟已发布的 Artifact 页面同一份内容，存本地留档（docs/done/open-api-manual.md 是内部真相来源，这份是排版过、可以直接发给外部团队的版本）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
POST /api/open/agents/:agentId/invoke（h3-video-prompt 这类不挂公司的 全局 Agent）跟公司级 invoke 是同一套请求体/轮询流程，只是端点和「查 存在还是查雇佣」不同，补一段区分说明 + 示例。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
POST /api/open/agents/:agentId/invoke —— 复用现有 company-scoped invoke （/api/open/companies/:companyId/agents/:agentId/invoke）那套 jobManager 异步 job + 轮询/webhook 机制，但不查 company_agents 雇佣关系（全局 agent 如 master/agent-creator/h3-video-prompt 本来就不挂在任何公司下，套雇佣 校验只会无条件 404）。只查本体是否存在（system/agents/{id}/config.json）。 两条 invoke 路由共用的执行逻辑（附件处理 + AgentManager 调用 + 写 job 结果）提到 _executeAgentInvocation，避免整段复制。 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> -
.gitignore 早就写了 .env，但历史上被 add -f 提交过，里面是真实密钥 （Feishu/GitHub OAuth/Google OAuth/Doubao/Tavily/JWT_SECRET）。 仓库不再跟踪，本地文件各自保留。历史 commit 里仍能看到旧值， 需要的话应轮换这些密钥（这个提交不处理历史，只停止后续跟踪）。 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>
-
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>
-
现状 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>
-
三者是 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>
-
sweepStuckActiveGoals 候选查询多加了 archived_at IS NULL，把「goal 被归档但 status 从未跟着收口成终态」这类形状（G-mt1qwgt5-6b77：唯一 task cancelled+archived 时 goal 的 archived_at 被打上同一时刻，status 却留在 active）永久排除在扫描之外。去掉该过滤： settleGoalIfAllTasksDone 对空 task 列表/存在非终态 task 都是 no-op，不会误收口合法归档 但确实没收敛的 goal。同时手动收口了 e2e-demo 库里唯一命中该形态的 G-mt1qwgt5-6b77。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
settleGoalIfAllTasksDone 用 listGoalTasks 默认口径（includeArchived: false）取 task 列表，task 若同时被 cancelled+archived 会被过滤掉， tasks.length 提前归零直接 return null，goal 永远收不了口——僵尸扫描等 于没扫到。实证：G-mt0a6upq-a98e / G-mt0a6upq-52ee 两条 goal 卡在 active 超 17 小时未被收口，两条 task 均已 cancelled+archived。 改成 includeArchived: true 取全量后再按语义过滤：draft 任务归档（人删 掉的需求）继续不参与判定，但 cancelled/completed/failed 之后再归档 （结果已发生只是从界面收起）必须照样计入，否则会反过来破坏"归档掉的 草稿不参与判定"这条既有行为（拆分产出可删的验收用例钉住的就是这个）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>