卡池装配

官方卡池来源

assemble_catalog 接收 CatalogSources，按固定顺序装配：

1. 主卡面；
2. 补充/历史卡面；
3. 仅生成 token；
4. Veteran 卡面；
5. 可选标签与兵种；
6. 一组具名效果源；
7. 运行时系统总部。

系统总部使用保留 ID __system_hq__，只作为规则对局中的总部哨兵，不可构筑。业务数据 若占用该 ID，装配立即失败。

严格失败

装配过程会检查：

• JSON 与枚举形状；
• 重复 card_id 和卡面索引；
• 效果源是否引用未知卡；
• Script 是否注册、参数是否匹配；
• DSL 是否能被当前主管线完整执行；
• can_create 是否形成闭合引用；
• 标签、兵种和效果数据是否能严格合并。

生产装配不会调用 sanitizer 修改返回卡池。可执行性探针只在私有副本上检查；只要发现 需要清除的槽，整个装配返回 UnsupportedEffects。

装配报告

成功时 CatalogReport 包含：

字段	含义
playable_and_generated_cards	业务卡面总数，不含系统总部
runtime_cards	运行时卡面总数，含系统总部
effect_entries	已严格合并的效果条目数
effect_sources	效果文档数
fingerprint	最终不可变卡池的稳定指纹

快照、回放和 DIY Pack 合并都以最终卡池指纹为兼容门槛。卡池内容或稳定顺序改变后， 旧产物会以 CatalogMismatch 拒绝，而不是按错误的 DefId 继续运行。

I/O 在调用方

测试辅助代码可读取仓库文件，但这是调用方职责。库接口只接收 &str，因此同一装配 逻辑既可用于嵌入资源，也可用于由宿主程序取得的数据，而不会把来源渠道写进规则层。