# Pflicht-Klick-Dummy vor der technischen Umsetzung

*(Quelle: `docs/core/module-mockup-guideline.md`, gekürzt)*

Bevor du mit Datenmodell, Workflow oder Frontend-Code beginnst, brauchst du einen **HTML-Klick-Dummy**
mit Demo-Daten — das ist Teil der Prüf-Pipeline (Stufe 1, Konsistenz), nicht optional.

```
Konzept-Dokument → Klick-Dummy (Demo-Daten) → deine eigene Abnahme
  → erst danach: Datenmodell-Migrationen → API-Workflow → Frontend-Code → Sandbox-Deploy
```

**Warum:** Ein Layout-, Rollen- oder Prozessfehler ist im Dummy eine Minute Änderungsaufwand.
Im fertigen Datenmodell + Workflow + Frontend ist derselbe Fehler eine Migration, mehrere
Workflow-Nodes und ein Redeploy.

## Pflichtbestandteile

1. **CI-Treue** — exakte Übernahme der Design-Tokens aus [04-ui-design-guidelines.md](04-ui-design-guidelines.md),
   keine eigene Farbpalette „weil es nur ein Dummy ist".
2. **Alle Rollen-Ansichten, nicht nur eine.** Dein Modul-Manifest deklariert, welche Rollen dein
   Modul bedient (`roles.sa_features`/`ma_features`/`user_permission`, siehe
   [01-manifest-schema.md](01-manifest-schema.md)) — der Dummy muss für **jede** davon eine echte
   Ansicht zeigen, nicht eine reduzierte Version derselben Seite.
3. **Dashboard-Widget-Vorschau**, falls dein Modul Widgets deklariert (`widgets[]` im Manifest) —
   wie sie im Mandanten-Dashboard tatsächlich aussehen würden.

Weiter mit [06-submission-review-process.md](06-submission-review-process.md).