安全升级 Pling
只有当应用仍能证明三件事时，升级才是安全的：页面声明了它打算暴露的能力，执行器用相同策略执行这些能力，旧客户端或持久状态不会被误解。安装包只是工作中最小的一部分。
改版本之前
记录当前包版本、Surface 协议版本、适配器、浏览器目标、Node 版本，以及持久化的连续性或委托格式。准备一个小基线：一个读取任务、一个写入任务、一次确认、一次失败和一次恢复任务。升级前先在当前构建上跑通它。
阅读所有变更包的发布说明，而不只是应用直接使用的适配器。更新 @plingjs/vue 可能通过 workspace 带入不同版本的 core、dom、agent 或 ui。部署应用应锁定完整包集合，并一起发布。
升级顺序
- 在分支中更新依赖。
- 运行声明、执行器、适配器与端到端测试。
- 用确定性回放尽可能重跑五项基线。
- 检查生成的能力定义，对比 id、输入 schema、风险等级与审批。
- 用旧持久检查点和委托会话测试新代码。
- 以较小能力集、较低轮数预算和明确停用开关做灰度。
- 将错误码、工具成功率、延迟与 token 用量和基线比较。
如果协议与包必须同时变化，先上线兼容的协议修订，并在迁移窗口内继续支持旧包。不要为了少发一个版本，静默改变既有能力的含义。
常见破坏点
最危险的变化不是编译错误，而是仍能编译的行为变化：动作在新规则下变得不可用，生成 id 改变，默认上限收紧，确认变成 always，快照字段被省略，或以前接受的输入现在无法通过 schema。
持久状态是第二个常见风险。旧版本检查点可能是合法 JSON，却与当前消息协议不兼容。应验证信封版本与页面身份，然后迁移或丢弃，而不是执行不确定状态。委托记录与审批回执同理：升级后无法 introspect 的 token 必须 fail-closed。
回滚
回滚不应依赖数据库重写。保留上一版服务端兼容构建，让助手入口可以远程停用，并让协议兼容期足够排空活跃会话。若新版本已经写入状态，要明确旧版本如何处理；最安全的答案通常是忽略，并要求用户重新开始任务。
验证清单
- 发布产物记录了包版本与协议版本。
- 能力 id 与 schema 经过对比，而不是凭假设。
- 确认与人工接力路径都实际走过。
- 旧检查点会迁移，或明确 fail-closed。
- 灰度可以在不发前端的情况下停用。
- 回滚路径已经演练，不只是写在文档里。