# UI-Design-Vorgaben für Module *(Quelle: `docs/core/ui-design-system.md` §0, gekürzt auf die für Module verbindlichen Regeln)* Diese Regeln werden **automatisch geprüft** — Verstöße blockieren die Marktplatz-Aufnahme (Prüf-Stufe 2, Stil-Compliance). | Regel | Erlaubt | Verboten | |---|---|---| | Buttons in der GUI | `btn btn-indigo`, `btn btn-red`, `btn btn-gray`, `btn btn-green` | `btn-primary` (Gradient, nur für Login/Reset reserviert) | | Native Dialoge | `showConfirmModal()`, eigene Modals | `alert()`, `confirm()`, `prompt()` | | HTML-Ausgabe von DB-Werten | `_esc(wert)` | Direktes `innerHTML = wert` | | Modul-CSS-Scope | Eigene Klassen mit Modul-Präfix (z.B. `.deinkey-`) | Überschreiben von Core-CSS-Klassen ohne Präfix | | Externe Scripts | Lokal unter `moduls//js/lib/` **oder** mit SRI-Hash (`integrity`+`crossorigin`) | CDN-Script ohne `integrity`-Attribut | | Neue HTML-Seiten | `` im `` | Fehlendes robots-Tag | ## Warum diese Vorgaben - **`btn-primary` nur Login/Reset:** Damit ein Nutzer auf einen Blick sieht, ob er sich in einem authentifizierten Bereich befindet oder nicht — ein Gradient-Button in der eingeloggten GUI würde das verwischen. - **Kein `alert()`/`confirm()`:** Native Browser-Dialoge lassen sich nicht stylen, blockieren den gesamten Tab und passen nicht ins Gesamtbild — jedes Modul nutzt dasselbe Modal-System. - **`_esc()` Pflicht:** verhindert XSS über Datenbankfelder, die Sonderzeichen enthalten könnten (siehe auch `03-security-rules.md`). Das vollständige Farb-/Komponenten-System (Buttons, Modals, Tabellen, Badges, Formulare) wird dir nach Sandbox-Zugang als Referenz-CSS bereitgestellt — für die reine Pflicht-Compliance oben genügen diese sechs Regeln. Weiter mit [05-mockup-guideline.md](05-mockup-guideline.md).