# Vendoo 1.35.0 – Modulsystem

## Ziel

Vendoo wird schrittweise als modularer Monolith organisiert. Der bestehende Code bleibt in 1.35.0 funktional unverändert und wird über `legacy-bridge`-Manifeste erfasst. Neue Funktionen müssen die Kernelverträge verwenden; bestehende Bereiche werden in späteren Releases einzeln migriert.

## Verbindliche Regeln

1. Jedes Modul besitzt eine eindeutige ID `vendoo.<name>` und ein validiertes `module.json`.
2. Abhängigkeiten müssen explizit und frei von Zyklen sein.
3. Neue Routen benötigen Besitzer, Policy, Auditklasse, Rate-Limit-Klasse und Stabilitätsstatus.
4. Unbekannte Policies verweigern den Zugriff. Es gibt keinen Allow-by-default-Fallback.
5. Module kommunizieren künftig über öffentliche Services, Capabilities und Events, nicht über interne Querimporte.
6. Ein Modul darf langfristig nur seine eigenen Tabellen beziehungsweise Repository-Schnittstellen verändern.
7. Externe Erweiterungen werden nicht im Vendoo-Hauptprozess ausgeführt. Ein isolierter Extension-Host bleibt bis zur sicheren Umsetzung deaktiviert.
8. Modulaktivierung durch bloßes Kopieren einer Datei ist unzulässig.

## Status 1.35.0

Die Bereiche System, Security, Auth, Benutzer, Themes, Medien, Artikel, AI, FLUX Studio, Quality Center, Publishing und Operations sind registriert. Ihr Status `legacy-bridge` bedeutet: Der Vertrag existiert, die bestehende Implementierung liegt aber noch überwiegend in `server.mjs`, `lib/`, `public/app.js` und `public/style.css`.

## Migrationsmethode

Vendoo verwendet das Strangler-Verfahren:

- neue Architektur neben dem Bestand aufbauen,
- einen fachlichen Bereich vollständig migrieren,
- Verhalten und Datenbestand prüfen,
- erst danach den alten Pfad entfernen.

Kein Big-Bang-Refactoring, keine Framework-Migration und kein Datenbankreset.
