Builder Flow v2 — Design System first, multi-variant, spójny wizualnie

Builder Flow v2 to proces przekształcania luźnego pomysłu w działający prototyp strony/aplikacji, z naciskiem na spójność wizualną i wielowariantowość. Kluczowa różnica względem v1: zamiast generować obrazy, definiujemy Design System (temat) przed HTML-em, i dajemy użytkownikowi wybór między wieloma wariantami stylistycznymi.

Proces dzieli się na 5 faz:

1. Specyfikacja — superpowers SDD generuje specyfikację biznesową, techniczną i wizualną (lista stron)
2. Design System z multi-variant — 3 propozycje stylów wizualnych z pełnym theme (kolory, fonty, spacing, komponenty)
3. HTML mockupy — wszystkie strony HTML z wybranym theme, spójne wizualnie, z mockowanymi danymi
4. Prototyp do klikania — człowiek przegląda i zatwierdza
5. Backend — dopiero po zatwierdzeniu prototypu

Kluczowa zasada: theme first, potem strony, potem backend. Każda strona używa tych samych zmiennych CSS — zmiana theme zmienia cały prototyp.

Faza 0: Od pomysłu do backlogu

Krok 0.1: Opisz pomysł w jednym zdaniu

Każdy pomysł zaczyna się od jednego zdania, które odpowiada na 3 pytania:

• Dla kogo? — kto jest użytkownikiem końcowym
• Co robi? — główna funkcjonalność
• Czego chce? — jaki problem rozwiązuje

Przykład: "Aplikacja dla pacjentów normobarii, która pokazuje harmonogram sesji i postępy w terapii."

Krok 0.2: Stwórz kanban task

hermes kanban --board convertere create \
  --body 'IDEA: Aplikacja harmonogramu normobarii dla pacjentów
UŻYTKOWNIK: pacjenci centrum normobarii
FUNKCJONALNOŚĆ: harmonogram, postępy, powiadomienia
PROBLEM: pacjenci nie wiedzą kiedy mają sesje i jak postępują' \
  'Builder Flow v2: [Nazwa projektu] - Faza 0: Idea'

Faza 1: Specyfikacja przez superpowers SDD

Superpowers SDD (Superpowers Driven Development) generuje task briefy z precyzyjnymi specyfikacjami. To jest rdzeń procesu — tu powstaje trzywarstwowa specyfikacja.

Struktura katalogu SDD

<projekt>/.superpowers/sdd/
├── progress.md                    # Postęp: które taski skończone
├── phase-1-brief.md               # Specyfikacja biznesowa
├── phase-1-report.md              # Raport z fazy 1
├── phase-2-brief.md               # Specyfikacja techniczna
├── phase-2-report.md              # Raport z fazy 2
├── phase-3-brief.md               # Specyfikacja wizualna (lista stron)
├── phase-3-report.md              # Raport z fazy 3
├── design-system-brief.md         # Brief dla multi-variant design systemu (NOWE)
├── design-system-report.md        # Raport z 3 wariantami (NOWE)
├── theme.css                      # Wybrany theme jako CSS variables (NOWE)
├── task-1-brief.md                # Strona: Dashboard
├── task-1-report.md               # Raport: Dashboard HTML
├── task-2-brief.md                # Strona: Harmonogram
├── task-2-report.md               # Raport: Harmonogram HTML
└── ...

Krok 1.1: Specyfikacja biznesowa (phase-1)

CEO pisze brief fazy 1, który superpowers rozszerza:

cd /root/projects/<projekt>

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

## Cel
Zdefiniuj model biznesowy aplikacji harmonogramu normobarii.

## Wymagane sekcje
1. **Persona** — kto jest użytkownikiem (pacjent, recepcja, admin)
2. **User stories** — 5-10 historyjek użytkownika w formacie "Jako [persona], chcę [funkcja], żeby [korzyść]"
3. **Przepływ biznesowy** — jak użytkownik przechodzi przez aplikację krok po kroku
4. **Metryki sukcesu** — po czym poznamy że aplikacja działa

## Output
Plik phase-1-report.md z pełną specyfikacją biznesową.
EOF

Uruchom opencode z superpowers:

opencode run --prompt 'Przeczytaj .superpowers/sdd/phase-1-brief.md i wygeneruj phase-1-report.md z pełną specyfikacją biznesową. Użyj superpowers SDD workflow.' --auto

Efekt: phase-1-report.md zawiera persony, user stories, mapę przepływu, metryki.

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 URL (np. /dashboard, /sessions, /profile)
2. **Model danych** — encje, relacje, kluczowe pola
3. **API endpoints** — REST lub GraphQL, metody, request/response
4. **Frontend stack** — framework, biblioteki, routing
5. **Backend stack** — język, baza danych, hosting

## Output
Plik phase-2-report.md z pełną specyfikacją techniczną.
EOF

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

Efekt: phase-2-report.md zawiera listę URL-i, schemat bazy, endpointy API.

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

CEO tworzy brief, który definiuje każdą stronę z adresem URL, zawartością i elementami:

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 (np. /dashboard, /sessions/123)
2. **Cel strony** — co użytkownik tu robi
3. **Komponenty UI** — lista komponentów (navbar, karta, tabela, formularz, wykres, przycisk, input)
4. **Dane mockowe** — przykładowe dane do wyświetlenia
5. **Layout** — układ strony: co na górze, na środku, na dole
6. **Akcje użytkownika** — co może kliknąć, wpisać, przeciągnąć

## Przykład
### URL: /dashboard
- Cel: Podgląd postępów pacjenta
- Komponenty: navbar, karta "Postęp", tabela "Ostatnie sesje", przycisk "Dodaj sesję"
- Dane mock: 4 sesje w tabeli, wykres postępu 60%
- Akcje: kliknięcie sesji → /sessions/{id}, kliknięcie "Dodaj" → /sessions/new

## Output
Plik phase-3-report.md — lista wszystkich stron z komponentami i layoutem.
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

Efekt: phase-3-report.md zawiera kompletną listę stron z URL-ami, komponentami, layoutem i danymi mockowymi.

Faza 1.5: Design System z multi-variant (NOWOŚĆ v2)

To jest kluczowa nowość w v2. Zamiast generować obrazki, definiujemy Design System — zestaw zmiennych CSS, który definiuje wygląd wszystkich stron. Użytkownik dostaje 3 propozycje stylów, wybiera jedną, i wszystkie strony są generowane z tym samym theme.

Krok 1.5.1: Brief dla Design Systemu

CEO tworzy brief, który opisuje charakter aplikacji i wymagania wizualne:

cat > .superpowers/sdd/design-system-brief.md << 'EOF'
# Design System z multi-variant

## Cel
Stwórz 3 kompletne warianty stylistyczne (theme) dla aplikacji harmonogramu normobarii.

## Charakter aplikacji
- Medyczna, ale przyjazna dla pacjenta
- Nowoczesna, czysta, budząca zaufanie
- Ma pokazywać postępy i motywować

## Wymagane elementy każdego wariantu
1. **Nazwa wariantu** — krótka, opisowa (np. "Dark Professional", "Light Clean")
2. **Paleta kolorów** — primary, secondary, accent, background, text, success, warning, error
3. **Typography** — font-family, font-size dla h1-h6, body, small
4. **Spacing** — base unit, padding, margin, border-radius
5. **Komponenty** — style dla: navbar, karta, tabela, formularz, przycisk, input, badge, modal
6. **Przykładowy fragment** — krótki HTML z użyciem tych stylów (np. karta + przycisk + tabela)

## Wymagane 3 warianty
### Wariant A: "Light Clinical"
- Jasny, medyczny, sterylny, biały + błękit
- Budzi zaufanie, wygląda profesjonalnie
- Kolory: biały background, niebieski primary, delikatne cienie

### Wariant B: "Dark Modern"
- Ciemny, nowoczesny, technologiczny
- Dla aplikacji które chcą wyglądać "tech"
- Kolory: dark background, neon/akcent kolory

### Wariant C: "Warm Healing"
- Ciepły, naturalny, przyjazny
- Dla aplikacji wellness/health
- Kolory: ziemiste, zielenie, ciepłe beże

## Format outputu
Dla każdego wariantu: lista CSS custom properties (--color-primary, --font-body, itp.)
+ krótki przykład HTML z użyciem.

