九条待合并 PR 的顺序：按文件重叠分成互不冲突的五条与需定序的四条

[johnnyzhang-eng]

背景

当前 16 个开着的 PR 里有 9 个来自同一个人，最早的三条（#321 #322 #324）已开了四天。这些 PR 的 CI 全部通过、评审意见全部 resolved，卡的只是合并顺序：其中四条改到同一批文件，先合谁决定其余几条要不要重做 rebase。

按文件重叠分组

统计九条 PR 各自改到的文件，两两求交集：

互不重叠，任意顺序都不会冲突（5 条）

PR	改动	文件数
#394	修 Frontend CI 随机红的断言	1
#392	无冻结流水的开放任务也拿到终态	2
#396	逐帧站位读数	2
#403	两个抠图模型 alpha 取并集	2
#387	main 过 CI 后自动发 Release	1

相互纠缠，需要定序（4 条）

组合	共享文件
#321 ↔ #322	ports/__init__.py、executor.py、model.py
#321 ↔ #324	同上，加 slicing/__init__.py
#322 ↔ #324	同上，加 task_repo.py
#321 ↔ #390	web/api/generation.py、test_generation_api.py

建议顺序

1. test(account-panel): 冷却断言改判是否进入冷却而非剩余秒数 #394 —— 排第一位的理由与它本身的改动量无关：近 30 小时里四条分支（分属三个人）都被 Frontend CI 在同一行随机打红，它一合，其余所有人的 PR 就不再被这条抖动挡住。
2. fix(orchestrator): 让没有冻结流水的开放任务也拿到终态 #392 → fix(matte): 两个显著性模型的 alpha 取并集补对方漏检 #403 → feat(postprocess): 按脚线与本体中心挑出站位偏离全序列的帧 #396 → ci: main 通过 CI 后自动发 Release #387 —— 五条独立里剩下的四条，顺序随意。fix(orchestrator): 让没有冻结流水的开放任务也拿到终态 #392 与 fix(matte): 两个显著性模型的 alpha 取并集补对方漏检 #403 各对应一个有线上证据的用户可见缺陷，建议排在前面。
3. fix(generation): 把缺母版与空动作描述拦在提交之前 #390 → feat(prompt): 用户描述先过措辞门禁与适配器 #321 → feat(quality-ledger): 生成成色与提示词版本落库 #322 → feat(judge): 增加只判可数四问的判官与 shadow 闸口 #324 —— 纠缠那组。fix(generation): 把缺母版与空动作描述拦在提交之前 #390 只与 feat(prompt): 用户描述先过措辞门禁与适配器 #321 重叠且是线上失败对应的修复，先合它代价最小；随后三条按开启时间排。

第 3 组每合一条，其余几条由提交者跟着 rebase 并重跑三道门（ruff check .、export_openapi 无漂移、lint-imports），不需要评审重复确认。

不包含

• 合并权限本身：这份顺序只是为了让持有权限的人不必自己推依赖关系
• 第 3 组的拆分或合并：四条各自关联独立 Issue，改动范围与 Issue 一致

验收

• 九条按上述顺序合入 main 后无冲突残留
• 合并过程中 Frontend CI 不再出现验证码冷却那一行的随机失败