tobatsu 2.0 · 迁移版本审计 · cc 第一手 DB 核对

2.0 迁移版本现状 · 确切认知

每个模板：1.0 ↔ 2.0、生产 ↔ 测试，到底是不是一回事。源数据=2.0 库 workflow_revisions 实查 + 1.0 ep-sweet-leaf 注册快照(2026-06-16)。

生产模板(无_test后缀)

1 / 12

只有 generic_ffmpeg_rendi 是路由克隆(test==prod)

7 / 15

2.0生产与1.0字节一致;另7个2.0改过

生产环境别名(28条全test)

三句话现状（先看这个）

1.0 本来就是两套并存、而且早就不一样。1.0 生产库里 kamila_hook 和 kamila_hook_test 这样的成对模板全都存在，且 12/12 对在 1.0 里内容就已不同。这个“生产/测试分开”是从 1.0 继承的，不是 2.0 迁移搞出来的。
迁移大体忠实，但不是全部原样。15 个生产模板里 7 个 2.0 内容与 1.0 字节一致；另外 7 个在 2.0 里已被改过（kamila 到 r20、material_board_creative 到 r37、delivery 到 r30…高版本号=迁移后在 2.0 上继续迭代过）。
“测试跑通=生产跑通”只对 1 个成立。只有 generic_ffmpeg_rendi 的 test 和生产逻辑一致（路由克隆）。其余每一对，_test 和生产都不同——我们这轮 RC-1..7 全跑在 _test 上，所以对那 6 个，验的是测试版、不等于验了生产版。

为什么会这样（模型）

生产模板 = 给真实业务跑的稳定版。_test = 上游团队（MB / Mai）的自测 lane，他们历来在 _test 上迭代新功能 / 修 bug，生产版往往滞后。这是 1.0 时代就有的运作方式，2.0 只是把这套结构原样搬过来了。所以“迁移过来就已经不一样”——对，是这样。

全模板矩阵

生产模板	1.0 生产 sha	2.0 生产 sha/rev	2.0==1.0?	2.0 测试 sha/rev	生产 vs 测试	本轮验证
`digital_human_omnihuman_mai`	c7ac2840d791 r2	c7ac2840d791 r2	一致	4e7f90fc7a93 r4	31行/实质23	RC-6 DH（跑 `digital_human_omnihuman_mai_test` v4）
`generic_ffmpeg_rendi`	d5d324814863 r6	d5d324814863 r6	一致	98fd69411b37 r1	路由克隆(逻辑一致)	RC-5 VE（跑 `generic_ffmpeg_rendi_test` v1）
`kamila_hook`	e67e3df74835 r6	29ecaace0969 r20	改过	dad1220171a7 r20	40行/实质33	RC-7 KAMILA（跑 `kamila_hook_test` v20）
`material_board_creative`	c8e1510e0e48 r36	56b95ed4fae4 r37	改过	cc49feffc3db r101	37行/实质35	早前 MB 联调验过（非本轮真画布）
`material_board_creative_ue_bridge`	b1e2edd242d7 r15	7296b7b09b03 r16	改过	6fa146ddfad8 r56	9行/实质6	早前 MB 联调验过（非本轮真画布）
`material_board_daily_crawl`	a1e4976036c2 r13	a142e361d7c8 r14	改过	f3f261dfc0ba r15	13行/实质8	早前 MB 联调验过（非本轮真画布）
`material_board_delivery`	dd9cb995d71b r29	65e7902720fc r30	改过	6b69aaf71465 r102	9行/实质6	早前 MB 联调验过（非本轮真画布）
`material_board_preview_research`	3768f1c5d004 r14	3768f1c5d004 r14	一致	3fba29d05d70 r7	15行/实质9	早前 MB 联调验过（非本轮真画布）
`video_pip_compose_mai`	3914415b3d68 r2	3914415b3d68 r2	一致	b1b67abeea47 r3	28行/实质19	RC-3 PIP（跑 `video_pip_compose_mai_test` v3）
`video_reframe_any`	dffaf61610a3 r29	1f82a5d721c2 r30	改过	cd4144b601bf r11	229行/实质224	RC-1 reframe（跑 `video_reframe_any_test` v11）
`voiceover_align`	60623c330f67 r12	c02e46f7bea3 r13	改过	a2bcdcbdc70e r10	20行/实质9	RC-4 VA（跑 `voiceover_align_test` v10）
`voiceover_digital_human_pip_subtitle_mai`	b07d337a747e r6	b07d337a747e r6	一致	3e03bd1fe524 r44	39行/实质20	RC-2 combo（跑 `voiceover_digital_human_pip_subtitle_mai_test` v44）
`subtitle_burn_in`	9c89ac6532d7 r4	fdb8587be356 r5	改过	—	—	本轮未单独验
`digital_human_omnihuman`	cb59ac8ed8c1 r3	cb59ac8ed8c1 r3	一致	—	—	本轮未单独验
`video_pip_compose`	a417fc401bea r4	a417fc401bea r4	一致	—	—	本轮未单独验