## Output
Plik design-system-report.md z 3 kompletnie zdefiniowanymi wariantami.
EOF

Krok 1.5.2: Generuj 3 warianty przez opencode

opencode run --prompt '
Przeczytaj .superpowers/sdd/design-system-brief.md, phase-1-report.md i phase-3-report.md.
Wygeneruj .superpowers/sdd/design-system-report.md z 3 wariantami stylistycznymi.

Dla KAŻDEGO wariantu:
1. Nazwa (np. "Light Clinical")
2. CSS custom properties (--color-primary, --color-bg, --font-body, --spacing-unit, itp.)
3. Style dla każdego komponentu z phase-3-report.md (navbar, karta, tabela, formularz, przycisk, input)
4. Przykładowy fragment HTML z użyciem tych stylów

Warianty:
A: Light Clinical — jasny, medyczny (biel + błękit)
B: Dark Modern — ciemny, technologiczny (dark + neon)
C: Warm Healing — ciepły, naturalny (zieleń, beż, brąz)

Wszystkie 3 warianty muszą być KOMPLETNE — każdy ma własne wartości dla każdego CSS property.
' --auto

Krok 1.5.3: Prezentacja użytkownikowi

CEO tworzy stronę prezentującą 3 warianty obok siebie:

opencode run --prompt '
Stwórz plik /var/www/projects/<projekt>/design-preview.html.

Na podstawie .superpowers/sdd/design-system-report.md, pokaż 3 warianty obok siebie w siatce.

Każdy wariant ma:
1. Nagłówek z nazwą
2. Paletę kolorów (kolorowe kółka/kwadraty z hexami)
3. Przykładowy fragment UI (karta, przycisk, tabela, input) wyrenderowany w tym stylu
4. Krótki opis stylu (1-2 zdania)

Design strony: czysty, neutralny, żeby nie konkurował z wariantami.
URL: https://r.10s.pl/<projekt>/design-preview/
' --auto

Krok 1.5.4: Użytkownik wybiera wariant

CEO zgłasza użytkownikowi:

[CEO] 3 warianty stylistyczne gotowe:
https://r.10s.pl/<projekt>/design-preview/

Opcje:
A: Light Clinical — jasny, medyczny, sterylny
B: Dark Modern — ciemny, technologiczny
C: Warm Healing — ciepły, naturalny

Który wariant wybierasz? Po wyborze generuję wszystkie strony w tym stylu.

Krok 1.5.5: Zapisz wybrany theme jako CSS variables

Po wyborze użytkownika, CEO zapisuje wybrany wariant jako plik CSS:

cat > /var/www/projects/<projekt>/theme.css << 'EOF'
/* ============================================
   THEME: [nazwa wariantu]
   Wybrany przez użytkownika: [data]
   ============================================ */

:root {
  /* Kolory */
  --color-primary: #2563eb;
  --color-primary-hover: #1d4ed8;
  --color-primary-light: #dbeafe;
  --color-secondary: #64748b;
  --color-accent: #f59e0b;
  --color-bg: #ffffff;
  --color-bg-secondary: #f8fafc;
  --color-surface: #ffffff;
  --color-text: #1e293b;
  --color-text-secondary: #64748b;
  --color-border: #e2e8f0;
  --color-success: #10b981;
  --color-warning: #f59e0b;
  --color-error: #ef4444;

  /* Typography */
  --font-body: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
  --font-heading: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
  --font-mono: 'SF Mono', 'Fira Code', monospace;
  --font-size-h1: 2rem;
  --font-size-h2: 1.5rem;
  --font-size-h3: 1.25rem;
  --font-size-body: 1rem;
  --font-size-small: 0.875rem;

  /* Spacing */
  --spacing-unit: 4px;
  --spacing-xs: calc(var(--spacing-unit) * 1);
  --spacing-sm: calc(var(--spacing-unit) * 2);
  --spacing-md: calc(var(--spacing-unit) * 4);
  --spacing-lg: calc(var(--spacing-unit) * 6);
  --spacing-xl: calc(var(--spacing-unit) * 8);

  /* Borders */
  --radius-sm: 4px;
  --radius-md: 8px;
  --radius-lg: 12px;
  --radius-full: 9999px;

  /* Shadows */
  --shadow-sm: 0 1px 2px rgba(0,0,0,0.05);
  --shadow-md: 0 4px 6px rgba(0,0,0,0.07);
  --shadow-lg: 0 10px 15px rgba(0,0,0,0.1);

  /* Transitions */
  --transition-fast: 150ms ease;
  --transition-normal: 250ms ease;
}

