docs: massive restructuring of documentation, development guides and agent playbooks

docs/03_Development/Backend/Multi_Tenant_Kurz.md

@@ -0,0 +1,28 @@
+---
+type: Reference
+status: ACTIVE
+owner: Lead Architect
+last_update: 2026-04-03
+---
+
+# Tenant-Isolation & Multi‑Tenant (Kurzfassung)
+
+Vollständige Entscheidung: [ADR‑0021: Tenant‑Resolution‑Strategie (Schema‑per‑Tenant)](../01_Architecture/adr/0021-tenant-resolution-strategy-de.md).
+
+## Kernaussagen
+
+- Eine Veranstaltung = ein Tenant = ein Datenbankschema (Schema‑per‑Tenant).
+- Requests tragen `X-Event-Id`; Backend validiert gegen `control.tenants` und schaltet das Schema je Request.
+- Flyway führt Migrationen je Tenant‑Schema aus (eigene `flyway_schema_history`).
+- Stammdaten (Reiter/Pferde/Vereine/Funktionäre) sind global und nicht tenant‑spezifisch; Entries/Kassa sind tenant‑lokal.
+
+## Umsetzung (Kurz)
+
+- Web‑Layer: `TenantWebFilter` (Spring) bzw. Plugin (Ktor) liest `X-Event-Id` und legt `TenantContext` ab.
+- Persistence: SCHEMA‑Multitenancy (`SET search_path`) oder Hibernate‑`MultiTenantConnectionProvider`.
+- Registry: `control.tenants(event_id, schema_name, status, db_url?, version, created_at)`.
+
+## Betroffene Bereiche
+
+- Datenmodell tenant‑lokal: `veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `teilnehmer_konten`, `turnier_kassa` (siehe [Datenbankschema](./Schema/Database_Schema_V1-V009.md)).
+- Services: Der Entries‑Service arbeitet mandantenfähig; andere Services bleiben Single‑Tenant/global (vgl. Backend‑Roadmap).