Builder Flow v3 — Brainstorming first, framework + gotowe komponenty

Builder Flow v3 to proces przekształcania luźnego pomysłu w działający prototyp strony/aplikacji, z naciskiem na precyzję przez brainstorming i maksymalne wykorzystanie gotowych puzzelków (framework + biblioteka komponentów). Kluczowe różnice względem v2:

1. Brainstorming — zanim cokolwiek powstanie, superpowers SDD prowadzi wielopytaniową wymianę z ownerem, żeby wyciągnąć maksimum precyzji
2. Gotowe komponenty — zamiast ręcznie pisać CSS, używamy frameworka (np. Tailwind CSS) + biblioteki komponentów (np. DaisyUI, shadcn/vue) — sprawdzone, przetestowane, gotowe puzzelki

Proces dzieli się na 6 faz:

1. Brainstorming — superpowers SDD zadaje pytania, owner odpowiada, powstaje precyzyjny brief
2. Specyfikacja — superpowers SDD generuje specyfikację biznesową, techniczną i wizualną
3. Wybór frameworku + komponentów — 3 propozycje frameworków, kilka bibliotek, owner wybiera
4. Design System + multi-variant — konfiguracja frameworka (tailwind.config.js) + 3 warianty wizualne
5. HTML mockupy — wszystkie strony z gotowych komponentów, spójne, z mockowanymi danymi
6. Backend — dopiero po zatwierdzeniu prototypu

Faza 0: Brainstorming — superpowers SDD × Owner (NOWOŚĆ v3)

Zanim powstanie jakakolwiek specyfikacja, superpowers SDD prowadzi wielopytaniową wymianę z ownerem produktu. Celem jest wyciągnięcie maksimum precyzji, zanim opencode zacznie cokolwiek generować.

Krok 0.1: Init — CEO tworzy brief brainstormingowy

CEO tworzy strukturę pytań, które superpowers zada ownerowi:

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

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

## Cel
Przeprowadź szczegółową wymianę pytań i odpowiedzi z ownerem produktu, żeby precyzyjnie zdefiniować projekt. To jest NAJWAŻNIEJSZA faza — im więcej pytań, tym mniej błędów potem.

## Kategorie pytań (wymagane wszystkie)

### 1. Business & Cel
Zadaj co najmniej 5 pytań o:
- Jaki problem rozwiązuje ta aplikacja?
- Dla kogo dokładnie jest? (wiek, zawód, potrzeby)
- Co jest najważniejsze: szybkość, wygląd, funkcje, niezawodność?
- Jakie znasz alternatywy? Co w nich nie działa?
- Jakie są kryteria sukcesu? (ilość użytkowników, revenue, retention)

### 2. Użytkownicy i Persony
Zadaj co najmniej 4 pytania o:
- Ile typów użytkowników? (admin, klient, gość, moderator)
- Co każdy typ użytkownika robi najczęściej?
- Jakie są uprawnienia? (kto co widzi/może edytować)
- Czy użytkownicy są zalogowani czy anonimowi?

### 3. Funkcjonalności — priorytetyzacja
Zadaj co najmniej 6 pytań o:
- Jaka jest JEDNA najważniejsza funkcja? (MVP)
- Jakie funkcje są "nice to have"?
- Czego NIE robi ta aplikacja? (anti-scope)
- Jakie są integracje? (API, płatności, email, SMS, webhooki)
- Czy są jakieś deadline/y? (data, faza księżyca, konferencja)
- Które funkcje mogą poczekać do v2?

### 4. UX i Design
Zadaj co najmniej 4 pytania o:
- Jakie aplikacje podobają Ci się wizualnie? (linki, screengraby)
- Jaki charakter ma mieć aplikacja? (poważny, zabawny, minimalistyczny, bogaty)
- Czy preferujesz dark mode czy light mode?
- Czy są jakieś elementy brandingowe? (logo, kolory firmy, font)

### 5. Technologia i hosting
Zadaj co najmniej 3 pytania o:
- Czy masz preferencje technologiczne? (React, Vue, Svelte, PHP, Python)
- Gdzie ma to być hostowane? (VPS, Netlify, Vercel, własny serwer)
- Czy potrzebujesz backendu czy może być statycznie?