/* ============================================
   GLOBAL STYLES
   ============================================ */
*, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; }
body {
  font-family: var(--font-body);
  font-size: var(--font-size-body);
  color: var(--color-text);
  background: var(--color-bg);
  line-height: 1.6;
}

/* ============================================
   COMPONENTS
   ============================================ */

/* Navbar */
.navbar {
  display: flex;
  align-items: center;
  justify-content: space-between;
  padding: var(--spacing-md) var(--spacing-lg);
  background: var(--color-surface);
  border-bottom: 1px solid var(--color-border);
  box-shadow: var(--shadow-sm);
}
.navbar-brand {
  font-size: var(--font-size-h3);
  font-weight: 700;
  color: var(--color-primary);
  text-decoration: none;
}
.navbar-links {
  display: flex;
  gap: var(--spacing-md);
  list-style: none;
}
.navbar-links a {
  color: var(--color-text-secondary);
  text-decoration: none;
  padding: var(--spacing-xs) var(--spacing-sm);
  border-radius: var(--radius-sm);
  transition: color var(--transition-fast), background var(--transition-fast);
}
.navbar-links a:hover,
.navbar-links a.active {
  color: var(--color-primary);
  background: var(--color-primary-light);
}

/* Card */
.card {
  background: var(--color-surface);
  border: 1px solid var(--color-border);
  border-radius: var(--radius-md);
  padding: var(--spacing-lg);
  box-shadow: var(--shadow-sm);
  transition: box-shadow var(--transition-normal);
}
.card:hover {
  box-shadow: var(--shadow-md);
}
.card-title {
  font-size: var(--font-size-h3);
  font-weight: 600;
  margin-bottom: var(--spacing-sm);
  color: var(--color-text);
}

/* Button */
.btn {
  display: inline-flex;
  align-items: center;
  gap: var(--spacing-xs);
  padding: var(--spacing-sm) var(--spacing-md);
  border: none;
  border-radius: var(--radius-sm);
  font-size: var(--font-size-body);
  font-weight: 500;
  cursor: pointer;
  transition: all var(--transition-fast);
}
.btn-primary {
  background: var(--color-primary);
  color: white;
}
.btn-primary:hover {
  background: var(--color-primary-hover);
}
.btn-secondary {
  background: var(--color-bg-secondary);
  color: var(--color-text);
  border: 1px solid var(--color-border);
}

/* Table */
.table {
  width: 100%;
  border-collapse: collapse;
}
.table th {
  text-align: left;
  padding: var(--spacing-sm) var(--spacing-md);
  font-size: var(--font-size-small);
  color: var(--color-text-secondary);
  border-bottom: 2px solid var(--color-border);
  text-transform: uppercase;
  letter-spacing: 0.05em;
}
.table td {
  padding: var(--spacing-sm) var(--spacing-md);
  border-bottom: 1px solid var(--color-border);
}
.table tr:hover {
  background: var(--color-bg-secondary);
}

/* Input */
.input {
  width: 100%;
  padding: var(--spacing-sm) var(--spacing-md);
  border: 1px solid var(--color-border);
  border-radius: var(--radius-sm);
  font-size: var(--font-size-body);
  font-family: var(--font-body);
  transition: border-color var(--transition-fast);
}
.input:focus {
  outline: none;
  border-color: var(--color-primary);
  box-shadow: 0 0 0 3px var(--color-primary-light);
}

