asdasd

docs/ANLEITUNG.md

@@ -63,7 +63,7 @@ Dort koennen derzeit insbesondere verwaltet werden:
 
 ## Module
 
-Klassische Module liegen unter `modules/<modul>/` und koennen als normale `App` im Desktop erscheinen.
+Installierbare Fach-Apps liegen unter `custom/apps/<app>/` und koennen als normale `App` im Desktop erscheinen.
 
 Aktuell gilt:
 

docs/CONTENT.md

@@ -83,7 +83,7 @@ Stand dieser Datei:
 - Startmenue mit `User Setting Bereich`, `Funktion-Bereich` und `Auswahlbereich`
 - rechter `Infobereich` mit benutzerbezogener Sichtbarkeit
 - `User Self Management` als Setup-App
-- erster echter Modulpfad fuer klassische Module mit Modul-Discovery aus `modules/<modul>/`
+- erster echter App-Pfad fuer installierbare Fach-Apps mit Discovery aus `custom/apps/<app>/`
 - `Mining-Checker` als erstes angebundenes klassisches Modul
 - `Waehrungs-Checker` als zweites angebundenes klassisches Modul mit Desktop-Widget fuer Kursaktualisierung
 - versionierte API auf demselben Host unter `(staging.)desktop.kusche.berlin/api/v1/...`
@@ -103,23 +103,24 @@ Aus [README.md](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/docs/READ
 - `src/Desktop/` enthaelt zentrale Desktop-Mechaniken
 - die API bleibt auf demselben Host wie die Desktop-Shell und wird unter `/api/v1/...` versioniert
 - `partials/desktop/` enthaelt Shell-Templates
-- `modules/` bleibt Zielort fuer klassische Module
+- `custom/apps/` bleibt Zielort fuer installierbare Fach-Apps
+- `system/apps/` bleibt Zielort fuer System-Tools
 - `temp/nexus-module-import/` ist Rohbasis fuer importierte Nexus-Module
 - Keycloak bleibt das Auth-System
 
 ### Module
 
-Aus [modules/README.md](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/modules/README.md):
+Aus [custom/apps/README.md](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/custom/apps/README.md):
 
-- klassische Module bleiben unter `modules/<modul>/`
+- installierbare Fach-Apps liegen unter `custom/apps/<app>/`
 - Businesslogik wird nicht in den Desktop-Core verschoben
 - ein Desktop-Modul kann eigene `desktop.php`, `pages/`, `api/` und `assets/` Strukturen mitbringen
 - Modul-Assets muessen nicht in den globalen Desktop-Asset-Baum kopiert werden
 
 ### Aktueller Modulstand
 
-- `Mining-Checker` ist das erste Modul, das als echte Desktop-App aus `modules/mining-checker/` angebunden wird
-- `Waehrungs-Checker` ist das zweite Modul, das als echte Desktop-App aus `modules/fx-rates/` angebunden wird
+- `Mining-Checker` ist eine Desktop-App aus `custom/apps/mining-checker/`
+- `Waehrungs-Checker` ist eine Desktop-App aus `custom/apps/fx-rates/`
 - die Desktop-Shell kann Moduldefinitionen zentral erkennen und als `App` bereitstellen
 - wiederverwendbare Modul-Helfer liegen im globalen Kern, die Fachlogik bleibt im Modul
 

docs/README.md

@@ -25,7 +25,8 @@ Zentraler Dokumentationsindex fuer das Projekt.
 - `src/Desktop/` zentrale Desktop-Mechaniken
 - `src/ModulesCore/` gemeinsame Helfer fuer Modul-Discovery, Modul-HTTP und wiederverwendbare Modul-Anbindung
 - `partials/desktop/` Shell-Template
-- `modules/` Zielort fuer klassische Module
+- `custom/apps/` Zielort fuer installierbare Fach-Apps
+- `system/apps/` Zielort fuer nicht installierbare System-Tools
 - `temp/nexus-module-import/` Rohbasis fuer importierte Nexus-Module
 
 ## Fachliche Hinweise
@@ -49,10 +50,10 @@ Es gilt:
 
 Aktuell wichtig:
 
-- der Mining-Checker ist das erste als echtes Desktop-Modul angebundene Modul unter `modules/mining-checker/`
-- der Waehrungs-Checker ist als zweites echtes Desktop-Modul unter `modules/fx-rates/` angebunden
-- der Salesforce Translation Import ist als weitere Desktop-App unter `modules/salesforce-translation-import/` angebunden
-- der Boersenchecker ist als weiteres importiertes Desktop-Modul unter `modules/boersenchecker/` angebunden
+- der Mining-Checker ist als echte Desktop-App unter `custom/apps/mining-checker/` angebunden
+- der Waehrungs-Checker ist als Desktop-App unter `custom/apps/fx-rates/` angebunden
+- der Salesforce Translation Import ist als Desktop-App unter `custom/apps/salesforce-translation-import/` angebunden
+- der Boersenchecker ist als importierte Desktop-App unter `custom/apps/boersenchecker/` angebunden
 - Modul-Assets koennen ueber einen gemeinsamen Auslieferungsweg aus dem Modul selbst geladen werden
 - die API bleibt vorerst auf demselben Host und wird nicht auf `api.desktop.kusche.berlin` ausgelagert
 - das gemeinsame Admin-Debug-Widget neben der Uhr ist der Standard fuer Live-Debugging in Desktop und Native-Apps

docs/Umsetzungsanweisung/02_ORDNERSTRUKTUR_UND_GRUNDREGELN.md

@@ -10,7 +10,8 @@ Die Ordnerstruktur soll sich so nah wie sinnvoll an der bestehenden Nexus-Strukt
 - `/api/` -> Backend- und API-Endpunkte
 - `/src/` -> Kernlogik, Services, Utilities
 - `/config/` -> Umgebungs-Configs
-- `/modules/<modul>/` -> klassische Module
+- `/custom/apps/<app>/` -> installierbare Fach-Apps
+- `/system/apps/<app>/` -> System-Tools und interne App-Quellen
 - `/partials/structure/` -> globale Layout-Bausteine
 - `/partials/landingpages/` -> Seiten oder Views
 - `/tools/` -> Worker, CLI, Hilfstools
@@ -48,7 +49,7 @@ Die klassische Modulstruktur bleibt erhalten.
 
 Das bedeutet:
 
-- Module bleiben unter `/modules/<modul>/`
+- 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

docs/Umsetzungsanweisung/03_MIGRATION_BESTEHENDE_MODULE.md

@@ -19,7 +19,7 @@ Die Übernahme erfolgt zweistufig:
 
 Mindestens:
 
-- `/modules/`
+- `/custom/apps/`
 - relevante globale Dokumentationsdateien
 - gegebenenfalls Referenzdateien aus `/src/`, wenn Modul-Helfer benötigt werden
 

docs/WEITERENTWICKLUNG.md

@@ -56,7 +56,8 @@ Verbindlich ist:
 
 ## Architekturregeln
 
-- `modules/<modul>/` bleibt Ort fuer klassische Module
+- `custom/apps/<app>/` bleibt Ort fuer installierbare Fach-Apps
+- `system/apps/<app>/` bleibt Ort fuer System-Tools und nicht installierbare App-Quellen
 - globale Desktop-Mechaniken liegen im gemeinsamen Kern
 - globale Modul-Helfer duerfen im gemeinsamen Kern liegen, Fachlogik aber nicht
 - globale Debug-Steuerung fuer Admins liegt im Desktop-Core; Aktivierung erfolgt ueber das gemeinsame Debug-Widget neben der Uhr