### 6. Ograniczenia i ryzyka
Zadaj co najmniej 3 pytania o:
- Jakie są największe ryzyka? (nie zdążymy, za drogo, nie ma danych)
- Co jeśli projekt się nie uda? (fallback, exit strategy)
- Czy są jakieś regulacje? (RODO, HIPAA, GDPR, PCI)

## Format odpowiedzi
Po każdej odpowiedzi ownera, superpowers może zadać pytanie doprecyzowujące.
Celem jest uzyskanie konkretnych odpowiedzi, nie ogólników.

## Output
Plik brainstorming-report.md z wszystkimi pytaniami i odpowiedziami.
EOF

Krok 0.2: Uruchom brainstorming

cd /root/projects/<projekt>
opencode run --prompt '
Przeczytaj .superpowers/sdd/brainstorming-brief.md.

Wykonaj brainstorming z ownerem:
1. Zadaj pytanie z kategorii 1 (Business & Cel)
2. Czekaj na odpowiedź
3. Jeśli odpowiedź jest ogólnikowa — zadaj pytanie doprecyzowujące
4. Przejdź do następnego pytania
5. Po wyczerpaniu kategorii 1, przejdź do kategorii 2

Zadaj WSZYSTKIE pytania ze wszystkich 6 kategorii.
Po zakończeniu zapisz pełny raport do .superpowers/sdd/brainstorming-report.md.

Uwaga: to jest interaktywna sesja — zadajesz pytanie, ja odpowiadam.
' --auto

Krok 0.3: Brainstorming — przykładowy przebieg

superpowers: Jaki problem rozwiązuje ta aplikacja?
Owner:      Pacjenci nie wiedzą kiedy mają sesje normobarii.

superpowers: Rozumiem. Czyli chodzi o harmonogram. A co jest teraz? Jak to działa?
Owner:      Dzwonią do recepcji, recepcja sprawdza w Excelu, mówi im.

superpowers: Excel — czyli jest już jakiś system. Czy chcesz go zastąpić, czy zrobić 
            coś równoległego?
Owner:      Zastąpić. Excel jest dla recepcji, nie dla pacjentów.

superpowers: Aha! Czyli aplikacja ma być dla pacjentów (self-service), a nie dla 
            recepcji. Czy recepcja też będzie miała swój panel?
Owner:      Nie, recepcja zostaje w Excelu. Aplikacja tylko dla pacjentów.

superpowers: OK, to kluczowe zawężenie. Aplikacja pacjencka, nie admin panel.
            ...

Efekt: brainstorming-report.md zawiera ~25+ pytań i odpowiedzi, które precyzyjnie definiują projekt. To jest jedno źródło prawdy dla wszystkich kolejnych faz.

Krok 0.4: Weryfikacja — czy brief jest wystarczająco precyzyjny?

CEO sprawdza czy brainstorming wyciągnął konkretne odpowiedzi, nie ogólniki:

# Sprawdź czy są konkretne odpowiedzi (nie "nie wiem")
grep -c "nie wiem\|nie jestem pewien\|trudno powiedzieć" \
  /root/projects/<projekt>/.superpowers/sdd/brainstorming-report.md || true

# Jeśli >3 ogólniki — CEO uruchamia dodatkową rundę pytań

Faza 1: Specyfikacja przez superpowers SDD

Po brainstromingu, mamy precyzyjny brief. 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, stwórz specyfikację biznesową.

## Wymagane sekcje
1. **Persona** — typy użytkowników z konkretnymi cechami
2. **User stories** — priorytetyzowane (P0, P1, P2)
3. **MVP scope** — minimalna wersja do uruchomienia
4. **Przepływ biznesowy** — krok po kroku
5. **Metryki sukcesu** — konkretne liczby

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

opencode run --prompt 'Przeczytaj brainstorming-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** — lista wszystkich ścieżek
2. **Model danych** — encje, relacje, pola
3. **API endpoints** — REST, metody, request/response
4. **Stack** — framework, baza, hosting

## 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 sekcje
Dla KAŻDEJ strony:
1. **URL** — ścieżka
2. **Cel strony** — co użytkownik tu robi
3. **Komponenty UI** — lista gotowych komponentów (navbar, karta, tabela, formularz, modal, sidebar, breadcrumb, pagination, badge, alert, dropdown)
4. **Dane mockowe** — przykładowe dane
5. **Layout** — układ strony
6. **Akcje użytkownika** — co może kliknąć

