Files

Lars Gebhardt-Kusche f9e41380b5

Deploy / deploy-staging (push) Successful in 24s

Details

Deploy / deploy-production (push) Has been skipped

Details

adas

2026-06-22 01:44:06 +02:00

Weiterentwicklung

Zentrale Arbeits- und Regeldatei fuer die Weiterentwicklung von desktop.kusche.berlin.

Diese Datei enthaelt:

Dokumentationspflicht

Die Projektdokumentation wird zentral und dezentral gleichzeitig gepflegt.

Verbindlich ist:

zentrale Inhalte und Begriffe muessen in CONTENT.md gepflegt werden
Nutzungs- und Hilfetexte muessen in ANLEITUNG.md gepflegt werden
Entwicklungsregeln muessen in dieser Datei gepflegt werden
vorhandene README.md-Dateien in Unterordnern muessen weiter gepflegt werden
wichtige Informationen aus den einzelnen README.md-Dateien muessen auch zentral gehalten werden
bei neuen wichtigen Unterordnern ist zu pruefen, ob eine eigene README.md noetig 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
lokale Persistenz und spaetere Backend-Synchronisierung getrennt vorbereiten
Nutzerdaten und Desktop-Preferences bevorzugt datenbankbasiert speichern, nicht dateibasiert
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

keine stillen Umbenennungen von Bereichen ohne Aktualisierung der zentralen Doku
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
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

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/...
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

Bei jeder groesseren Aenderung ist zu pruefen:

docs/UMSETZUNGSSTATUS.md nur dann als erledigt markieren, wenn es ausdruecklich freigegeben wurde
Fokus liegt aktuell auf Desktop-UI und Apps
Login und Keycloak sind vorerst akzeptiert und nicht der aktuelle Hauptschwerpunkt
API-Zielpfade sollen auf (staging.)desktop.kusche.berlin/api/v1/... vereinheitlicht werden
Desktop-Icons sind frei verschiebbar und werden pro Benutzer und Skin lokal gespeichert
die Schriftfarbe von Desktop-Icons passt sich automatisch an den Hintergrund an
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