dadssad

docs/README.md

@@ -35,6 +35,7 @@ Zentraler Dokumentationsindex fuer das Projekt.
 - Keycloak bleibt das Auth-System.
 - API und Desktop laufen auf demselben Host. Zielpfad ist `(staging.)desktop.kusche.berlin/api/v1/...`.
 - der Theme-Handoff ist in [keycloak-theme-handoff.md](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/docs/keycloak-theme-handoff.md) beschrieben.
+- das globale Admin-Debugging ist Teil der Desktop-Shell und wird nicht pro App als eigene Grundfunktion dupliziert
 
 ## Dokumentationsregel
 
@@ -51,3 +52,4 @@ Aktuell wichtig:
 - der Mining-Checker ist das erste als echtes Desktop-Modul angebundene Modul unter `modules/mining-checker/`
 - 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

@@ -28,6 +28,7 @@ Empfohlene Ergänzungen:
 - `/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
@@ -51,6 +52,7 @@ Das bedeutet:
 - 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
 
 ## Trennung
 
@@ -64,6 +66,7 @@ Es gibt drei Ebenen:
 
 - 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/`
@@ -75,6 +78,7 @@ 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/`
 

docs/Umsetzungsanweisung/06_STARTPROMPT_NEUE_SESSION.md

@@ -26,6 +26,8 @@ Rahmenbedingungen:
 - Die neue Oberfläche ist eine Desktop-Shell, keine klassische Website.
 - Root `/` soll die Desktop-Oberfläche sein.
 - Skins sollen als `Windows`, `Apple`, `Linux` angelegt werden, technisch aber auf einer gemeinsamen Shell beruhen.
+- Globale Desktop-Funktionen wie Admin-Debugging sollen zentral in der Shell liegen und nicht pro App neu gebaut werden.
+- Der Standard fuer Live-Debugging ist ein gemeinsames Admin-Debug-Widget neben der Uhr mit eigenem Debug-Fenster und gemeinsamem Debug-Bus.
 - Spätere Modul-Anbindung muss vorbereitet werden, aber die Shell ist zuerst zu bauen.
 
 Erste Aufgabe:
@@ -40,5 +42,6 @@ Wichtig:
 - keine Arbeiten mehr im alten Nexus durchführen
 - keine Modulmigration im Blindflug
 - keine Vermischung von alter Website-Navigation und neuer Desktop-Interaktion
+- keine neue globale Debug-UI pro App bauen, wenn die Desktop-Shell diese Funktion zentral bereitstellen soll
 - `Old-Nexus/` nur lesen, nie technisch verwenden
 ```

docs/WEITERENTWICKLUNG.md

@@ -26,6 +26,7 @@ Verbindlich ist:
 - Desktop-Mechaniken zentral halten, nicht pro App duplizieren
 - Fensterverhalten konsistent halten
 - gemeinsame Standards fuer Fensterinhalte nutzen, sofern eine App kein bewusst eigenes UI benoetigt
+- globale Debug-Infrastruktur zentral halten und ueber alle Apps wiederverwenden
 - Begriffe in UI und Doku konsistent nach `CONTENT.md` verwenden
 - Apps als bereitgestellte Systemfunktionen denken, nicht nur als sichtbare Fenster
 - Unterschiede zwischen `App`, `Infobereich` und `Widget-Bereich` sauber trennen
@@ -41,6 +42,7 @@ Verbindlich ist:
 - keine Rueckbauten bestehender Desktop-Mechaniken ohne ausdrueckliche Entscheidung
 - keine Vermischung von Modul-Businesslogik mit globalem Desktop-Core
 - keine Skin-Sonderlogik direkt in einzelnen Apps, wenn sie global loesbar ist
+- keine neue globale Debug-Grundlogik pro App, wenn der Desktop-Debug-Bus und das zentrale Debug-Fenster genutzt werden koennen
 - keine nur lokalen README-Informationen ohne zentrale Uebernahme der wichtigen Punkte
 - keine Hilfeinhalte nur in Chatverlaeufen oder Ad-hoc-Notizen belassen
 - keine produktive Architekturabhaengigkeit zu `Old-Nexus/` oder vergleichbaren Altbestaenden
@@ -51,6 +53,7 @@ Verbindlich ist:
 - `modules/<modul>/` bleibt Ort fuer klassische Module
 - 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
 - API und Desktop teilen sich im aktuellen Zielbild denselben Host; offizielle Basis ist `/api/v1/...`
 - Skins definieren Darstellung und Interaktionsdetails, nicht die Fachlogik
 - Hilfe- und Inhaltsdateien sollen spaeter maschinenlesbar oder zumindest klar strukturierbar in einen Hilfebereich ueberfuehrt werden koennen
@@ -76,3 +79,5 @@ Bei jeder groesseren Aenderung ist zu pruefen:
 - Benutzerdaten sollen spaeter sauber in LDAP oder Keycloak geschrieben werden
 - Standard-Fensterinhalte sollen ein gemeinsames Design nutzen
 - Desktop-Nutzereinstellungen liegen in einer eigenen Tabelle mit erkennbarem `_user_data`-Suffix
+- das globale Admin-Debug-Fenster ist der Standardweg fuer Live-Debugging in Desktop und Native-Apps
+- Debug-Tracking soll nur waehrend eines geoeffneten globalen Debug-Fensters laufen; der letzte Status soll einen Reload pro Benutzer ueberstehen