用途：针对 Procore 中某个具体资源与操作做端点契约切换。资料明确说明 Procore 没有统一的整包版本升级，因此不能在没有端点级文档的情况下声称通用 v1 到 v1.1 升级。
前提条件：已弃用的路由、方法、版本或负载格式及其有文档记录的替代方案；覆盖所有已部署调用方的 API Call Activity Report 切片；新旧响应契约、测试夹具、发布负责人与移除截止时间。
主要步骤：一是用生产活动与全量搜索（服务、定时任务、事件处理器、共享适配器）证明受影响流量；二是对比路径、请求头、ID、查询参数、请求与响应字段、分页、权限、状态码、Webhook schema 与生命周期阶段；三是把新契约隔离在资源专属接口后构建兼容适配器，只归一化业务层真正需要的字段并保留供应商错误与元数据；四是并排验证，读操作比对脱敏结果集与状态哈希，写操作使用沙箱夹具或供应商支持的幂等策略，不重复真实变更；五是按队列灰度，监控错误与速率信号，保留明确回滚边界；六是在流量证据归零且观察期结束后移除兼容代码、夹具、配置与文档。
鉴权：新旧契约都使用既定的 OAuth 2.0 主体与公司边界，迁移不得扩大 DMSA 权限或更换授权类型，除非单独评审该安全变更。工具纪律：用 Read 与 Grep 检查变更日志、活动报告、适配器和调用方；仅对获批的适配器、迁移测试、发布配置或回执使用 Write 或 Edit，不执行重复的实时写入。
输出：供应商证据与完整调用方清单、契约差异、兼容适配器与等价性测试、灰度、回滚、零流量与移除回执，并返回确切的新旧契约、受影响量、语义差异、发布状态与删除证据。
错误处理：替代方案无文档时停止并联系 Procore API 支持，不要猜测私有路由；读取结果出现差异时逐项分类，等待确认后再切换；新契约需要更多权限时单独审查清单变更并重跑负权限测试；旧流量仍在时继续查找剩余调用方，不要删除兼容代码。