j_kedzierski/prompts/00-przeglad-strategia-i-workflow.md

# Przegląd, strategia i workflow — poprawa strony j_kedzierski

**Klient:** Dipl.-Ing. Janusz Kędzierski, Finanz- & Lohnbuchhaltung — Beratungsstelle
b.b.h. Lohnsteuerhilfeverein e.V. (§4 Nr. 11 StBerG)
**Cel biznesowy:** wizytówka + pozyskiwanie klientów (Polacy pracujący w Niemczech,
rozliczenie po polsku) — nie e-commerce, nie SaaS. Konwersja = kontakt na WhatsApp.
**Stack:** Payload CMS 3 + Next.js 16.3.3 + React 19 + Tailwind 4 + Framer Motion +
`@intecion/ipal-kit`. Repo: `j_kedzierski` (folder `kedzierski_website` na Macu).

Ten plik spina wszystkie pozostałe. Przeczytaj go pierwszy — reszta plików zakłada,
że decyzje z sekcji 2 i 4 są już podjęte.

---

## 1. Co faktycznie jest w zipie (audyt, nie domysły)

Rozpakowałem `j_kedzierski.zip` i przeczytałem `scripts/content-snapshot.json`
(pełny zrzut wszystkich 10 stron PL+DE + globali) zamiast zakładać stan projektu.
Stan faktyczny:

### 1.1 Co jest zrobione dobrze (Antigravity, faza „kod i logika")
- Payload 3 + Next 16 + ipal-kit poprawnie zszyte: i18n PL/DE, `proxy.ts` (nie
  middleware), kolekcje `Pages`/`Media`/`Users`, globale `Header`/`Footer`/`Company`
  + `site-settings` z pluginu.
- **17 bloków** już zbudowanych i podłączonych do `RenderBlocks`: Hero, TrustBar,
  UniqueValue, Stats, ServicesList, Process, Affiliation, Testimonials, FAQTeaser,
  FinalCTA, PageHeader, ServicesDetailed, Eligibility, ContactInfo, Bio, Team,
  TextSection.
- Hero ma już realną robotę: Framer Motion stagger na tekst, 3D-parallax na
  zdjęcie (`useParallax3D`, pointer-tracked rotateX/rotateY), floating stat card.
  To nie jest szkielet — to działający, dopracowany komponent.
- Motyw jasny/ciemny (`next-themes`, `data-theme`) działa, przełącznik jest.
- **Design tokeny już wybrane i wdrożone** w `globals.css` (Tailwind 4 `@theme`):
  ciepłe tło papieru `#F7F5F1`, atrament `#1C1B1A`, akcent pieczęć-czerwień
  `#A13D2C` (hover `#8A3324`), karta biała, border `#E2DDD3`, radius przycisku 6px
  (nie „pill"). Ciemny motyw: tło `#17140F`, akcent `#D4634A`. Fonty: **Fraunces**
  (nagłówki, serif) + **Public Sans** (body).
- Treść tekstowa homepage, usług, procesu i „o nas" jest już napisana — dobrej
  jakości, konkretna, PL i DE, nie jest to placeholder AI-lorem.

### 1.2 Realne braki (to jest do zrobienia, nie do zgadywania)
| Obszar | Stan faktyczny w zipie |
|---|---|
| Zdjęcia | Każdy blok ma `"image": 1` — czyli wskazuje na media ID 1, ale w paczce **nie ma żadnego pliku graficznego**. Zero zdjęć, zero logo, zero favicon. |
| Dane firmy | `address: "DO POTWIERDZENIA PRZEZ KLIENTA"`, `phone: "+49 123 456 789"`, `email: "[email protected]"`, `whatsappNumber: "49123456789"` — wszystko placeholder. |
| Strony prawne | Impressum, Polityka prywatności, Polityka cookies, Stowarzyszenie: treść = `"Treść w przygotowaniu"` / `"Inhalt in Vorbereitung"`. Puste. |
| FAQ (strona) | Też `TextSection` placeholder — mimo że homepage ma już `faqTeaser` z 8 pytaniami. Brak pełnej listy/kategoryzacji. |
| System Pages | `privacyPolicy`, `cookiePolicy`, `termsOfService` w `site-settings` = `null`. Role nieprzypisane → `getSystemPagePath` nie zadziała, linki w stopce/bannerze cookies będą martwe. |
| Baner cookies | Brak w kodzie `ConsentProvider`/`CookieBanner` w przejrzanych plikach — do potwierdzenia przy realizacji, patrz [11](./11-integracje-seo-wydajnosc.md). |
| Wygląd (Impeccable) | **Nie uruchomiony ani razu.** `styles.css` w `(frontend)` to nadal domyślny boilerplate Payloada (czarne tło, `font-family: system-ui`) — nieużywany, ale zostawiony w repo (do usunięcia, patrz [10](./10-architektura-cms.md)). Realny design system żyje w `globals.css`, ale nikt jeszcze nie przepuścił żadnej strony przez `/impeccable polish`/`audit`/`document`. |
| Formularz kontaktowy | Nie istnieje — jest tylko `contactInfo` (statyczne dane: adres/telefon/email/godziny). Cała konwersja opiera się o link do WhatsApp w `finalCta`/`hero`. |

**Wniosek:** to NIE jest projekt od zera. Faza „Antigravity" (funkcjonalność,
edytowalność, treść) jest w ~80% zrobiona i solidna. Brakuje: (a) prawdziwych
danych i zdjęć klienta, (b) treści na stronach prawnych/FAQ/stowarzyszenie,
(c) całej fazy „Impeccable" — wizualnego dopracowania, animacji scrollowania,
efektów — którą ten plan rozpisuje sekcja po sekcji.