/* Badge */
.badge {
  display: inline-flex;
  align-items: center;
  padding: 2px var(--spacing-sm);
  border-radius: var(--radius-full);
  font-size: var(--font-size-small);
  font-weight: 500;
}
.badge-success { background: #dcfce7; color: #166534; }
.badge-warning { background: #fef3c7; color: #92400e; }
.badge-error   { background: #fee2e2; color: #991b1b; }

/* Layout helpers */
.container {
  max-width: 1200px;
  margin: 0 auto;
  padding: 0 var(--spacing-lg);
}
.grid {
  display: grid;
  gap: var(--spacing-lg);
}
.grid-2 { grid-template-columns: repeat(2, 1fr); }
.grid-3 { grid-template-columns: repeat(3, 1fr); }
.grid-4 { grid-template-columns: repeat(4, 1fr); }

@media (max-width: 768px) {
  .grid-2, .grid-3, .grid-4 { grid-template-columns: 1fr; }
}
EOF

Kluczowa zasada: Ten plik theme.css jest ładowany przez KAŻDĄ stronę prototypu. Zmiana theme = zmiana całego prototypu w jednym miejscu.

Faza 2: HTML mockupy z wybranym theme

Teraz, gdy mamy wybrany wariant i zdefiniowany theme jako CSS variables, generujemy wszystkie strony. Każda strona ładuje theme.css i używa jego zmiennych.

Krok 2.1: Generuj pierwszą stronę (wzór)

opencode run --prompt '
Stwórz plik /var/www/projects/<projekt>/dashboard/index.html.

Zasady:
1. Ładuje theme.css: <link rel="stylesheet" href="/<projekt>/theme.css">
2. Używa TYLKO CSS custom properties z theme.css (--color-primary, --spacing-md, itp.)
3. NIGDY nie używa twardych wartości CSS (hexów, pixelów) — tylko zmienne
4. Wszystkie komponenty używają klas z theme.css (.navbar, .card, .btn, .table, .input)
5. Realistyczne dane mockowe
6. Wszystkie linki prowadzą do innych stron prototypu
7. Stopka: "Prototyp v2 — design: [nazwa wariantu]"

Na podstawie phase-3-report.md, strona /dashboard.
Komponenty: navbar, karta postępu, tabela sesji, przycisk dodawania.
' --auto

Krok 2.2: Generuj wszystkie strony z jednym theme

CEO może uruchomić opencode z jednym promptem, który wygeneruje wszystkie strony naraz:

opencode run --prompt '
Stwórz kompletny prototyp HTML dla projektu <projekt>.

WAŻNE — SPÓJNOŚĆ WIZUALNA:
1. Najpierw przeczytaj /var/www/projects/<projekt>/theme.css — to są JEDYNE dozwolone wartości CSS
2. Każda strona ładuje: <link rel="stylesheet" href="/<projekt>/theme.css">
3. Używaj TYLKO klas i zmiennych z theme.css — żadnych własnych kolorów, fontów, paddingów
4. Jeśli potrzebujesz nowego komponentu — dodaj go do theme.css, NIE do strony

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

/var/www/projects/<projekt>/
├── index.html               — Strona główna (lista 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:
- Ładuje theme.css
- Używa tylko CSS variables
- Ma navbar, content, footer
- Realistyczne mock dane
- Linki wewnętrzne do innych stron

Po wygenerowaniu: NIE zmieniaj theme.css. Jeśli czegoś brakuje w theme.css — zgłoś w komentarzu.
' --auto

Krok 2.3: Weryfikacja spójności

CEO weryfikuje że wszystkie strony używają tych samych zmiennych:

# Sprawdź czy któraś strona ma twarde wartości kolorów (hex)
for f in $(find /var/www/projects/<projekt>/ -name 'index.html'); do
  hard_colors=$(grep -cE '#[0-9a-fA-F]{3,6}' "$f" || true)
  if [ "$hard_colors" -gt 5 ]; then
    echo "⚠️  $f — $hard_colors twardych kolorów (powinno być 0)"
  fi
done

# Sprawdź czy wszystkie strony ładują theme.css
for f in $(find /var/www/projects/<projekt>/ -name 'index.html'); do
  has_theme=$(grep -c 'theme.css' "$f" || true)
  if [ "$has_theme" -eq 0 ]; then
    echo "❌ $f — brak linku do theme.css"
  fi
done

# 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 3: Weryfikacja prototypu

Krok 3.1: Raport do zatwierdzenia

hermes kanban --board convertere comment <card-id> \
  "[CEO] ✅ Prototyp v2 gotowy do klikania:
Theme: [nazwa wariantu]
Design preview: https://r.10s.pl/<projekt>/design-preview/

Strony:
- https://10s.pl/<projekt>/dashboard/
- https://10s.pl/<projekt>/sessions/
- https://10s.pl/<projekt>/sessions/123/
- https://10s.pl/<projekt>/profile/
- https://10s.pl/<projekt>/settings/

Status: ✅ Wszystkie strony HTTP 200
Status: ✅ Wszystkie linki wewnętrzne działają
Status: ✅ Spójny design (wszystkie strony używają theme.css)
Status: ⏳ Czekam na zatwierdzenie przed backendem"

Krok 3.2: Iteracja — zmiana theme bez zmiany stron

To jest supermoc v2. Jeśli użytkownik mówi "zmień kolor primary na zielony" — CEO zmienia JEDNĄ linię w theme.css, a wszystkie strony automatycznie go używają:

# Zmiana koloru primary z niebieskiego na zielony
sed -i 's/--color-primary: #2563eb/--color-primary: #059669/' /var/www/projects/<projekt>/theme.css
sed -i 's/--color-primary-hover: #1d4ed8/--color-primary-hover: #047857/' /var/www/projects/<projekt>/theme.css
sed -i 's/--color-primary-light: #dbeafe/--color-primary-light: #d1fae5/' /var/www/projects/<projekt>/theme.css

# Weryfikacja — sprawdź wszystkie strony (bez zmiany HTML)
for path in /dashboard /sessions /profile; do
  curl -s -o /dev/null -w "HTTP %{http_code}\n" --max-time 5 "https://10s.pl/<projekt>$path/"
done

Bez zmiany HTML, bez regeneracji, bez błędów. Wszystkie strony odświeżają się z nowym kolorem.

Faza 4: Backend — z zachowaniem Design Systemu

Po zatwierdzeniu prototypu, backend implementuje ten sam design, używając tych samych zmiennych CSS.

Krok 4.1: Przenieś theme.css do backendu

# Kopiuj theme.css do projektu backendowego
cp /var/www/projects/<projekt>/theme.css /root/projects/<projekt>/src/static/theme.css

Krok 4.2: Implementacja przez SDD z zachowaniem theme

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

Zachowaj Design System z prototypu:
1. Plik theme.css jest w /root/projects/<projekt>/src/static/theme.css
2. WSZYSTKIE strony backendu muszą go ładować
3. ŻADNYCH nowych kolorów/fontów — tylko zmienne z theme.css
4. Jeśli potrzebujesz nowego komponentu — dodaj do theme.css, NIE do strony

Na podstawie .superpowers/sdd/phase-2-report.md:
- API endpoints
- Baza danych (schema + seed data)
- Integracja frontend-backend (zastąp mock data API calls)

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

Multi-variant: full workflow

Scenariusz: Użytkownik nie jest pewien stylu

CEO uruchamia pełny multi-variant workflow:

1. superpowers SDD → phase-1, phase-2, phase-3 (specyfikacje)
2. opencode → 3 warianty w design-system-report.md
3. opencode → design-preview.html (3 warianty obok siebie)
4. CEO → "Wybierz styl A, B lub C"
5. Użytkownik wybiera → CEO zapisuje theme.css
6. opencode → wszystkie strony z wybranym theme
7. CEO → weryfikacja spójności
8. Użytkownik zatwierdza → backend

Scenariusz: Użytkownik chce zmienić theme po prototypie

1. Użytkownik: "Zmieniam zdanie, chcę wariant B zamiast A"
2. CEO: generuje nowy theme.css z wariantu B
3. CEO: sprawdza czy strony nie mają twardych wartości (powinny mieć 0)
4. Weryfikacja HTTP 200
5. Gotowe — wszystkie strony w nowym stylu, bez zmiany HTML

Scenariusz: Użytkownik chce własny styl

1. Użytkownik: "Chcę coś pomiędzy A i C — jasny, ale z zielonym akcentem"
2. CEO: edytuje theme.css — zmienia --color-primary na zielony
3. CEO: dostosowuje --color-bg i --color-surface
4. Gotowe — wszystkie strony w nowym, unikalnym stylu

Case study: Aplikacja harmonogramu normobarii (v2)

Pomysł: Aplikacja dla pacjentów centrum normobarii.

Przebieg z multi-variant:

Czas od pomysłu do prototypu: ~30 minut.

Czas na zmianę koloru primary: ~1 sekunda (1 linia w theme.css).

Czas na zmianę całego wariantu: ~2 minuty (nowy theme.css).

Ryzyka i wyzwania

Ryzyko 1: Strona używa twardych wartości zamiast zmiennych

Najczęstszy błąd — opencode generuje HTML z hexami zamiast var(--color-primary).

Rozwiązanie: Weryfikacja automatem. CEO przed zamknięciem taska sprawdza:

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

Jeśli są twarde wartości: sed -i do zamiany lub zaregeneruj stronę z jaśniejszym promptem.

Ryzyko 2: Nowy komponent nie ma stylu w theme.css

Gdy opencode potrzebuje nowego komponentu (np. modal, tooltip), dodaje style inline, co łamie spójność.

Rozwiązanie: W promptu: "Jeśli potrzebujesz nowego komponentu — dodaj go do theme.css, a nie do strony. Nigdy nie używaj inline style."

Ryzyko 3: Użytkownik nie chce wybierać

Niektórzy użytkownicy mówią "po prostu zrób, nie chce mi się wybierać".

Rozwiązanie: CEO wybiera domyślny wariant (Light Clinical — bezpieczny, medyczny). Raportuje: "Wybrałem domyślnie Light Clinical. Jeśli chcesz inny styl — warianty B i C czekają."

Ryzyko 4: 3 warianty to za dużo/malo

Dla małych projektów (1-2 strony) 3 warianty to overkill.

Rozwiązanie: Dla małych projektów → 2 warianty. Dla dużych (10+ stron) → 3-4 warianty. Zasada: tyle wariantów, ile stron w prototypie / 3.

Playbook: 30-minutowy Builder Flow v2

Cel: Od pomysłu do klikalnego prototypu z Design Systemem w 30 minut

Przygotowanie (3 min):

• [ ] Opisz pomysł w 1 zdaniu
• [ ] mkdir -p /root/projects/<projekt> && cd $_ && git init
• [ ] Zapisz IDEA.md
• [ ] Stwórz kanban task

Specyfikacja (10 min):

• [ ] Uruchom opencode z superpowers (Faza 1: 3 specyfikacje)
• [ ] Przeczytaj phase-1/2/3-report.md

Design System z multi-variant (8 min):

• [ ] Stwórz design-system-brief.md
• [ ] Uruchom opencode → 3 warianty w design-system-report.md
• [ ] Uruchom opencode → design-preview.html
• [ ] Pokaż użytkownikowi, wybierz wariant
• [ ] Zapisz theme.css

HTML mockupy (7 min):

• [ ] Uruchom opencode → wszystkie strony z theme.css
• [ ] Ustaw uprawnienia: chmod -R 755 /var/www/projects/<projekt>/

Weryfikacja (2 min):

• [ ] Sprawdź HTTP 200 dla każdej strony
• [ ] Sprawdź linki wewnętrzne
• [ ] Sprawdź spójność (brak twardych kolorów)
• [ ] Zgłoś użytkownikowi URL-e

Mierzenie sukcesu

Porównanie v1 vs v2

Źródła (Linki URL)

• superpowers — obra/superpowers GitHub
• opencode — kimi-k27/code
• Hermes Agent — Nous Research
• 10s.pl — platforma hostingowa
• r.10s.pl — raporty i dokumentacja
• Builder Flow v1 — poprzednia wersja
• Builder Flow v2 — ta wersja
• CSS Custom Properties (MDN)
• Design Systems — patterny i komponenty

Źródła (Pliki)

• /root/.config/opencode/opencode.json — konfiguracja opencode (model kimi-k2-7-code, superpowers plugin)
• /root/.hermes/profiles/ceo/skills/devops/opencode-delegation/SKILL.md — skill delegacji do opencode
• /root/.hermes/profiles/ceo/skills/devops/delegation-todo-workflow/SKILL.md — Kanban workflow
• /root/.hermes/profiles/ceo/skills/devops/10s-pl-deploy/SKILL.md — deploy na 10s.pl
• /root/convertere/reports/builder-flow-v1.md — poprzednia wersja raportu
• /root/convertere/reports/builder-flow-v2.md — ten raport