プロトコルSDKのメジャー更新では、依存パッケージや型・APIを新世代へ移しただけで、新しいwire revisionが有効になるとは限らない。互換性維持のため、通常のServerやClient生成は旧revisionを既定にし、新revisionは専用HTTP entry、version negotiation、明示的なopt-inで初めて選ばれる設計がある。型検査とビルドが通っても、通信は旧handshakeのままという偽greenが起こりうる。

移行計画では「SDK surfaceの更新」と「wire protocolの採用」を別契約として読む。migration guideで、server entry、client negotiation、legacy fallback、per-era codecの切替点を確認し、既存transportを新packageへ差し替えるだけで十分かを一次情報で判断する。互換fallbackを残す場合は、同一endpointで新旧のどちらが選ばれたかを観測できるようにする。

検証は少なくとも二方向に分ける。新revisionをpinしたclientが接続し、negotiated eraまたはraw wireで新handshake・必須header・新response fieldを確認する。一方でlegacy modeのclientも同じendpointへ接続し、旧response shapeへ新revision固有fieldが漏れないことを確認する。自動fallbackだけのテストは、新entryが未実装でも旧revisionへ退避してgreenになるため、移行完了のoracleには使わない。