From 502ffee31f4085797416f8a20b6c44c7ef58df55 Mon Sep 17 00:00:00 2001 From: rasm-its Date: Wed, 26 Aug 2026 13:53:41 +0200 Subject: [PATCH] i18n: NEXT_LOCALE cookie; graph: sender display name from panel --- docs/PLAYBOOK.md | 21 ++++++++++++++++++--- docs/forms.md | 25 +++++++++++++++++++++++++ docs/getting-started.md | 3 +++ 3 files changed, 46 insertions(+), 3 deletions(-) diff --git a/docs/PLAYBOOK.md b/docs/PLAYBOOK.md index dfe9e5d..c1fa182 100644 --- a/docs/PLAYBOOK.md +++ b/docs/PLAYBOOK.md @@ -4,12 +4,13 @@ Sztywna procedura dla pracownika albo AI (Antigravity). Mówi CO robić, W JAKIE KOLEJNOŚCI, i CZYM SIĘ KIEROWAĆ. Zasady są twarde, przykłady realne — wzięte z faktycznych błędów, które się zdarzyły. Odstępstwa tylko za świadomą decyzją. -Powiązane: [publishing.md](./publishing.md) (cykl publikacji), [getting-started.md](./getting-started.md) +Powiązane: [standardy-kodu.md](./standardy-kodu.md) (dobre praktyki senior), +[publishing.md](./publishing.md) (cykl publikacji), [getting-started.md](./getting-started.md) (nowy projekt), ../ANTIGRAVITY-ZASADY-AGENT.md (zasady dla AI). --- -## ZŁOTE ZASADY +## ZŁOTE ZASADY (łam tylko świadomie) 1. **Nic na sztywno.** Tekst, obraz, link, dane firmy → panel/baza, nie kod. 2. **Logika w pluginie, projekt podłącza.** Jeśli piszesz w projekcie coś, co @@ -18,6 +19,8 @@ Powiązane: [publishing.md](./publishing.md) (cykl publikacji), [getting-started 4. **Weryfikuj każdy etap grepem.** Nie zakładaj, że zadziałało. Sprawdź. 5. **Napraw u źródła, nie łataj.** Bez `as any`, `@ts-ignore`, kopii logiki. 6. **Zmiana w pluginie nie działa, dopóki nie: build → publish → wciągnięcie.** +7. **Zmieniłeś API → zaktualizuj docs w tym samym commicie.** Docs jadą w + pakiecie; rozjazd kod↔docs = agent dostaje złą mapę. --- @@ -39,6 +42,11 @@ cd ~/payload-cms/ipal-kit # 1. ŹRÓDŁA — nanieś zmianę, ZWERYFIKUJ że jest grep -c "" src/<ścieżka> # MUSI być >0 +# 1b. DOCS — jeśli zmiana dotyka API/zachowania, ZAKTUALIZUJ docs/ +# (nowa funkcja, zmiana sygnatury, nowe pole panelu, nowy adapter...). +# Docs jadą w pakiecie (files: dist, docs) — nieaktualne docs = agent +# dostaje złą mapę. Kod i docs publikuj RAZEM. + # 2. BUILD — zbuduj, ZWERYFIKUJ że dist ma zmianę pnpm build grep -c "" dist/<ścieżka> # MUSI być >0 @@ -83,6 +91,9 @@ pokazał 0. Naprawa: dodać eksport, przejść łańcuch od nowa. publish, grep dist po buildzie. - **`pnpm add` przy działającym dev** → proces ma stary adapter w pamięci. Payload czyta email/config przy starcie. ZAWSZE restart po wciągnięciu. +- **Publikacja bez aktualizacji docs** → agent (Antigravity) po `pnpm add` + czyta `node_modules/@intecion/ipal-kit/docs/` z NIEAKTUALNĄ mapą. Jeśli + zmieniłeś API — docs w tym samym commicie. --- @@ -236,4 +247,8 @@ Nie mów „działa", dopóki: - [ ] brak dubletu @payloadcms/ui (Część D) - [ ] grep potwierdza wersję pluginu w node_modules - [ ] sekrety w .env (nie w repo), maskowane w panelu -- [ ] brak plików middleware.ts, brak zaszytej mapy slugów \ No newline at end of file +- [ ] brak plików middleware.ts, brak zaszytej mapy slugów +- [ ] strona 404 (not-found.tsx) — edytowalna, per język, link powrotu +- [ ] formularze z buildera w panelu (NIE własne hardkodowane) +- [ ] compliance: polityki, baner cookies, zgoda RODO w formularzach + (patrz [wymagania-prawne.md](./wymagania-prawne.md)) \ No newline at end of file diff --git a/docs/forms.md b/docs/forms.md index c1a5058..5b9a28c 100644 --- a/docs/forms.md +++ b/docs/forms.md @@ -4,6 +4,31 @@ Wpina `@payloadcms/plugin-form-builder` (kolekcje forms + form-submissions) i dostarcza `submitForm` — wywoływalną z frontu funkcję, która spina: weryfikację Turnstile → zapis zgłoszenia → wysyłkę maili (naszym senderem). +## ⚠️ ZASADA: formularz POCHODZI z buildera w panelu (obowiązkowe) + +**Formularze buduje redaktor w panelu** (kolekcja Forms), NIE deweloper w kodzie. +To jest CMS — klient sam definiuje pola, etykiety, komunikaty, odbiorcę. Front +tylko RENDERUJE formularz z panelu i wysyła przez `submitForm`. + +**NIGDY nie twórz własnego, hardkodowanego formularza** — z ręcznie wpisanymi +polami, etykietami w JSX, własną walidacją. To łamie „nic na sztywno" (klient nie +zmieni pól ani tekstów) i omija cały mechanizm pluginu (Turnstile, rate-limit, +consent RODO, powiadomienia). + +| ŹLE (własny formularz) | DOBRZE (builder pluginu) | +|---|---| +| `` w JSX | pola z kolekcji Forms (panel) | +| etykiety/komunikaty w kodzie | etykiety per język w panelu | +| własna walidacja/wysyłka | `submitForm` (Turnstile+consent+mail) | +| klient nie zmieni formularza | klient edytuje pola w panelu | + +**Jak poprawnie:** redaktor tworzy formularz w kolekcji Forms → front pobiera +jego definicję → renderuje pola dynamicznie → wysyła przez `submitForm`. Pola, +etykiety, komunikaty, odbiorca — wszystko z panelu. + +Jeśli formularz wymaga pola, którego builder nie ma — dodaj je przez konfigurację +`fields` (patrz niżej) albo rozbuduj plugin. NIE hardkoduj własnego formularza. + ## Zależność ```json diff --git a/docs/getting-started.md b/docs/getting-started.md index aa7b553..823d7d0 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -172,6 +172,9 @@ export const blockRegistry: BlockComponentMap = { } ``` +> **Jak budować treść, żeby klient mógł wszystko edytować** (filozofia +> CMS, kolejność komponent→blok→strona): [architektura-tresci.md](./architektura-tresci.md). + **Puste `blocks: []` crashuje** (traverseFields) — zawsze co najmniej jeden blok. ### enhanceProps — wstrzykiwanie danych server-side do bloków