-
两类回填合在同一个脚本里（§十二.5 的要求）：同一次数据形态变更分两个 脚本，只会让「跑了哪个没跑哪个」变成新问题。 **沿用原 taskId，不新发一个** —— 这是这一步最要紧的判断。conversations 目录名是 task-{taskId}、汇报链路按 taskId 找回这条派单、summary 里互相 引用。换 id 等于把这些引用全断掉，而回填的目的恰恰是「别让历史消失」。 落点： - executor='agent'、assignee_agent_id ← dispatch 的 to、parent_task_id ← 派单链 - company_id 落 _global：tasklog 的行没有 company 这一维（from/to 都是本体 id）， 全局 agent 的会话本来就落在这个保留 id 下（28 §5.1）。不去猜某条派单 「其实属于哪家公司」—— 猜错会让它出现在错误的公司列表里，比都归 _global 更难发现 - 每条派单自带一个 goal：tasks.goal_id 是 NOT NULL 真外键，而派单没有「人提的需求」 那一层。与 §六.3 给 POST /:cid/tasks 设计的兼容路径同一条，不给 goal_id 开可空口子 - 标题把 <br> 还原成换行再取首行，否则整条正文糊成一长条 - dispatched → running（派出去了还没回话，不是终态） 实跑：4 条派单全部回填成功、零失败；再跑一次全部跳过、零新增。 回填后 executor='agent' 的行指向 hunter / digester / master / agent-creator， 原 taskId 一个没变。 守卫：server/tests/unit/tasklog-backfill.test.js（4 例） 顺带修掉自己踩的一个：新测试用 Date.now() 拼临时库路径，撞了 test-id-stability 那条守卫 —— 和另一个会话昨天踩的是同一个。改用 fs.mkdtempSync（仓库既有写法，graph-engine.test.js 的 runsDir 就是它）。 全量：131 文件 / 1251 测试全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
