feat: evidence_type Feld (code/process/hybrid) fuer Controls

Neues Feld auf canonical_controls klassifiziert, ob ein Control
technisch im Source Code (code), organisatorisch via Dokumente (process)
oder beides (hybrid) nachgewiesen wird. Inklusive Backfill-Endpoint,
Frontend-Badge/Filter und MkDocs-Dokumentation.

- Migration 079: evidence_type VARCHAR(20) + Index
- Backend: Filter, Backfill-Endpoint mit Domain-Heuristik, CRUD
- Frontend: EvidenceTypeBadge (sky/amber/violet), Nachweisart-Dropdown
- Proxy: evidence_type Passthrough fuer controls + controls-count
- Tests: 22 Tests fuer Klassifikations-Heuristik
- Docs: Eigenes MkDocs-Kapitel mit Mermaid-Diagramm

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

docs-src/services/sdk-modules/evidence-type.md

@@ -0,0 +1,132 @@
+# Evidence Type — Code vs. Prozess Controls
+
+## Uebersicht
+
+Nicht jedes Control kann gleich nachgewiesen werden. Ein Verschluesselungs-Control
+ist im Quellcode pruefbar, ein Risikomanagement-Control erfordert Dokumente und
+Nachweise. Diese Unterscheidung bestimmt, **wie** die Compliance-Plattform den
+Nachweis automatisiert oder den Nutzer unterstuetzt.
+
+Das Feld `evidence_type` auf `canonical_controls` klassifiziert jeden Control
+in eine von drei Kategorien.
+
+## Die drei Typen
+
+```mermaid
+graph LR
+    subgraph "code"
+        C1["Source Code"]
+        C2["IaC / Terraform"]
+        C3["CI/CD Pipeline"]
+        C4["Cloud Config"]
+    end
+
+    subgraph "process"
+        P1["Policies"]
+        P2["Schulungsnachweise"]
+        P3["Vertraege"]
+        P4["Screenshots / Audits"]
+    end
+
+    subgraph "hybrid"
+        H1["Code + Doku"]
+        H2["Config + Schulung"]
+    end
+```
+
+### Code Controls
+
+| Eigenschaft | Beschreibung |
+|---|---|
+| **evidence_type** | `code` |
+| **Nachweis** | Automatisiert pruefbar: Source Code, IaC, CI/CD, Cloud-Konfiguration |
+| **Automatisierung** | Hoch — SAST, Dependency Scan, Config Audit |
+| **Beispiel-Domains** | SEC, AUTH, CRYPT, NET, LOG, ACC, API |
+| **Beispiel** | "AES-256 Verschluesselung at rest" → pruefbar via Code Review / IaC Scan |
+
+### Prozess Controls
+
+| Eigenschaft | Beschreibung |
+|---|---|
+| **evidence_type** | `process` |
+| **Nachweis** | Dokumente, Policies, Schulungsnachweise, Vertraege, Screenshots |
+| **Automatisierung** | Gering — erfordert manuelle Uploads oder MCP-Dokumenten-Scan |
+| **Beispiel-Domains** | GOV, ORG, COMP, LEGAL, HR, FIN, RISK, AUDIT, ENV |
+| **Beispiel** | "Reallabor-Zugang fuer KMUs bereitstellen" → Nachweis ueber Programm-Dokumentation |
+
+!!! info "Governance & Regulatorische Controls"
+    Controls wie "Behoerde muss KMUs Zugang zu Reallaboren geben" sind Prozess-Controls.
+    Der Nachweis erfolgt ueber Dokumente — nicht im Source Code.
+    Auch regulatorische Umsetzungspflichten (GOV-Domain) fallen hierunter.
+
+### Hybrid Controls
+
+| Eigenschaft | Beschreibung |
+|---|---|
+| **evidence_type** | `hybrid` |
+| **Nachweis** | Sowohl Code als auch Dokumente erforderlich |
+| **Automatisierung** | Teilweise — Code-Teil automatisiert, Prozess-Teil manuell |
+| **Beispiel-Domains** | DATA, AI, INC, IAM |
+| **Beispiel** | "MFA implementieren" → Config pruefbar (code) + Nutzer-Schulung noetig (process) |
+
+## Backfill-Heuristik
+
+Der Backfill klassifiziert Controls automatisch anhand des Domain-Prefix:
+
+```
+POST /api/compliance/v1/canonical/controls/backfill-evidence-type?dry_run=true
+```
+
+**Algorithmus:**
+
+1. Domain-Prefix extrahieren (z.B. `SEC` aus `SEC-042`)
+2. Gegen vordefinierte Domain-Sets pruefen (code / process / hybrid)
+3. Falls Domain unbekannt: Category als Fallback nutzen
+4. Falls auch keine Category: `process` (konservativ)
+
+### Domain-Zuordnung
+
+| Typ | Domains |
+|---|---|
+| **code** | SEC, AUTH, CRYPT, CRYP, NET, LOG, ACC, APP, SYS, API, WEB, DEV, SDL, PKI, HSM, TEE, TPM, VUL, ... |
+| **process** | GOV, ORG, COMP, LEGAL, HR, FIN, RISK, AUDIT, ENV, HLT, TRD, LAB, PHYS, PRIV, DPO, ... |
+| **hybrid** | DATA, AI, INC, IAM, OPS, MNT, INT, ... |
+
+## Frontend-Anzeige
+
+In der Control-Library werden Controls mit farbcodierten Badges angezeigt:
+
+| evidence_type | Badge | Farbe | Bedeutung |
+|---|---|---|---|
+| `code` | **Code** | Blau (sky) | Technisch, im Source Code pruefbar |
+| `process` | **Prozess** | Amber/Orange | Organisatorisch, Dokument-basiert |
+| `hybrid` | **Hybrid** | Violett | Beides erforderlich |
+
+Zusaetzlich steht ein Dropdown-Filter "Nachweisart" zur Verfuegung.
+
+## Zusammenspiel mit anderen Feldern
+
+| Feld | Zweck | Beispiel |
+|---|---|---|
+| `evidence_type` | **WAS** wird nachgewiesen (Code oder Prozess) | `code` |
+| `verification_method` | **WIE** wird verifiziert | `code_review`, `document`, `tool`, `hybrid` |
+| `evidence_confidence` | **WIE SICHER** ist der Nachweis (0.0 - 1.0) | `0.92` |
+| `normative_strength` | **WIE VERBINDLICH** ist das Control | `must`, `should`, `may` |
+
+!!! warning "evidence_type vs. verification_method"
+    `evidence_type` sagt, ob ein Control technisch oder organisatorisch ist.
+    `verification_method` sagt, mit welcher Methode es geprueft wird.
+    Ein `process`-Control kann trotzdem `verification_method = tool` haben
+    (z.B. wenn ein MCP-Scan Dokumente automatisch prueft).
+
+## Kuenftige Automatisierung
+
+### Code Controls
+- **Git-Repository-Scan**: SAST, Secret Detection, Dependency Check
+- **IaC-Analyse**: Terraform/Pulumi/CloudFormation Policies
+- **CI/CD-Integration**: Pipeline-Ergebnisse als Evidence sammeln
+
+### Prozess Controls
+- **MCP-Dokumenten-Scan**: Kunden-Laufwerk anbinden, Dokumente automatisch pruefen
+- **Screenshot-Analyse**: OCR + LLM-Validierung von Screenshots
+- **Interview-Protokolle**: Strukturierte Audit-Checklisten