宜博 / lemonboss

验证阶段真查出一个 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>

_scanConversationsDir 塞进 list 的字段是 conversationId，getTaskTimeline
过滤时却读 c.convId（始终 undefined），传进 _extractTaskId 后
convId.includes(...) 直接抛 TypeError，导致 /api/tasks/:id/timeline
每次调用都 500，前端任务详情页因此看不到任何日志。

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

此前只有人类对话路径 agent-chat.js 会写 memory.md，图执行的验收反馈从不进
memory.md，Dream 天天扫全是空转。runClaimedNode 结算后新增 recordNodeOutcomeMemory
桥接点，只在真派发（isRealDispatch）且 systemAgentId 对应本体已雇佣（bodyDir 存在）
时才记一行 success/fail 摘要，避免测试夹具/假 executor 用例把假地址写进真实
system/agents/ 目录。memory-service.appendToMemoryMd 补 mkdirSync，因为这条新调用方
不像既有的 saveSessionSummary 那样先建过 memory/ 目录。

从原本混在墙钟看门狗改动里的工作区 diff 中拆出，两个特性互不相关。

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

manual 模式没人点「下一步」、auto 驱动循环随进程重启丢失时，run_status='running'
的 run 再也不会触发 checkBudget，wallclock_ms 超时无人发现（实例：T-msx6toej 卡
135 小时才被人工揪出）。新增 sweepWallclockBudgets + 60s 兜底定时器
startWallclockWatchdog，复用既有 checkBudget/suspendRunTree 路径，接入点在
index.js DISABLE_BACKGROUND_AGENTS 早退之前。

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

用户问"当前 company 用到的所有 agent 骨架是不是都完整"，顺手全量核对了一遍
e2e-demo 实际会用到的 18 个本体（org 层三个 + 三张 work graph 骨架的全部节点 +
四个元规划本体），揪出两处：

- unit-tester：这次真实回归测试撞见过的那个空骨架（32/34/35 号文档记录的样本），
  agent.md/soul.md/SKILL.md 三份全是没填充过的 _base 原始内容。照 coder 的规格
  （同一张 executor.json 骨架的实现节点）写了一份对应的自测节点定义——四段式细则、
  网页/代码两类产物的检查手段选择（网页类点名用 scripts/visual-acceptance-check.mjs，
  不许用正则解析文本冒充浏览器检查）、数据契约、硬规矩。

- org-coder：完全独立于本次回归测试撞见的一处更早的缺口——soul.md 从 8/18 创建
  agent.md 起就没写过，这个本体已经在多个真实任务里跑过。照它自己 agent.md 里
  "实现节点"这个身份定位、比着 coder/soul.md 的规格补上，顺带记了一句它是跨公司
  共享本体（P1 虚拟引用），别把单个公司的业务细节写进去。

agentLocator.missingBodyDefinition() 核对过，18 个本体全部通过。全量单测
1012/1012 通过（本身不涉及后端逻辑改动，只是确认没有连带影响）。

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

e2e-demo 公司真实回归任务（T-mt2r6fz0-125b，31/33 号文档验证用）跑 org-coder
支线时新招的两个本体，system/agents/ 是全部 agent 本体的唯一目录，理应入库。

coder/agent.md 正常填充过（角色专属内容）。

⚠️ unit-tester/agent.md 仍是未填充的 _base 原始骨架（带 LEMONBOSS_BASE_SKELETON
哨兵标记）——这正是 32/34/35 号文档反复分析的"招聘装配没填充完"问题的真实样本，
如实提交，不假装它是完整的。它已经在真实图执行里跑过一整条任务（见 34 号文档
§五），提案 A（35 号文档，commit bab675c）落地后，这类未填充本体会在图执行前
被 body_not_ready 闸门拦下，不会再静默拿空提示词跑真实调用。

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>

35 号文档剩下的三个提案，彼此直接相关（C 产出 D 消费的证据，B 展示 D 算出的结果），
一次做完。

提案 D（goal-contract.js 引擎级证据闸门）：
  `runBenchmark` 新增 evidence 检测——`evidence_hint` 命中"浏览器/视口/开发者工具/
  console/network/截图"类关键词的维度，必须在 evidence.<dim> 有真实字符串支撑，
  否则该维度判不过（哪怕分数达标）。证据来源两处都认：`--target` 文件自带的
  `evidence.<dim>`，或同目录姊妹判词文件 `attempt-<n>.json` 的 `dimensions[].evidence`
  ——后者是 benchmark-validator/agent.md 早就在教的既有写法，不用 agent 多写一份。
  新增 `dimensions[].evidence_required` 字段随判决落盘。6 条新单测。

提案 C（可复用视觉验收工具）：
  新增 scripts/visual-acceptance-check.mjs，四个子命令（overflow/style/console/
  contrast），封装最常见的几类真实浏览器检查（Playwright），agent 通过 bash 直接
  调用，不用每次自己临时想办法（真实撞见过两个极端：一次真写了 Playwright 认真测，
  一次只写了正则解析文本）。配一份不进 vitest 快速循环的独立冒烟脚本（起真
  Chromium，几秒量级）。benchmark-validator/agent.md Step 2 加了引用说明。

提案 B（控制台证据可见性）：
  GET /api/graph-runs/:id 新增 benchmarkVerdicts 字段（只读 goal-contract.js 已落盘
  的判决，不重新计算）。NodeDetailPanel 概览 tab 新增"验收证据"小节：逐维度显示
  分数 + 是否有证据支撑，evidence_required 且缺证据的标 ⚠️。纯展示，不改判定逻辑。
  2 条新单测。

全量单测 1012/1012 通过；控制台功能用 Chrome 实测过（截图确认"验收证据"小节正确
渲染）。

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>

runClaimedNode 派发真实调用之前，先查一次 agentLocator.missingBodyDefinition
(systemAgentId)——此前这个判据只在招聘/建公司路径上被查过，图执行的核心路径
从没查过：本体因任何原因（装配没跑完、手工改坏、迁移遗留）仍是空骨架时，引擎
会原样把它当正常本体派发一次真实调用，静默产出一份没有角色指导支撑的结果
（真实样本见 34 号文档 §五：unit-tester 顶着 _base 骨架跑完了一整条真实任务）。

本体不完整时：新 fail_reason='body_not_ready'（与招聘路径的同名状态同义），
不扣预算（没有调用发生，"一次调用一定发生了"这条记账理由不成立）、不起边界
守卫、走正常的选边/兜底/熔断路径（不发明第二套重试语义）。

只在 agentExecutor === defaultAgentExecutor 时生效（与 boundaryGuardApplicable
同一判据）——第一版忘了这条，把全仓库几百个用假 systemAgentId + 注入假 executor
的用例全部判成 body_not_ready，跑单测直接炸穿 75 个用例；加上这条判据后收窄回来，
只在真会起 CLI 的路径上生效。

只查 agent_call 节点：subgraph 节点的 systemAgentId 不是即将被直接调用的本体，
它派发的是 workgraph-planning 去规划子图。

新增 graph-engine-body-not-ready.test.js（4 例）+ 更新
graph-engine-fail-reason.test.js 的取值域断言（五个→六个）。全量单测
1004/1004 通过。

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>