## Output
Plik phase-3-report.md — lista wszystkich stron z komponentami.
EOF

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

Faza 2: Wybór frameworku + biblioteki komponentów (NOWOŚĆ v3)

Zamiast pisać CSS ręcznie, wybieramy gotowy framework CSS + bibliotekę komponentów — sprawdzone puzzelki, które dają spójność za darmo.

Krok 2.1: 3 propozycje frameworków

CEO prezentuje 3 najbardziej popularne frameworki CSS:

Rekomendacja: Tailwind CSS — największa elastyczność, najlepsze biblioteki komponentów, ogromna społeczność. Bootstrap jako fallback dla admin paneli.

Krok 2.2: 5 bibliotek komponentów

CEO prezentuje biblioteki gotowych komponentów — sprawdzone puzzelki:

Rekomendacja (projekty nowoczesne): DaisyUI (najszybszy start, CDN, 0 konfiguracji) lub shadcn/vue (najpiękniejszy, pełna kontrola).

Rekomendacja (admin panel): Flowbite (najwięcej komponentów dashboardowych).

Krok 2.3: Prezentacja + wybór

CEO prezentuje opcje i pyta użytkownika:

[CEO] Wybór frameworku i komponentów:

Frameworki:
A) Tailwind CSS — najpopularniejszy, max elastyczność (rekomendowany)
B) Bootstrap 5 — najprostszy, gotowe komponenty, CDN
C) Bulma — prosty, czysty HTML, pure CSS

Biblioteki komponentów (do Tailwinda):
1) DaisyUI — 30+ komponentów, najprostszy, CDN, wbudowane motywy
2) shadcn/vue — najpiękniejszy, kopiuj-wklej, accessible
3) Flowbite — 500+ komponentów, Figma, dashboardy
4) Preline — 300+ komponentów, dark mode, Figma
5) Nuxt UI — 200+ komponentów, tylko dla Nuxt/Vue

Rekomendacja: Tailwind CSS + DaisyUI (szybki start, CDN, 30+ komponentów, wbudowane motywy)

Krok 2.4: Konfiguracja — instalacja

Po wyborze, CEO instaluje framework + bibliotekę:

cd /root/projects/<projekt>

# Opcja 1: Tailwind CSS + DaisyUI (rekomendowana)
mkdir -p src && cd src
cat > index.html << 'EOF'
<!DOCTYPE html>
<html lang="pl">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Prototyp</title>
  <!-- DaisyUI + Tailwind przez CDN (zero konfiguracji!) -->
  <link href="https://cdn.jsdelivr.net/npm/daisyui@5" rel="stylesheet">
  <script src="https://cdn.tailwindcss.com"></script>
</head>
<body>
  <!-- Prototyp będzie tutaj -->
</body>
</html>
EOF

# Opcja 2: Bootstrap 5 (alternatywa)
cat > index.html << 'EOF'
<!DOCTYPE html>
<html lang="pl">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Prototyp</title>
  <link href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css" rel="stylesheet">
</head>
<body>
  <!-- Prototyp będzie tutaj -->
</body>
</html>
EOF

# Opcja 3: Tailwind + shadcn/vue (zaawansowana)
npm create vue@latest vue-app -- --typescript
cd vue-app
npx nuxi module add ui
# Pełna konfiguracja Nuxt UI

Faza 3: Design System — konfiguracja frameworka

Zamiast pisać theme.css ręcznie (jak w v2), konfigurujemy framework przez jego system konfiguracji.

Krok 3.1: Multi-variant przez framework theme

DaisyUI ma wbudowane 30+ motywów. To idealne do multi-variant:

cat > /root/projects/<projekt>/src/theme-config.html << 'EOF'
<!-- DaisyUI themes - wybierz data-theme -->
<!--
  Wariant A: "light" — jasny, czysty, profesjonalny
  Wariant B: "dark" — ciemny, nowoczesny, technologiczny
  Wariant C: "emerald" — zielony, naturalny, wellness
  Wariant D: "cupcake" — ciepły, przyjazny, delikatny
  Wariant E: "corporate" — biznesowy, stonowany, elegancki
  Wariant F: "synthwave" — neonowy, kreatywny, odważny
-->

<!-- Przykład: strona z wariantem A -->
<html data-theme="light">

