ADR-0034: Katalog-Kopien und bidirektionaler Sync

• Status: accepted
• Datum: 2026-09-01
• Phase: Web Schema-CMS / Stammdaten
• Bezug: ADR-0025, ADR-0032, ADR-0033

Kontext

Zentrale Akteure und Produkt-Stammdaten leben in der Org-DB. Projekte brauchen eine übertragbare Arbeitsmenge (Kopien), plus eine eigene Sync-Funktion — nicht nur Live-Share ohne Kopie.

Entscheidung

1. Zentrale Records: entity_records.project_id IS NULL. Projektkopien: project_id gesetzt, source_record_id auf die Zentrale, content_hash / last_synced_hash / synced_at.
2. Pull: POST /projects/{id}/catalog/pull mit höchstens 100 IDs, idempotent pro Quelle.
3. Sync: Celery-Job (inline wenn CELERY_EAGER). Richtung both | to_project | to_central. Drei-Wege über Hashes: eine Seite geändert → anwenden; beide → sync_conflicts. Nutzer wählt Zentrale oder Projekt. Kein JSONB-Automerge.
4. Hybrid: Kopien von Akteuren schreiben persons/organizations mit project_id und source_*_id, damit QGIS Value Relations flache Spalten und Filter haben.
5. Analyse: serverseitige Aggregate (/analyse/summary|field|catalog), keine Feature-Dumps.

Begründung (für dieses Setup)

Celery/Redis sind im Compose-Stack. Hash-Konfliktinbox verhindert stilles Last-Write-Wins. Flache Kompat-Tabellen bleiben QGIS-tauglich. Pagination und Batch-Größe halten den Hot Path klein.

Verworfene Alternativen

Folgen

• ADR-0032: Org-Stamm bleibt zentral; Kopien sind projektbezogen, Isolation weiter die Org-DB.
• Web: Stammdaten-Pull/Sync, Analyse-Nav. Plugin: dieselben APIs.