Das Frontend von dbXapp ist normalerweise CMS-getrieben. Seiten werden ueber Permalinks gefunden, aus Content-Datensaetzen gerendert und koennen Module einbetten.

CMS-Funktionalitaet

Das CMS bietet:

Seitenbaum
Content-Seiten
Mehrsprachigkeit
Medienverwaltung
SEO-Daten
Permalink-Index
Content-Cache
Modul-Inclusions
Template-Auswahl je Inhalt
Admin-Bearbeitung im Laufzeitkontext

Content-Ablauf

Permalink
  -> Content aufloesen
  -> Sprache/Design bestimmen
  -> Content-Template laden
  -> Modul-Inclusions interpretieren
  -> Cache beruecksichtigen
  -> HTML ausgeben

CMS- und dbxKi-Ablauf

Modul-Inclusion im CMS

Content kann Module enthalten:

[modul=dbxContact]dbx_run1=tickets[/modul]

Mit Parametern:

[modul=dbxContent]dbx_run1=show&cid=17[/modul]

Der Interpreter fuehrt diese Inseln aus. Im Template-Editor bleiben sie Rohtext.

Content-Bereiche und Spalten

Das CMS kann Content mit einfachen Markern in Bereiche aufteilen. Ein Template entscheidet, welche Slots existieren:

<section class="cms-hero {cms:hero_class}" style="{hero:style}">
   <div class="hero">{cms:hero}<div class="hero-text">{cms:hero_text}</div></div>
</section>
 
<section class="cms-header header">{cms:header}</section>
 
<section class="cols cols-{cms:cols}">
   <div class="col col-1">{cms:col1}</div>
   <div class="col col-2">{cms:col2}</div>
   <div class="col col-3">{cms:col3}</div>
</section>
 
<footer class="footer">{cms:footer}</footer>

Im Editor trennt der Inhalt Bereiche ueber einfache Marker, z.B.:

<hr class="dbx-cms-marker dbx-cms-marker-header"
    data-dbx-marker="dbx:header" data-label="Header">
 
<hr class="dbx-cms-marker dbx-cms-marker-footer"
    data-dbx-marker="dbx:footer" data-label="Footer">

Text vor, zwischen und nach diesen Markern wird vom CMS-Renderer in die passenden Slots gelegt. Spalten entstehen ueber Templates mit {cms:col1}, {cms:col2} und {cms:col3}. Dadurch braucht der Content keine eigene PHP-Logik, um mehrspaltig oder mit Header/Footer dargestellt zu werden.

Mehrsprachigkeit

Content kann pro Sprache gefuehrt werden. Je nach Modulstruktur werden Sprachfelder, eigene Tabellen oder Verknuepfungen ueber lng_uid verwendet.

Wichtige Punkte:

Sprache wird ueber dbx_lng und Remember-State gefuehrt.
Permalinks muessen sprachbezogen eindeutig sein.
Cache muss bei Content-Aenderungen invalidiert werden.

Content-Cache

Der Content-Cache beschleunigt Permalink-Seiten. Er ist fuer oeffentliche Seiten gedacht, nicht fuer dynamische Admin-Reports.

Typische Cache-Inhalte:

gerenderte Content-Seiten
Permalink-/Home-Indizes
sprachbezogene Metadaten

dbxKi

dbxKi ist die KI-Schnittstelle fuer CMS- und Modulaufgaben. Sie soll strukturierte Vorschlaege liefern, aber nicht eigenmaechtig die dbXapp-Regeln umgehen.

Moegliche Aufgaben:

Content-Entwurf
SEO-Texte
Uebersetzung
Modul-Briefings
Strukturvorschlaege fuer Seiten
Erklaerung vorhandener Templates

Visuelle CMS-Nutzung mit dbxKi

dbxKi ist nicht nur eine technische Schnittstelle. Es ist auch fuer die menschenfreundliche Arbeit im CMS gedacht. Der Benutzer soll im CMS gefuehrt werden: Seite auswaehlen, Aufgabe beschreiben, Kontext bereitstellen, Vorschlag pruefen und erst danach speichern.

Ein typischer Ablauf fuer einen Redakteur:

CMS oeffnen
  -> Seite, Sprache und Template sehen
  -> Aufgabe fuer dbxKi formulieren
  -> Vorschlag/Preview anzeigen
  -> Aenderungen visuell pruefen
  -> ausfuehren und Content speichern
  -> Cache/Permalink-Index aktualisieren

Der Vorteil ist, dass der Benutzer nicht mit Datenbanktabellen, IDs oder internen Speicherformaten arbeiten muss. Die Oberflaeche zeigt die Seite und die relevanten CMS-Informationen. dbxKi liefert dazu einen strukturierten Vorschlag, der ueber die vorhandenen dbXapp-Wege ausgefuehrt wird.

