00 — Dekalog

Rdzeń doktryny. Jeśli przeczytasz tylko jeden plik z tego zestawu — niech to będzie ten. Każde przykazanie ma rozwinięcie w dalszych rozdziałach.

I. Dokumentuj dla agenta, nie dla archiwum.

Każdy katalog ma AI_README.md. Aktualizujesz go przed commitem, nie „kiedyś”. Dokumentacja, którą czyta się przed dotknięciem kodu, oszczędza godziny re-derywacji; dokumentacja dopisywana po fakcie („udokumentuję na końcu”) rozjeżdża się z kodem i zaczyna kłamać — bo kontekst już wyparował, a „koniec” nie nadchodzi. → 01

II. Szukaj w historii, zanim napiszesz linijkę.

git log -S"symbol", git log --grep, git blame, AI_README katalogu. Większość „nowych” problemów ktoś już rozwiązał w tym repo — istnieje helper, była Migracja (bazy danych) — Kontrolowana zmiana układu bazy — dodanie kolumny, tabeli czy przeniesienie danych — krok po kroku. Jak remont według planu: przebudowa danych w ustalonej kolejności, żeby nic się nie „zawaliło”., jest powód, dla którego kod ma taki kształt. Re-derywacja jest droższa niż minuta szukania. → 05

III. Weryfikuj, nie deklaruj.

Nie piszesz „działa” — pokazujesz dowód: Smoke test — Szybki test „czy w ogóle działa” zaraz po wdrożeniu — sprawdza najważniejsze ścieżki (np. logowanie). Łapie katastrofy w 30 sekund, zanim zobaczy je użytkownik. Tani sposób na spokojny sen po deployu., kod HTTP, liczby, screenshot. Jeśli testy padają — mówisz to z outputem. Jeśli krok pominięto — mówisz, że pominięto. Zaufanie buduje się na uczciwym raporcie, nie na optymizmie. → 03

IV. Dry-run jest domyślny; `--execute` jest świadomy.

Każdy skrypt, który zmienia dane, najpierw pokazuje plan (co, ile, gdzie). Mutację odpalasz dopiero po przeczytaniu tego planu. Skrypt bez trybu próbnego to broń bez bezpiecznika. → 04

V. Backup to mechanizm rollbacku, nie ostrożność.

Migracje forward-only (bez down-migracji). Snapshot przed każdą zmianą schematu lub danych na prodzie. Cofnięcie schematu = przywrócenie backupu. Backup nie jest „na wszelki wypadek” — jest jedyną drogą powrotu. → 04

VI. Prod jest święty — nie dotykasz go bez wyraźnego „wdrażaj”.

Commit i push na życzenie to nie deploy. git pull na serwerze, pm2 reload, swap bazy, flaga maintenance — tylko gdy user powie wprost. Działania nieodwracalne i „na zewnątrz” (publikacja, wysyłka, kasowanie) potwierdzaj zawsze. Zgoda w jednym kontekście nie rozciąga się na następny. → 05

VII. Dane użytkownika są nienaruszalne.

Przy podmiance bazy: wylicz każdą tabelę z FK do użytkownika (konta, recenzje, koszyki, odznaki, gry, czat, sesje), mapuj user-dane po stabilnym kluczu (Slug — Czytelna, krótka część adresu strony, opisująca jej treść słowami zamiast tajemniczego numeru. Lepszy dla człowieka i SEO; trwały slug nie psuje linków przy zmianach.), nie po ID (ID dryfują po merge’ach), źródłem prawdy dla kont jest żywy prod, a po wszystkim sprawdź integrity_check i policz wiersze. → 05

VIII. Taguj każdy deploy i pisz, co user zyskał.

Annotated tag (deploy-RRRR-MM-DD) to jedyny stabilny znacznik „co jest live” i podstawa Rollback — Cofnięcie zmiany do poprzedniego, działającego stanu — „Ctrl+Z” dla wdrożenia. Gdy nowa wersja psuje produkcję, rollback przywraca poprzednią w sekundy zamiast naprawiać w panice.. Przy każdym deployu zaktualizuj publiczny changelog — prostym językiem, bez żargonu (żadnego „Scraping — Automatyczne zbieranie danych ze stron internetowych przez program zamiast ręcznego kopiowania. Potężne do pozyskiwania danych, ale wymaga kultury: szanuj cudze zasady (robots.txt), nie przeciążaj serwera./migracja/commit”; pisz, co użytkownik zyskuje). → 05

IX. Mały, spójny commit; jeden temat.

Rozdzielaj niezwiązane zmiany na osobne commity. Trzymaj git status czysty — śmieci (.bak, pliki tymczasowe, przypadkowe bazy) i sieroty (niezacommitowana praca w tle) wykrywaj wcześnie, zanim wmieszają się w deploy. Rozróżniaj realny diff od szumu CRLF. → 05

X. Plan → iteruj → review.

Najpierw pokaż plan albo szkic (3 przykłady, nie 100). Zbierz feedback. Dopiero potem skaluj. Liczby weryfikuj u źródła. UX dowieź z ciepłem w odbiorze, nie tylko poprawnością — produkt ma być przyjemny, nie tylko działający. → 06

Siedem grzechów głównych (czego NIE robić)

Nadęty optymizm w raporcie — „wszystko działa” bez dowodu. (łamie III)
Mutacja bez planu — odpalenie skryptu zmieniającego dane od razu z --execute. (łamie IV)
Auto-deploy — „skoro gotowe, to wrzucam na prod”. (łamie VI)
Swap bazy „prócz kont” potraktowany jako jedna tabela users — utrata recenzji/odznak/czatu, bo nie wyliczono wszystkich tabel FK. (łamie VII)
Commit-śmietnik — niezwiązane zmiany + artefakty w jednym commicie. (łamie IX)
Skalowanie przed review — wygenerowanie 500 sztuk, zanim user zobaczył 3. (łamie X)
Dokumentacja „później” — kod idzie, AI_README zostaje w tyle, następna sesja błądzi. (łamie I)

Złota zasada altytudy

Wolno tam, gdzie błąd jest drogi (prod, dane userów, schemat). Szybko tam, gdzie jest tani (lokalny eksperyment, szkic UI, Dry-run — Uruchomienie „na sucho” — skrypt pokazuje, co BY zrobił, ale niczego nie zmienia. Widzisz skutki przed wykonaniem; zmiana na danych idzie dopiero po świadomym potwierdzeniu.). Tempo dobieraj do kosztu pomyłki, nie do niecierpliwości.