| name | deploy-check |
| description | データの欠損・古い値・期待と異なる表示など「データが正しく見えない」系の調査を始めるとき。クライアントコードに潜る前に、まず backend のデプロイ状態と、デプロイ環境側の構成（feature flag / config / 環境差分）を確認させる。ローカルの .env や secrets ファイルは読みに行かない。 |
Deploy Check
データ不整合系の調査で「いきなりクライアントコードを読み始める」失敗を防ぐためのトリアージ手順。
いつ使うか
以下のような症状を訴えられたとき:
- 期待した値が表示されない / 古い値のままになっている
- API レスポンスに欠けているフィールドがある
- 環境ごとに挙動が違う（staging では出る / prod では出ない 等）
- 直近の変更を取り込んだはずなのに反映されていない
手順
順番を守ること。1 → 2 で原因が特定できる場合が多く、3 まで進む前にクライアント側を疑わない。
1. Backend のデプロイ状態を確認
- 最新コミット (main / 当該リリースブランチ) が実環境にデプロイ済みか
- デプロイパイプラインの直近実行が成功で終わっているか
- ロールバック直後ではないか
2. デプロイ環境側の構成を確認
「デプロイ先の環境がどう構成されているか」を確認するフェーズ。ローカルの設定ファイルを読み込むのではない。
確認対象は以下のような デプロイ先側の情報源 に限る:
- デプロイコンソール / マネージドサービスの env 設定画面に表示されている値（プラットフォーム UI 上で）
- CI / CD ログに出力されている設定の出自・バージョン
- feature flag 管理画面の現在値
- 環境ごとの非機密 config 定義（リポジトリ内のコードとして管理されているもの）
確認すべきこと:
- 期待される値と実環境の設定が一致しているか（値そのものを読ませるのではなく、ユーザーに「期待値 vs 実環境」の差分を確認してもらう）
- feature flag / config が想定の状態か
- 環境ごとの差分が今回の症状を説明し得るか
やってはいけないこと
- ローカルの
.env / .env.* / secrets/* / credentials* 等を Read しに行く
- CI ログから API キー・トークン・パスワードを抜き出して文脈に取り込む
- 秘密情報を Claude のコンテキスト・出力・ファイルに混入させる
シークレット値が「正しく注入されているか」を確認したい場合は、値そのものを見るのではなく、「シークレットが set されているか / 期待された名前で参照されているか」だけ をユーザーに尋ねること。
3. ここでようやくクライアントコードを読む
1 / 2 で原因が見つからなかった場合のみ、フロントエンド / SDK / ローカルキャッシュ等の調査に進む。
