Compare commits
2 Commits
f434126c96
...
074117869e
| Author | SHA1 | Date | |
|---|---|---|---|
| 074117869e | |||
| edcdc83a0e |
12
AGENTS.md
12
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.
|
||||
- Sprawdź `git diff --check` oraz `git status`. Nie commituj wygenerowanego churnu w `next-env.d.ts`.
|
||||
- Po każdej zmianie rób commit i używaj formatu Conventional Commits, np. `fix: correct warning filtering`.
|
||||
- Dobieraj lokalną weryfikację proporcjonalnie do ryzyka zmiany. CI w Gitea Actions jest ostateczną bramką jakości po pushu.
|
||||
- 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`.
|
||||
- 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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -98,7 +98,7 @@ export function DayForecastModal({
|
||||
role="dialog"
|
||||
aria-modal="true"
|
||||
aria-labelledby="day-forecast-title"
|
||||
className="h-full max-h-full w-full overflow-hidden bg-background shadow-card sm:max-w-6xl sm:rounded-panel sm:border sm:border-border/70"
|
||||
className="h-full max-h-full w-full overflow-hidden rounded-panel border border-border/70 bg-background shadow-card sm:max-w-6xl"
|
||||
initial={{ opacity: 0, y: 28, scale: 0.985 }}
|
||||
animate={{ opacity: 1, y: 0, scale: 1 }}
|
||||
exit={{ opacity: 0, y: 20, scale: 0.99 }}
|
||||
|
||||
@@ -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
|
||||
npm run lint
|
||||
npm run typecheck
|
||||
npm run build
|
||||
```
|
||||
- dokumentacja, teksty i komentarze: przegląd diffu oraz opcjonalnie `git diff --check`,
|
||||
- drobne zmiany wizualne: bez rutynowego builda; `npm run lint` tylko przy ryzyku błędu składni lub reguł lintingu,
|
||||
- zmiany w logice, hookach, typach, parserach i danych pogodowych: `npm run typecheck`, a dla TS/TSX także `npm run lint`,
|
||||
- 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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user