Next

adas

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