この章の答え
昔の再現手順・原因仮説・現在守るべき条件を切り離して評価する。
Issue に詳しい分析があっても、時間が経てば実装は変わります。同じ症状が残っているか、原因だけ変わったか、再現条件が成立しなくなったかを、現在の状態遷移から判断します。
01|図でつかむ
名前が消えたことだけで、問題が解決したとは言えない。
02|3つのポイントで理解する
1. 古い手順をそのまま実行する前に読む
対象バージョン、必要な状態、失敗する操作を抽出します。存在しなくなったコマンドや処理名があれば、現在の操作へ対応付ける必要があります。
2. 変わらず守りたい条件を決める
例えば「送信可能な待機入力が、回復後に取り残されない」という条件は、関数名が変わっても意味があります。これを invariant として現在の経路を読み直します。
3. 結論を証拠に合わせる
再現した、手順の前提が成立しない、別の原因候補がある、まだ確認できない、を分けます。再現しなかった一回だけで、あらゆる経路が直ったとは結論しません。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "on_task_complete|maybe_send_next_queued_input" codex-rs
読む入口: codex-rs/tui/src/chatwidget/turn_runtime.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
古い Issue の説明から関数名を外し、利用者が観察できる症状と期待だけで二文にまとめます。
04|30秒で復習
- 症状と古い原因仮説を分ける。
- 現在の状態遷移で条件を確認する。
- 再現結果に見合う結論を出す。