<!-- Przykład: strona z wariantem B -->
<html data-theme="dark">

<!-- Custom theme (jeśli żaden gotowy nie pasuje) -->
<!-- patrz: https://daisyui.com/docs/themes/ -->
<script>
  tailwind.config = {
    daisyui: {
      themes: [
        {
          mytheme: {
            "primary": "#2563eb",
            "secondary": "#64748b",
            "accent": "#f59e0b",
            "neutral": "#1e293b",
            "base-100": "#ffffff",
            "info": "#3b82f6",
            "success": "#10b981",
            "warning": "#f59e0b",
            "error": "#ef4444",
          },
        },
      ],
    },
  }
</script>
EOF

Krok 3.2: Design System — gotowe komponenty z biblioteki

Zamiast definiować każdy komponent ręcznie (jak w v2), używamy gotowych klas z biblioteki:

DaisyUI — gotowe komponenty:

Bootstrap 5 — gotowe komponenty:

Krok 3.3: Weryfikacja — framework + biblioteka działają

# Sprawdź czy framework ładuje się poprawnie
curl -s https://10s.pl/<projekt>/dashboard/ | grep -c 'daisyui\|bootstrap\|tailwind'
# Oczekiwane: >= 1 (framework jest załadowany)

Faza 4: HTML mockupy z gotowych komponentów

Teraz opencode generuje wszystkie strony, używając wyłącznie gotowych klas z wybranej biblioteki. Żadnego ręcznego CSS.

Krok 4.1: Generuj strony z DaisyUI

opencode run --prompt '
Stwórz prototyp HTML dla projektu <projekt> w katalogu /var/www/projects/<projekt>/.

ZASADY — WAŻNE:
1. Framework: Tailwind CSS + DaisyUI (CDN)
2. Każda strona ładuje:
   <link href="https://cdn.jsdelivr.net/npm/daisyui@5" rel="stylesheet">
   <script src="https://cdn.tailwindcss.com"></script>
3. Używaj TYLKO gotowych klas DaisyUI: navbar, card, btn, table, input, badge, alert, modal, dropdown, tabs, breadcrumbs, loading, progress, avatar
4. NIE używaj własnego CSS ani inline styles. NIE twórz pliku theme.css.
5. Jeśli potrzebujesz zmienić kolor — użyj atrybutu data-theme na <html> (np. data-theme="light")
6. Do marginesów/paddingów używaj Tailwind utility classes: p-4, m-2, gap-4, flex, grid, itp.

Na podstawie .superpowers/sdd/phase-3-report.md, wygeneruj:

/var/www/projects/<projekt>/
├── index.html               — Strona główna (hero + karty stron)
├── dashboard/index.html     — Dashboard
├── sessions/index.html      — Lista sesji
├── sessions/123/index.html — Szczegóły sesji
├── profile/index.html       — Profil
├── settings/index.html      — Ustawienia

Każda strona:
- data-theme="light" (lub inny wybrany wariant)
- Navbar DaisyUI: <div class="navbar bg-base-100 shadow-sm">
- Card: <div class="card card-bordered bg-base-100 shadow-sm">
- Button: <button class="btn btn-primary">
- Table: <table class="table table-zebra">
- Input: <input class="input input-bordered w-full">
- Badge: <span class="badge badge-success">
- Footer: <footer class="footer footer-center p-4 bg-base-200">

Wszystkie linki wewnętrzne prowadzą do innych stron prototypu.
Realistyczne dane mockowe (imiona, daty, wartości).
' --auto

Krok 4.2: Przykład — strona dashboard z DaisyUI

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

<!-- Navbar -->
<div class="navbar bg-base-100 shadow-sm sticky top-0 z-50">
  <div class="flex-1">
    <a class="btn btn-ghost text-xl">NormoCare</a>
  </div>
  <div class="flex-none gap-2">
    <ul class="menu menu-horizontal px-1">
      <li><a href="/normo/dashboard/" class="active">Dashboard</a></li>
      <li><a href="/normo/sessions/">Sesje</a></li>
      <li><a href="/normo/profile/">Profil</a></li>
      <li><a href="/normo/settings/">Ustawienia</a></li>
    </ul>
  </div>
</div>

