desktop/docs/Umsetzungsanweisung/02_ORDNERSTRUKTUR_UND_GRUNDREGELN.md

Ordnerstruktur und Grundregeln

Grundsatz

Die Ordnerstruktur soll sich so nah wie sinnvoll an der bestehenden Nexus-Struktur orientieren.

Beibehaltene Strukturidee

• /public/ -> Web Root, globale Assets und Einstieg
• /api/ -> Backend- und API-Endpunkte
• /src/ -> Kernlogik, Services, Utilities
• /config/ -> Umgebungs-Configs
• /custom/apps/<app>/ -> installierbare Fach-Apps
• /system/apps/<app>/ -> System-Tools und interne App-Quellen
• /system/shell/<tool>/ -> globale Shell-Werkzeuge und shell-nahe Desktop-Helfer
• /partials/structure/ -> globale Layout-Bausteine
• /partials/landingpages/ -> Seiten oder Views
• /tools/ -> Worker, CLI, Hilfstools
• /debug/ -> Debug-Ausgaben

Neue zusätzliche Bereiche für die Desktop-UI

Empfohlene Ergänzungen:

• /src/Desktop/
  • Window Manager
  • Desktop Registry
  • Skin Resolver
  • Widget Layout Engine
• /public/assets/desktop/
  • globale Desktop-CSS
  • JavaScript für Fenster, Dock, Tray, Desktop-Interaktion
  • globale Debug-Infrastruktur fuer Admin-Widget, Debug-Bus und Debug-Fenster
• /partials/desktop/
  • Desktop Shell
  • Window Templates
  • Dock
  • Tray
  • Menu

Optional für die Übergangsphase:

• /Old-Nexus/
  • komplette Altbasis zur Sichtprüfung und als Entwicklungserinnerung
  • nur temporär

Wichtige Regel

Die klassische Modulstruktur bleibt erhalten.

Das bedeutet:

• installierbare Fach-Apps bleiben unter /custom/apps/<app>/
• der neue Desktop-Layer ist nur die neue Oberfläche
• Module dürfen nicht ungeordnet in den Desktop-Core verschoben werden
• gemeinsame Desktop-Mechaniken liegen nicht in Modulen, sondern im globalen Kern
• gemeinsame Debug-Grundlogik liegt ebenfalls nicht in Modulen, sondern im globalen Desktop-Core
• globale Shell-Werkzeuge sollen als eigene Einheiten unter /system/shell/ abgelegt werden

Trennung

Es gibt drei Ebenen:

1. globales System
2. Desktop-UI-Schicht
3. klassische Module

Was nicht passieren soll

• keine Vermischung von Fenster-Manager-Code mit Modulbusinesslogik
• keine Skin-spezifischen Sonderlösungen in einzelnen Modulen
• keine eigene globale Debug-Basis je Modul oder App
• keine harte Kopplung zwischen alter Seitenstruktur und neuem Desktop-Verhalten
• keine technische Abhängigkeit zu Old-Nexus/
• keine Includes, Imports, Autoloading-Pfade oder Assets aus Old-Nexus/

Architekturregel

Die neue Oberfläche muss so gebaut sein, dass:

• Module später als Fenster gerendert werden können
• Apps, Widgets und Seitenmodule aus einer gemeinsamen Registry kommen
• Skins ausschließlich Layout, Stil und Interaktionsdetails definieren
• globale Admin-Werkzeuge wie Debug als gemeinsame Desktop-Funktion bereitgestellt werden

Sonderregel für Old-Nexus/

Wenn Old-Nexus/ im neuen Projekt vorhanden ist, dann gilt verbindlich:

• nur lesen und vergleichen
• niemals direkt einbinden
• niemals als Referenzpfad im Produktivcode verwenden
• niemals als Dauerbestandteil der neuen Architektur einplanen
• nach Abschluss der Umsetzung wieder entfernen