コンパイル、通信形式、実行時の意味を別々に比べて互換性を判断する。
Rust の型が変わっても JSON は同じかもしれません。逆に JSON が読めても、操作の意味が変わればクライアントは壊れます。互換性は一つのチェックで済ませず、三つの層で見る必要があります。
01|図でつかむ
Source・Wire・Semantic の三つを別々に検証する。
02|3つのポイントで理解する
1. Source compatibility を見る
呼び出し側が再コンパイルできるか、型名やフィールドの変更がどこへ影響するかを調べます。内部リネームだけなら通信上の名前が維持される場合もあります。
2. Wire compatibility を見る
serde や型生成の設定から、実際の JSON 名・必須項目・null の扱いを確認します。Rust の before_turn_id が camelCase の beforeTurnId として流れる、といった変換も対象です。
3. Semantic compatibility を見る
同じ JSON でも、対象 turn を含めるか除外するか、返答時点で何が完了しているかが変われば、利用側の期待が壊れます。schema の差分に出ない意味もテストで確認します。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "before_turn_id|rename_all" codex-rs
# schema の生成差分も確認する場合
just write-app-server-schema
just test -p codex-app-server-protocol
テスト用ツールはリポジトリの手順に従って用意します。ここに載せたコマンドは学習用で、この編集作業で Codex 本体のテストを実行したという記録ではありません。
読む入口: codex-rs/app-server-protocol/src/protocol/v2/thread.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
一つの API フィールドを選び、Rust 名、JSON 名、実行時の意味を三列で書きます。
04|30秒で復習
- 型の互換性と通信の互換性を分ける。
- serde と生成 schema の変換を確認する。
- 同じ形式でも意味が変われば影響がある。