refactor(admin): split controls, training, control-provenance, iace/verification pages

Each page.tsx exceeded the 500-LOC hard cap. Extracted components and hooks into
colocated _components/ and _hooks/ directories; page.tsx is now a thin orchestrator.

- controls/page.tsx: 944 → 180 LOC; extracted ControlCard, AddControlForm,
  LoadingSkeleton, TransitionErrorBanner, StatsCards, FilterBar, RAGPanel into
  _components/ and useControlsData, useRAGSuggestions into _hooks/; types into _types.ts
- training/page.tsx: 780 → 288 LOC; extracted ContentTab (inline content generator tab)
  into _components/ContentTab.tsx
- control-provenance/page.tsx: 739 → 122 LOC; extracted MarkdownRenderer, UsageBadge,
  PermBadge, LicenseMatrix, SourceRegistry into _components/; PROVENANCE_SECTIONS
  static data into _data/provenance-sections.ts
- iace/[projectId]/verification/page.tsx: 673 → 196 LOC; extracted StatusBadge,
  VerificationForm, CompleteModal, SuggestEvidenceModal, VerificationTable into _components/

Zero behavior changes; logic relocated verbatim.

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

admin-compliance/app/sdk/control-provenance/_data/provenance-sections.ts

@@ -0,0 +1,404 @@
+export interface ProvenanceSection {
+  id: string
+  title: string
+  content: string
+}
+
+export const PROVENANCE_SECTIONS: ProvenanceSection[] = [
+  {
+    id: 'methodology',
+    title: 'Methodik der Control-Erstellung',
+    content: `## Unabhaengige Formulierung
+
+Alle Controls in der Canonical Control Library wurden **eigenstaendig formuliert** und folgen einer
+**unabhaengigen Taxonomie**. Es werden keine proprietaeren Bezeichner, Nummern oder Strukturen
+aus geschuetzten Quellen uebernommen.
+
+### Dreistufiger Prozess
+
+1. **Offene Recherche** — Identifikation von Security-Anforderungen aus oeffentlichen, frei zugaenglichen
+   Frameworks (OWASP, NIST, ENISA). Jede Anforderung wird aus mindestens 2 unabhaengigen offenen Quellen belegt.
+
+2. **Eigenstaendige Formulierung** — Jedes Control wird mit eigener Sprache, eigener Struktur und eigener
+   Taxonomie (z.B. AUTH-001, NET-001) verfasst. Kein Copy-Paste, keine Paraphrase geschuetzter Texte.
+
+3. **Too-Close-Pruefung** — Automatisierte Aehnlichkeitspruefung gegen Quelltexte mit 5 Metriken
+   (Token Overlap, N-Gram Jaccard, Embedding Cosine, LCS Ratio, Exact-Phrase). Nur Controls mit
+   Status PASS oder WARN (+ Human Review) werden freigegeben.
+
+### Rechtliche Grundlage
+
+- **UrhG §44b** — Text & Data Mining erlaubt fuer Analyse; Kopien werden danach geloescht
+- **UrhG §23** — Hinreichender Abstand zum Originalwerk durch eigene Formulierung
+- **BSI Nutzungsbedingungen** — Kommerzielle Nutzung nur mit Zustimmung; wir nutzen BSI-Dokumente
+  ausschliesslich als Analysegrundlage, nicht im Produkt`,
+  },
+  {
+    id: 'filters',
+    title: 'Filter in der Control Library',
+    content: `## Dropdown-Filter
+
+Die Control Library bietet 7 Filter-Dropdowns, um die ueber 3.000 Controls effizient zu durchsuchen:
+
+### Schweregrad (Severity)
+
+| Stufe | Farbe | Bedeutung |
+|-------|-------|-----------|
+| **Kritisch** | Rot | Sicherheitskritische Controls — Verstoesse fuehren zu schwerwiegenden Risiken |
+| **Hoch** | Orange | Wichtige Controls — sollten zeitnah umgesetzt werden |
+| **Mittel** | Gelb | Standardmaessige Controls — empfohlene Umsetzung |
+| **Niedrig** | Gruen | Nice-to-have Controls — zusaetzliche Haertung |
+
+### Domain
+
+Das Praefix der Control-ID (z.B. \`AUTH-001\`, \`SEC-042\`). Kennzeichnet den thematischen Bereich.
+Die haeufigsten Domains:
+
+| Domain | Anzahl | Thema |
+|--------|--------|-------|
+| SEC | ~700 | Allgemeine Sicherheit, Systemhaertung |
+| COMP | ~470 | Compliance, Regulierung, Nachweispflichten |
+| DATA | ~400 | Datenschutz, Datenklassifizierung, DSGVO |
+| AI | ~290 | KI-Regulierung (AI Act, Transparenz, Erklaerbarkeit) |
+| LOG | ~230 | Logging, Monitoring, SIEM |
+| AUTH | ~200 | Authentifizierung, Zugriffskontrolle |
+| NET | ~150 | Netzwerksicherheit, Transport, Firewall |
+| CRYP | ~90 | Kryptographie, Schluesselmanagement |
+| ACC | ~25 | Zugriffskontrolle (Access Control) |
+| INC | ~25 | Incident Response, Vorfallmanagement |
+
+Zusaetzlich existieren spezialisierte Domains wie CRA, ARC (Architektur), API, PKI, SUP (Supply Chain) u.v.m.
+
+### Status (Release State)
+
+| Status | Bedeutung |
+|--------|-----------|
+| **Draft** | Entwurf — noch nicht freigegeben |
+| **Approved** | Freigegeben fuer Kunden |
+| **Review noetig** | Muss manuell geprueft werden |
+| **Zu aehnlich** | Too-Close-Check hat Warnung ausgeloest |
+| **Duplikat** | Wurde als Duplikat eines anderen Controls erkannt |
+
+### Nachweis (Verification Method)
+
+| Methode | Farbe | Beschreibung |
+|---------|-------|-------------|
+| **Code Review** | Blau | Nachweis durch Quellcode-Inspektion |
+| **Dokument** | Amber | Nachweis durch Richtlinien, Prozesse, Schulungen |
+| **Tool** | Teal | Nachweis durch automatisierte Scans/Monitoring |
+| **Hybrid** | Lila | Kombination aus mehreren Methoden |
+
+### Kategorie
+
+Thematische Einordnung (17 Kategorien). Kategorien sind **thematisch**, Domains **strukturell**.
+Ein AUTH-Control kann z.B. die Kategorie "Netzwerksicherheit" haben.
+
+### Zielgruppe (Target Audience)
+
+| Zielgruppe | Bedeutung |
+|------------|-----------|
+| **Unternehmen** | Fuer Endkunden/Firmen relevant |
+| **Behoerden** | Spezifisch fuer oeffentliche Verwaltung |
+| **Anbieter** | Fuer SaaS/Plattform-Anbieter |
+| **Alle** | Allgemein anwendbar |
+
+### Dokumentenursprung (Source)
+
+Filtert nach der Quelldokument-Herkunft des Controls. Zeigt alle Quellen sortiert nach
+Haeufigkeit. Die wichtigsten Quellen:
+
+| Quelle | Typ |
+|--------|-----|
+| KI-Verordnung (EU) 2024/1689 | EU-Recht |
+| Cyber Resilience Act (EU) 2024/2847 | EU-Recht |
+| DSGVO (EU) 2016/679 | EU-Recht |
+| NIS2-Richtlinie (EU) 2022/2555 | EU-Recht |
+| NIST SP 800-53, CSF 2.0, SSDF | US-Standards |
+| OWASP Top 10, ASVS, SAMM | Open Source |
+| ENISA Guidelines | EU-Agentur |
+| CISA Secure by Design | US-Behoerde |
+| BDSG, TKG, GewO, HGB | Deutsche Gesetze |
+| EDPB Leitlinien | EU Datenschutz |`,
+  },
+  {
+    id: 'badges',
+    title: 'Badges & Lizenzregeln',
+    content: `## Badges in der Control Library
+
+Jedes Control zeigt mehrere farbige Badges:
+
+### Lizenzregel-Badge (Rule 1 / 2 / 3)
+
+Die Lizenzregel bestimmt, wie ein Control erstellt und genutzt werden darf:
+
+| Badge | Farbe | Regel | Bedeutung |
+|-------|-------|-------|-----------|
+| **Free Use** | Gruen | Rule 1 | Quelle ist Public Domain oder EU-Recht — Originaltext darf gezeigt werden |
+| **Zitation** | Blau | Rule 2 | Quelle ist CC-BY oder aehnlich — Zitation + Quellenangabe erforderlich |
+| **Reformuliert** | Amber | Rule 3 | Quelle hat eingeschraenkte Lizenz — Control wurde eigenstaendig reformuliert, kein Originaltext |
+
+### Processing-Path
+
+| Pfad | Bedeutung |
+|------|-----------|
+| **structured** | Control wurde direkt aus strukturierten Daten (Tabellen, Listen) extrahiert |
+| **llm_reform** | Control wurde mit LLM eigenstaendig formuliert (bei Rule 3 zwingend) |
+
+### Referenzen (Open Anchors)
+
+Zeigt die Anzahl der verlinkten Open-Source-Referenzen (OWASP, NIST, ENISA etc.).
+Jedes freigegebene Control muss mindestens 1 Open Anchor haben.
+
+### Weitere Badges
+
+| Badge | Bedeutung |
+|-------|-----------|
+| Score | Risiko-Score (0-10) |
+| Severity-Badge | Schweregrad (Kritisch/Hoch/Mittel/Niedrig) |
+| State-Badge | Freigabestatus (Draft/Approved/etc.) |
+| Kategorie-Badge | Thematische Kategorie |
+| Zielgruppe-Badge | Enterprise/Behoerden/Anbieter/Alle |`,
+  },
+  {
+    id: 'taxonomy',
+    title: 'Unabhaengige Taxonomie',
+    content: `## Eigenes Klassifikationssystem
+
+Die Canonical Control Library verwendet ein **eigenes Domain-Schema**, das sich bewusst von
+proprietaeren Frameworks unterscheidet. Die Domains werden **automatisch** durch den
+Control Generator vergeben, basierend auf dem Inhalt der Quelldokumente.
+
+### Top-10 Domains
+
+| Domain | Anzahl | Thema | Hauptquellen |
+|--------|--------|-------|-------------|
+| SEC | ~700 | Allgemeine Sicherheit | CRA, NIS2, BSI, ENISA |
+| COMP | ~470 | Compliance & Regulierung | DSGVO, AI Act, Richtlinien |
+| DATA | ~400 | Datenschutz & Datenklassifizierung | DSGVO, BDSG, EDPB |
+| AI | ~290 | KI-Regulierung & Ethik | AI Act, HLEG, OECD |
+| LOG | ~230 | Logging & Monitoring | NIST, OWASP |
+| AUTH | ~200 | Authentifizierung & Session | NIST SP 800-63, OWASP |
+| NET | ~150 | Netzwerksicherheit | NIST, ENISA |
+| CRYP | ~90 | Kryptographie & Schluessel | NIST SP 800-57 |
+| ACC | ~25 | Zugriffskontrolle | OWASP ASVS |
+| INC | ~25 | Incident Response | NIS2, CRA |
+
+### Spezialisierte Domains
+
+Neben den Top-10 gibt es ueber 90 weitere Domains fuer spezifische Themen:
+
+- **CRA** — Cyber Resilience Act spezifisch
+- **ARC** — Sichere Architektur
+- **API** — API-Security
+- **PKI** — Public Key Infrastructure
+- **SUP** — Supply Chain Security
+- **VUL** — Vulnerability Management
+- **BCP** — Business Continuity
+- **PHY** — Physische Sicherheit
+- u.v.m.
+
+### ID-Format
+
+Control-IDs folgen dem Muster \`DOMAIN-NNN\` (z.B. AUTH-001, SEC-042). Dieses Format ist
+**nicht von BSI oder anderen proprietaeren Standards abgeleitet**, sondern folgt einem
+allgemein ueblichen Nummerierungsschema.`,
+  },
+  {
+    id: 'open-sources',
+    title: 'Offene Referenzquellen',
+    content: `## Primaere offene Quellen
+
+Alle Controls sind in mindestens einer der folgenden **frei zugaenglichen** Quellen verankert:
+
+### OWASP (CC BY-SA 4.0 — kommerziell erlaubt)
+- **ASVS** — Application Security Verification Standard v4.0.3
+- **MASVS** — Mobile Application Security Verification Standard v2.1
+- **Top 10** — OWASP Top 10 (2021)
+- **Cheat Sheets** — OWASP Cheat Sheet Series
+- **SAMM** — Software Assurance Maturity Model
+
+### NIST (Public Domain — keine Einschraenkungen)
+- **SP 800-53 Rev.5** — Security and Privacy Controls
+- **SP 800-63B** — Digital Identity Guidelines (Authentication)
+- **SP 800-57** — Key Management Recommendations
+- **SP 800-52 Rev.2** — TLS Implementation Guidelines
+- **SP 800-92** — Log Management Guide
+- **SP 800-218 (SSDF)** — Secure Software Development Framework
+- **SP 800-60** — Information Types to Security Categories
+
+### ENISA (CC BY 4.0 — kommerziell erlaubt)
+- Good Practices for IoT/Mobile Security
+- Data Protection Engineering
+- Algorithms, Key Sizes and Parameters Report
+
+### Weitere offene Quellen
+- **SLSA** (Supply-chain Levels for Software Artifacts) — Google Open Source
+- **CIS Controls v8** (CC BY-NC-ND — nur fuer interne Analyse)`,
+  },
+  {
+    id: 'restricted-sources',
+    title: 'Geschuetzte Quellen — Nur interne Analyse',
+    content: `## Quellen mit eingeschraenkter Nutzung
+
+Die folgenden Quellen werden **ausschliesslich intern zur Analyse** verwendet.
+Kein Text, keine Struktur, keine Bezeichner aus diesen Quellen erscheinen im Produkt.
+
+### BSI (Nutzungsbedingungen — kommerziell eingeschraenkt)
+- TR-03161 Teil 1-3 (Mobile, Web, Hintergrunddienste)
+- Nutzung: TDM unter UrhG §44b, Kopien werden geloescht
+- Kein Shipping von Zitaten, Embeddings oder Strukturen
+
+### ISO/IEC (Kostenpflichtig — kein Shipping)
+- ISO 27001, ISO 27002
+- Nutzung: Nur als Referenz fuer Mapping, kein Text im Produkt
+
+### ETSI (Restriktiv — kein kommerzieller Gebrauch)
+- Nutzung: Nur als Hintergrundwissen, kein direkter Einfluss
+
+### Trennungsprinzip
+
+| Ebene | Geschuetzte Quelle | Offene Quelle |
+|-------|--------------------|---------------|
+| Analyse | ✅ Darf gelesen werden | ✅ Darf gelesen werden |
+| Inspiration | ✅ Darf Ideen liefern | ✅ Darf Ideen liefern |
+| Formulierung | ❌ Keine Uebernahme | ✅ Darf zitiert werden |
+| Struktur | ❌ Keine Uebernahme | ✅ Darf verwendet werden |
+| Produkttext | ❌ Nicht erlaubt | ✅ Erlaubt |`,
+  },
+  {
+    id: 'verification-methods',
+    title: 'Verifikationsmethoden',
+    content: `## Nachweis-Klassifizierung
+
+Jedes Control wird einer von vier Verifikationsmethoden zugeordnet. Dies bestimmt,
+**wie** ein Kunde den Nachweis fuer die Einhaltung erbringen kann:
+
+| Methode | Beschreibung | Beispiele |
+|---------|-------------|-----------|
+| **Code Review** | Nachweis durch Quellcode-Inspektion | Input-Validierung, Encryption-Konfiguration, Auth-Logic |
+| **Dokument** | Nachweis durch Richtlinien, Prozesse, Schulungen | Notfallplaene, Schulungsnachweise, Datenschutzkonzepte |
+| **Tool** | Nachweis durch automatisierte Tools/Scans | SIEM-Logs, Vulnerability-Scans, Monitoring-Dashboards |
+| **Hybrid** | Kombination aus mehreren Methoden | Zugriffskontrollen (Code + Policy + Tool) |
+
+### Bedeutung fuer Kunden
+
+- **Code Review Controls** koennen direkt im SDK-Scan geprueft werden
+- **Dokument Controls** erfordern manuelle Uploads (PDFs, Links)
+- **Tool Controls** koennen per API-Integration automatisch nachgewiesen werden
+- **Hybrid Controls** benoetigen mehrere Nachweisarten`,
+  },
+  {
+    id: 'categories',
+    title: 'Thematische Kategorien',
+    content: `## 17 Sicherheitskategorien
+
+Controls sind in thematische Kategorien gruppiert, um Kunden eine
+uebersichtliche Navigation zu ermoeglichen:
+
+| Kategorie | Beschreibung |
+|-----------|-------------|
+| Verschluesselung & Kryptographie | TLS, Key Management, Algorithmen |
+| Authentisierung & Zugriffskontrolle | Login, MFA, RBAC, Session-Management |
+| Netzwerksicherheit | Firewall, Segmentierung, VPN, DNS |
+| Datenschutz & Datensicherheit | DSGVO, Datenklassifizierung, Anonymisierung |
+| Logging & Monitoring | SIEM, Audit-Logs, Alerting |
+| Vorfallmanagement | Incident Response, Meldepflichten |
+| Notfall & Wiederherstellung | BCM, Disaster Recovery, Backups |
+| Compliance & Audit | Zertifizierungen, Audits, Berichtspflichten |
+| Lieferkettenmanagement | Vendor Risk, SBOM, Third-Party |
+| Physische Sicherheit | Zutritt, Gebaeudesicherheit |
+| Personal & Schulung | Security Awareness, Rollenkonzepte |
+| Anwendungssicherheit | SAST, DAST, Secure Coding |
+| Systemhaertung & -betrieb | Patching, Konfiguration, Hardening |
+| Risikomanagement | Risikoanalyse, Bewertung, Massnahmen |
+| Sicherheitsorganisation | ISMS, Richtlinien, Governance |
+| Hardware & Plattformsicherheit | TPM, Secure Boot, Firmware |
+| Identitaetsmanagement | SSO, Federation, Directory |
+
+### Abgrenzung zu Domains
+
+Kategorien sind **thematisch**, Domains (AUTH, NET, etc.) sind **strukturell**.
+Ein Control AUTH-005 (Domain AUTH) hat die Kategorie "authentication",
+aber ein Control NET-012 (Domain NET) koennte ebenfalls die Kategorie
+"authentication" haben, wenn es um Netzwerk-Authentifizierung geht.`,
+  },
+  {
+    id: 'master-library',
+    title: 'Master Library Strategie',
+    content: `## RAG-First Ansatz
+
+Die Canonical Control Library folgt einer **RAG-First-Strategie**:
+
+### Schritt 1: Rule 1+2 Controls aus RAG generieren
+
+Prioritaet haben Controls aus Quellen mit **Originaltext-Erlaubnis**:
+
+| Welle | Quellen | Lizenzregel | Vorteil |
+|-------|---------|------------|---------|
+| 1 | OWASP (ASVS, MASVS, Top10) | Rule 2 (CC-BY-SA, Zitation) | Originaltext + Zitation |
+| 2 | NIST (SP 800-53, CSF, SSDF) | Rule 1 (Public Domain) | Voller Text, keine Einschraenkungen |
+| 3 | EU-Verordnungen (DSGVO, AI Act, NIS2, CRA) | Rule 1 (EU Law) | Gesetzestext + Erklaerung |
+| 4 | Deutsche Gesetze (BDSG, TTDSG, TKG) | Rule 1 (DE Law) | Gesetzestext + Erklaerung |
+
+### Schritt 2: Dedup gegen BSI Rule-3 Controls
+
+Die ~880 BSI Rule-3 Controls werden **gegen** die neuen Rule 1+2 Controls abgeglichen:
+
+- Wenn ein BSI-Control ein Duplikat eines OWASP/NIST-Controls ist → **OWASP/NIST bevorzugt**
+  (weil Originaltext + Zitation erlaubt)
+- BSI-Duplikate werden als \`deprecated\` markiert
+- Tags und Anchors werden in den behaltenen Control zusammengefuehrt
+
+### Schritt 3: Aktueller Stand
+
+Aktuell: **~3.100+ Controls** (Stand Maerz 2026), davon:
+- Viele mit \`source_original_text\` (Originaltext fuer Kunden sichtbar)
+- Viele mit \`source_citation\` (Quellenangabe mit Lizenz)
+- Klare Nachweismethode (\`verification_method\`)
+- Thematische Kategorie (\`category\`)
+
+### Verstaendliche Texte
+
+Zusaetzlich zum Originaltext (der oft juristisch/technisch formuliert ist)
+enthaelt jedes Control ein eigenstaendig formuliertes **Ziel** (objective)
+und eine **Begruendung** (rationale) in verstaendlicher Sprache.`,
+  },
+  {
+    id: 'validation',
+    title: 'Automatisierte Validierung',
+    content: `## CI/CD-Pruefungen
+
+Jedes Control wird bei jedem Commit automatisch geprueft:
+
+### 1. Schema-Validierung
+- Alle Pflichtfelder vorhanden
+- Control-ID Format: \`^[A-Z]{2,6}-[0-9]{3}$\`
+- Severity: low, medium, high, critical
+- Risk Score: 0-10
+
+### 2. No-Leak Scanner
+Regex-Pruefung gegen verbotene Muster in produktfaehigen Feldern:
+- \`O.[A-Za-z]+_[0-9]+\` — BSI Objective-IDs
+- \`TR-03161\` — Direkte BSI-TR-Referenzen
+- \`BSI-TR-\` — BSI-spezifische Locators
+- \`Anforderung [A-Z].[0-9]+\` — BSI-Anforderungsformat
+
+### 3. Open Anchor Check
+Jedes freigegebene Control muss mindestens 1 Open-Source-Referenz haben.
+
+### 4. Too-Close Detektor (5 Metriken)
+
+| Metrik | Warn | Fail | Beschreibung |
+|--------|------|------|-------------|
+| Exact Phrase | ≥8 Tokens | ≥12 Tokens | Laengste identische Token-Sequenz |
+| Token Overlap | ≥0.20 | ≥0.30 | Jaccard-Aehnlichkeit der Token-Mengen |
+| 3-Gram Jaccard | ≥0.10 | ≥0.18 | Zeichenketten-Aehnlichkeit |
+| Embedding Cosine | ≥0.86 | ≥0.92 | Semantische Aehnlichkeit (bge-m3) |
+| LCS Ratio | ≥0.35 | ≥0.50 | Longest Common Subsequence |
+
+**Entscheidungslogik:**
+- **PASS** — Kein Fail + max 1 Warn
+- **WARN** — Max 2 Warn, kein Fail → Human Review erforderlich
+- **FAIL** — Irgendein Fail → Blockiert, Umformulierung noetig`,
+  },
+]