ADR-0025: Schema-CMS Hybrid (Management) und QGIS Value Relations

• Status: accepted
• Datum: 2026-08-27
• Phase: Editor Management / Schema-CMS
• Bezug: ADR-0010 (geo_objects), ADR-0023 (Stammdaten), ADR-0008 (QGIS-Export)

Kontext

Der Editor braucht einen Reiter Management (Datenbank + Layer) mit erweiterbarem Datenmodell (String, Liste, Zahl, URI, Email, Telefon, Bild, Dokument, Relation, Enum). Default-Kinds (Projekt, Phase, Akteur, …) sollen mitgeliefert, aber löschbar sein. Gleichzeitig müssen QGIS Value Relations weiter funktionieren: Dropdowns lesen stabile Spalten aus PostGIS-/GPKG-Tabellen (z. B. projects.project_manager → persons.person_id / full_name).

Entscheidung

1. Zentrum: entity_kinds + field_definitions + entity_records (attrs JSONB, validiert gegen Felddefs). Nicht „Projekt“ als Zentrumstabelle.
2. Hybrid (2A): Default-Kinds spiegeln weiter flache Kompat-Tabellen (projects, persons, organizations, geo_object_kinds) über Adapter (compat_table / compat_id auf dem Record). Custom Kinds und Custom Felder leben nur in der Registry/Records.
3. Seed: project, phase, actor, actor_assignment, layer (ex admin_group), feature_type mit is_seeded=true, löschbar (Confirm + QGIS-Warnung).
4. Dateien: entity_files auf FILE_STORAGE_DIR (kein bytea); Preview clientseitig (PDF.js / docx / SheetJS).
5. API: /api/v1/entity-kinds, …/fields, /api/v1/entities, /api/v1/entity-files.
6. Editor-IA: Workspace Karte | Management; unter Management Tabs Datenbank | Layer | Feature (ADR-0027). Menüpunkt Manager entfällt.
7. GIS: geo_objects bleibt Geometrie-SSOT; Feature-Typ synced Code/Label nach geo_object_kinds.

Begründung

Value Relations und bestehende Editor-/Dashboard-Project-APIs brauchen flache Spalten. Reines EAV ohne Projektion bricht Live-QGIS und den GPKG-Export. Registry + JSONB-Attrs skalieren für Custom Fields; Pagination und search_text vermeiden Full-Dumps.

Verworfene Alternativen

Folgen

• Alembic 0007_schema_cms.
• Dashboard /stammdaten kann später dieselbe API nutzen (nicht Teil dieses Slices).
• Beilage-Tabellen (geo_object_tkg, …) bleiben bis eigene Migration; Feature-Typ-CMS ersetzt nur die Kind-Metadaten-Pflege.