Skip to content

ADR-0033: Linetra Web as schema SSOT, logical project schema, Plugin apply-only

Kontext

Schema-CMS lebte in der Org-DB ohne Projektbindung; die Management-UI nur im Tauri-Editor. Das QGIS-Plugin konnte nackte Kinds anlegen. Die Webapp heißt intern weiter FastAPI+Next.js, soll aber Linetra Web sein (linetra-web/), nicht „Dashboard“. Projekte bleiben Zeilen in der Org-DB (keine physische DB pro Projekt).

Entscheidung

  1. Produktname / Repo: linetra-dashboard → linetra-web. Home-Nav Übersicht. Compose-Services bleiben backend / frontend.
  2. Schema-SSOT ist Web. Datenmanagement (Schemata | Datensätze, darunter Datenbank | Layer | Feature) in Next.js. Org-Admin pflegt den Basis-Katalog (instantiation_scope=base); Editor projektspezifische Kinds/Felder.
  3. Logisches Projektschema: project_schema_kinds / project_schema_fields. Neues Projekt instanziert nur base. Klon kopiert Bindings, nicht GIS und nicht Records.
  4. Kind-code bleibt org-weit eindeutig (GIS geo_objects.kind).
  5. QGIS-Plugin wendet das effektive Projektschema an (Layer, Formulare, Value Relations). Kein Kind-Create im Plugin.
  6. Tauri-Editor bleibt Legacy-Client derselben API, nicht SSOT-UI.

Begründung (für dieses Setup)

Eine physische Projekt-DB widerspricht ADR-0026/0030 und sprengt Certs, PgBouncer und Alembic. Bindings halten Kind-Codes stabil. Web als Schema-SSOT vermeidet Drift zwischen Plugin-Stubs und FastAPI. QGIS braucht weiter flache Spalten (ADR-0025) und live PostGIS.

Verworfene Alternativen

Alternative Warum verworfen
CREATE DATABASE pro Projekt Ops, Certs, Alembic; ADR-0026
entity_kinds.project_id als Teil-PK Bricht stabile Kind-Codes für GIS
Schema weiter im Plugin anlegen Drift zur Web-SSOT
Management nur im Editor lassen Editor ist nicht Primärpfad (ADR-0030)

Folgen

  • Alembic 0014_project_schema_catalog (Tenant 0002).
  • Plugin: apply-only; ADR-0030 Punkt „Schema-CMS-UI“ gilt nur noch als Lesen/Anwenden.
  • Folge: Katalog-Kopien und Sync in ADR-0034.