---

## 2. Rozstrzygnięcie: bbh-lohnsteuerhilfe.de jako wzorzec — czego dokładnie

Sprawdziłem aktualną `bbh-lohnsteuerhilfe.de` (live). To generyczna strona na
Astro, wizualnie przeciętna: header z dużym menu, slider-hero ze zdjęciem
stockowym, sekcja usług jako tekst z listą, blok wideo, teaser porad podatkowych
(„Steuerspar-Tipps"), jeden cytat-pull-quote, newsletter, stopka z adresem i
linkami Impressum/Datenschutz/Satzung/Beitragsordnung, plakietki zaufania
(„Verschlüsselte Verbindung", „Server in Deutschland").

**Decyzja (przyjmuję jako założenie — popraw mnie, jeśli chodziło o coś innego):**
biorę z bbh **strukturę i sygnały zaufania branży**, nie warstwę wizualną.
Wizualnie bbh wygląda dokładnie jak to, czego już raz się pozbyliśmy w tym
projekcie („AI slop"/generic — patrz historia ustaleń w `.agents/context`) —
kopiowanie 1:1 jego stylu byłoby krokiem wstecz względem tokenów, które już są
w `globals.css` i które są dobrym, nietuzinkowym kierunkiem dla biura
podatkowego (ciepły papier + pieczęć = metafora „dokumentu urzędowego", a nie
kolejny SaaS). Zamiast przepisywać paletę bbh, **przenoszę z niego wzorce, które
faktycznie konwertują w tej branży**:

| Z bbh bierzemy (treść/UX) | Z bbh NIE bierzemy (wizualnie) |
|---|---|
| „Znajdź doradcę" / silny, jeden CTA nad zgięciem | Generyczny header z rozwijanym mega-menu |
| Sekcja „co to jest Lohnsteuerhilfe" (edukacja + wideo) | Stockowe zdjęcie slidera na cały ekran |
| Teaser porad podatkowych jako sygnał eksperckości | Płaska siatka kart bez hierarchii |
| Pull-quote klienta jako emocjonalny dowód społeczny | Domyślna typografia (system sans, brak charakteru) |
| Plakietki zaufania w stopce (szyfrowanie, serwery w UE) | Newsletter jako główny CTA (u nas to WhatsApp) |
| Linki Satzung/Beitragsordnung jako PDF w stopce | Brak spójnego motion/scroll storytellingu |
| Adres, telefon, godziny zawsze widoczne | — |

Kierunek wizualny: **ciepły „dokument urzędowy", nie SaaS** — już potwierdzony
w kodzie (papier/pieczęć/Fraunces). Ten plan go **dociąga do poziomu „petarda"**:
teksturę papieru, subtelne linie jak w formularzu podatkowym, akcenty pieczęci/
stempla, mikro-interakcje przy scrollowaniu, sekcję wideo i realne social proof —
wszystko przepuszczone przez Impeccable, żeby nie zjechać w stronę żadnego z
61 wzorców AI-slop (pełna lista w [01](./01-design-system-impeccable.md)).

Jeśli w istocie chodziło o dosłowne przejęcie wyglądu bbh (kolory, font, układ) —
to jest jedyne założenie w tym planie, które warto zweryfikować przed startem
budowy; reszta dokumentu nie zależy od tej decyzji.

---

## 3. Kolejność plików w tym planie

| Plik | Zawartość |
|---|---|
| `00-przeglad-strategia-i-workflow.md` | Ten plik. Audyt, decyzja stylu, workflow. |
| `01-design-system-impeccable.md` | PRODUCT.md, DESIGN.md, paleta/typografia/motion, kolejność komend Impeccable, checklista anty-slop. |
| `02-strona-glowna.md` | Home — sekcja po sekcji: treść, zdjęcia, animacje, tło, scroll. |
| `03-uslugi.md` | Usługi / Leistungen. |
| `04-jak-sie-umowic.md` | Jak się umówić / Terminvereinbarung. |
| `05-o-nas.md` | O nas / Über uns. |
| `06-faq.md` | FAQ — pełna strona (obecnie placeholder). |
| `07-stowarzyszenie.md` | Stowarzyszenie / Verein — pełna treść (obecnie placeholder). |
| `08-kontakt.md` | Kontakt. |
| `09-strony-prawne.md` | Impressum, Datenschutz, Cookie-Richtlinie — treść robocza + granica odpowiedzialności. |
| `10-architektura-cms.md` | Zmiany w kolekcjach/blokach/globalach, media, System Pages, sitemapa URL. |
| `11-integracje-seo-wydajnosc.md` | WhatsApp, formularz, SEO/schema.org, analytics za zgodą, bezpieczeństwo, wydajność. |
| `12-checklist-odbioru.md` | Skrócona, spriorytetyzowana checklista odbioru pod ten konkretny projekt. |

---

## 4. Workflow realizacji (Antigravity + Impeccable, w tej kolejności)

Zgodnie z `architektura-tresci.md`: **Antigravity najpierw (funkcjonalność),
Impeccable potem (wygląd)**. Tu funkcjonalność w ~80% już jest, więc kolejność:

1. **Dane wejściowe od klienta** (blokujące wszystko inne — patrz [10](./10-architektura-cms.md)
   §1): realny adres, telefon, e-mail, numer WhatsApp, logo/zdjęcie Janusza,
   ew. zdjęcia biura. Bez tego część sekcji zostaje na placeholderach.
2. **Antigravity — uzupełnienia funkcjonalne**: nowe pola/bloki wymagane przez
   ten plan (FAQ accordion, treść Stowarzyszenie, System Pages role, WhatsApp
   floating button, ew. formularz kontaktowy) — patrz [10](./10-architektura-cms.md) i
   [11](./11-integracje-seo-wydajnosc.md). Zero stylowania ad hoc na tym etapie
   (zgodnie z A6.8 w `antigravity-zasady-agent.md`).
3. **Impeccable `/impeccable init`** → wygeneruj `PRODUCT.md` (gotowa treść w
   [01](./01-design-system-impeccable.md) §1 — do wklejenia/potwierdzenia).
4. **Impeccable `/impeccable document`** → wygeneruj `DESIGN.md` z istniejących
   tokenów w `globals.css` (Impeccable powinien je wykryć automatycznie —
   zweryfikuj wynik względem tabeli w [01](./01-design-system-impeccable.md) §2).
5. Dla każdej podstrony, w kolejności home → usługi → jak się umówić → o nas →
   FAQ → stowarzyszenie → kontakt → prawne:
   `/impeccable polish` z konkretnym promptem sekcja-po-sekcji z odpowiedniego
   pliku (`02`–`09`) → `npx impeccable detect` na zbudowanej stronie → popraw
   findings → `/impeccable audit` jako ostateczna kontrola jakości.
6. **`/impeccable animate`** na sekcjach, które w planie mają oznaczone efekty
   scrollowania (hero, proces, statystyki, sekcja zaufania) — pojedynczo, nie
   hurtowo, żeby nie przesadzić z ruchem (patrz zasada „Motion" w [01](./01-design-system-impeccable.md) §4).
7. Po wszystkich stronach: jeden przelot `/impeccable critique` na całości,
   potem checklista z [12](./12-checklist-odbioru.md).

**Zasada obowiązująca cały czas:** żadna treść, obraz ani link nie ląduje na
sztywno w JSX — wszystko przez panel Payload (pole `localized`, `upload→media`,
`relationship→pages`), zgodnie z `architektura-tresci.md` i twardymi zakazami
w `antigravity-zasady-agent.md` (A1–A4). Ten plan opisuje TREŚĆ i WYGLĄD, które
mają trafić do pól CMS — nie jest to specyfikacja tekstu zaszytego w komponencie.