Builder Flow v5 — Persona-specific landing pages + wspólna aplikacja

Builder Flow v5 to proces przekształcania luźnego pomysłu w działający prototyp, gdzie każda persona ma własny landing page i proces sprzedażowy, ale wszyscy używają tej samej aplikacji.

Kluczowe różnice względem v4:

1. Persona Discovery — po brainstormingu, identyfikujemy konkretne persony i ich potrzeby zakupowe
2. Landing page per persona — każda persona dostaje stronę, która do niej przemawia (język, argumenty, cena, metoda płatności)
3. Wspólna aplikacja — po zakupie, wszyscy użytkownicy wchodzą do tej samej aplikacji
4. Sales funnel — każda landing page prowadzi przez proces zakupowy dostosowany do danej persony

Proces dzieli się na 8 faz:

1. Brainstorming — ogólna wymiana o produkcie

0.5. Persona Discovery — identyfikacja person, ich potrzeb, bólów, preferencji zakupowych

1. Specyfikacja — superpowers SDD generuje specyfikację biznesową, techniczną i wizualną

1.5. Sales Funnel per Persona — landing page, pricing, checkout flow dla każdej persony

1. Design System — DaisyUI theme — wspólny motyw dla landing page i aplikacji
2. Landing Pages — osobne strony sprzedażowe dla każdej persony
3. App mockupy — wspólna aplikacja (ta sama dla wszystkich person)
4. Backend — dopiero po zatwierdzeniu

Faza 0: Brainstorming — produkt ogólnie

Zanim przejdziemy do person, CEO przeprowadza ogólny brainstorming o produkcie (jak w v4).

mkdir -p /root/projects/<projekt>/.superpowers/sdd

cat > /root/projects/<projekt>/.superpowers/sdd/brainstorming-brief.md << 'EOF'
# Brainstorming — produkt

## Kategorie pytań

### 1. Business & Cel
- Jaki problem rozwiązuje ten produkt?
- Jaka jest jedna zdaniowa definicja produktu?
- Jakie są kryteria sukcesu?

### 2. Funkcjonalności — MVP
- Jaka jest JEDNA najważniejsza funkcja?
- Co jest nice-to-have?
- Czego NIE robi ten produkt?

### 3. Technologia
- Czy masz preferencje technologiczne?
- Gdzie ma być hostowane?
- Czy potrzebuje backendu?

## Output
Plik brainstorming-report.md
EOF

opencode run --promret 'Przeczytaj brainstorming-brief.md. Zadaj pytania ownerowi, zapisz odpowiedzi do brainstorming-report.md.' --auto

Faza 0.5: Persona Discovery (NOWOŚĆ v5)

Po ogólnym brainstromingu, CEO identyfikuje różne typy klientów, którzy kupią ten sam produkt, ale każdy z innych powodów i w inny sposób.

Krok 0.5.1: Brief Persona Discovery

cat > /root/projects/<projekt>/.superpowers/sdd/persona-discovery-brief.md << 'EOF'
# Persona Discovery — identyfikacja różnych typów klientów

## Cel
Zidentyfikuj 2-5 różnych person (typów klientów), którzy kupią ten sam produkt.
Każda persona ma INNE: motywacje zakupowe, obawy, preferowane metody płatności,
oczekiwania co do prywatności, język którym mówi.

## Wymagane — dla KAŻDEJ persony odpowiedz na wszystkie pytania

### Tożsamość
- Nazwa persony (np. "Prywaciarz", "Firmowiec", "Kryptoentuzjasta")
- Kim jest? (wiek, zawód, styl życia)
- Jaki ma problem, który nasz produkt rozwiązuje?

### Motywacje zakupowe
- Dlaczego kupuje TEN produkt, a nie alternatywę?
- Co jest dla niego najważniejsze? (cena, prywatność, łatwość, wsparcie, marka)
- Jakie ma obawy przed zakupem?

### Preferencje płatności
- Jak chce płacić? (karta, krypto, BLIK, PayPal, przelew)
- Czy chce być anonimowy?
- Czy potrzebuje faktury?

### Oczekiwania co do prywatności
- Jakie dane osobowe jest gotów podać? (email, imię, firma, adres)
- Jakie dane bezwzględnie chce ukryć?
- Czy akceptuje cookies/analitykę?