“2.0==1.0” = 2.0 生产模板内容是否与 1.0 快照字节一致。“生产 vs 测试” = 同在 2.0 里，生产名模板和 _test 的内容差多少行（实质=去掉纯改名后的真差异）。

那 7 个「2.0 改过 1.0」的生产版——谁改的、改了啥

看起来"7 个生产模板和 1.0 不一致"会吓人，但逐个查作者/时间/提交说明后，没有一个是来路不明的偷改，分三类：

生产模板	谁改的 / 何时	改动性质	判定
`kamila_hook` r20	上游 kamila-cc 经 external_api · 06-18	真·新版本(上游团队自己推的)	跟迁移无关；上游迭代
`material_board_creative` r37 `..._ue_bridge` r16 `..._daily_crawl` r14 `material_board_delivery` r30	codex-2.0-mb-rebuild · 06-20	提交说明=`v7 skill rename reference only`=只改技能名引用	非行为改动；MB 重建的改名
`video_reframe_any` r30	codex-mai-2.0-restore · 06-20	`canonical_output_upload_parser`	迁移声明的清理(上传解析)
`voiceover_align` r13	codex-mai-2.0-restore · 06-20	`remove_runtime_pip_install_pydub`	迁移声明的清理(去运行时装包)

所以这 7 个 = 1 个上游推的真新版(kamila)+ 4 个 MB 改技能名(非行为)+ 2 个迁移声明的清理。不是黑箱乱改。

★ 但更要命的一点：这些"生产当前版"几乎没被验证过

这些生产模板历史上跑过几百次（material_board_daily_crawl 累计 done 583、video_reframe_any 434、voiceover_align 303…），看着很成熟。但那都是在旧修订上跑的。我查了「当前修订（也就是真翻生产时会上的那串字节）上到底有没有成功任务」：

生产模板	当前修订	当前修订上的任务	历史(老修订)
`kamila_hook`	v20	done 7（但不是 RC 真画布那批）	累计 done 21
`material_board_daily_crawl`	v14	failed 14、done 0（=那 14 条 401）	老 v12 done 231…累计 583
`material_board_creative`	v37	无任务	老 v14 done 128…累计 413
`material_board_creative_ue_bridge`	v16	无任务	老 v2 done 20…累计 62
`material_board_delivery`	v30	无任务	老 v12 done 115…累计 402
`video_reframe_any`	v30	无任务	老 v27 done 210…累计 434
`voiceover_align`	v13	无任务	老 v12 done 150…累计 303

结论：7 个里 6 个的"生产当前版"零成功任务，1 个(daily_crawl)当前版只有失败，只有 kamila v20 有 7 次成功但不是真画布验证。翻生产=上的就是这些当前版=基本未经验证。

运行时现实：连我们测的运行时都不是生产用的

RC-1..7 跑的是 test 队列，它优先解析到 canary 运行时 = v0.2.12（rev12 / 0b85c99b）。但真实业务队列用的是 active 运行时 = v0.2.0（ee98f108）。我第一手查 runtime_profiles 表确认：v0.2.0=active、v0.2.12=canary。所以连"我们验过的运行时"都不是生产在用的那个——上生产还得决定要不要把 canary rev12 提为 active（rev12 带的字体/透明解码/Node CLI 修复才会生效）。

那 7 个改过的生产版，到底有没有风险（逐个判定）

"没验证"不等于"危险"。我把每个改过的生产当前版，跟它上一个有绿任务的修订逐行 diff，看改动性质：

