fix(genome): Distillation-Prompt schärfen – Specialized-Definition + Anti-Patterns

- Specialized klar abgegrenzt: nur konkrete Server-Deployments, Renames, Seeding
- 5 häufige Distillation-Fehler dokumentiert (member-added ignorieren, nur Anfang lesen, etc.)
- Erweiterte Evolutions-Muster (GPU-Hardening, Hot-Reload, API statt Restart)
- Zusätzliche Sanitization-Regeln (Server-IPs, Package-Namen)
- Erwartete Conversion-Rate: 15-30% als Orientierung

.github/prompts/genome-distill.prompt.md

@@ -22,7 +22,7 @@ Für **jeden Trait** und jede Mutation darin:
 | ------------------ | ---------------------------------------------- | --------------------------------------------------------------- |
 | 🔴 **Critical**    | Bugfixes, die andere Repos auch treffen würden | Fehlende Escapes, falsche Tool-Syntax, Security-Lücke in Prompt |
 | 🟡 **Evolution**   | Generelle Verbesserungen, übertragbar          | Bessere Formulierung, neues Pattern, strukturelle Optimierung   |
-| ⚪ **Specialized** | Projektspezifisch, NICHT übertragbar           | App-spezifische Pfade, domänenspezifische Logik, Projekt-IDs    |
+| ⚪ **Specialized** | Projektspezifisch, NICHT übertragbar           | Deployment auf einen konkreten Server (IP/Domain), projektspezifische DB-Seeding-Daten, App-spezifische Package-Namen ohne generelles Pattern |
 
 ### 2. Scoring (1–10)
 
@@ -42,6 +42,25 @@ Ersetze in den Diffs:
 - Tokens, API-Keys, Secrets → `<redacted>`
 - Projektspezifische IDs (Issue-Nummern, Project-Board-IDs) → `<project-id>`
 - Repo-spezifische Namen (z.B. `bollwerk`, `krisenvorrat`) → `<project>`
+- Server-IPs/Domains (z.B. `195.246.231.210`, `bollwerk.online`) → `<server>`
+- Package-Namen (z.B. `de.bollwerk.app`) → `<package>`
+
+### Specialized vs. Evolution – Abgrenzung
+
+> **Specialized** = betrifft NUR dieses eine Projekt und ist nach Sanitization NICHT auf ein anderes Repo übertragbar.
+
+**Specialized (entfernen):**
+- Deployment-Skripte die eine konkrete Server-IP/Domain ansprechen (SCP auf den Island-VPS)
+- Projekt-Renames (`krisenvorrat` → `bollwerk`) ohne inhaltliche Verbesserung
+- Seeding-Daten, Issue-Body-Templates für ein konkretes Feature dieses Projekts
+- Docker-Compose-Anpassungen für einen konkreten Server
+
+**NICHT Specialized (behalten als Evolution):**
+- Technologie-Handling: Gradle-Build-Patterns, Room-Migration-Checklisten, Emulator-GPU-Workarounds
+- Workflow-Patterns: Ticket-Orchestrierung, Sub-Agent-Isolation, Board-Status-Automatisierung
+- Tooling-Bugfixes: PowerShell-Binary-Encoding umgehen, ADB-Timeout-Loops, Force-Kill-Fallbacks
+- Architektur-Patterns: API-Call statt Container-Restart, Hot-Reload ohne Emulator-Neustart
+- Neue Skills/Prompts deren Kernlogik nach Sanitization universell ist
 
 ### 4. Filterung
 
@@ -49,6 +68,38 @@ Ersetze in den Diffs:
 - **Reine Formatting-Änderungen** (nur Whitespace/Tabellenausrichtung): entfernen
 - **Renames ohne inhaltliche Änderung**: entfernen
 
+## ⚠️ Häufige Fehler bei der Distillation (vermeiden!)
+
+### Fehler 1: `member-added` pauschal als Specialized verwerfen
+
+Neue Dateien (`member-added`) sind oft die **wertvollsten** Mutations. Ein neuer Skill, Prompt oder Agent ist nach Sanitization häufig hochgradig übertragbar. Prüfe:
+- Enthält die Datei ein **allgemeines Pattern** (z.B. Checkliste, Workflow-Struktur, Fehlerklassen-Katalog)?
+- Ist sie nach Pfad-/Namen-Sanitization auf andere Projekte anwendbar?
+- → Wenn ja: **Evolution** (Score 7–9), nicht Specialized.
+
+**Nur** als Specialized werten, wenn der **gesamte Inhalt** projektspezifisch ist (z.B. nur eine Entity-Definition für eine bestimmte App).
+
+### Fehler 2: Nur den ersten Teil der raw-mutations lesen
+
+Die raw-mutations-Datei kann **tausende Zeilen** lang sein. Skills, Scripts und neue Traits stehen oft am Ende. **Lies die GESAMTE Datei** bevor du klassifizierst – nicht nur die ersten 1000–2000 Zeilen.
+
+### Fehler 3: Mehrteilige Commits nicht trennen
+
+Ein einzelner Commit kann enthalten:
+- 3× Specialized (Rename `krisenvorrat`→`bollwerk` in 3 Dateien)
+- 1× Evolution (GPU-Hardening-Pattern mit Timeout-Loop)
+- 1× Evolution (Hot-Reload-Action als neues Pattern)
+
+Trenne diese **pro Hunk**, nicht pro Commit.
+
+### Fehler 4: Technische Scripts als Specialized abtun
+
+PowerShell/Python-Scripts die ein **universelles DevOps-Problem** lösen (z.B. Emulator-Boot-Timing, PowerShell-Binary-Encoding-Bug, APK-Deployment ohne Container-Restart) sind **Evolutions**, auch wenn sie projektspezifische Pfade enthalten. Nach Sanitization sind sie übertragbar.
+
+### Fehler 5: Zu konservativ scoren
+
+Eine Conversion-Rate von < 10% ist ein Warnsignal. Bei typischen aktiven Repos mit 20+ Traits sollte die Rate bei **15–30%** liegen (bezogen auf Traits mit mindestens einer Evolution, nicht auf Mutations-Gesamtzahl).
+
 ## Regeln zur Diff-Analyse
 
 > ⚠️ **Wichtig: Commits haben oft eine dominante + eine versteckte Änderung.**
@@ -66,6 +117,11 @@ Gehe für jeden Commit wie folgt vor:
 - Board/Order-Zuweisung zu Ticket-Erstellung hinzugefügt → Evolution Score 8
 - Script-Aufruf statt vager Beschreibung in Prompt → Evolution Score 7
 - Vollständige Label-Liste statt unvollständiger → 🔴 Critical
+- **Neues Skript das universellen Bug umgeht** (z.B. PowerShell-Binary-Encoding, GPU-Inkompatibilität) → Evolution Score 8
+- **Neuer Skill/Prompt mit transferierbarer Checkliste** (z.B. DB-Migration-Steps, Audit-Fehlerklassen) → Evolution Score 8–9
+- **Workflow-Isolation** (Sub-Agent pro Iteration, kein geteilter Kontext) → Evolution Score 7
+- **API-Call statt Container-Restart** für Config-Updates → Evolution Score 7
+- **Timeout-Loop + Fallback** statt einfachem `wait-for-device` → Evolution Score 7
 
 ## Output-Format