<main class="container mx-auto p-6">

  <!-- Nagłówek -->
  <div class="flex justify-between items-center mb-6">
    <h1 class="text-3xl font-bold">Dashboard</h1>
    <button class="btn btn-primary">+ Dodaj sesję</button>
  </div>

  <!-- Karty statystyk -->
  <div class="grid grid-cols-1 md:grid-cols-3 gap-4 mb-6">
    <div class="card card-bordered bg-base-100 shadow-sm">
      <div class="card-body">
        <h2 class="card-title">Ukończone sesje</h2>
        <p class="text-4xl font-bold text-primary">12</p>
        <p class="text-sm text-base-content/60">z 20 zaplanowanych</p>
        <progress class="progress progress-primary w-full" value="60" max="100"></progress>
      </div>
    </div>
    <div class="card card-bordered bg-base-100 shadow-sm">
      <div class="card-body">
        <h2 class="card-title">Łączny czas</h2>
        <p class="text-4xl font-bold text-secondary">24h</p>
        <p class="text-sm text-base-content/60">w tym tygodniu: 4h</p>
      </div>
    </div>
    <div class="card card-bordered bg-base-100 shadow-sm">
      <div class="card-body">
        <h2 class="card-title">Compliance</h2>
        <p class="text-4xl font-bold text-accent">85%</p>
        <p class="text-sm text-base-content/60">ostatnie 30 dni</p>
        <span class="badge badge-success">+5% vs poprzedni miesiąc</span>
      </div>
    </div>
  </div>

  <!-- Tabela sesji -->
  <div class="card card-bordered bg-base-100 shadow-sm">
    <div class="card-body">
      <h2 class="card-title">Ostatnie sesje</h2>
      <div class="overflow-x-auto">
        <table class="table table-zebra">
          <thead>
            <tr>
              <th>Data</th>
              <th>Czas</th>
              <th>Ciśnienie</th>
              <th>Wynik</th>
              <th>Status</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>2026-07-20</td>
              <td>60 min</td>
              <td>1500 hPa</td>
              <td>Bardzo dobry</td>
              <td><span class="badge badge-success">Ukończona</span></td>
            </tr>
            <tr>
              <td>2026-07-18</td>
              <td>45 min</td>
              <td>1500 hPa</td>
              <td>Dobry</td>
              <td><span class="badge badge-success">Ukończona</span></td>
            </tr>
            <tr>
              <td>2026-07-16</td>
              <td>60 min</td>
              <td>1500 hPa</td>
              <td>Średni</td>
              <td><span class="badge badge-warning">Przerwana</span></td>
            </tr>
          </tbody>
        </table>
      </div>
    </div>
  </div>

</main>

<!-- Footer -->
<footer class="footer footer-center p-4 bg-base-200 text-base-content/60 mt-8">
  <p>Prototyp v3 — Tailwind + DaisyUI | data-theme="light"</p>
</footer>

</body>
</html>

Krok 4.3: Weryfikacja spójności

# 1. Sprawdź czy 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. Sprawdź czy są twarde kolory (hex/RGB) — powinno być 0
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 (DaisyUI powinien je eliminować)"
done

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

Faza 5: Backend z tym samym frameworkiem

Backend używa tego samego frameworka CSS + biblioteki komponentów. Żadnych nowych zależności CSS.

Krok 5.1: Kopiuj konfigurację

# Skopiuj szablon HTML z frameworkiem do backendu
cp /var/www/projects/<projekt>/dashboard/index.html \
  /root/projects/<projekt>/src/templates/base.html

# Wyciągnij navbar i footer jako osobne szablony
# (w zależności od frameworka backendowego)

Krok 5.2: Implementacja z zachowaniem komponentów

opencode run --prompt '
Zaimplementuj backend dla projektu <projekt>.

ZACHOWAJ FRAMEWORK I KOMPONENTY:
1. Użyj TEGO SAMEGO frameworka CSS co prototyp (DaisyUI + Tailwind)
2. Użyj TYCH SAMYCH klas komponentów: navbar, card, btn, table, input, badge
3. ŻADNYCH nowych styli CSS — tylko gotowe klasy
4. Szablon bazowy: base.html z navbar, footer i DaisyUI CDN

Na podstawie .superpowers/sdd/phase-2-report.md:
- API endpoints
- Baza danych
- Integracja frontend-backend

Po implementacji: zweryfikuj HTTP 200 dla wszystkich stron.
' --auto