生产模板	当前版 vs 上一绿版改了啥	判定
`material_board_creative` `..._ue_bridge` · `..._daily_crawl` · `material_board_delivery`	只 4 行：技能引用 `material-board-pipeline-v7-test` → `material-board-pipeline-v7`	基本安全：本就该指 prod 技能。prod 技能已存在(非悬空)。小尾巴：prod 技能只 1 个修订、test 技能 5 个，技能层内容也得对一下
`voiceover_align`	1 行：删掉运行时 `pip install pydub`	基本安全：迁移卫生(依赖该在镜像里)。确认镜像有 pydub 即可
`video_reframe_any`	69 行：删的是一段冗长的"上传输出怎么解析"警告 prose(`canonical_output_upload_parser`)。上传逻辑本身没动——仍 `output_upload: r2`、仍解析 `output.url`(5 处)	内容安全：只删了冗余警告、解析逻辑还在。唯一缺口=当前版 v30 零任务=没真跑过，补 1 个 smoke 即可
`kamila_hook`	96 行：48 行 description/title + 48 行同内容中→英翻译 + 加 1 个技能绑定(`mai-platform-delivery`)。管线(board→seedance→rendi)没变	良性：是翻译+加技能、不是逻辑重写。而且 v20 已有 7 次成功(kamila-cc 06-18 自跑)=已被运行过

逐个挖到底后的结论：7 个改过的生产版没有一个是危险的。4 个技能改名(良性)+ 1 个删运行时装包(良性)+ reframe 删冗余警告(逻辑没动)+ kamila 翻译加技能(且已跑过 7 次)。真正的缺口不是"改坏了"，而是"几个当前版没在自己这版上真跑过(0 任务)"——补几个生产名 smoke 任务即可坐实；以及 kamila 生产是老 seedance 管线、test 是新 windowed-omni，那是产品取舍(要不要把新管线推生产)，不是缺陷。

每个模板的细账（逐个）

digital_human_omnihuman_mai 已分叉忠实1.0

1.0 生产c7ac2840d791 r2 2.0 生产c7ac2840d791 r2 1.0 测试078aa69ce1b6 r1 2.0 测试4e7f90fc7a93 r4 生产 vs 测试31 行不同（实质 23） 本轮验证RC-6 DH（跑 digital_human_omnihuman_mai_test v4） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

test -n "${UNIFIED_GENERATION_AUTH_KEY:?missing UNIFIED_GENERATION_AUTH_KEY}"
cutout:
type: boolean
unified_token:

生产模板是 1.0 忠实拷贝，但 _test 上有生产没有的东西。上生产要么把 _test 的改动回灌生产、要么生产按 1.0 老行为跑（没本轮验证）。

generic_ffmpeg_rendi 路由克隆忠实1.0

1.0 生产d5d324814863 r6 2.0 生产d5d324814863 r6 1.0 测试98fd69411b37 r1 2.0 测试98fd69411b37 r1 生产 vs 测试路由克隆·逻辑一致 本轮验证RC-5 VE（跑 generic_ffmpeg_rendi_test v1） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

（无实质新增，或仅路由名差异）

test 与生产逻辑一致（只差名字）。这一族测试通过=生产通过，最接近“切一下即可”。

kamila_hook 已分叉 2.0改过

1.0 生产e67e3df74835 r6 2.0 生产29ecaace0969 r20 1.0 测试83a57a311190 r6 2.0 测试dad1220171a7 r20 生产 vs 测试40 行不同（实质 33） 本轮验证RC-7 KAMILA（跑 kamila_hook_test v20） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