Wichtig ist die Trennung:

Der Mensch entscheidet, welche Seite, Sprache und Aufgabe gemeint ist.
dbxKi erzeugt Vorschlaege, Jobs oder API-Aktionen.
dbXapp speichert nur ueber die vorhandenen CMS-, Form- und DB-Pipelines.

Dadurch bleibt die Arbeit gefuehrt und nachvollziehbar. Auch umfangreiche Aufgaben wie neue Seite anlegen, Seite uebersetzen, SEO-Texte verbessern oder Hero-Bild zuordnen bestehen aus wenigen Schritten.

Direkter KI-Zugriff fuer Codex und Cursor

KI-Werkzeuge wie Codex oder Cursor koennen direkt auf eine lokale dbXapp- Installation zugreifen, wenn sie Zugriff auf den Projektordner und/oder den lokalen HTTP-Endpunkt haben. Dann ist kein manuelles Hochladen und Herunterladen einer ZIP-Datei noetig.

Der direkte Weg laeuft ueber das Modul:

?dbx_modul=dbxKi&dbx_run1=api

Die KI ruft zuerst system.describe auf. Danach kennt sie die erlaubten Aktionen, Pflichtparameter, Sprachen, Tokens und Beispiel-Requests. Sie darf CMS-Daten dann nicht direkt per SQL aendern, sondern nutzt die von dbxKi bereitgestellten Aktionen.

Empfohlener Ablauf fuer Codex/Cursor:

system.describe
  -> cms.snapshot, folder.list, page.list oder page.get
  -> Aenderung als preview planen
  -> Preview-Ergebnis auswerten
  -> execute_request aus Preview senden
  -> Ergebnis pruefen

Beispiel fuer den ersten API-Aufruf:

{
  "action": "system.describe"
}

Beispiel fuer eine kontrollierte Aktualisierung:

{
  "action": "page.update",
  "mode": "preview",
  "params": {
    "lng": "de",
    "id": 12,
    "patch": {
      "title": "Neuer Seitentitel"
    }
  }
}

Die Preview liefert einen ausfuehrbaren Request. Dadurch muss die KI nicht raten, welche Parameter beim Speichern notwendig sind. Der Ablauf ist gefuehrt: erst lesen, dann planen, dann ausfuehren.

ZIP-Bundle fuer KI ohne direkten Zugriff

Der ZIP-Weg ist fuer Situationen gedacht, in denen die KI keinen direkten Zugriff auf die Installation hat, zum Beispiel bei einem externen Chat-System. Dann exportiert der Mensch ein Briefing, die KI erzeugt daraus ein Antwort- Bundle und der Mensch importiert dieses Bundle wieder in dbXapp.

Briefing-ZIP exportieren
  -> KI erstellt job.json und optionale assets/
  -> Antwort-ZIP importieren
  -> dbxKi prueft Job und zeigt Preview
  -> Mensch fuehrt aus

Bei Codex oder Cursor auf demselben Rechner ist dieser ZIP-Umweg normalerweise nicht notwendig. Dort kann der direkte API- oder Projektzugriff benutzt werden. Der ZIP-Weg bleibt trotzdem wichtig, weil er einen sicheren Austauschweg fuer Installationen ohne gemeinsamen Dateisystem- oder HTTP-Zugriff bietet.

dbxKi-Ablauf

Briefing
  -> Kontext sammeln
  -> Preview erzeugen
  -> Mensch prueft
  -> Execute/Speichern
  -> Cache/Index aktualisieren

KI-Aktionen sollen preview-faehig sein. Direkte irreversible Aktionen ohne Benutzerkontrolle sind zu vermeiden.

Content mit dbxKi bearbeiten: menschliche Sicht

Der Mensch arbeitet immer aus der dbXapp-Oberflaeche heraus. Er muss keine Datenbanktabellen, Dateipfade oder internen Speicherformate kennen.

Typische Einstiege:

Neue CMS-Seite: ?dbx_modul=dbxKi&dbx_run1=briefing_page_create
Bestehende CMS-Seite aendern: ?dbx_modul=dbxKi&dbx_run1=briefing_page_update
CMS-Seite uebersetzen: ?dbx_modul=dbxKi&dbx_run1=briefing_page_translate
Import fertiger KI-Antwort: ?dbx_modul=dbxKi&dbx_run1=bundle

Der menschliche Ablauf fuer eine Content-Aenderung:

dbxKi-Briefing oeffnen
  -> Aufgabe waehlen: neu, aendern oder uebersetzen
  -> Seite, Sprache, Zielordner und Template auswaehlen
  -> zu aendernde Felder festlegen
  -> Medien- und Hero-Regeln festlegen
  -> erlaubte Bootstrap-Komponenten auswaehlen
  -> Auftragstext schreiben
  -> KI-Auftrags-ZIP exportieren oder direkten API-Weg nutzen
  -> Antwort-ZIP importieren
  -> dbxKi prueft manifest.json und job.json
  -> Preview pruefen
  -> ausfuehren
  -> CMS-Seite im Editor und Frontend kontrollieren

Wichtig fuer den Redakteur:

Der Mensch entscheidet, welche Seite, Sprache und Aufgabe gemeint ist.
Die Auswahl der Bootstrap-Komponenten ist Teil des Auftrags. Nur die im Briefing ausgewaehlten Komponenten duerfen in den Content eingebaut werden.
Medien werden ueber die Medienverwaltung erzeugt oder zugeordnet, nicht ueber manuelle files/media/...-Pfade im HTML.
Hero-Bilder sind kein normaler HTML-Inhalt. Sie werden ueber die Hero- oder Medien-Aktionen von dbxKi ersetzt oder neu angelegt.
Der Import fuehrt nicht blind Fremdcode aus. dbxKi validiert den Job und benutzt die vorhandenen CMS-Pipelines.
Nach dem Ausfuehren werden Cache, Permalink-Index und Medienzuordnungen ueber die dbXapp-Wege aktualisiert.

Content mit dbxKi bearbeiten: KI-Sicht

Die KI denkt nicht ueber die komplette dbXapp-Implementierung nach. Sie liest den Auftrag und fuellt das feste Antwortschema. Die Ausfuehrung macht dbxKi.

Die KI liest im Auftrags-Bundle mindestens:

KI-AUFTRAG.md
briefing.json
context.json
job.vorlage.json
manifest.json
optionale Medien- oder Beispiel-Dateien unter assets/

Verbindlicher KI-Ablauf fuer CMS-Content:

Auftrag lesen
  -> briefing.json und context.json auswerten
  -> erlaubte Felder, Sprache und Seiten-ID uebernehmen
  -> erlaubte Bootstrap-Komponenten beachten
  -> job.vorlage.json nach job.json kopieren
  -> alle ___KI_FUELLEN___ ersetzen
  -> nur erlaubte actions verwenden
  -> manifest.json beibehalten
  -> optionale assets/ passend referenzieren
  -> antwort.zip mit manifest.json, job.json, README.md und assets/ liefern

Erlaubte Content-Aktionen werden von dbxKi vorgegeben, zum Beispiel:

page.create
page.update
translation.apply
page.hero_replace_image
page.hero_create_image
media.create_base64
media.create_image_variant
media.assign

Regeln fuer die KI:

Kein SQL, kein PHP, keine direkten Datei- oder Datenbank-Aenderungen.
Keine eigenen Tools oder Nebenprozesse fuer die Ausfuehrung erfinden.
job.json ist die einzige fachliche Antwortstruktur fuer dbxKi.
IDs, Sprache, Template, Ordner und bestehende Content-Felder aus dem Kontext nicht frei raten.
Felder, die nicht im Auftrag stehen, unveraendert lassen.
Content ist HTML, nicht Markdown.
Modul-Inclusions wie [modul=...]...[/modul] exakt erhalten, ausser der Auftrag fordert die Aenderung ausdruecklich.
Bootstrap-Komponenten nur verwenden, wenn sie im Briefing erlaubt wurden und fuer Jodit/CMS sinnvoll nutzbar sind.
Inline-Medien nach media.create_* ueber die von dbxKi gelieferten inline_src- oder inline_img-Werte einbauen.
Neue Medien immer anschliessend mit media.assign zuordnen, wenn sie im CMS als Hero, Gallery oder Inline-Medium erscheinen sollen.
Bei direktem API-Weg zuerst system.describe lesen, dann Guide/Preview nutzen und den gelieferten execute_request unveraendert ausfuehren.

Module mit dbxKi bearbeiten: menschliche Sicht

Neue Module werden zuerst ueber den Modul-Wizard angelegt. dbxKi fuer Module ist fuer die kontrollierte Bearbeitung bestehender Module gedacht.

Typische Einstiege:

Modul-Auftrag erstellen: ?dbx_modul=dbxKi&dbx_run1=briefing_module
Modul-Antwort importieren: ?dbx_modul=dbxKi&dbx_run1=module_bundle
Modul-API beschreiben: ?dbx_modul=dbxKi&dbx_run1=module_api&action=system.describe

Der menschliche Ablauf fuer Modul-Aenderungen:

