plugin-fleet-sweep

扫描 DSH 主机升级后的插件集群

主机升级会同时改变每个插件所依赖的契约。工作单位不是单个插件，而是整个集群：按固定顺序逐一扫描，每个插件给出一个结论，每个损坏的插件都走一轮发布流程。扫描必须在实际升级后的主机上进行——源代码和基于 Node 的测试通过，并不能证明浏览器引擎和运行时表面没有变化。

常规规则

1. 在目标主机上验证，而不是检查源代码。 当插件的客户端包已提供、CSS style[data-plugin] 标签存在，且没有任何 slot entry crashed / 激活失败记录时，才算插件“已加载”。只有当其界面标记出现在 DOM 中，且预期请求已发出时，才算插件“正常工作”。记录你已验证了哪一项。
2. 先低成本地进行一次静态扫描。 在打开浏览器之前，先对每个插件的源代码进行 grep，查找新主机重命名或移除的 API（见 plugin-upgrade/references/ 中目标版本对应的版本跨度卡片）。静态扫描命中即为结论：修复前视为损坏。
3. 没有错误并非有力证据。 如果界面需要交互触发（仅在粘贴、文件操作或焦点事件后出现），那么在空闲扫描中看不到任何内容。对于每个插件，都要明确其触发条件，并模拟触发，或者将结论标记为“已加载，未测试交互路径”，不要声称成功。
4. 按插件分别修复和发布，绝不能将整个集群合并为一次提交。 每个损坏的插件都要有自己的分支或主分支提交、版本升级、更新日志条目、标签和镜像推送（遵循各仓库自己的镜像流程；sync-mirrors.mjs 仅适用于作者的插件仓库——请使用目标仓库文档中说明的流程；如果没有镜像流程，则跳过）。将多个插件混在一次提交中，会导致无法逐个回滚。
5. 当插件必须兼容多个主机代际时，优先构建兼容版本，而不是锁定主机版本的版本：通过回退链（旧名称 → 新变体）在运行时解析已重命名的主机导出，而不是使用静态命名导入；并在单元测试的模块模拟中补充每个回退名称（严格模拟会在访问未定义的导出时抛出异常，从而掩盖实际故障）。

工作流

1. 阅读目标主机版本对应的版本跨度卡片（plugin-upgrade/references/v<target>.md），并据此推导静态扫描模式——卡片会指出已重命名或移除的表面。
2. 静态扫描：对集群中的每个仓库 grep 这些模式；将命中记录为修复前视为损坏，并注明文件:行号。
3. 实时扫描：使用受控的无头浏览器，在升级后的主机上加载真实 GUI，并逐个插件断言：(a) 客户端 CSS/样式标签存在；(b) 控制台中没有 slot entry crashed 记录；(c) 界面对应的 DOM 标记存在；(d) 预期请求已发出。操作方法见： references/fleet-sweep-checklist.md （其中包含 plugin-runtime-debug/references/browser-forensics.md 中关于通过身份验证访问 GUI 和遵循仪器化规范的内容）。
4. 通过模拟触发条件（粘贴、写入文件、键盘快捷键）重新验证需要交互触发的界面，或者明确降低结论等级。
5. 对每个损坏的插件：依据主机源代码进行诊断（遵循 plugin-runtime-debug 的常规规则）；如果集群跨越多个主机版本，则采用兼容多个主机代际的修复方案；运行该插件的类型检查、测试和构建，然后发布：升级版本、添加更新日志/兼容性表条目并注明主机版本范围、提交、打标签、推送镜像。
6. 发布后重新运行实时扫描，并记录最终的逐插件结论表（插件、支持的主机版本、证据）。

报告

最后附上按插件划分的表格：结论（正常运行／已修复并发布／未测试交互路径／已损坏）、覆盖的宿主版本，以及证据（在哪个位置通过了哪项断言）。注明发现的任何宿主错误（向上游报告，并提供最小复现），以及安装目录中的任何热修复（下次升级宿主时会被覆盖）——列出重新应用所需的材料。