-
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>
-
swept=0 时原来完全不打日志，导致"扫描确实跑过但没找到"和"扫描压根没 跑起来"在日志里长一个样——这正是本次要修的那类静默失败。改成不管 swept 是否为 0 都打一行，运维靠这行就能确认扫描器真正跑起来了。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
resumePendingGoalValidations 只补「收敛钩子跑过、卡在验收/汇报半路」的情形； 若钩子压根没被触发过（进程重启/异常吞掉/事件丢失），task 早到终态但 goal 永远停在 active，只能靠人工 OKR 巡检发现（e2e-demo 公司 G-mt2r62ia-73af 卡 了 48 小时）。新增 sweepStuckActiveGoals 开机全量扫描一次，并启动 5 分钟 周期性 startZombieGoalSweeper 兜底，把发现窗口从「天」压到「分钟」。 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>
-
两个独立的小修复，都是这次 e2e 回归 + 用户讨论"workgraph-planning 该怎么训练"时发现的： 1. workgraph-plan-<taskId>.md 撞名：一个任务里 org-planner/org-coder/org-validator 各自调 workgraph-planning 一次、各自的规划记录却共用同一个文件名，落在同一个项目根下， 后写的原样覆盖先写的——真实撞见过（org-planner 当时的规划记录被 org-validator 覆盖， 事后一个字都找不回来）。改成 workgraph-plan-<taskId>-<宿主orgNode节点名>.md。 2. subgraph 节点结算 → workgraph-planning 自己的 memory.md 桥接：阶段一的 recordNodeOutcomeMemory 明确排除了 subgraph 节点（那是给 agent_call 记的），导致 workgraph-planning 每次规划出的图最终跑得好不好，完全没有可积累的历史——这正是它 "允许裁剪却没有具体判据"这个问题一直无法通过真实反馈自我改进的原因之一。新增 recordWorkgraphPlanningMemory，在 subgraph 节点结算时把结果记进 workgraph-planning （全局唯一规划本体，不是宿主 org node 自己的身份）的 memory.md，只在真实规划 （planWorkGraph===defaultPlanWorkGraph）时记，避免测试夹具污染真实目录。 新增 3 条回归测试，graph-engine 相关测试文件全绿。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
run_b962ea87f58f 卡在 wallclock_ms 耗尽的锚点未结清问题上，需要人工追加预算 才能继续。extendBudget 只增不减、只加到已配额的维度上，追加时顺带结清卡死的 墙钟锚点（否则 startRunSync 一启动就把挂起时长记进新预算里）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
30 号文档记录的真实事故：org-coder-test 被上游 missing_required_input 打回后， 产出的是「建议重跑 org-coder-validator」的诊断文件而不是正常测试结果，引擎把诊断文件里 的 infra_flake 标记当成了这个节点自己的执行结果——infra_flake 原地重跑故意不烧 attempt/backward_count（"这不是节点的错，不该烧它的重试额度"），代价是它是唯一没有 熔断线的失败路径，真撞上了一次每轮产出雷同、永不停止的死循环，眼看着把任务预算耗光。 新增 graph_run_nodes.infra_flake_count 列，只在 infra_flake 原地重跑时累加，真正发起 新一轮真实派发（bumpNodeAttempt）时清零；连续判 infra_flake 超过硬顶（3，与 LOOP_HARD_CAP_EDGE 同量级）就不再原地重跑，改判 blocked 交给人工——不猜该走哪条 fail 边（infra_flake 这个取值域通常没人给它连边）。新增回归测试锁死"永不恢复的 infra_flake 在硬顶后停止重跑"这条行为，graph-engine 相关 10 个测试文件 94/94 通过。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
招聘自动训练与「重新训练」按钮都是给 org-innovator 发消息、由它去执行训练， 所以对话记录一直落在 org-innovator 的会话库里，而不是被训练的那个 agent 自己—— conversationId 里带目标 agent 的名字只是命名巧合，容易让人在错的 agent 页面下找不到记录 （今天实测：手工模板训练页删除前产生的一条记录就复现过这个问题）。 - company.js /hire：训练 conversationId 提前算好并通过 res.json 带回给前端 （不再等 setTimeout 回调里才生成，那时响应早发完了） - CompanyDashboard.vue 重新训练按钮：发完请求立即 window.open 到正确的 /agent/org-innovator/{convId} - CompanyDashboard.vue 招聘弹窗：雇佣触发自动训练时，弹窗给出可复制的正确链接 （不自动开新标签页——这条训练要等 agent-creator 先写完定义，立刻打开大概率是空的） 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>
-
24h 的"取消超时"曾是刻意为之，但代价是子进程已产出终态判词、仅 session/result 消息迟迟不来时，sendPrompt() 的 promise 没有任何兜底会挂到 24h 耗尽 （T-mt5esage：T-mt5d3mi9-57cf 卡 50+ 分钟才被 COO 心跳巡检发现，且已连续 3 次）。 收紧到与 process-guard.js FRESH_DEFAULTS.maxMs(10min) 同一量级：对话态 8min （无工具执行理应持续有 token 流），工具执行态 15min（跑测试/构建允许更长静默）。 补测试复现"tool_use 开始后无输出"场景，验证 15min 兜底生效而非 24h。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
POST /:cid/tasks -> enqueueTaskRun 入队时从未写过 assignee_agent_id， COO 心跳巡检靠 tasks.assignee_agent_id(the "to" field) 判断任务有没有 人接手，读到永远的 NULL 就把正常跑图的任务误报成孤儿任务 (本周已发生两次：T-mt25asz4、T-mt5d3mi9-57cf)。 - enqueueTaskRun 入队时补写占位哨兵 'org-graph'（GRAPH_TAKEOVER_ASSIGNEE） - settleTaskFromRun 收敛时用 COALESCE 兜底，只在仍为空时补，不覆盖 派单式任务（agent-chat dispatch 流程）已经写好的真实 assignee - TASK_PATCH_COLUMNS 补上 assigneeAgentId，否则 updateTask 写不进这列 T-mt5dkvjm Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
侧栏 170px 太窄看不全 agent 名字，改成 260px 并把名字从省略号截断 改成允许换行；顶部加搜索框按 name/id 过滤列表，点击过滤结果复用 已有的 switchAgent() 跳转逻辑，不用额外写定位/滚动代码。 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>
-
system/templates/ 已在 28 号文档的合并里并入 system/agents/，「模板」作为独立 数据概念已经消失；确认后手工 CRUD 页面（创建/改名/删除骨架、触发生成与训练、 传 skill 文件、provision）也已经没人用，一并下线： - 前端：删 AppNav「Templates」菜单项、/templates 路由、TemplateAgents.vue - 后端：company.js 删掉只服务于该页面的写接口（PATCH/DELETE/POST /templates、 generate/train/skills-upload/provision/files 系列），保留 GET /templates （CompanyDashboard 招聘弹窗和 CLI `company templates` 命令仍依赖它列出可招角色） - CLI：bin/lemon.js 删 `template create`/`template train`（调用的是被删接口） - 修正两处过时注释（company-service.js / graph-service.js）：不再声称 buildAgentDefinitionBrief 有两个调用方，/hire 是唯一派单点 - work-layer-body-paths.test.js 同步更新断言（2 处调用方 → 1 处） Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>