主画布与分集画布的引用继承和状态同步

以下对象字段、状态名和代码是同类短剧系统的设计示例，供工程评估使用，不代表嘟哩已公开的接口或内部数据库结构。嘟哩的产品流程以当前手册和实际版本为准。
多集项目中常见一种隐性故障：主角服装改过，但有两集仍引用旧图；项目成员为了赶进度在分集画布复制了一份主体，后来主画布更新也无法同步。问题不在分集数量，而在引用关系不清楚。
嘟哩短剧通过主画布保存全剧剧本和公共主体，通过分集画布推进单集制作。工程模型应把共享资产当引用，而不是把整份内容复制到每集。

嘟哩剧本分集卡片与画布入口
对象 关键字段 约束
Episode episode_id, sequence, script_revision 项目内序号唯一
Canvas scope, episode_id, project_id main 或 episode
AssetRef asset_id, revision, usage_scope 指向确定版本
Binding shot_id, asset_ref_id, role 镜头明确绑定角色/场景/道具

当主体新版本产生，系统不应静默将全部分集切到最新版本。可以计算受影响引用，标记 needs_review，由负责人选择当前集是否升级。分集拆分失败时保留总剧本，重复请求要通过幂等键避免产生重复集。
状态可从 draft -> split -> reviewed -> canvas_created -> producing 推进。错误状态应说明是剧本解析、画布创建还是资产绑定失败。
第一版先做显式版本引用、影响提示和单集状态；复杂的自动版本合并可以后续扩展。剧情断点和资产变化的业务含义必须由编剧确认。
上游更新与下游状态
主画布资产发布新版本后，不应静默替换所有分集。可以计算受影响的 AssetRef，将相关镜头标记 needs_review，由负责人选择保留旧版或创建新候选。仅修改显示名时，也应避免误判为视觉变化。
分集拆分失败应保留总剧本和已成功创建的分集。创建接口使用幂等键，重复点击不能产生两份同序号画布。删除分集先归档，再检查剪辑工程和媒体引用后清理。
回归用例覆盖增删分集、调整顺序、主资产升级、单集剧本修订和权限撤回。第一版先做到引用明确、旧版可恢复、受影响范围可见，不必马上做完整依赖图。
删除、归档和版本升级
分集删除要区分列表移除、项目归档和物理清理。生成视频可能已被剪辑工程引用，直接级联删除会破坏历史复现。建议先归档并禁止新任务引用，检查依赖后再按企业保留策略清理媒体。因授权到期而禁用时，则拒绝新访问并保留必要的审计信息。
主资产升级建议采用显式传播。系统列出引用该资产的分集和镜头，由负责人选择哪些集迁移；低风险标签修改可自动同步，角色外观变化应人工确认。旧版本继续供历史成片使用。
回归用例覆盖增删分集、顺序调整、主资产升级、单集剧本修订和权限撤回。第一版不必构建完整影响图，但要让引用明确、旧版可恢复、受影响范围可见。
重排分集时，不重写内容身份
Episode 的稳定 ID 与显示序号分开。新增一集序章后，原第一集可以显示为第二集，但 canvas_id、镜头 ID 和生成媒体不应全部跟着更名。对外展示可以调整，引用身份保持稳定，才能追溯之前的审稿和剪辑。
一个建议的绑定实例是：
{"episode_id":"ep_amber","display_order":2,"canvas_id":"cv_amber","script_ref":"script@r4","subject_refs":[{"subject_id":"hero","revision":2,"variant":"raincoat"}]}
角色换装，要更新哪一级
第三集改夜行装，变化应落在该集选用的变体。基础主体的脸部身份可以继续沿用；若导演决定全剧改人设，则新增公共主体版本，再选择迁移范围。不要用一个 latest 指针同时表达这两种操作。
仅记录“素材已更新”也不够。可用变更原因区分 display_only、visual_change、permission_change。标签改名通常不影响已生成画面，视觉变化需要内容复核，权限撤回则应立即阻止新的读取。三者不能共用一条自动重跑策略。
一个可落地的传播策略
第一版可以维护资产到分集的引用表，用查询列出受影响集数，由制片选择检查。无需先实现复杂图数据库。若某集已锁定交付，保留旧版引用并注明新资产版本存在，不把它自动改回待制作。
回归时，创建三集并让第三集使用换装资产，之后重排集数、改角色显示名、升级基础外形。分别检查稳定身份、视觉引用与权限校验。嘟哩主画布和分集画布给出了共享与单集制作的产品结构；如何传播变更，仍要通过当前版本验证。