Porównanie v1 vs v2 vs v3

Playbook: 30-minutowy Builder Flow v3

Przygotowanie (2 min):

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

Brainstorming (5 min):

• [ ] Stwórz brainstorming-brief.md
• [ ] Uruchom opencode z pytaniami
• [ ] Odpowiedz na 20+ pytań
• [ ] Zapisz brainstorming-report.md

Specyfikacja (8 min):

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

Wybór frameworku (2 min):

• [ ] Pokaż 3 frameworki (Tailwind, Bootstrap, Bulma)
• [ ] Pokaż 5 bibliotek (DaisyUI, shadcn, Flowbite, Preline, Nuxt UI)
• [ ] Użytkownik wybiera → rekomendacja: Tailwind + DaisyUI

Design System (3 min):

• [ ] Wybierz motyw (data-theme: light, dark, emerald, cupcake...)
• [ ] Skonfiguruj CDN w szablonie

HTML mockupy (8 min):

• [ ] Uruchom opencode → wszystkie strony z DaisyUI
• [ ] Ustaw uprawnienia

Weryfikacja (2 min):

• [ ] Sprawdź HTTP 200
• [ ] Sprawdź linki
• [ ] Sprawdź spójność (framework załadowany, brak hexów)
• [ ] Zgłoś użytkownikowi

Ryzyka i wyzwania

Ryzyko 1: Opencode pisze własny CSS zamiast używać DaisyUI

Opencode (kimi-k2-7-code) może dodać inline style zamiast klas DaisyUI.

Rozwiązanie: W promptu dodaj: "NIE używaj style="" ani własnego CSS. Używaj TYLKO klas DaisyUI (btn, card, table, navbar, input, badge, alert, modal, dropdown, tabs, breadcrumbs, progress, loading, avatar). Jeśli potrzebujesz marginesu — użyj Tailwind (p-4, m-2, gap-4, flex, grid). Jeśli potrzebujesz koloru — użyj klas DaisyUI (text-primary, bg-base-100, badge-success)."

Ryzyko 2: CDN nie działa

DaisyUI przez CDN wymaga internetu. Jeśli serwer nie ma dostępu, strony się nie ładują.

Rozwiązanie: Użyj npm zamiast CDN: npm install tailwindcss @tailwindcss/vite daisyui@latest i build lokalnie. Lub sprawdź czy serwer ma dostęp do CDN: curl -s -o /dev/null https://cdn.jsdelivr.net/npm/daisyui@5/dist/full.min.css.

Ryzyko 3: Za dużo opcji (paraliż decyzyjny)

3 frameworki × 5 bibliotek = 15 kombinacji. Owner może nie wiedzieć co wybrać.

Rozwiązanie: CEO daje rekomendację: "Rekomenduję Tailwind CSS + DaisyUI. To najszybszy start — CDN, 30+ komponentów, wbudowane motywy. Jeśli nie masz preferencji — idziemy z tym."

Ryzyko 4: DaisyUI zmienia API między wersjami

DaisyUI v4 → v5 zmieniło system theme (z data-theme na CSS layers).

Rozwiązanie: CEO sprawdza aktualną wersję DaisyUI przed startem: curl -s https://cdn.jsdelivr.net/npm/daisyui@5/package.json | grep version. Prompt używa wersji z CDN, nie hardcodowanej.

Ryzyko 5: Brainstorming trwa za długo

20+ pytań może zająć 30 minut, co rozciąga cały proces.

Rozwiązanie: CEO skraca brainstorming do 10 najważniejszych pytań dla małych projektów. Dla dużych — pełne 20+ pytań.

Mierzenie sukcesu

Źródła (Linki URL)

• Tailwind CSS — dokumentacja
• DaisyUI — 30+ komponentów, motywy
• shadcn/vue — piękne, accessible komponenty
• Flowbite — 500+ komponentów, Figma
• Preline — 300+ komponentów, darmowy
• Nuxt UI — 200+ komponentów dla Nuxt
• Bootstrap 5 — dokumentacja
• Bulma — pure CSS framework
• Headless UI — unstyled accessible components
• superpowers — obra/superpowers GitHub
• opencode — kimi-k27/code
• Hermes Agent — Nous Research
• Builder Flow v1
• Builder Flow v2
• Builder Flow v3 — 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 — ten raport