Modul-Wizard nutzen, falls ein neues Modul benoetigt wird
  -> dbxKi Modul-Briefing oeffnen
  -> bestehendes Modul auswaehlen
  -> optional DD auswaehlen
  -> Aufgabe und Kontextumfang festlegen
  -> Auftrag fuer die KI schreiben
  -> KI-Auftrags-ZIP exportieren
  -> Antwort-ZIP importieren
  -> dbxKi validiert Modulname, Pfade, Actions und Schema
  -> dbxKi erstellt vor Schreibzugriff ein Modul-Backup
  -> Preview/Import-Ergebnis pruefen
  -> Modul im Admin und Frontend testen
  -> bei schwerem Fehler Modul-Backup wiederherstellen

Wichtig fuer den Admin:

dbxKi darf nur das ausgewaehlte Modul bearbeiten.
Aenderungen ausserhalb von dbx/modules/{modul}/ sind nicht Bestandteil eines Modul-Jobs.
DD-Dateien sind vollstaendig. Sie duerfen nicht von inc-Dateien abhaengen.
Jede DD gehoert zu ihrer eigenen DB-Tabelle.
DD-zu-DB-Sync laeuft ueber dbxKi und die dbXapp-Pipeline, nicht ueber manuelle SQL-Migrationen.
Templates werden ueber die dbXapp-Templatewege gelesen und geschrieben, sinngemaess wie dbx()->get_tpl() und dbx()->set_tpl().
Formulare sollen dbxForm-Konventionen nutzen.
Reports sollen dbxReport-Konventionen nutzen, inklusive Multi-Select, Multi-Delete, Edit, Detail, Callback-Funktionen und Remember-State, wenn der Auftrag das verlangt.

Module mit dbxKi bearbeiten: KI-Sicht

Die KI bearbeitet kein Projekt frei. Sie liefert einen Modul-Job im festen Schema. dbxKi prueft und schreibt danach ueber eigene Funktionen.

Die KI liest im Modul-Auftrag mindestens:

KI-AUFTRAG.md
briefing.json
module.describe.json
module.snapshot.json
job.vorlage.json
manifest.json
optionalen Modulkontext unter module_context/

Verbindlicher KI-Ablauf fuer Modul-Aenderungen:

Modul-Auftrag lesen
  -> ausgewaehltes Modul und optionales DD feststellen
  -> module.describe.json als API-Vertrag nutzen
  -> module.snapshot.json fuer Bestand und Grenzen nutzen
  -> nur erlaubte module.* actions planen
  -> job.vorlage.json nach job.json kopieren
  -> alle ___KI_FUELLEN___ ersetzen
  -> README.md mit kurzer menschlicher Zusammenfassung schreiben
  -> antwort.zip mit manifest.json, job.json, README.md und optional assets/ liefern

Erlaubte Modul-Aktionen werden von dbxKi vorgegeben, zum Beispiel:

module.backup
module.file.write
module.file.delete
module.dd.write
module.dd.sync
module.template.set
module.asset.write

Regeln fuer die KI:

Niemals ausserhalb des ausgewaehlten Moduls schreiben.
Niemals Dateien durch direkte Shell-, SQL- oder Fremdtool-Anweisungen aendern.
Keine Migrationen oder Altlasten erzeugen, wenn die aktuelle Struktur der Auftrag ist.
DD-Dateien immer vollstaendig liefern.
DD-zu-DB-Sync nur mit module.dd.sync anfordern.
Templates ueber module.template.set liefern, nicht durch frei erfundene Speicherorte.
PHP-Code an den bestehenden Modulstil anpassen und vorhandene dbx()-, dbxForm-, dbxReport-, openWin-, Ajax-, Confirm- und Remember-Konventionen verwenden.
UI-State, Auswahlzustaende und schnelle Ajax-Aktionen nicht an Report-HTML- Reloads koppeln, wenn der Auftrag JSON-only oder no-response verlangt.
Kein globales Refactoring und keine Aenderungen an Core, anderen Modulen, globalen Templates, Konfiguration oder Datenbanken, ausser dbxKi erlaubt die konkrete Aktion im Job.
Die Antwort ist kein Patch-Text fuer einen Menschen, sondern ein ausfuehrbares dbxKi-Antwort-Bundle.

Ziel der festen dbxKi-Pipeline

Die feste Pipeline nimmt der KI die falschen Freiheitsgrade. Die KI muss nicht erraten, wie dbXapp intern speichert. Sie muss nur ein valides, kleines Schema fuellen. dbxKi uebernimmt Validierung, Backup, Preview, Ausfuehrung, Cache-Aktualisierung und die Einhaltung der dbXapp-Regeln.

Regeln

KI darf Content vorschlagen, aber Systemwege nicht umgehen.
Modul-Inclusions muessen exakt erhalten bleiben, wenn Content uebersetzt wird.
HTML-Struktur darf nicht unkontrolliert zerstoert werden.
Speichern laeuft ueber vorhandene Module, Forms und DB-Pipelines.