Design Studio

On this page

User pathways
Why a new design is always your own package
File contract
Design slots
dbxForm, dbxTPL, dbxDB and dbxReport
AI order ZIP
AI response ZIP
Security and integrity rules
Compatibility test
Responsible classes
Related documentation

Reference status: 2026-07-25

dbxDesign admin is the mandatory interface for personalizing and creating complete dbxapp designs. The module combines a simple wizard with the controlled design pipeline of dbxKi.

User pathways

Without AI

Design Studio
  -> Ausgangsdesign wählen
  -> neuen technischen Namen vergeben
  -> Seitenaufteilung, Menüform, Breite und Footer wählen
  -> Branding, Logo, Farben und Typografie festlegen
  -> optional als Frontend-Standard setzen
  -> im Staging erzeugen und validieren
  -> Vorschau in neuem Tab

Entries:

?dbx_modul=dbxDesign_admin&dbx_run1=list

?dbx_modul=dbxDesign_admin&dbx_run1=wizard

The Wizard never changes the original design. He copies it as an independent technical basis, replaces all hard paths on the initial package and then creates the new shell. This keeps the existing styles available for dbxForm, dbxReport, CMS, Shop, Menus, Ajax and openWin without the new design depending on private files of another design at runtime.

With AI

Design Studio oder dbxKi-Hub
  -> Design-Briefing öffnen
  -> bestehendes Design ändern oder neues Design entwickeln
  -> Ziel, Aufteilung, Menü, Branding, Footer und Mobilverhalten beschreiben
  -> KI-Auftrags-ZIP herunterladen
  -> ZIP von der KI bearbeiten lassen
  -> Antwort-ZIP hochladen
  -> Dateiliste und Status neu/geändert/unverändert prüfen
  -> Anwendung per dbxForm bestätigen
  -> Backup, Staging, Vertragsprüfung und Aktivierung

Entry:

?dbx_modul=dbxKi&dbx_run1=briefing_design

Why a new design is always your own package

A direct change of dbxapp or Flowers It would be easy for an untrained user in the short term, but it would make updates, comparisons and recovery more difficult. This is why the standard action Personalisation technically a safe derivation:

The original remains.
The target name is clear.
no silent overwrites;
complete package check before activation;
as a front-end standard only after explicit selection;
new designs appear automatically in the existing design selection.

File contract

A design managed by the Wizard has additional design.json:

{
  "contract": "dbx.design.v1",
  "name": "meine-firma",
  "source_design": "dbxapp",
  "layout": "sidebar",
  "menu_style": "pills",
  "content_width": "wide",
  "managed_by": "dbxDesign_admin",
  "slots": ["logo", "branding", "footer"]
}

design.json is metadata and editing context. The runtime remains filed and requires neither a database nor a new configuration pipeline.

The core files written by the Wizard are:

htm/default.htm
htm/logo.htm
htm/branding.htm
htm/footer.htm
css/design-custom.css
design.json

All other component files come as an independent copy from the original design.

Design slots

The optional structuring takes place via:

Markers	Fragment file	Responsibility
`[dbx:logo]`	htm/logo.htm	Logo or trademark
`[dbx:branding]`	htm/branding.htm	Brand name and claim
`[dbx:footer]`	htm/footer.htm	Footer and window dock

dbxTPL::replace_design_slots() uses only markers that are present in the loaded design shell. If a fragment is missing, the respective optional marker is resolved empty. Designs without these markers remain byte-logical in the previous process. Fragments shall not be: [dbx:content] include other design slots; As a precautionary measure, the runtime removes such nested markers and the design validator rejects the package.

The central extension is necessary because reusable areas of the design shell are a runtime responsibility and not a module responsibility. There is no second template engine and no special treatment in dbxDesign admin.

dbxForm, dbxTPL, dbxDB and dbxReport

The wizard and all releases run over dbxForm.
Pages, maps, previews and results come from dbxTPL.
dbxDB is not used because design packages are deliberately filed.
dbxReport shall not be misused: The design overview has no DD or table source and requires neither DB-Pagination nor DB-Selection.

Thus, libraries are used according to their domain responsibility and not only formally called up.

AI order ZIP

A design briefing includes:

00-START.md
manifest.json
briefing.json
context.json
KI-AUFTRAG.md
RESULT-FORMAT.md
source-design/{design}/...

The complete design context is included. The AI does not have to guess paths, markers or dependencies. manifest.json Marks this package with the contract dbx.design.briefing. v1 and asks for an answer dbx.design.result. v1.

AI response ZIP

The answer has only:

manifest.json

result/design/{neue-oder-geänderte-dateien}

Example:

{
  "contract": "dbx.design.result.v1",
  "mode": "update",
  "source_design": "meine-firma",
  "target_design": "meine-firma",
  "summary": "Header, Branding und mobile Navigation überarbeitet"
}

No PHP and no free AI command is executed. dbxKi only handles files with allowed design extensions. The result is built on a copy in staging and verified against the full design contract.

Security and integrity rules

Module access is to the group admin restricted.
Use Wizard, Upload and Sharing dbxForm.
ZIP paths comprising: .., absolute paths, drive specifications or zero bytes are rejected.
PHP files and unknown file types are prohibited in AI results.
Inline handlers, inline scripts, external script/CSS resources, active SVG and own network transport in the design JavaScript are rejected.
[dbx:content Must occur exactly once.
dbx system marker, skin and core.js must be preserved.
Update creates a ZIP under files/sys/design-backups/.
Write accesses are made first in files/tmp/design-admin/.
A new design does not overwrite an existing package.
The AI does not change modules, DDs, FDs, databases or rights.

Compatibility test

A design shall be considered as activatable only if at least the following are satisfied:

htm/default.htm existing;
[dbx:content Exactly once;
{dbx:title, {dbx:design, {dbx:skin css and {dbx:skin class existing;
dbx/js/lib/core.js involved;
all design slots used have fragments;
No symbolic links;
Only allowed design file types.

In addition, check in the browser:

Admin access and dbxForm tokens;
Wizard steps and responsive representation;
Preview for top, sidebar and hybrid distribution;
Main and admin menu;
dbxForm, dbxReport, CMS, Shop, Ajax and openWin;
narrow and wide viewports;
all skins offered by the initial design.

Responsible classes

Category	Responsibility
dbxDesignAdmin	Routing and user interface
dbxDesignService	Pathline, generation, validation, backup and activation
dbxKiDesignService	Briefing ZIP, Response Import, Preview and Release
dbxTPL	Optional design slots in the page shell