game_layout: { type: string, title: "Game-screen layout: none (live-action talking shot) |
- omni-handler
**Pipeline (windowed multi-image omni, 2026-06-18):** `per-beat board guide (image2image,
Input is in `payload.shots[]` (each shot: no / duration / costume(key) / characters / scen

生产模板在 2.0 里已被改过（不再等于 1.0），且与 _test 仍不同。上生产前必须搞清这个 2.0 生产版到底是什么、谁改的、验没验。

material_board_creative 已分叉 2.0改过

1.0 生产c8e1510e0e48 r36 2.0 生产56b95ed4fae4 r37 1.0 测试3f1138740319 r97 2.0 测试cc49feffc3db r101 生产 vs 测试37 行不同（实质 35） 本轮验证早前 MB 联调验过（非本轮真画布） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

engine_profile: claude-default
runtime:
You are an automation agent running inside Tobatsu.

生产模板在 2.0 里已被改过（不再等于 1.0），且与 _test 仍不同。上生产前必须搞清这个 2.0 生产版到底是什么、谁改的、验没验。

material_board_creative_ue_bridge 已分叉 2.0改过

1.0 生产b1e2edd242d7 r15 2.0 生产7296b7b09b03 r16 1.0 测试04955298e21d r52 2.0 测试6fa146ddfad8 r56 生产 vs 测试9 行不同（实质 6） 本轮验证早前 MB 联调验过（非本轮真画布） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

engine_profile: claude-default
You are an automation agent running inside Tobatsu.

生产模板在 2.0 里已被改过（不再等于 1.0），且与 _test 仍不同。上生产前必须搞清这个 2.0 生产版到底是什么、谁改的、验没验。

material_board_daily_crawl 已分叉 2.0改过

1.0 生产a1e4976036c2 r13 2.0 生产a142e361d7c8 r14 1.0 测试560247ce85d8 r11 2.0 测试f3f261dfc0ba r15 生产 vs 测试13 行不同（实质 8） 本轮验证早前 MB 联调验过（非本轮真画布） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

engine_profile: claude-default
You are an automation agent running inside Tobatsu.

生产模板在 2.0 里已被改过（不再等于 1.0），且与 _test 仍不同。上生产前必须搞清这个 2.0 生产版到底是什么、谁改的、验没验。

material_board_delivery 已分叉 2.0改过

1.0 生产dd9cb995d71b r29 2.0 生产65e7902720fc r30 1.0 测试81f2d64f0ffd r98 2.0 测试6b69aaf71465 r102 生产 vs 测试9 行不同（实质 6） 本轮验证早前 MB 联调验过（非本轮真画布） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

engine_profile: claude-default
You are an automation agent running inside Tobatsu.

生产模板在 2.0 里已被改过（不再等于 1.0），且与 _test 仍不同。上生产前必须搞清这个 2.0 生产版到底是什么、谁改的、验没验。

material_board_preview_research 已分叉忠实1.0

1.0 生产3768f1c5d004 r14 2.0 生产3768f1c5d004 r14 1.0 测试eaaec1a7bf56 r4 2.0 测试3fba29d05d70 r7 生产 vs 测试15 行不同（实质 9） 本轮验证早前 MB 联调验过（非本轮真画布） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

engine_profile: claude-default
You are an automation agent running inside Tobatsu.

生产模板是 1.0 忠实拷贝，但 _test 上有生产没有的东西。上生产要么把 _test 的改动回灌生产、要么生产按 1.0 老行为跑（没本轮验证）。

video_pip_compose_mai 已分叉忠实1.0

1.0 生产3914415b3d68 r2 2.0 生产3914415b3d68 r2 1.0 测试7e854c8e0c97 r1 2.0 测试b1b67abeea47 r3 生产 vs 测试28 行不同（实质 19） 本轮验证RC-3 PIP（跑 video_pip_compose_mai_test v3） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

pip_cutout:
type: boolean
stroke:
type: ["object", "null"]

生产模板是 1.0 忠实拷贝，但 _test 上有生产没有的东西。上生产要么把 _test 的改动回灌生产、要么生产按 1.0 老行为跑（没本轮验证）。

video_reframe_any 已分叉 2.0改过

1.0 生产dffaf61610a3 r29 2.0 生产1f82a5d721c2 r30 1.0 测试3911f9790d75 r10 2.0 测试cd4144b601bf r11 生产 vs 测试229 行不同（实质 224） 本轮验证RC-1 reframe（跑 video_reframe_any_test v11） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

master_map_url:
type: string
format: uri
This is NOT a pillarbox and NOT a center-overlay. Do not paste the original

生产模板在 2.0 里已被改过（不再等于 1.0），且与 _test 仍不同。上生产前必须搞清这个 2.0 生产版到底是什么、谁改的、验没验。

voiceover_align 已分叉 2.0改过

1.0 生产60623c330f67 r12 2.0 生产c02e46f7bea3 r13 1.0 测试70820dbfe62a r9 2.0 测试a2bcdcbdc70e r10 生产 vs 测试20 行不同（实质 9） 本轮验证RC-4 VA（跑 voiceover_align_test v10） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

（无实质新增，或仅路由名差异）

生产模板在 2.0 里已被改过（不再等于 1.0），且与 _test 仍不同。上生产前必须搞清这个 2.0 生产版到底是什么、谁改的、验没验。

voiceover_digital_human_pip_subtitle_mai 已分叉忠实1.0

1.0 生产b07d337a747e r6 2.0 生产b07d337a747e r6 1.0 测试3e03bd1fe524 r44 2.0 测试3e03bd1fe524 r44 生产 vs 测试39 行不同（实质 20） 本轮验证RC-2 combo（跑 voiceover_digital_human_pip_subtitle_mai_test v44） 别名环境test (生产) · test (测试)

_test 比生产多/不同的关键点：

hidden: true
# Mai Combo Video Workflow (Test Only)
You are running a **test-only** Mai combo workflow. It combines four existing Tobatsu capa

生产模板是 1.0 忠实拷贝，但 _test 上有生产没有的东西。上生产要么把 _test 的改动回灌生产、要么生产按 1.0 老行为跑（没本轮验证）。

subtitle_burn_in 无test 2.0改过

1.0 生产9c89ac6532d7 r4 2.0 生产fdb8587be356 r5 1.0 测试— rNone 2.0 测试— r— 生产 vs 测试无 test 本轮验证本轮未单独验 别名环境test (生产) · 无 (测试)

_test 比生产多/不同的关键点：

（无实质新增，或仅路由名差异）

没有 _test 对应；生产模板独立。

digital_human_omnihuman 无test 忠实1.0

1.0 生产cb59ac8ed8c1 r3 2.0 生产cb59ac8ed8c1 r3 1.0 测试— rNone 2.0 测试— r— 生产 vs 测试无 test 本轮验证本轮未单独验 别名环境test (生产) · 无 (测试)

_test 比生产多/不同的关键点：

（无实质新增，或仅路由名差异）

没有 _test 对应；生产模板独立。

video_pip_compose 无test 忠实1.0

1.0 生产a417fc401bea r4 2.0 生产a417fc401bea r4 1.0 测试— rNone 2.0 测试— r— 生产 vs 测试无 test 本轮验证本轮未单独验 别名环境test (生产) · 无 (测试)

_test 比生产多/不同的关键点：

（无实质新增，或仅路由名差异）

没有 _test 对应；生产模板独立。

那上生产到底还要做什么（codex 核机制 + cc 核数据，双方查实）

不是“切一下”。按顺序，9 步，全是 owner 拍板的活：

1. 逐模板定内容：每个分叉模板决定——生产保持它当前的版本，还是把 _test 验过的行为回灌生产名模板。别假设 _test 成功 = 生产名验证。
2. 补验证：凡是验过的行为只活在 _test 的，给生产名模板建/批一个含该行为的修订，并真验。
3. 建生产快照：给选定的生产名模板建 environment=prod 的不可变快照。现 restore 脚本只能建 test、且代码里主动拒绝 prod 别名（restore_mai_2_0.py 写死 test）——所以这是另一条没建的路。
4. 发布 prod 别名：经 owner-gated 控制面/API（app.py 有 publish/rollback 别名端点）发布 prod 别名。现 prod 别名 = 0。另：生产非 test 快照必须绑 active 运行时、不能绑版本钉死的（代码强制）。
5. 运行时决定：保持 active ee98(v0.2.0) 还是把 canary rev12(0.2.12) 提为 active。要 rev12 的字体/透明/Node CLI 修复，就得把 canary 提为 active——光 test 队列不算生产。
6. 队列 / 容量：现 w2+w3 = test 1+1、material 10+10、mai 队列 desired=0；旧 magi3 还挂着 mai=30 / material=30。生产要明确容量 + 队列迁移（30+50≈80 容器，现 2 台扛不住）。
7. 引流 + 凭据：把上游 / Mai / MB 生产流量指到 2.0 生产选择器；域名 / token / 密钥 / 回调归属——全 owner-gated。
8. 生产 smoke：prod 别名建好后，每个模板族至少跑 1 个真生产任务，验：task_type 不带 _test、走 prod 别名、active 运行时 digest、队列 / host、产物 / 画布 / 回调。
9. 备回滚：别名发布会记 previous_snapshot_id、可回滚；但首次 prod 发布之前没有 previous 可回，得显式留一个目标。

一句话：RC-1..7 证明了 _test lane 的逻辑 + 运行时 / 画布机制是通的；它没有证明生产名模板、也没建任何生产路由。本页全程只查不改，没动 DB / 生产 / magi3 / 1.0。