feat(optimization): Regulatory Optimization — Roadmap/Management renderer over the Capability Delta

Roadmap item 5. GAP analysis and measure-prioritisation are the SAME computation: Required −
Known = the Capability Delta. The Capability Delta Engine (RS-005) computes it once; renderers
read that ONE delta. Interview Renderer (missing info → questions) was already built; this adds
the Roadmap/Management Renderer (missing capabilities → measures ranked by regulatory leverage).

- compliance/optimization/: regulatory_leverage() + select_within_budget() (pure leverage math)
  + roadmap_from_delta(assessment, ...) — the keystone binding optimization to the RS-005 delta
  (dependency optimization → transition_reasoning, acyclic; the delta engine stays hermetic).
  leverage(measure) = number of regulatory requirements it closes at once (e.g. patch management
  → CRA+MaschinenVO+IEC62443+ISO27001 = 4). No new corpus, no new meta-model class (freeze v1.0).
- Welt-1 honesty: percentages are exact count ratios over the IDENTIFIED requirements (the known
  delta), never "% gesetzeskonform".
- reference suite: "Regulatory Optimization" section runs the SAME convergence delta → ranked
  measures + budget answer + the management sentence "of N identified requirements you close M
  with the top-K measures (X%) — highest regulatory leverage".
- ADR-003: Capability Delta Engine — one delta, many renderers; rename Gap → Capability Delta.

13 optimization tests (31 with transition+company), mypy --strict clean, check-loc 0.
Product code with no app caller + ADR/reference = non-runtime → no deploy (ADR-001).

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

docs-src/architecture/adr/ADR-003-capability-delta-engine-with-renderers.md

@@ -0,0 +1,56 @@
+# ADR-003: Capability Delta Engine — one delta, many renderers
+
+- **Status:** Accepted
+- **Datum:** 2026-06-27
+- **Typ:** Architektur-Entscheidung
+- **Bezug:** [ADR-002](ADR-002-transition-is-data-not-architecture.md), [`../transition-reasoning-spec-v1.md`](../transition-reasoning-spec-v1.md), Architektur-Freeze v1.0, [[transition-reasoning]], [[regulatory-intelligence-vision]]
+
+## Kontext
+
+GAP-Analyse („Was fehlt mir / welche Informationen brauche ich noch?") und
+Maßnahmenpriorisierung („Womit soll ich anfangen?") wurden bisher als zwei Features gedacht.
+Sie sind aber **dieselbe Berechnung**:
+
+```
+Required Capabilities  −  Known Capabilities  =  Capability Delta
+```
+
+`Known` entsteht aus Company Profile + Zertifizierungen + Nachweisen + beantworteten Fragen
+(Company 2A). `Required` entsteht aus den Zielregelwerken (CRA, MaschinenVO, Data Act, …).
+Die Differenz ist das **Capability Delta**. Erst beim Output verzweigt es sich nach Zielgruppe.
+
+Das Risiko: das Delta in mehreren Engines getrennt neu zu berechnen (eine „Gap Engine", eine
+„Roadmap Engine"). Dann driften die Sichten auseinander und es gibt mehr als eine Wahrheit.
+
+## Entscheidung
+
+1. **Es gibt genau EINE Capability Delta Engine** (`compliance/transition_reasoning`, RS-005).
+   Sie berechnet `Required − Known = Capability Delta` ein einziges Mal.
+
+2. **Alle Zielgruppen-Outputs sind RENDERER über demselben Delta — keine zweite Berechnung:**
+   - **Interview Renderer** — fehlende *Informationen* → Fragen (`TransitionQuestionRequest`, gebaut).
+   - **Roadmap / Management Renderer** — fehlende *Capabilities* → Maßnahmen nach regulatorischem
+     Hebel (`compliance/optimization`, gebaut).
+   - **Evidence Renderer** — fehlende *Evidence* → Nachweis-Upload (später).
+   - **(Ticket/Control Renderer)** — fehlende *Controls* → Tickets (später).
+
+3. **Abhängigkeitsrichtung:** Renderer hängen von der Delta-Engine ab, nie umgekehrt
+   (`optimization → transition_reasoning`, azyklisch). Die Delta-Engine bleibt hermetisch
+   (0 Fremd-Import), damit sie die einzige Quelle der Wahrheit bleibt.
+
+4. **Begriff:** „Gap" → **„Capability Delta"**. Es beschreibt präziser, was berechnet wird
+   (eine Differenz von Fähigkeiten), und trägt durch alle Renderer.
+
+## Konsequenzen
+
+- **Eine Wahrheit, viele Sichten.** Jede neue Capability, jedes neue Regelwerk und jeder neue
+  Nachweis verbessert automatisch ALLE Renderer gleichzeitig — kein Sicht-Drift.
+- **Kundenreise in drei Fragen, eine Datenbasis:** (1) *Was gilt für mich?* → Reasoning/Scope →
+  (2) *Was fehlt mir?* → Capability Delta → (3) *Womit anfangen?* → Optimierungsplan.
+- **Regulatory Leverage** (Roadmap-Renderer): `leverage(Maßnahme) = Anzahl Regelwerke/Anforderungen,
+  die sie gleichzeitig schließt`. Ranking nach Hebel + kumulative Abdeckung + Budget-Auswahl.
+- **Welt-1-Disziplin:** der Prozentwert des Roadmap-Renderers ist ein exakter Abzählwert über die
+  **identifizierten** Anforderungen (bekanntes Delta), **kein** „% gesetzeskonform" (Welt 2).
+- **Freeze-konform:** kein neues Metamodell, kein neuer Graph — Renderer sind reine, deterministische
+  Sichten (computed-not-stored). Neue Regelwerke bleiben ein Datenproblem (ADR-002).
+- Diese ADR ist non-runtime → kein Deploy (siehe [ADR-001](ADR-001-runtime-deploy-policy.md)).