多次回传，
幂等收敛。

一个 task，三个回传口。

MB 在 dispatch 时给 tobatsu 三个 URL：业务正常出料走 /result； agent 自己知道挂了走 /failed； runner 层挂掉 agent 没机会发，tobatsu platform 走兜底 /platform-terminal。

callback URL 由 MB 在 dispatch 时 mint，写进 envelope： envelope.callback_url、envelope.callback_failed_url、 platform_terminal_callback.url。auth 用 per-run 一次性 callback_token，存在 agent_runs.callback_token。

状态机里只有 5 个格子，但路径有 7 条。

你需要知道的所有"这次 callback 该怎么处理"答案，都在 run.status 这一个字段里。MB 看到当前状态 + 进来的 callback 类型，决定下一步。

源码：src/routes/runs.ts:768 的 isLateUpdate = (run.status === 'done') — 就这一行 boolean 决定是首发 INSERT 还是 late UPSERT。

首发 INSERT，后到 UPSERT，状态只翻一次。

逻辑像一个 if 分支：当前 row 状态是 done 吗？是 → 走 late update 分支，UPSERT 同一行， 不动 status；否 → 走首发分支，INSERT 新行 + 翻 status 到 done。

// src/routes/runs.ts · /result handler · creative stage 简化版
const isLateUpdate = run.status === 'done'

if (!isLateUpdate) {
  // 首发：INSERT 新 row + flip status
  await tx`INSERT INTO creative_boards (...) VALUES (...)`
  await tx`UPDATE agent_runs SET status='done', result_count=1
           WHERE id=${runId}
             AND status IN ('running','failed')
             AND callback_token=${run.callback_token}`
} else {
  // 后到：UPDATE 同 source_run_id 行（meta 用 || 合并）
  await tx`UPDATE creative_boards SET title=..., blocks=..., meta=meta || ${...}
           WHERE source_run_id=${runId} AND deleted_at IS NULL`
  // 刷一次 result_count 让 UI 看到当前 live 数
  await tx`UPDATE agent_runs SET result_count = (
              SELECT COUNT(*) FROM creative_boards WHERE source_run_id=${runId}
            ) WHERE id=${runId}`
}

要点：status='done' 之后再来 /result 不报错、不翻回 running、 finished_at 不动。agent 不需要知道这是"第几次"，server 端拿 row 状态判断。

每一条 callback 都得过三关。

MB 不让 agent 自己生成 idempotency_key。靠三层自然约束兜底： run 层、task 层、item 层。

真"多 item" 只有一个 stage，其它都是单 row 全覆盖。

这是我第一次给 mai 出建议时栽的跟头 —— 把 crawl_daily 的语义当成 MB 通用。其实只有它是真 stream，creative / delivery late merge 是同一行重写。

源码：src/lib/run-schemas.ts:169 是 CrawlDailyResultSchema.items[]； :197 是 CreativeResultSchema.item（单数）； :240 是 DeliveryResultSchema.item（单数）。

谁先到谁赢，后到的写 error_secondary。

agent 自己发 /failed 和 tobatsu 平台发 /platform-terminal 可能同时发生。MB 不让两边争 status，只让先到者写 status + error。

源码：src/routes/tobatsu-platform.ts 完整 state machine。 MB 还保留特殊 case：status='done' 后到了 /platform-terminal，记 error_secondary 但不翻 status —— 业务成功覆盖平台兜底。

不是单 endpoint，也不是 single+status，
是 update 多次 + result 一次。

Mai 的 delivery agent 不稳定，需要分多次提交真正不同的产物（不是同一行重写）。 MB 的 crawl_daily 模型贴近这个需求，creative/delivery 不贴近。 所以照搬 MB /result 不对。

第一版建议不对，pair review 把我捞回来。

这次给 mai 出建议本来要 4 个 message，结果 6 个 —— 中间 mb-codex 看完我的方案后从源码角度反例了我，过程值得记下来当模板。