feat: Capability Registry v1 API-Vertrag (#59) + Ownership-Modell finalisiert

#59 (geschaerft, User): capabilities.json -> capability_registry_v1 (contract_version 1.0):
stabile `cap.*`-IDs (NIE umbenennen) + 5 Vertragsfelder (description/guidance_basis/
realizes_obligations/required_procedures/evidence_patterns), PRODUKTNEUTRAL (keine Features).
= stabiler API-Vertrag fuer die Product->Compliance-Schnittstelle (Feature->Capability,
Session 3 mappt read-only dagegen).
session_ownership_model_v1.md RESOLVED: Legal-Owner = Re-Ingest-Session (vergibt KEINE
obligation_id, nur citation_span->legal_basis) · 4. Session -> Quality & Validation (nur
Tests, KEINE Daten) · Compliance 2 Branches DAUERHAFT (A=Build, B=Runtime). 4-Bibliotheken-
Zielbild (Legal/Product/Capability/Evidence).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs-src/development/session_ownership_model_v1.md

@@ -75,3 +75,26 @@ wir, was fehlt, wo interpretieren wir falsch?"
 NIS2/AI-Act/Data-Act-Runs verschoben (liefern Reuse-Kennzahlen, aber keine neue Produktfrage). KEINE
 weitere Datenmodell-Klasse (Freeze v1.0). Product Knowledge Graph hat Vorrang — er schließt die Lücke
 zwischen Kunden- und Regulierungssprache.
+
+## RESOLVED (2026-06-26, User-Entscheidung) — die 3 offenen Fragen geklärt, Vertrag final
+
+1. **Legal Knowledge Owner = die Re-Ingest-/Knowledge-Session.** Besitzt Parser/CELLAR/Span/Authority/
+   Retrieval/Citation-API. **Vergibt KEINE `obligation_id`** — liefert nur `citation_span → legal_basis`;
+   die `obligation_id` entsteht im Compliance-Graph. Verhindert, dass dieselbe Pflicht zweimal modelliert wird.
+2. **4. Session NICHT auflösen → umbenennen in „Quality & Validation".** Besitzt KEINE Daten/Registry —
+   NUR Tests: Golden/Regression/Precision/Recall/Halluzination/Benchmark/Hazard-Qualität/FMEA-Validierung.
+   Darf produktive Modelle NIE verändern; sagt nur „funktioniert / funktioniert nicht". → **4 Verantwort-
+   lichkeiten:** Legal *liefert* Wissen · Compliance *modelliert* Wissen · Product *liefert* Kontext ·
+   Quality *prüft* alles.
+3. **Compliance Execution bleibt 2 Branches (dauerhaft getrennt, NICHT mergen):**
+   - **Branch A** (`feat/obligation-aggregation`) = **BUILD**: Registry · Discovery · Ontology · Capabilities ·
+     Procedures · Graph (ändert sich ~wöchentlich).
+   - **Branch B** (`feat/advisor-status`) = **RUNTIME / Execution Engine**: API · Advisor · Endpoint · Status ·
+     Evidence · Reasoning (ändert sich ~täglich).
+   Unterschiedliche Geschwindigkeit → bewusst getrennt.
+
+**Plattform-Zielbild: 4 Bibliotheken** — `Legal Library → Product Library → Capability Library →
+Evidence Library`; darauf sitzen Advisor · Runtime · Auditor · Ticket-System · CE-/CRA-/NIS2-/AI-Act-
+Assistent — **alle auf derselben Wissensbasis**. Die **Capability Library/Registry ist der Dreh- und
+Angelpunkt** zwischen Product- und Compliance-Graph → muss ein **stabiler, versionierter API-Vertrag**
+sein (stabile `cap.*`-IDs, nie umbenennen; produktneutral). Das ist #59.