Lovable Rulebook v1.0

Standaard werkwijze – ontwerp, code, UI, releases, updates

1. Doel van dit rulebook

Een vaste werkwijze die alle toekomstige Lovable-projecten:

• voorspelbaar maakt

• veilig maakt

• onderhoudsbaar houdt

• schaalbaar houdt

• en altijd één duidelijke rode draad volgt

Dit is jouw blauwdruk / architectuurhandboek.

2. Kernprincipes

1. Eenvoud boven complexiteit
   Alles moet zonder uitleg te begrijpen zijn.

2. Data-first design
   Database & types bepalen de code, niet andersom.

3. Consistente componenten
   Nooit 2 varianten van hetzelfde UI-element.

4. Categorie bepaalt gedrag
   (zoals T/A toggles → voor ALLE gekoppelde producten)

5. Inline documentatie via componenten
   Elke belangrijke component bevat 1 blok commentaar:

   • Doel

   • Props

   • Verwachte output

   • Afhankelijkheden

6. Release = klein, veilig, incrementeel
   Geen grote batches, altijd iteratief.

3. Bestandsstructuur Richtlijn

src/
  components/
    ui/
    cards/
    forms/
  pages/
    products/
    categories/
    customers/
    bon/
  lib/
    api/
    supabase/
  styles/
  types/

Regels:

• Eén component per bestand

• Geen dubbele styling → Tailwind + 1 util bestand

• Geen logica in UI-components → logica gaat naar /lib

4. Frontend Workflow (Lovable)

4.1 Nieuwe feature bouwen

1. Use-case beschrijven (max 3 regels)

2. Type aanpassen indien nodig

3. DB lezen → UI schetsen → component maken

4. Page integratie

5. Visueel finetunen

6. Testen op mobiel → desktop → print (BON)

4.2 Bugfix workflow

1. Reproduceer

2. Vind bron (component, state, database)

3. Fix klein

4. Test op mobiel

5. Deploy

4.3 UI-regels (standaard)

• Buttons altijd:

  • rechts = primaire actie

  • links = annuleren

• Shadow alleen bij “onverwerkt”

• Border alleen bij “verwerkt”

• Iconen minimalistisch (Apple-style)

5. Data & Sync Regels

5.1 Koppeling Lovable ↔ Supabase

Gouden regel:
FRONTEND schrijft nooit directe businesslogica; database en types bepalen wat mag.

5.2 State Management

• React state voor UI

• Supabase realtime alleen voor live BON

• Geen global state tenzij strikt nodig

5.3 Performance

• Pagina’s laden via:

  • useEffect(() => loadData())

  • caching in memory

• Lijsten altijd pagineren als > 200 items

6. Categorie-gestuurd Systeem (zoals T/A)

Altijd leidend.
Categorie = eigenaar van presentatie:

• show_text

• show_image

• image_url

Producten erven ALTIJD deze instellingen.

7. Veiligheid

• Geen client-side filtering voor rechten

• Geen inline secrets

• Validatie dubbele input

• Uploads alleen naar eigen bucket

8. Release Protocol

1. Commit message formaat

[feature] categorie T/A system
[fix] price rendering decimal
[ui] mobile header update

2. Testflow:

   • mobiel klein

   • iPad

   • desktop

   • BON print

3. Deploy → review → acceptatie

9. Roadmap Format (3 weken)

Week 1: Structuur & database
Week 2: UI / UX onboarding
Week 3: Performance & polish

Altijd in kleine stappen.

10. Blauwdruk / Prompt

Dit regelboek bepaalt ALLE toekomstige opdrachten.
Bij elke nieuwe taak gelden de vaste regels:

• Hou het simpel

• Hou het consistent

• Hou het schaalbaar

• Categorie bepaalt gedrag

• Database bepaalt logica

• UI moet Apple-clean zijn

Rulebook v1.0 – updatebaar
Je mag altijd revisies vragen: v1.1, v1.2, …