mining checker

docs/ANLEITUNG.md

@@ -36,6 +36,7 @@ Das Startmenue ist in drei Bereiche gegliedert:
 - Desktop-Icons koennen direkt geoeffnet werden.
 - Im Startmenue lassen sich Programme ueber den `Auswahlbereich` starten.
 - Fenster koennen verschoben, minimiert, maximiert und geschlossen werden.
+- Programme koennen sowohl globale System-Apps als auch klassische Module sein.
 
 ## Einstellungen oeffnen
 
@@ -48,6 +49,16 @@ Dort koennen derzeit insbesondere verwaltet werden:
 - sichtbare Apps
 - Inhalte des `Infobereichs`
 
+## Module
+
+Klassische Module liegen unter `modules/<modul>/` und koennen als normale `App` im Desktop erscheinen.
+
+Aktuell gilt:
+
+- der `Mining-Checker` ist das erste echte Modul in dieser Form
+- Modul-Businesslogik bleibt im Modul und wird nicht in den Desktop-Core verschoben
+- gemeinsame Desktop-Mechaniken wie Fenster, Asset-Einbindung und Zugriffsschutz werden global bereitgestellt
+
 ## Benutzerdaten
 
 Aktuell gelten folgende Regeln:

docs/CONTENT.md

@@ -80,6 +80,8 @@ 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>/`
+- `Mining-Checker` als erstes angebundenes klassisches Modul
 - Benutzereinstellungen fuer Desktop-Skin, App-Auswahl, Infobereich und Profildaten in einer eigenen Datenbanktabelle mit `_user_data`-Suffix
 - vorhandene JSON-Dateien dienen nur noch als Fallback oder Uebergang fuer lokale Entwicklung und Altbestaende
 - LDAP-Synchronisierung fuer Standardfelder wie Name, E-Mail, Telefon, Titel und Ort
@@ -105,6 +107,14 @@ Aus [modules/README.md](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/m
 
 - klassische Module bleiben unter `modules/<modul>/`
 - 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
+- die Desktop-Shell kann Moduldefinitionen zentral erkennen und als `App` bereitstellen
+- wiederverwendbare Modul-Helfer liegen im globalen Kern, die Fachlogik bleibt im Modul
 
 ### Skins
 
@@ -125,6 +135,7 @@ Fuer einen spaeteren Hilfebereich sollen Inhalte aus dieser Datei in Themenblcke
 - `Fenster verwenden`
 - `Infobereich konfigurieren`
 - `Apps und Desktop Type verwalten`
+- `Module verstehen und starten`
 - `Benutzerdaten und Synchronisierung`
 
 Die Inhalte sollen spaeter moeglichst nicht neu erfunden, sondern aus den zentral gepflegten Dateien abgeleitet werden.

docs/README.md

@@ -23,6 +23,7 @@ Zentraler Dokumentationsindex fuer das Projekt.
 
 - `public/` Web-Root mit Desktop-Shell auf `/`
 - `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
 - `temp/nexus-module-import/` Rohbasis fuer importierte Nexus-Module
@@ -43,3 +44,8 @@ Es gilt:
 - wichtige Inhalte aus Unterordner-`README.md`-Dateien werden zentral in `docs/CONTENT.md` gespiegelt
 - Nutzungswissen wird in `docs/ANLEITUNG.md` gepflegt
 - Entwicklungsregeln werden in `docs/WEITERENTWICKLUNG.md` gepflegt
+
+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

docs/UMSETZUNGSSTATUS.md

@@ -1,6 +1,6 @@
 # Umsetzungsstatus Desktop UI
 
-Stand: 2026-06-07
+Stand: 2026-06-21
 
 Diese Datei ist die laufende Arbeitsgrundlage fuer die Umsetzung der Anweisungen aus `docs/Umsetzungsanweisung/`.
 
@@ -23,8 +23,10 @@ Aktuell ist das Projekt auf einem V1-Scaffold-Stand:
 - Skin-System `Windows` / `Apple` / `Linux` ist vorbereitet
 - einfacher Fenster-Manager ist vorhanden
 - App-Registry, Widget-Registry und Import-Basis sind angelegt
+- erster echter Modulmechanismus fuer klassische Module ist vorhanden
+- `Mining-Checker` ist als erstes klassisches Modul angebunden
 - Keycloak ist nur konzeptionell vorbereitet, nicht integriert
-- Admin-Bereiche, persistente User-Desktops und echte Modul-Anbindung sind noch offen
+- Admin-Bereiche und persistente User-Desktops sind noch offen
 
 ## Verbindliche Regeln
 
@@ -49,7 +51,7 @@ Erfuellt:
 Offen:
 
 - globale Verwaltungsseiten nur als Platzhalter vorhanden
-- klassische Module sind noch nicht schrittweise an die Shell angebunden
+- weitere klassische Module sind noch nicht schrittweise an die Shell angebunden
 - persoenliche Dashboards sind noch nicht funktional
 
 Nachweise:
@@ -98,7 +100,7 @@ Erfuellt:
 
 Offen:
 
-- `modules/<modul>/` im neuen Projekt enthalten noch keine wirklich angebundenen Module
+- weitere `modules/<modul>/` sind noch nicht angebunden
 - `partials/landingpages/` und `partials/structure/` sind nur minimal vorbereitet
 - `tools/` und `debug/` sind noch nicht mit Funktion befuellt
 - Skin-Ordnerkonzept mit `base`-Fallback sowie pro Skin getrennten Layout-/Asset-Dateien fachlich fertigziehen und abnehmen
@@ -119,18 +121,24 @@ Erfuellt:
 - Rohkopie der Altmodule liegt in `temp/nexus-module-import/modules/`
 - relevante Doku aus der Altbasis wurde in den Import-Ordner uebernommen
 - Produktivcode referenziert den Import-Ordner nicht zur Laufzeit
+- `Mining-Checker` wurde als erstes Modul aus der Projektstruktur `modules/mining-checker/` an die Shell angebunden
+- Modul-Assets werden aus dem Modul selbst geladen statt ueber eine alte Sonderkopie
+- gemeinsame Modul-Helfer fuer Discovery und Zugriffsschutz sind im globalen Kern vorbereitet
 
 Offen:
 
 - keine Modulpruefung je Modul durchgefuehrt
-- keine App-Registry-Eintraege fuer echte importierte Module vorhanden
-- keine Modulansichten in die Fensterlogik integriert
+- weitere App-Registry-Eintraege fuer echte importierte Module fehlen noch
+- Fenstertauglichkeit weiterer Module ist nicht geprueft
 - kein Skin-Test je Modul erfolgt
 
 Nachweise:
 
 - [temp/nexus-module-import](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/temp/nexus-module-import:1)
 - [config/apps.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/config/apps.php:1)
+- [modules/mining-checker](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/modules/mining-checker:1)
+- [src/ModulesCore/ModuleRegistry.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/src/ModulesCore/ModuleRegistry.php:1)
+- [public/module-assets/index.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/public/module-assets/index.php:1)
 
 ### 5. `04_UMSETZUNGSPLAN_V1.md`
 
@@ -168,7 +176,7 @@ Phase 4 Inhaltssystem:
 
 - `ERLEDIGT`: App Registry als Grundstruktur
 - `TEILWEISE`: Widget Registry als Grundstruktur, noch nicht abgenommen
-- `OFFEN`: Seitenmodule
+- `TEILWEISE`: Seitenmodule, erster echter Modulpfad vorhanden
 - `OFFEN`: persoenliche Linklisten
 - `TEILWEISE`: oeffentliches Home-Dashboard nur als Placeholder
 - `TEILWEISE`: persoenliche Workspaces nur als Placeholder
@@ -185,8 +193,8 @@ Phase 5 Admin-Bereiche:
 Phase 6 Modul-Anbindung:
 
 - `TEILWEISE`: importierte Nexus-Module liegen vor
-- `OFFEN`: erste Module als Apps in der Shell
-- `OFFEN`: Fenstertauglichkeit je Modul pruefen
+- `TEILWEISE`: erstes Modul als App in der Shell
+- `OFFEN`: Fenstertauglichkeit weiterer Module pruefen
 - `OFFEN`: langfristige UX-Anpassung je Modul
 
 V1-Minimalziel:
@@ -244,17 +252,23 @@ Vorhanden:
 - JSON-Payload fuer Frontend per `api/desktop.php`
 - PHP-Autoload-Basis
 - App-Registry
+- Modul-Registry fuer klassische Module
 - Widget-Registry
 - Skin-Resolver
 - Default-Workspace- und Widget-State
 - einfacher Window-Manager
 - Window-Controls fuer minimieren, maximieren und schliessen
 - CSS/JS fuer Shell, Fenster, Taskbar, Startmenue, Widgets und Uhr
+- gemeinsamer Modul-Asset-Endpoint
+- `Mining-Checker` als erstes echtes Modul unter `modules/`
 
 Hauptdateien:
 
 - [public/index.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/public/index.php:1)
 - [api/desktop.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/api/desktop.php:1)
 - [src/App/App.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/src/App/App.php:1)
+- [src/ModulesCore/ModuleRegistry.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/src/ModulesCore/ModuleRegistry.php:1)
+- [src/ModulesCore/ModuleHttp.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/src/ModulesCore/ModuleHttp.php:1)
 - [src/Desktop/DesktopState.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/src/Desktop/DesktopState.php:1)
 - [public/assets/desktop/desktop.js](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/public/assets/desktop/desktop.js:1)
+- [public/module-assets/index.php](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/public/module-assets/index.php:1)

docs/WEITERENTWICKLUNG.md

@@ -48,6 +48,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
 - Skins definieren Darstellung und Interaktionsdetails, nicht die Fachlogik
 - Hilfe- und Inhaltsdateien sollen spaeter maschinenlesbar oder zumindest klar strukturierbar in einen Hilfebereich ueberfuehrt werden koennen