### Język i komunikacja
- Jaki język? (polski, angielski)
- Jaki ton? (formalny, casual, techniczny, emocjonalny)
- Gdzie szuka informacji? (Google, Twitter, LinkedIn, polecenie)

### Customer journey
- Jak znajduje produkt? (reklama, social media, polecenie, review)
- Co go przekonuje do zakupu? (demo, case study, gwarancja, opinie)
- Co go blokuje? (cena, brak zaufania, skomplikowany proces)

## Przykład 1: Persona "Prywaciarz"
- Problem: potrzebuje prywatnej przeglądarki, nie chce być śledzony
- Motywacja: prywatność > wszystko inne
- Płatność: tylko krypto (monero, bitcoin), żadnych danych osobowych
- Prywatność: zero emaila, zero imienia, zero logowania
- Język: polski, techniczny, konkretny
- Blokery: musi mieć pewność że nie ma backdoorów, open source

## Przykład 2: Persona "Firmowiec"
- Problem: firma potrzebuje bezpiecznej przeglądarki dla pracowników
- Motywacja: bezpieczeństwo, compliance, faktura VAT
- Płatność: karta firmowa, przelew, faktura na firmę
- Prywatność: dane firmy OK, ale produkt ma gwarantować prywatność użytkowania
- Język: polski, formalny, biznesowy
- Blokery: musi być B2B, faktura, umowa, support

## Output
Plik persona-discovery-report.md z 2-5 personami, każda z pełnym profilem.
EOF

Krok 0.5.2: Uruchom Persona Discovery

cd /root/projects/<projekt>
opencode run --prompt '
Przeczytaj brainstorming-report.md i persona-discovery-brief.md.

Wykonaj Persona Discovery z ownerem:
1. Dla każdej persony zadaj WSZYSTKIE pytania z briefu
2. Po odpowiedziach, zaproponuj nazwę persony i podsumowanie
3. Po zakończeniu wszystkich person, zapisz do persona-discovery-report.md

Zacznij od pytania: "Ile różnych typów klientów widzisz dla tego produktu?"
' --auto

Krok 0.5.3: Przykładowy przebieg — 2 persony

CEO: Ile różnych typów klientów widzisz dla tego produktu?
Owner: Dwa. Jeden chce pełnej anonimowości, drugi to firma.

CEO: OK, zacznijmy od pierwszego. Nazwijmy go roboczo "Prywaciarz".
     Kim jest? Wiek, zawód, styl życia?
Owner: 25-40 lat, IT, programista lub admin. Zna się na technologii.
       Wie jak działa śledzenie, chce go unikać.

CEO: Co jest dla niego najważniejsze przy zakupie?
Owner: Prywatność. Że nikt nie wie, że kupił, czego używa.
       Cena jest drugorzędna. Ważne żeby było open source.

CEO: Jak chce płacić?
Owner: Tylko krypto. Monero najlepiej, bitcoin jak nie ma monero.
       Żadnej karty, żadnego PayPal. Żadnego emaila.

CEO: Czyli zero danych osobowych?
Owner: Zero. Ani email, ani imię, ani nic. Po prostu płaci i używa.

CEO: A drugi typ — "Firmowiec"?
Owner: 35-50 lat, dyrektor IT w firmie 50-500 osób.
       Szuka rozwiązania dla zespołu. Ważne: faktura, B2B, support.

CEO: Jak płaci?
Owner: Kartą firmową lub przelewem. Faktura VAT na firmę.
       Imię, firma, NIP, adres — wszystko może podać.

CEO: Czyli diametralnie różne potrzeby zakupowe, ale ten sam produkt?
Owner: Dokładnie. Ta sama przeglądarka, tylko inaczej sprzedana.

Krok 0.5.4: Persona Discovery — przykładowy output

# Persona Discovery Report

## Persona 1: Prywaciarz
- **Opis**: Programista 25-40 lat, zna technologię, chce pełnej anonimowości
- **Motywacja**: Prywatność > wygoda > cena. Open source wymagany.
- **Płatność**: Tylko krypto (Monero > Bitcoin). Zero danych osobowych.
- **Prywatność**: Żaden email, żadne imię, żadne konto. Płaci i używa.
- **Blokery**: Zamknięty kod, backdoory, wymóg logowania
- **Customer journey**: GitHub, Twitter, polecenie, review techniczne

