Next

adas

docs/ANLEITUNG.md

@@ -67,9 +67,19 @@ Klassische Module liegen unter `modules/<modul>/` und koennen als normale `App`
 Aktuell gilt:
 
 - der `Mining-Checker` ist das erste echte Modul in dieser Form
+- der `Waehrungs-Checker` ist das zweite 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
 
+## Waehrungs-Checker
+
+Der `Waehrungs-Checker` verwaltet gespeicherte Wechselkurse, Kurs-Historie, Umrechnungen und manuelle Aktualisierung.
+
+- das Oeffnen der App loest keinen externen Abruf aus
+- ein manueller Abruf ist nur erlaubt, wenn die letzten gespeicherten Kurse aelter als die konfigurierte Sperrzeit sind
+- mit `force` kann ein Abruf bewusst erzwungen werden
+- das zugehoerige Widget im `Widget-Bereich` nutzt dieselbe Regel wie App und API
+
 ## Benutzerdaten
 
 Aktuell gelten folgende Regeln:

docs/CONTENT.md

@@ -85,6 +85,7 @@ Stand dieser Datei:
 - `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
+- `Waehrungs-Checker` als zweites angebundenes klassisches Modul mit Desktop-Widget fuer Kursaktualisierung
 - versionierte API auf demselben Host unter `(staging.)desktop.kusche.berlin/api/v1/...`
 - 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
@@ -118,6 +119,7 @@ Aus [modules/README.md](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/m
 ### 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
 - 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

@@ -50,6 +50,9 @@ 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
 - 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
+- der Waehrungs-Checker stellt zusaetzlich ein Desktop-Widget fuer manuelle Kursaktualisierung bereit
+- das Oeffnen des Waehrungs-Checkers darf keinen externen Kursabruf ausloesen; Refreshes laufen nur nach Altersregel oder mit `force`

docs/Umsetzungsanweisung/START_HIER.md

@@ -33,6 +33,8 @@ Bitte diese Dateien in genau dieser Reihenfolge lesen:
 - Die Umsetzung erfolgt **nicht** mehr im alten Nexus-Projekt.
 - Die bestehenden Module aus Nexus dienen als Basis und Referenz, sollen aber in `desktop.kusche.berlin` separat weiterentwickelt werden.
 - Der neue UI-Layer ist eine neue Anwendungsschicht, kein Theme-Umbau des alten Systems.
+- Importierte Module sollen im neuen Projekt als echte Desktop-Module mit eigener `desktop.php`, eigener `api/`-Struktur und eigenen `public/apps/...` beziehungsweise `public/api/...`-Einstiegspunkten angebunden werden.
+- Gemeinsame Regeln wie Debugging, Zugriffsschutz, Fensterstandard und Widget-Verhalten sollen zentral loesbar sein und nicht pro importierter App neu erfunden werden.
 
 ## Erwartetes Vorgehen im neuen Projekt
 

docs/WEITERENTWICKLUNG.md

@@ -35,6 +35,9 @@ Verbindlich ist:
 - `README.md`-Dateien in Teilbereichen aktuell halten
 - zentrale Doku bei jeder relevanten Struktur- oder Begriffsanpassung mitpflegen
 - API-Pfade versioniert und host-konsistent unter `(staging.)desktop.kusche.berlin/api/v1/...` halten
+- importierte Module mit eigener API ueber konsistente `public/api/<modul>/index.php`-Shims an die gemeinsame Desktop-Auth anbinden
+- importierte Module mit eigener Fensterseite ueber konsistente `public/apps/<modul>/index.php`-Shims anbinden
+- Widget-Logik einer App muss dieselben fachlichen Regeln wie die App-API verwenden, nicht eigene Sonderwege
 
 ## NoGo's
 
@@ -47,6 +50,7 @@ Verbindlich ist:
 - keine Hilfeinhalte nur in Chatverlaeufen oder Ad-hoc-Notizen belassen
 - keine produktive Architekturabhaengigkeit zu `Old-Nexus/` oder vergleichbaren Altbestaenden
 - keine neue Standard-API-Domain wie `api.desktop.kusche.berlin`, solange keine ausdrueckliche Architekturentscheidung dafuer getroffen wurde
+- keine stillen externen API-Abrufe beim blossen Oeffnen einer App, wenn die Fachregel explizite Refresh-Sperren vorsieht
 
 ## Architekturregeln
 
@@ -55,6 +59,7 @@ Verbindlich ist:
 - 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/...`
+- App, API und Widget einer Fachfunktion muessen dieselben Sperr- und Force-Regeln fuer externe Abrufe nutzen
 - Skins definieren Darstellung und Interaktionsdetails, nicht die Fachlogik
 - Hilfe- und Inhaltsdateien sollen spaeter maschinenlesbar oder zumindest klar strukturierbar in einen Hilfebereich ueberfuehrt werden koennen