ADR-0036: Named schemas (Standard + federated packs)

Status: superseded by ADR-0037 (federated extra packs); standard document remains
Datum: 2026-09-01
Phase: Web Schema-CMS
Bezug: ADR-0033, ADR-0032, ADR-0025

Kontext

Schemata waren bisher der Katalog der Kinds (entity_kinds) hinter einem Query-mode= bzw. einem Tab Schemata. Es gab kein benanntes Dokument „Standard-Schema“ und keine weiteren Packs. Nutzer brauchen eine Liste (Standard plus selbst angelegte Schemata) und je Schema eine eigene Seite — nicht ?mode= und nicht alle Packs auf einer Endlosseite.

Entscheidung

Zentrum: schema_definitions (code, label, is_standard, is_federated, optionales project_id). Kinds bleiben Spezialisierung (entity_kinds.schema_code).
Standard-Schema (code=standard) ist gesetzt, föderiert, nicht löschbar. Es zeigt nur Basis-Entitäten mit Basis-Feldern.
Neue Schemata: Dialog Bezeichnung + serialisierte ID (serializeCode) + Switch föderiert (über Projekte hinweg). Nicht föderiert → an das aktuelle Projekt gebunden.
Routen: /datenmanagement/schemata (Liste) → /datenmanagement/schemata/{code}/{tab}. Kind-code bleibt org-weit eindeutig.

Begründung (für dieses Setup)

Ein benanntes Schema ist das Produkt; weitere Packs hängen nicht an project_id auf entity_kinds (ADR-0033). Föderiert = instantiation_scope=base und project_id leer; projektgebunden bleibt isoliert. Eigene Seiten halten die IA (keine Query-Parameter-Screens).

Verworfene Alternativen

Alternative	Warum verworfen
Weiter nur `instantiation_scope` ohne Namensdokument	Keine Liste, kein Standard als Zeile
`?schema=` auf einer Management-Seite	Widerspricht function-scoped pages
Eigenes Kind-`code` pro Schema	Bricht GIS `geo_objects.kind`
Physische Schema-DB pro Pack	Ops; ADR-0033

Folgen

Alembic 0015_named_schemas (Tenant 0003).
API /schema-definitions; GET /entity-kinds?schema_code=.
Plugin bleibt apply-only auf dem effektiven Projektschema.