# 执行门槛与分批交付 本规范是 DOC-07 计划复审后的补充。完整范围继续覆盖全部 22 包，调整依赖以尽早得到真实反馈，不降低相关能力的兼容和发布要求。 ## 1. 最小启动基线 BASE-01 先固定核心和 chapter 试点的已发布 tarball、integrity、来源和支持窗口；全包清单先保留待验证项，其他包的发布证据在各自 01 契约任务中补齐。不能因一个无发布记录或外部资源缺失的包阻止安装测试工具。 BASE-02 至 BASE-05 的初始自动化集中于核心与试点。其余包不能借此声称已验证；每包开始迁移前仍须完成自身基线。BASE-08 建立消费者及环境矩阵，区分包分发格式与运行能力：legacy 语法可生成，不等于 WebCodecs、PiP、WebAudio 或模型运行时能在所有旧浏览器工作。 ## 2. 早期试点 chapter 的 03/04 步不再依赖重构后的设置面板与插件管理器，先以已有核心和公开契约完成包内整理及 TS 迁移。PILOT-01 必须走完旧核心消费者、真实浏览器、类型、tarball 和维护文档闭环，才开始 CORE-01。 试点不用新核心的内部方法，不为试点修改核心 API。由实际反馈确定其余任务的粒度、工具选择和测试成本；最终候选核心仍在 chapter 05/06 步重新验证。试点完成不等于 chapter 全部重构任务完成。 ## 3. 历史失败与测试可靠性 ENG-10 建立有来源、有任务归属的历史失败台账：区分旧版即存在的缺陷、第三方类型冲突、环境能力缺失和候选回归。 - 迁移模块使用严格类型检查；未迁移模块的历史类型问题单独列出，不能用全仓库 skipLibCheck/ts-nocheck 隐藏，也不能要求先修完所有插件才开始试点。 - 对未迁移部分可记录基线失败，但禁止新增同类失败；必须保存准确测试 ID、环境、旧版复现及负责修复任务。 - 受影响模块的旧缺陷必须明确处理结论，不能仅因进入台账就豁免发布。所有未关闭项在该包发布门槛再次审查。 - 不用 sleep 判断播放准备就绪；使用事件/状态条件、受控网络与时钟。记录失败 trace，有限重试用于判定偶发问题，不能把重试后绿灯等同无回归。 - 多实例、连续切源和事件顺序比较使用语义断言，避免比较浮动墙钟时间或把浏览器允许的事件差异误判为重构失败。 ## 4. 真实环境不会阻塞无关准备工作 包内类型和本地 adapter 测试可以先完成并独立提交。Cast、IMA、移动 Safari、PiP、模型、codec 等真实检查仍在对应集成任务中维护；缺环境时标 blocked，不能标 done。 SITE-04 是各包文档的最终交叉核对，包内文档仍随每次实现更新。文档静态构建和本地候选 tarball 准备不依赖 Cast 等设备验证完成。整个 demo 的 EX-03 和真实验证任务继续保留，不从完成定义中删除。 SITE-05 的本地构建、搜索、链接、编辑器与声明注入检查可独立于 SITE-07 的字体来源核实执行。 SITE-07 改为 SITE-06 文档站最终交付的直接前置；许可缺口仍阻止最终交付及下游发布。 这只调整执行顺序，不将本地功能通过当作字体授权、外部服务或发布准入通过。 BASE-08 的环境矩阵至少包含：包/能力、支持版本依据、样本与外部资源版本、自动化方法、真实设备/SDK 环境、报告位置、负责完成的任务、状态、阻塞及解除方式。尚未具备的设备记录为未知/待提供，不虚构执行者或通过结果。 ## 5. 发布按实际批次核定 每个实际发布批次还须满足 [三轮复盘](release-reviews.md) 的架构/兼容、真实环境和 npm 产物检查。全项目 REVIEW-01/02/03 保留完整范围；分批子任务遵守同等标准，未测能力不能通过。 REL-08 提前建立分包准入台账；REL-01 是版本和差异方案，REL-02 是本地候选内容与消费者验证。公开发布仍需后续授权。 每批冻结：包名与版本、源码提交、依赖锁/工具版本、构建配置、tarball integrity、支持组合、所需测试及真实环境证据、兼容例外、回退产物。测试的 tarball 必须就是准备发布的内容；源码、依赖或构建改变后，原证据失效并重跑受影响检查。 REL-03/05/06 作为全项目阶段汇总。若先交付一批已完成包，先拆出具有独立 ID、范围及验收条件的发布子任务，只依赖该批所需测试/文档/设备/消费者证据；全项目汇总保持未完成。不能为提前发布将未完成原任务改为 done 或删除依赖。 某个 Cast 插件缺设备不自动阻止独立工具包交付，但若核心更改影响 Cast 集成，这就是该核心批次的真实兼容缺口，仍需验证，不能按包名简单排除。 ## 6. 无障碍与用户自定义界面 BASE-04 增加键盘可达性、焦点返回、可访问名称、设置菜单交互及字幕的实际基线。CORE-23 在保留旧 DOM/CSS/热键契约的前提下检查并补齐这些能力，结构调整不能削弱原有键盘体验。新增行为造成兼容冲突时单独记录，不借此默认重做 UI。 ## 7. 任务粒度和证据 开始每项任务前确认它能形成一个可验收、可回退的提交。CORE-01、CORE-18 等横跨多个模块的任务必要时先拆出子任务；父任务作为汇总不能与子任务重复宣称实现。子任务使用当前校验器支持的 ID，如 CORE-UTIL-TIME-01，并更新下游依赖。 每次检查记录起点 SHA 和候选源码/产物的内容标识。完成提交包含状态及文档，提交 SHA 在提交后由 Git 日志核对，避免要求同一提交包含自身 SHA。当前 plan 校验器检查状态和证据文件存在，不能代替测试，也不自动证明每个 done 任务已有 commit；提交审计纳入 ENG-09。 汇报分别给出规划任务与实施任务完成情况。任务数量不是工作量百分比，不将文档完成数当作代码重构进度。 ## 8. 基线启动与覆盖映射（DOC-12 复审） BASE-03/04/06 的初始采集使用固定旧 tarball、现有 Node 测试和 docs 页面，以及随基线任务提交的最小探针/断言与运行步骤。按需安装工具仍已授权，但不提前重构生产源码。ENG-05/08 再将这些证据和用例接入正式服务及报告，不能反过来要求 BASE 等待依赖它的 ENG 完成，也不能让无法重跑的聊天记录充当基线。 BASE-05 对每包记录实际分发类别：播放器库/插件/proxy/工具使用对应产物验收；文档站使用站点构建、URL 和静态资源验收，是否另发 npm 按发布历史核实。22 包全部在重构和版本目标范围内，但不强行为没有历史库入口的站点包创造 UMD/ESM 消费 API。每个不适用项需依据及替代验收，不是跳过该包。 BASE-02 至 BASE-05 开始登记“契约编号/包/支持版本/场景 -> 固定测试 ID -> 执行命令/源码或候选标识/报告 -> 负责实施任务”。ENG-09 接入可检查的覆盖索引，明确哪些只是计划、哪些已执行、哪些缺证据。目录覆盖和测试数量不能代替契约覆盖。 SSR 区分 import 的环境安全、静态 html/useSSR 模板能力、浏览器挂载和非浏览器构造错误。当前核心 constructor 明确在非浏览器抛错，不能把“SSR 兼容”理解为允许在服务端 new 播放器；BASE-05/CORE-12/EX 消费分别比较旧行为。 ## 9. 复盘顺序与版本落实 DOC-12 发现 REVIEW-01 经 MOD-05 -> MOD-04 间接依赖 mask 设备验收。第一轮改为依赖 MOD-01/02/03 等可用的工具和核心性能结论；重型插件真实环境仍经 REL-03 -> REVIEW-02 保留。早期代码复盘可登记尚未验证的设备能力，不允许由此批准发布。 REL-09 是全包 major 版本准备的明确实施任务，位于 REL-01 方案之后、REL-02 候选构建之前。按需拆分版本准备子任务，每个完成任务独立提交；只改目标文档不能算版本已落地。既有各包分发验收仍有效，但最终发布必须重新验证完成版本修改后的候选。 ## 10. 何时继续补计划 现在固定兼容范围、任务依赖、任务/证据归属、版本和发布门槛。具体文件名、类型泛型、工具版本、拆分粒度、性能阈值及新复现缺陷在相关任务开始时根据源码和试点调整。不要为了补全假想细节无限增加规划任务，也不要将已知依赖冲突留到执行时碰运气。 扩展任务同时更新下游验收依赖和证据索引，保留旧 ID/历史事实。plan 校验器检查关键顺序（早期试点、首轮不依赖专项设备、最终发布依赖复盘/CI/版本准备）及实施任务到最终里程碑的可达性；这不能证明测试有效或代码无回归。 代码迁移完成后仍有 REVIEW 与发布准备；发布就绪后仍有实际授权发布步骤。未来长任务按用户指定终点执行，不能因 REL-05/06 尚未授权而冒充全项目发布完成，也不能擅自执行 publish 来清空任务表。