Stand: 2026-07-14
Diese Datei ist der verbindliche Arbeitskontext fuer KI-Agenten bei Aufgaben an Designs, Themes, Skins, Menues und Design-Fenstern. Die erklaerende Menschen-Dokumentation steht unter Design, Themes und Skins.
Geltungsbereich
Unveraenderliche Architekturregeln
- Ein Design ist ein eigenstaendiges Paket unter dbx/design/{name}.
- Designpakete erben keine privaten CSS-, JS- oder Bilddateien voneinander.
- Fachlogik bleibt in Modulen; Designs enthalten Layout und Darstellung.
- Globale Infrastruktur wird weiterverwendet: Bootstrap, Bootstrap Icons, jQuery, core.js, dbxTPL, openWin, Ajax und UI-State.
- Ein oeffentlich waehlbares Design braucht htm/default.htm.
- [dbx:content] ist der verbindliche Marker fuer den Modul-/Seiteninhalt.
- Skins werden ueber dbx_color, Designs ueber dbx_design gefuehrt.
- Admin-Module mit _admin im Modulnamen werden fuer Administratoren gegen default_design_admin aufgeloest.
- Das horizontale Admin-Menue bleibt auch im Flowers-Frontend horizontal.
- Keine neue iframe-, Ajax-, Fenster- oder Persistenzarchitektur ohne einen ausdruecklichen Auftrag und eine Aktualisierung dieser Dokumentation.
- Geführte Design-Erstellung und Design-KI laufen über dbxDesign_admin beziehungsweise dbxKiDesignService; freie Dateischreibwege sind kein Ersatz.
Kanonische Laufzeitwerte
| Wert | Bedeutung | Quelle/Persistenz |
|---|---|---|
| dbx_design | gewaehltes Design oder Alias user/admin | Request und Remember-State |
| dbx_page | Design-Seitenvariante | Systemvariable |
| dbx_lng | aktive Sprache | Request und Remember-State |
| dbx_color | kanonische Skin-ID | Request und Remember-State |
| dbx_activ_design | optional bereits aufgeloestes Design | Systemvariable |
| dbx_activ_page | optional bereits aufgeloeste Page | Systemvariable |
| dbx_window | Fenstermodus; waehlt aktuell _window | Request/Systemvariable |
| dbx_ajax | nur Modulinhalt, keine Designschale | Request/Systemvariable |
Die Aliaswerte werden in dbxWebApp::check_design() aufgeloest:
Aktuelle Konfiguration:
Vor jeder Designaenderung lesen
Mindestens diese Dateien pruefen:
Bei Flowers zusaetzlich:
Aktuelle Designvertraege
dbxapp
flowers
Andere vorhandene Flowers-Dateien mit Namen wie skin-blau.css sind keine Freigabe, diese Varianten im Menue anzuzeigen. Die sichtbaren Optionen werden in dbxMenu::skin_options() festgelegt.
Design-Erkennung und Auswahl
dbxMenu::frontend_design_options() erkennt Verzeichnisse nach diesem Vertrag:
Eine KI darf fuer ein neues Design keine zweite statische Designliste einfuehren. Beschriftungen werden derzeit aus dem Verzeichnisnamen abgeleitet; dbxapp erhaelt die Sonderbeschriftung dbxapp.
Template-Vertrag
Ein default.htm muss die folgenden Aufgaben erfuellen:
Beim Kopieren eines Design-Templates sind harte Pfade auf das Ursprungsdesign vollstaendig zu ersetzen. Nur Vendor- und zentrale dbxapp-Ressourcen bleiben gemeinsam.
CSS-Vertrag
Entscheidungsregel:
Keine unnoetigen !important-Ketten erzeugen. Vor einem z-index-Fix zuerst Stacking Contexts (position, transform, filter, overflow, isolation) der beteiligten Eltern pruefen.
Fenster und Admin-Inhalte
Aktueller Ist-Zustand:
Die Bezeichnung _adminWin ist eine moegliche spaetere Zielrichtung, aber keine aktuelle Datei oder Runtime-Regel. Eine KI darf sie nicht dokumentieren oder verwenden, bevor Implementierung, Fallback und Tests existieren.
Erlaubte Aenderungen
- Ein bestehendes Design visuell verbessern.
- Eigene Design-Assets ergaenzen.
- Einen weiteren Skin ergaenzen, wenn auch Menue und Client-Normalisierung angepasst werden.
- Ein neues vollstaendiges Designpaket anlegen.
- Design-spezifische responsive oder Accessibility-Fixes vornehmen.
- Das Flowers-Menue scroll- und dropdownfaehig halten.
Nicht ohne ausdruecklichen Auftrag
- default_design_admin von dbxapp wegschalten.
- Admin- und Frontend-Rechte anhand des Designs entscheiden.
- Fachlogik in Design-JavaScript verschieben.
- dbxWebApp, dbxTPL oder core.js nur fuer eine optische Einzelkorrektur umbauen.
- ein Design von einem anderen privaten Designpaket abhaengig machen.
- neue Skin-IDs ohne server- und clientseitige Normalisierung einfuehren.
- eine _adminWin- oder iframe-Architektur nur teilweise implementieren.
Arbeitsablauf fuer KI-Agenten
- Auftrag einer Ebene zuordnen: globales Design, Skin, Systemkomponente oder Modulkomponente.
- Aktive Designstruktur und alle Selektoren der betroffenen Komponente lesen.
- Pruefen, ob der Fehler im Layout, Stacking Context, Overflow, UI-State oder Modul-CSS entsteht.
- Kleinste passende Ebene aendern.
- Cache-Buster in default.htm nur erhoehen, wenn Browsercache die geaenderte Design-Datei sonst verdeckt.
- Beide Designs auf Regression pruefen, wenn gemeinsame Menue- oder Core-Dateien geaendert wurden.
- Gast-, Benutzer- und Adminzustand testen.
- Light/Dark sowie responsive Breiten testen.
- Diese Referenz aktualisieren, wenn sich ein Architekturvertrag aendert.
Für ein vom Benutzer gestartetes KI-Design gilt stattdessen der kontrollierte Paketweg:
Die KI liefert nur Dateien unter result/design/. PHP, Module, DD, FD, Datenbankaktionen und freie Shell-Anweisungen sind in diesem Vertrag verboten.
Mindesttests
Abschlussbericht einer KI
Der Bericht nennt:
- geaenderte Design-, Modul- und Core-Dateien getrennt,
- sichtbare Auswirkung fuer dbxapp und flowers,
- gepruefte Rollen, Skins und Viewports,
- verbleibende Grenzen, insbesondere Fenster-/iframe-Isolation,
- ob ein Cache-Buster geaendert wurde.
Details zum Benutzer-Wizard und ZIP-Vertrag: Design Studio und KI-Wizard.