docs: update agent verification rules

AGENTS.md

@@ -102,9 +102,15 @@ Przy zmianach UI:
 - Utrzymuj mały zakres zmian. Nie refaktoruj niezwiązanych modułów i nie cofaj cudzych zmian.
 - Nie dodawaj mocków jako źródła danych pogodowych. Przy zmianie źródeł API zaktualizuj route handler, typy, normalizację, UI i README.
 - Przy zmianach PWA sprawdź spójność `public/manifest.json`, `public/sw.js` i rejestracji service workera.
-- Przed zakończeniem uruchom co najmniej `npm run lint` i `npm run build`. Jeśli dodano testy, uruchom także ich skrypt.
+- Dobieraj lokalną weryfikację proporcjonalnie do ryzyka zmiany. CI w Gitea Actions jest ostateczną bramką jakości po pushu.
-- Sprawdź `git diff --check` oraz `git status`. Nie commituj wygenerowanego churnu w `next-env.d.ts`.
+- Zmiany w README, docs, tekstach i komentarzach: nie uruchamiaj `npm run lint`, `npm run typecheck` ani `npm run build`; wystarczy `git diff` i ewentualnie `git diff --check`.
-- Po każdej zmianie rób commit i używaj formatu Conventional Commits, np. `fix: correct warning filtering`.
+- Małe zmiany wizualne, np. klasy Tailwind, border, radius, spacing, kolory albo copy w JSX: nie uruchamiaj rutynowo `npm run build`. Uruchom `npm run lint` tylko, gdy zmiana mogła naruszyć składnię albo reguły lintingu, a `npm run typecheck` tylko przy zmianach typów, propsów lub logiki.
+- Zmiany w komponentach z logiką, hookach, typach, parserach i danych pogodowych: uruchom `npm run typecheck`; dodaj `npm run lint`, jeśli zmiana dotyka kodu TS/TSX.
+- Zmiany wysokiego ryzyka, np. Next routing, config, dependencies, `package-lock`, PWA/service worker, API/server code, build config i obsługa env: uruchom pełny zestaw `npm run lint`, `npm run typecheck` i `npm run build`.
+- Przed większym pushem albo większym refaktorem możesz uruchomić pełną weryfikację.
+- Sprawdź `git status` przed zakończeniem. Używaj `git diff --check` wtedy, gdy zmiana mogła wprowadzić problemy whitespace. Nie commituj wygenerowanego churnu w `next-env.d.ts`.
+- Commituj zakończone zmiany w formacie Conventional Commits, np. `fix: correct warning filtering`, ale nie używaj eskalacji dla `git commit` bez realnej potrzeby.
+- Nie pushuj automatycznie, chyba że użytkownik wyraźnie o to poprosi. Jeśli push wymaga autoryzacji, zatrzymaj się i poproś użytkownika o wykonanie `git push origin main`.
 - Ważne decyzje o źródłach danych, ograniczeniach API, uruchamianiu i wdrożeniu dokumentuj krótko w `README.md`.
 
 ## Utrzymywanie pliku

README.md

@@ -84,6 +84,8 @@ Pipeline działa na `ubuntu-latest`, instaluje zależności przez `npm ci`, a na
 
 Na instancji Gitea musi być włączony Actions runner kompatybilny z etykietą `ubuntu-latest`.
 
+CI jest ostateczną bramką jakości po pushu. Lokalnie dobieraj komendy proporcjonalnie do ryzyka zmiany: dokumentacja zwykle wymaga tylko przeglądu diffu, drobne zmiany UI nie wymagają rutynowego builda, a pełny zestaw `lint`, `typecheck` i `build` zostaw dla zmian wysokiego ryzyka.
+
 ## Struktura Projektu
 
 ```text

docs/deployment.md

@@ -72,13 +72,12 @@ Do zwykłego uruchomienia aplikacji pogodowej zmienne Web Push nie są wymagane.
 
 ## Jakość
 
-Przed zakończeniem zmian uruchamiaj:
+Repozytorium używa Gitea Actions jako końcowej bramki jakości po pushu. Lokalna weryfikacja powinna być proporcjonalna do ryzyka zmiany:
 
-```bash
+- dokumentacja, teksty i komentarze: przegląd diffu oraz opcjonalnie `git diff --check`,
-npm run lint
+- drobne zmiany wizualne: bez rutynowego builda; `npm run lint` tylko przy ryzyku błędu składni lub reguł lintingu,
-npm run typecheck
+- zmiany w logice, hookach, typach, parserach i danych pogodowych: `npm run typecheck`, a dla TS/TSX także `npm run lint`,
-npm run build
+- routing Next.js, config, zależności, `package-lock`, PWA/service worker, API/server code, build config i obsługa env: `npm run lint`, `npm run typecheck` oraz `npm run build`.
-```
 
 Repozytorium nie ma obecnie skryptu testów ani formattera.