[EPIC] Slim Host – Fachbereiche vollständig aus dem Runtime-Host entfernen

[p3t3r67x0]

Vision

Der Open City Planner soll auf einen schlanken, fachbereichsfreien Host reduziert werden. Der Host stellt ausschließlich technische Plattformfähigkeiten bereit; fachliche Produktbereiche werden aus dem Runtime-Host entfernt und später als installierbare Module wieder eingeführt.

Leitprinzip:

Runtime klein halten. Komplexität an Systemrändern lösen.

Der aktuelle Analysis-Areas-Cutover hat gezeigt, dass mehrere eingebaute Fachbereiche untereinander über private Host-Typen und Domainwissen gekoppelt sind. Ein isolierter #196-Cleanup ist deshalb nicht sinnvoll vollständig buildfähig, solange Assistant, Search und Comparison ihre bisherigen Built-in-Abhängigkeiten behalten.

Statt neue Übergangs-DTOs und Host-Fallbacks einzubauen, wird der Host bewusst entkernt.

Zielbild

Open City Planner Slim Host
├─ FastAPI / Nuxt Runtime
├─ Auth / Users / Permissions
├─ Module Runtime / Discovery / Installer
├─ Module SDK / Service Registry
├─ Events / Outbox
├─ Scheduler / Jobs
├─ Cache / Cache Generations
├─ HTTP / Storage
├─ Logging / Tracing / Observability
├─ DB Session / Migration Infrastructure
├─ generische Polygon-Plattform
├─ MapLibre Host Runtime
├─ generische UI-/Map-/Sitemap-Contributions
└─ Notifications
        │
        ▼
   installierbare Fachmodule

Harte Host-Invarianten

Bleibt im Host

• FastAPI- und Nuxt-Runtime
• Auth, Benutzer, Rollen und Permissions
• Module Discovery, Installer, Registry und Runtime
• Backend-/Frontend-Module SDK
• Events / Transactional Outbox
• Scheduler / Jobs
• Cache / Cache Generations
• HTTP Client
• Storage
• Logging / Tracing / Observability
• DB Session- und generische Migrations-Infrastruktur
• generische Polygon-Grundfunktionen und öffentliche Polygon-Ports
• MapLibre Host Runtime und generische Map Contributions
• generische UI-/Navigation-/Sitemap-Contributions
• Notifications als generische Host-Capability

Soll aus dem Host heraus

• Analysis Areas
• Assistant
• Search / Intelligent Search
• Comparison
• Statistics-Fachlogik
• Social Publishing-Fachlogik
• fachliche Analytics
• fachliche OSM-Verarbeitung
• Wikidata-Fachlogik
• domain-spezifische API-Routen, Stores, Pages, DTOs, Scheduler-Jobs und Map-Layer

Wichtige Regel: Notifications bleiben im Host

Notifications werden ausdrücklich nicht als Fachmodul ausgelagert.

Der Host behält insbesondere:

• Notification Delivery Infrastructure
• Preferences
• Follow/Unfollow generischer Ressourcen
• Read/Unread State
• Notification Policies, soweit fachneutral
• öffentliche Notification-Ports

Domain-spezifische Sonderfälle innerhalb der Notification-Logik sollen entfernt oder über generische Resource-IDs/Contracts abgebildet werden, ohne die Notification-Plattform selbst auszulagern.

Datenstrategie

Code-Entfernung bedeutet nicht Datenlöschung.

• keine Produktivdaten im Rahmen der Host-Entkernung löschen
• keine Tabellen nur deshalb droppen, weil ein Fachbereich temporär nicht verfügbar ist
• historische Daten und funktionierende Baseline-Commits als Referenz erhalten
• spätere Modul-Migrationen erhalten eigene Daten-/Ownership-Gates

Referenzstrategie

Vor der Entkernung wird ein funktionierender historischer Stand festgehalten.

Alte funktionierende Commits dienen später als:

• Characterization Reference
• fachliche Spezifikation
• Testreferenz
• Bauplan für neue Module

Sie werden nicht blind cherry-picked.

Phasen

Phase A – Slim-Host-Audit und Baseline

