Stand: 2026-07-24

Dieser Bereich ist verbindlich. Eine KI, die in dbxapp arbeitet, muss diese Regeln einhalten.

Vor einer datenbasierten Modulentwicklung ist Verbindliches Modulhandbuch vollständig zu lesen und als Golden Path zu verwenden.

Fuer einzelne Fachbereiche gelten zusaetzliche, strengere Referenzen:

• Design: Design-KI-Referenz
• Design-Wizard und Antwort-ZIP: Design Studio und KI-Wizard
• Shop: Shop-KI-Referenz

Vor einer Aenderung in einem dieser Bereiche muss die passende Referenz vollstaendig gelesen werden. Eine Bereichsreferenz ergaenzt diese Regeln; sie hebt keine projektweite Sicherheits- oder Architekturregel auf.

Nicht anfassen

Kernel-Klassen und JavaScript-Libs sind tabu, ausser der Benutzer fordert genau diese Aenderung ausdruecklich an.

Tabu ohne ausdrueckliche Anforderung:

• dbx/include/dbxApi.php
• dbx/include/dbxWebApp.class.php
• dbx/include/dbxTPL.class.php
• dbx/include/dbxDB.class.php
• dbx/include/dbxDD.class.php
• dbx/include/dbxForm.class.php
• dbx/include/dbxReport.class.php
• dbx/js/lib/core.js
• dbx/js/lib/ajax.js
• dbx/js/lib/openWin.js
• dbx/js/lib/confirm.js
• andere Systemlibs

Diese Dateien werden genutzt, nicht ersetzt.

Keine neuen Wege erfinden

Verboten:

• eigener AJAX-Mechanismus neben ajax.js
• eigene Fensterlogik neben openWin.js
• eigene Confirm-Dialoge neben confirm.js
• direkter Browser-Storage ausserhalb von core.js
• direkte PDO-/SQL-Sonderwege in Fachmodulen, wenn dbxDB reicht
• selbstgebaute Reports mit Suche/Pagination statt dbxReport
• Formular-HTML komplett in PHP statt dbxForm/Templates
• private Modulmethoden, die lediglich dbx() oder get_system_obj() weiterreichen
• manuelles Setzen der von dbxDB verwalteten Owner-, Benutzer- und Zeitfelder
• DD-Felder über lokale $addField-Closures oder andere versteckende Hilfsabstraktionen definieren; verbindlich ist das explizite dbxapp-Exportformat mit TABLE, FIELDS und INDEXES
• pauschale Escape-Wrapper um normale DD-, Form- oder Reportwerte

Standardentscheidung

dbxKi-Regel

CMS-Inhalte, Seiten, Medien, Uebersetzungen und SEO-Daten werden von einer KI nicht direkt in der Datenbank geaendert. Eine KI nutzt dafuer dbxKi.

Wenn Codex, Cursor oder ein vergleichbarer Agent Zugriff auf die lokale Installation haben, ist der direkte Weg zu verwenden:

Der erste Aufruf ist system.describe. Danach werden erlaubte Aktionen, Parameter, Tokens und Beispiel-Requests aus der Antwort verwendet. Der ZIP-Bundle-Weg ist nur fuer KI-Systeme ohne direkten Datei- oder HTTP-Zugriff gedacht.

Vorgehen bei neuen Funktionen

1. Verbindliches Modulhandbuch lesen.
2. Vorhandene Module und Templates suchen.
3. Routen in lesend und mutierend klassifizieren.
4. DD/FD pruefen oder modellieren.
5. Template und eindeutige {i}-Targets anlegen.
6. dbxForm oder dbxReport verwenden.
7. Aktionen als Templates bauen.
8. JavaScript nur ueber vorhandene Libs anbinden.
9. Mutierende GETs mit vorhandenem Action-Token schützen.
10. Rechte, normalen Fallback, Ajax und Mehrfachinstanzen testen.
11. dbx() und Systemobjekte direkt verwenden; keine Aliasmethoden ohne eigene Fachverantwortung.
12. Automatische dbxDB-Systemfelder nicht im Modul duplizieren.
13. Keine unrelated Refactors.

Kernel- und Größenregel

Eine große Kernelklasse wird nicht allein wegen ihrer Größe aufgeteilt. dbxDB, dbxDD, dbxForm und dbxReport bleiben die öffentlichen Fassaden. Eine interne Extraktion erfordert einen nachgewiesenen Nutzen, kompatible API und Regressionstests. Eine KI darf keine neuen öffentlichen Parallelfassaden erfinden.

Dashboard-Regel

Dashboard-Templates definieren nur Aufteilung.

Gut:

Schlecht:

• Dashboard baut eigene SysMsg-Liste.
• Dashboard kopiert Reportlogik.
• Dashboard hat Sonderlogik fuer Collapse, obwohl Report/Utility das kann.

dbx_edit-Regel

Der Interpreter laeuft fuer die Webseitenausgabe auch bei dbx_edit > 0. Nur im Template-Editor wird Rohtext geschuetzt.

Ziel

KI soll dbxapp-Code so erweitern, als waere sie ein vorsichtiger Entwickler im Projekt: vorhandene Wege verstehen, kleine Aenderungen machen, Systemkonzepte respektieren.