## Persona 2: Firmowiec
- **Opis**: Dyrektor IT 35-50 lat, kupuje dla zespołu 10-100 osób
- **Motywacja**: Bezpieczeństwo, compliance, kontrola. Faktura VAT.
- **Płatność**: Karta firmowa, przelew. Faktura na firmę.
- **Prywatność**: Dane firmy OK, produkt ma gwarantować prywatność użytkowania
- **Blokery**: Brak B2B, brak faktury, brak umowy, brak supportu
- **Customer journey**: LinkedIn, konferencje, Google, polecenie od CIO

## Persona 3: Kryptoentuzjasta (opcjonalna)
- **Opis**: Inwestor krypto, 30-50 lat, dużo krypto, chce wydawać krypto
- **Motywacja**: Wydać krypto na realny produkt. Podoba mu się idea.
- **Płatność**: Krypto, ale akceptuje też email. Może dać email do newslettera.
- **Prywatność**: Może podać email, ale nie chce karty bankowej.
- **Blokery**: Tylko karta, brak krypto payment
- **Customer journey**: Twitter krypto, newsletter, podcasty

Faza 1: Specyfikacja przez superpowers SDD

Po brainstromingu i persona discovery, mamy pełny obraz. Teraz superpowers generuje 3 specyfikacje.

Krok 1.1: Specyfikacja biznesowa (phase-1)

cat > .superpowers/sdd/phase-1-brief.md << 'EOF'
# Faza 1: Specyfikacja biznesowa

## Cel
Na podstawie brainstorming-report.md i persona-discovery-report.md, stwórz specyfikację biznesową.

## Wymagane sekcje
1. **Persony** — podsumowanie z persona-discovery (każda z profilem, motywacją, blokerami)
2. **User stories** — priorytetyzowane (P0, P1, P2), osobno dla każdej persony
3. **MVP scope** — minimalna wersja
4. **Przepływ biznesowy** — od landing page do aktywnego użytkownika (osobny dla każdej persony)
5. **Metryki sukcesu** — konwersja per persona, retention, revenue

## Output
Plik phase-1-report.md
EOF

opencode run --prompt 'Przeczytaj brainstorming-report.md, persona-discovery-report.md i phase-1-brief.md. Wygeneruj phase-1-report.md.' --auto

Krok 1.2: Specyfikacja techniczna (phase-2)

cat > .superpowers/sdd/phase-2-brief.md << 'EOF'
# Faza 2: Specyfikacja techniczna

## Cel
Na podstawie phase-1-report.md, zdefiniuj architekturę techniczną.

## Wymagane sekcje
1. **Struktura URL-i** — landing page per persona ORAZ wspólna aplikacja
2. **Model danych** — encje, relacje, pola
3. **API endpoints** — REST, metody, request/response
4. **Stack** — framework, baza, hosting

