用途：在兼容性与回滚控制下，系统化迁移 Salesforce 的 API 版本、季节性发布、CLI、客户端库、元数据、事件与集成契约，用完整清单、兼容矩阵、分阶段验证、明确归属和可逆的消费方迁移替代固定版本的猜测。
主要能力：盘点仓库与组织中所有显式及库默认的 API 版本、CLI 与库版本、端点、schema 快照、事件客户端与元数据消费方；重新拉取 API EOL 表、发布说明、客户端库发布、CLI 契约与组织升级计划；把每个依赖分类为受支持、已弃用、已退役、预览、测试版或客户特定，并指定负责人；为响应、错误、分页、元数据、事件 schema、限制与部分失败构建兼容性 fixture；每次只升级一个边界，运行静态、单元、契约、沙箱与部署检查；对代表性读取和已批准的非生产写入做金丝雀验证，再按可逆批次迁移消费方；最后对账，待所有消费方与回滚窗口关闭后才移除旧版本，并安排下次评审。
使用方式：使用 Read、Glob、Grep 检查已批准的仓库与证据文件，用 WebFetch 复查 Salesforce 一方文档，仅用 Write 或 Edit 输出无密钥的计划、fixture、配置和脱敏凭据；兼容性测试沿用既有已批准的应用与主体契约，不添加密码回退、不把生产令牌复制到测试环境，也不为弥补升级缺陷而扩大权限。
限制与边界：变更 API 版本、依赖、组织设置、元数据、事件消费方或生产流量前，需获得代码、平台、安全与业务负责人批准。请求的 API 版本已退役时应停止请求，经契约测试后迁移到受支持版本，不要重试已退役 URI；库默认与配置版本不一致时，在原始请求边界固定并测试有效版本；季节性发布改变组织行为时应暂停发布，在预览或沙箱路径复现并更新兼容性决策。据资料，版本 21.0 至 30.0 当前不可用，但每次迁移前必须重新拉取最新支持表。输出为版本清单、权威证据、兼容矩阵、契约变更、测试结果、批次计划、回滚点与退役日期。