Verbindliche Regeln fuer KI-Agenten

Stand: 2026-07-14

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

Fuer einzelne Fachbereiche gelten zusaetzliche, strengere Referenzen:

• Design: Design-KI-Referenz
• 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

Standardentscheidung

Aufgabe	Zu verwenden
HTML/Layout	dbxTPL
Formular	dbxForm
Liste	dbxReport
Daten	dbxDB
Struktur	DD
Formularsicht	FD
AJAX	ajax.js
Fenster	openWin.js
Confirm	confirm.js
UI-State	core.js
Modul einbetten	[modul=...]...[/modul]
CMS/KI-Aenderung	dbxKi

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:

?dbx_modul=dbxKi&dbx_run1=api

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. Vorhandene Module/Templates suchen.
2. DD/FD pruefen.
3. Route festlegen.
4. Template anlegen oder erweitern.
5. dbxForm oder dbxReport verwenden.
6. Aktionen als Templates bauen.
7. JavaScript nur ueber vorhandene Libs anbinden.
8. AJAX-Target eindeutig machen.
9. Keine unrelated Refactors.

Dashboard-Regel

Dashboard-Templates definieren nur Aufteilung.

Gut:

<div class="dbx-admin-dashboard-slot">
   [modul=dbxAdmin]dbx_run1=sysmsg&dbx_run2=list_sysmsg[/modul]
</div>

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.