## URL structure
- / — landing page główna (przekierowuje do właściwej persony)
- /prywaciarz/ — landing page dla persony 1
- /firmowiec/ — landing page dla persony 2
- /krypto/ — landing page dla persony 3
- /app/ — wspólna aplikacja (dashboard, sesje, profil, ustawienia)
- /app/* — wszystkie podstrony aplikacji

## Output
Plik phase-2-report.md
EOF

opencode run --prompt 'Przeczytaj phase-1-report.md i phase-2-brief.md. Wygeneruj phase-2-report.md.' --auto

Krok 1.3: Specyfikacja wizualna — lista stron (phase-3)

cat > .superpowers/sdd/phase-3-brief.md << 'EOF'
# Faza 3: Specyfikacja wizualna

## Cel
Na podstawie phase-1-report.md i phase-2-report.md, stwórz listę wszystkich stron.

## Wymagane — podziel na dwie kategorie

### Kategoria A: Landing Pages (osobna dla każdej persony)
Dla KAŻDEJ landing page:
1. **URL** — np. /prywaciarz/, /firmowiec/, /krypto/
2. **Persona** — do kogo jest skierowana
3. **Cel strony** — sprzedaż produktu tej personie
4. **Sekcje** — hero, problem, rozwiązanie, korzyści, cena, CTA, FAQ, footer
5. **CTA** — przycisk zakupu, co się dzieje po kliknięciu
6. **Komponenty DaisyUI** — navbar, hero, card, button, badge, alert, accordion, dropdown, modal

### Kategoria B: Aplikacja (wspólna dla wszystkich person)
Dla KAŻDEJ strony aplikacji:
1. **URL** — np. /app/dashboard, /app/sessions
2. **Cel strony**
3. **Komponenty DaisyUI**
4. **Dane mockowe**
5. **Layout**

## Output
Plik phase-3-report.md — lista landing pages + lista stron aplikacji.
EOF

opencode run --prompt 'Przeczytaj phase-1-report.md, phase-2-report.md i phase-3-brief.md. Wygeneruj phase-3-report.md.' --auto

Faza 1.5: Sales Funnel per Persona (NOWOŚĆ v5)

CEO definiuje proces zakupowy dla każdej persony. Ta sama aplikacja, ale inna droga do niej.

Krok 1.5.1: Brief sales funnel

cat > .superpowers/sdd/sales-funnel-brief.md << 'EOF'
# Sales Funnel per Persona

## Cel
Zdefiniuj proces zakupowy dla każdej persony z persona-discovery-report.md.

## Wymagane — dla KAŻDEJ persony

### Landing page
- URL (np. /prywaciarz/)
- Hero: nagłówek, podtytuł, CTA
- Problem: jaki problem rozwiązuje (język persony)
- Rozwiązanie: jak produkt to robi
- Korzyści: 3-6 punktów
- Cena: ile kosztuje, co zawiera
- CTA: przycisk zakupu
- FAQ: 3-5 pytań
- Footer: stopka, social proof

### Pricing
- Ile kosztuje?
- Co zawiera cena?
- Czy są różne plany? (monthly, yearly, lifetime)
- Czy jest gwarancja? (30 dni, money back)

### Checkout flow
- Krok 1: Kliknięcie CTA → co się dzieje?
- Krok 2: Jakie dane zbiera?
- Krok 3: Jaka metoda płatności?
- Krok 4: Co dostaje po zapłaceniu?
- Krok 5: Jak wchodzi do aplikacji?

### Onboarding
- Jak wygląda pierwsze logowanie?
- Czy jest tutorial?
- Jakie są pierwsze kroki?

## Przykład: Persona "Prywaciarz"
### Landing page URL: /prywaciarz/
### Hero: "Prywatna przeglądarka. Zero śledzenia. Zero logowania."
### CTA: "Kup za Monero →"
### Pricing: 0.05 XMR / lifetime
### Checkout flow:
1. Kliknięcie "Kup za Monero"
2. Pojawia się adres Monero + QR kod
3. Użytkownik wysyła krypto
4. Po 1 konfirmacji → generuje się unikalny link dostępu
5. Użytkownik wchodzi przez link (żadnego konta, żadnego hasła)
6. Link ważny 24h → w aplikacji ustawia PIN

## Output
Plik sales-funnel-report.md — proces zakupowy dla każdej persony.
EOF

opencode run --prompt '
Przeczytaj persona-discovery-report.md, phase-1-report.md i sales-funnel-brief.md.

Wygeneruj sales-funnel-report.md z procesem zakupowym dla każdej persony.
Dla każdej: landing page sekcje, pricing, checkout flow krok po kroku, onboarding.
' --auto

Krok 1.5.2: Przykład — Sales Funnel dla 2 person

Landing Page URL: /prywaciarz/

┌──────────────────────────────────────────────┐
│  HERO                                         │
│  "Prywatna przeglądarka. Zero śledzenia.      │
│   Zero logowania. Zero danych osobistych."     │
│  [Kup za Monero →]                            │
├──────────────────────────────────────────────┤
│  PROBLEM                                      │
│  Każda przeglądarka Cię śledzi. Google,       │
│  Facebook, reklamy — wszyscy wiedzą kim       │
│  jesteś.                                      │
├──────────────────────────────────────────────┤
│  ROZWIĄZANIE                                  │
│  Nasza przeglądarka: zero telemetrii, zero    │
│  cookies, zero logowania, open source.        │
├──────────────────────────────────────────────┤
│  KORZYŚCI                                     │
│  ✅ Open source — kod do wglądu               │
│  ✅ Zero danych — nie zbieramy nic            │
│  ✅ VPN wbudowany — IP ukryty                 │
│  ✅ Adblock — zero reklam                     │
│  ✅ Lifetime — płacisz raz, używasz zawsze    │
├──────────────────────────────────────────────┤
│  CENA                                         │
│  0.05 XMR (≈ $15)                            │
│  Jednorazowo, dożywotnio                      │
│  [Kup za Monero →]                            │
├──────────────────────────────────────────────┤
│  FAQ                                          │
│  ❓ Czy muszę podać email? → Nie.             │
│  ❓ Czy mogę zwrócić? → Tak, 30 dni money back│
│  ❓ Czy jest open source? → Tak, GitHub       │
│  ❓ Jakie krypto akceptujecie? → Monero, BTC  │
├──────────────────────────────────────────────┤
│  CHECKOUT                                     │
│  1. Klikasz "Kup za Monero"                   │
│  2. Dostajesz adres XMR + QR                  │
│  3. Wysyłasz krypto                           │
│  4. Po 1 konfirmacji → unikalny link          │
│  5. Klikasz link → ustawiasz PIN              │
│  6. Gotowe — używasz przeglądarki             │
└──────────────────────────────────────────────┘

Landing Page URL: /firmowiec/

┌──────────────────────────────────────────────┐
│  HERO                                         │
│  "Bezpieczna przeglądarka dla Twojej firmy.   │
│   Faktura VAT. B2B. Support 24/7."            │
│  [Zamów dla firmy →]                          │
├──────────────────────────────────────────────┤
│  PROBLEM                                      │
│  Pracownicy używają Chrome/Edge — zero        │
│  kontroli, dane firmy wyciekają.              │
├──────────────────────────────────────────────┤
│  ROZWIĄZANIE                                  │
│  Przeglądarka z centralnym zarządzaniem,      │
│  politykami bezpieczeństwa, raportami.         │
├──────────────────────────────────────────────┤
│  KORZYŚCI                                     │
│  ✅ Centralne zarządzanie — polityki per team  │
│  ✅ Raporty — kto, co, kiedy, gdzie           │
│  ✅ VPN — wszystkie połączenia szyfrowane     │
│  ✅ Faktura VAT — na firmę                    │
│  ✅ Support 24/7 — dedykowany opiekun         │
├──────────────────────────────────────────────┤
│  CENA                                         │
│  $19/miesiąc za użytkownika                   │
│  Rabat 20% przy rocznej                       │
│  [Zamów dla firmy →]                          │
├──────────────────────────────────────────────┤
│  CHECKOUT                                     │
│  1. Klikasz "Zamów dla firmy"                 │
│  2. Formularz: firma, NIP, email, liczba userów│
│  3. Karta firmowa lub przelew                 │
│  4. Faktura VAT wysłana na email              │
│  5. Panel admina: dodajesz pracowników        │
│  6. Każdy dostaje link + instrukcje           │
└──────────────────────────────────────────────┘

Faza 2: Design System — DaisyUI theme

Wspólny motyw DaisyUI dla landing pages + aplikacji. Ten sam data-theme, te same kolory, ta sama czcionka.

# Wybierz motyw (np. corporate dla B2B, emerald dla wellness)
echo "data-theme: corporate" > /root/projects/<projekt>/.superpowers/sdd/selected-theme.txt

<!DOCTYPE html>
<html lang="pl" data-theme="corporate">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>PROJEKT — {{persona}}</title>
  <link href="https://cdn.jsdelivr.net/npm/daisyui@5" rel="stylesheet">
  <script src="https://cdn.tailwindcss.com"></script>
</head>
<body>

Faza 3: Landing Pages — jedna per persona

CEO generuje osobną landing page dla każdej persony, każda pod swoim URL-em.

Krok 3.1: Lista landing pages

Na podstawie sales-funnel-report.md:

Krok 3.2: Generuj landing page dla persony 1

opencode run --prompt '
Stwórz landing page dla persony "Prywaciarz" w /var/www/projects/<projekt>/prywaciarz/index.html.

ZASADY:
1. DaisyUI + Tailwind przez CDN (data-theme="corporate")
2. TYLKO gotowe klasy DaisyUI — zero hexów, zero inline style, zero własnego CSS
3. Język: polski, techniczny, konkretny, bez marketingu-cukierkowego

STRUKTURA LANDING PAGE:

### Hero
- Nagłówek: "Prywatna przeglądarka. Zero śledzenia. Zero logowania."
- Podtytuł: "Kupujesz krypto, dostajesz link. Żadnego emaila, żadnego konta."
- CTA: button btn-primary "Kup za Monero →"
- Tło: neutralne, ciemne lub gradient

### Problem
- "Każda przeglądarka Cię śledzi. Google, Facebook, reklamy — wszyscy wiedzą kim jesteś."
- Karty z konkretami: "Chrome zbiera historię", "Edge wysyła dane do Microsoft", "Firefox ma telemetrię"

### Rozwiązanie
- "Nasza przeglądarka: zero telemetrii, zero cookies zewnętrznych, zero logowania."
- Lista z badge: Open Source, Zero data collection, VPN wbudowany, Adblock, Lifetime

### Korzyści (karty DaisyUI)
Grid 2x2 lub 3x2 z kartami:
1. Open source — kod do wglądu na GitHub
2. Zero danych — nie zbieramy absolutnie nic
3. VPN — IP ukryty, geolokacja zamaskowana
4. Adblock — zero reklam, zero trackerów
5. Lifetime — płacisz raz, używasz zawsze
6. Bez logowania — żadnego konta, tylko link

### Cena
- Cena: 0.05 XMR (≈ $15)
- "Jednorazowo, dożywotnio. 30 dni money back."
- CTA: button btn-primary btn-lg "Kup za Monero →"

### Jak to działa (steps DaisyUI)
<ul class="steps steps-vertical">
  <li class="step step-primary">Klikasz "Kup za Monero"</li>
  <li class="step step-primary">Dostajesz adres XMR + QR kod</li>
  <li class="step step-primary">Wysyłasz krypto z dowolnego portfela</li>
  <li class="step step-primary">Po 1 konfirmacji → unikalny link</li>
  <li class="step step-primary">Klikasz link → ustawiasz PIN → gotowe</li>
</ul>

### FAQ (accordion DaisyUI)
- "Czy muszę podać email?" → Nie. Zero danych.
- "Jakie krypto akceptujecie?" → Monero (XMR), Bitcoin (BTC)
- "Czy mogę zwrócić?" → Tak, 30 dni money back w krypto
- "Czy jest open source?" → Tak, pełny kod na GitHub
- "Czy mogę użyć na wielu urządzeniach?" → Tak, do 3 urządzeń

### Footer
- Stopka: linki do /firmowiec/ (dla firm), /app/ (aplikacja)
- "Prototyp v5 — DaisyUI | data-theme=corporate | Persona: Prywaciarz"
' --auto

Krok 3.3: Generuj landing page dla persony 2

opencode run --prompt '
Stwórz landing page dla persony "Firmowiec" w /var/www/projects/<projekt>/firmowiec/index.html.

ZASADY:
1. DaisyUI + Tailwind przez CDN (data-theme="corporate")
2. TYLKO gotowe klasy DaisyUI
3. Język: polski, formalny, biznesowy

STRUKTURA:

### Hero
- Nagłówek: "Bezpieczna przeglądarka dla Twojej firmy."
- Podtytuł: "Faktura VAT. Centralne zarządzanie. Support 24/7."
- CTA: btn-primary "Zamów dla firmy →"

### Problem
- "Pracownicy używają Chrome/Edge — zero kontroli, dane firmy wyciekają."
- "Ransomware, phishing, tracking — każdego dnia nowe zagrożenia."

### Rozwiązanie
- "Przeglądarka z politykami bezpieczeństwa, raportami i VPN."

### Korzyści (karty DaisyUI)
1. Centralne zarządzanie — polityki per team
2. Raporty — kto, co, kiedy, gdzie
3. VPN — wszystkie połączenia szyfrowane
4. Faktura VAT — na firmę
5. Support 24/7 — dedykowany opiekun
6. Onboarding — wdrożenie w 1 dzień

### Cena
- $19/miesiąc za użytkownika
- Rabat 20% przy rocznej
- CTA: btn-primary btn-lg "Zamów dla firmy →"

### Jak to działa (steps)
1. Klikasz "Zamów dla firmy"
2. Formularz: firma, NIP, email, liczba userów
3. Karta firmowa lub przelew
4. Faktura VAT wysłana na email
5. Panel admina: dodajesz pracowników
6. Każdy dostaje link + instrukcje

### FAQ
- "Czy jest faktura?" → Tak, VAT na firmę
- "Ile kosztuje?" → $19/user/miesiąc, rabat 20% roczna
- "Czy jest support?" → Tak, 24/7, dedykowany opiekun
- "Czy mogę przetestować?" → Tak, 14 dni trial

### Footer
- Linki: /prywaciarz/ (dla indywidualnych), /app/ (aplikacja)
' --auto

Krok 3.4: Strona główna — wybór persony

opencode run --prompt '
Stwórz stronę główną /var/www/projects/<projekt>/index.html.

CEL: pomóż użytkownikowi wybrać swoją personę.

Dwie duże karty obok siebie (grid grid-cols-1 md:grid-cols-2):

### Karta 1: "Jestem osobą prywatną"
- Ikona: tarcza/priv
- Chcę: prywatności, anonimowości, krypto
- Cena: 0.05 XMR lifetime
- CTA: btn-primary "Wybierz →" → link do /prywaciarz/

### Karta 2: "Reprezentuję firmę"
- Ikona: budynek/briefcase
- Chcę: B2B, faktury, zarządzania zespołem
- Cena: $19/user/miesiąc
- CTA: btn-secondary "Wybierz →" → link do /firmowiec/

Hero: "Wybierz swoją ścieżkę"
Podtytuł: "Ta sama aplikacja, inny sposób zakupu"
' --auto

Faza 4: App mockupy — wspólna aplikacja

Aplikacja jest taka sama dla wszystkich person. Niezależnie od tego, czy ktoś kupił przez krypto czy przez firmę — wchodzi do tego samego dashboardu.

opencode run --prompt '
Stwórz wspólną aplikację w /var/www/projects/<projekt>/app/.

ZASADY:
1. DaisyUI + Tailwind przez CDN (data-theme="corporate")
2. TYLKO gotowe klasy DaisyUI
3. Aplikacja jest IDENTYCZNA dla wszystkich person — nie ma śladu która persona kupiła

Struktura:
/var/www/projects/<projekt>/app/
├── index.html              — Dashboard (przekierowanie do /app/dashboard/)
├── dashboard/index.html    — Dashboard główny
├── sessions/index.html     — Lista sesji
├── sessions/123/index.html — Szczegóły sesji
├── profile/index.html      — Profil (ustawienia, PIN, urządzenia)
├── settings/index.html     — Ustawienia

### Dashboard
- Navbar: logo, linki (Dashboard, Sesje, Profil), avatar/ikona
- Breadcrumbs: App > Dashboard
- Statystyki w kartach: ukończone sesje, czas, compliance
- Tabela ostatnich aktywności (table table-zebra)
- Alert informacyjny (alert alert-info)

### Sesje
- Lista sesji z paginacją
- Filtry: data, status, typ
- Każdy wiersz: data, czas, status, akcje

### Profil
- Ustawienia PIN
- Lista urządzeń
- Preferencje (język, theme)
' --auto

Faza 5: Weryfikacja — kompletny prototyp

CEO weryfikuje że wszystkie landing pages + aplikacja działają i są spójne.

Krok 5.1: Weryfikacja struktury

# Sprawdź czy wszystkie landing pages istnieją
ls -la /var/www/projects/<projekt>/*/index.html  # landing pages
ls -la /var/www/projects/<projekt>/app/*/index.html  # app

# Sprawdź HTTP 200 dla WSZYSTKICH stron
for url in / /prywaciarz/ /firmowiec/ /app/dashboard/ /app/sessions/ /app/profile/; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 "https://10s.pl/<projekt>$url")
  echo "$url → HTTP $code"
done

Krok 5.2: Weryfikacja spójności

# 1. Wszystkie strony ładują DaisyUI
for f in $(find /var/www/projects/<projekt>/ -name 'index.html'); do
  has_daisy=$(grep -c 'daisyui' "$f" || true)
  [ "$has_daisy" -eq 0 ] && echo "❌ $f — brak DaisyUI"
done

# 2. Brak hexów (twardych kolorów)
for f in $(find /var/www/projects/<projekt>/ -name 'index.html'); do
  hard=$(grep -cE '#[0-9a-fA-F]{3,6}' "$f" || true)
  [ "$hard" -gt 2 ] && echo "⚠️  $f — $hard hexów"
done

# 3. Brak inline style
for f in $(find /var/www/projects/<projekt>/ -name 'index.html'); do
  inline=$(grep -c 'style="' "$f" || true)
  [ "$inline" -gt 0 ] && echo "⚠️  $f — $inline inline style"
done

# 4. Ten sam data-theme na wszystkich stronach
grep -r 'data-theme' /var/www/projects/<projekt>/ | grep -oP 'data-theme="[^"]*"' | sort -u
# Oczekiwane: tylko 1 unikalny motyw

Krok 5.3: Raport do zatwierdzenia

hermes kanban --board convertere comment <card-id> \
  "[CEO] ✅ Prototyp v5 gotowy:

Persony:
🔒 Prywaciarz: https://10s.pl/<projekt>/prywaciarz/ (krypto, zero danych)
🏢 Firmowiec: https://10s.pl/<projekt>/firmowiec/ (B2B, faktura)
🏠 Strona główna: https://10s.pl/<projekt>/ (wybór persony)

Aplikacja (wspólna):
📊 Dashboard: https://10s.pl/<projekt>/app/dashboard/
📋 Sesje: https://10s.pl/<projekt>/app/sessions/
👤 Profil: https://10s.pl/<projekt>/app/profile/

Weryfikacja:
✅ HTTP 200 — wszystkie strony
✅ DaisyUI — wszystkie strony
✅ Zero hexów — brak twardych kolorów
✅ Zero inline style
✅ Ten sam data-theme na wszystkich
⏳ Czekam na zatwierdzenie przed backendem"

Porównanie v4 → v5

Playbook: 45-minutowy Builder Flow v5

Przygotowanie (2 min):

• [ ] mkdir -p /root/projects/<projekt> && cd $_ && git init
• [ ] Stwórz kanban task

Brainstorming (3 min):

• [ ] Pytania o produkt, zapisz odpowiedzi

Persona Discovery (8 min):

• [ ] Brief persona-discovery
• [ ] Uruchom opencode — identyfikacja 2-5 person
• [ ] Dla każdej: motywacje, płatność, prywatność, język, blokery

Specyfikacja (8 min):

• [ ] superpowers SDD → phase-1, phase-2, phase-3

Sales Funnel (5 min):

• [ ] Brief sales funnel
• [ ] Uruchom opencode — proces zakupowy per persona

Design System (2 min):

• [ ] Wybierz motyw DaisyUI
• [ ] Stwórz base.html z CDN

Landing Pages (10 min):

• [ ] Persona 1: landing page z DaisyUI
• [ ] Persona 2: landing page z DaisyUI
• [ ] Strona główna: wybór persony

App mockupy (5 min):

• [ ] Wspólna aplikacja (dashboard, sesje, profil)

Weryfikacja (2 min):

• [ ] HTTP 200 dla wszystkich stron
• [ ] Spójność: DaisyUI, zero hexów, ten sam theme
• [ ] Zgłoś użytkownikowi

Ryzyka i wyzwania

Ryzyko 1: Za dużo person

5+ person = 5+ landing pages = dużo czasu i treści.

Rozwiązanie: Zacznij od 2-3 person. Resztę dodaj w iteracji.

Ryzyko 2: Landing page i aplikacja różnią się stylem

Landing page ma więcej marketingu, aplikacja jest bardziej utility. Łatwo o rozjazd stylistyczny.

Rozwiązanie: Ten sam DaisyUI data-theme, te same kolory, ten sam navbar. Różni się tylko treść i layout.

Ryzyko 3: Checkout flow nie jest spójny z landing page

Landing page obiecuje coś (np. "zero danych"), a checkout wymaga emaila.

Rozwiązanie: CEO weryfikuje: landing page promises → checkout delivers. Żadnych sprzeczności.

Ryzyko 4: Osoba trafia na złą landing page

Ktoś szuka przeglądarki dla firmy, trafia na /prywaciarz/ i myśli że to nie dla niego.

Rozwiązanie: Strona główna z wyborem persony + linki w footerze każdej landing page do pozostałych.

Mierzenie sukcesu

Źródła (Linki URL)

• DaisyUI — dokumentacja
• DaisyUI — lista komponentów
• DaisyUI — lista motywów
• Tailwind CSS — dokumentacja
• superpowers — obra/superpowers GitHub
• opencode — kimi-k27/code
• Builder Flow v1
• Builder Flow v2
• Builder Flow v3
• Builder Flow v4
• Builder Flow v5 — ta wersja

Źródła (Pliki)

• /root/.config/opencode/opencode.json — konfiguracja opencode
• /root/convertere/reports/builder-flow-v1.md — v1 raport
• /root/convertere/reports/builder-flow-v2.md — v2 raport
• /root/convertere/reports/builder-flow-v3.md — v3 raport
• /root/convertere/reports/builder-flow-v4.md — v4 raport
• /root/convertere/reports/builder-flow-v5.md — ten raport