• vollständiges Domain-/Ownership-Inventar erstellen
• funktionierende Pre-Slim-Baseline dokumentieren
• Host-Core vs. Fachbereiche verbindlich klassifizieren
• vorhandenen Multi-Domain-WIP gegen aktuellen Staging-Stand bewerten

Phase B – Host entkernen

• Analysis-Areas-Built-in-Reste entfernen
• Assistant aus Runtime-Host entfernen
• Search aus Runtime-Host entfernen
• Comparison aus Runtime-Host entfernen
• Social-Publishing-Fachlogik entfernen
• Statistics-Runtime fachlich deaktivieren/entkoppeln, ohne Datenverlust
• fachliche Analytics und OSM-Verarbeitung klassifizieren und entfernen

Phase C – Slim-Host absichern

• Backend und Frontend ohne Fachmodule boot-/buildfähig machen
• Auth / Permissions / Module Runtime prüfen
• Notifications vollständig funktionsfähig halten
• Map Host / Polygon Platform prüfen
• negative Architecture Guards gegen neue Fachlogik einführen
• fehlende Features bewusst dokumentieren statt Hidden Fallbacks einzubauen

Phase D – Referenzmodul / Proof

• externes analysis-areas Modul gegen Slim Host installieren
• API, /gebiete, Map Contributions, Statistics Integration, Sitemap und OSM-Sync prüfen
• beweisen, dass Fachfunktion ausschließlich durch ein externes Modul zurückkehrt

Phase E – spätere Fachmodule

Nach stabilem Slim Host werden eigenständige Module geplant bzw. wieder aufgebaut:

• Search
• Comparison
• Statistics
• Assistant
• Social Publishing
• weitere OSM-/Analytics-Fachmodule

Bezug zu bestehenden Issues

• [EPIC] Open City Planner als modularen Host mit stabilem Module SDK entwickeln #91 – Modular Host / Module SDK
• [Migration] Bestehende Fachdomänen schrittweise in Module überführen und Legacy-Pfade abbauen #108 – schrittweise Fachdomänen-Migration
• [Migration] analysis-areas als externes installierbares Modul migrieren und Built-in nach E2E-Nachweis entfernen #184 – Analysis-Areas-Migration
• [Cutover] Verbleibendes Analysis-Areas-Fachwissen aus dem Host entfernen #196 – verbleibendes Analysis-Areas-Fachwissen aus dem Host entfernen
• [Cutover] Finalen Analysis-Areas-E2E-, Security- und Deployment-Nachweis für #184 durchführen #197 – finaler Analysis-Areas E2E-/Security-/Deployment-Nachweis

#196 bleibt ein Teilnachweis dieses größeren Slim-Host-Cutovers; dieses Epic ersetzt #184/#196/#197 nicht.

Nicht-Ziele

• kein Microservice-Big-Bang
• keine neue parallele Plugin-Runtime
• keine Hidden Host-Fallbacks für entfernte Fachfeatures
• keine sofortige Wiederherstellung aller Fachmodule im selben PR
• keine Produktivdatenlöschung
• Notifications nicht auslagern

Definition of Done

• Host startet ohne installierte Fachmodule.
• Frontend baut ohne installierte Fachmodule.
• Auth, Users und Permissions funktionieren.
• Module Discovery / Install / Enable / Disable funktionieren.
• Events, Scheduler, Cache, HTTP, Storage und Observability funktionieren.
• Notifications funktionieren vollständig als Host-Capability.
• Map Host und generische Polygon-Plattform funktionieren.
• Host enthält keine eingebaute Analysis-Areas-, Assistant-, Search-, Comparison-, Statistics-, Social- oder sonstige Fachlogik mehr.
• Fachfeatures besitzen keine versteckten Built-in-Fallbacks.
• Daten bleiben erhalten bzw. werden bewusst in späteren Modul-Migrationen behandelt.
• Architecture Guards verhindern neues Domainwissen im Host.
• analysis-areas funktioniert als extern installiertes Referenzmodul gegen den Slim Host.
• spätere Module können aus dokumentierten Characterization-Baselines gezielt wieder aufgebaut werden.

Coordinates: #91, #108, #184, #196, #197