---
description: "Knowledge Conduit Phase 2: Destilliert raw-improvements.md – klassifiziert, scored und bereinigt Improvements für Cross-Team-Transfer."
model: Claude Opus 4.6 (copilot)
tools: [read, edit]
---

# Knowledge Conduit – Distillation

Du erhältst eine Datei mit rohen Git-Improvements aus KI-Tooling-Dateien. Deine Aufgabe: **klassifizieren, scoren, bereinigen** – damit nur übertragbare Verbesserungen übrig bleiben.

## Input

Lies die Datei `.github/knowledge-conduit/output/raw-improvements.md`.

## Aufgabe

Für **jede Capability** und jedes Improvement darin:

### 1. Klassifizierung

| Klasse             | Bedeutung                                      | Beispiele                                                                                                                                     |
| ------------------ | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| 🔴 **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           | Deployment auf einen konkreten Server (IP/Domain), projektspezifische DB-Seeding-Daten, App-spezifische Package-Namen ohne generelles Pattern |

### 2. Scoring (1–10)

Bewerte den **Übertragungswert** jedes Critical/Evolution-Improvements:

- **9–10:** Universell wertvoll, jedes Repo profitiert
- **7–8:** Breit anwendbar, gutes Pattern
- **4–6:** Situativ nützlich
- **1–3:** Grenzwertig, kaum übertragbar

### 3. Sanitization

Ersetze in den Diffs:

- Benutzernamen → `<user>`
- Maschinenpfade (z.B. `C:\Users\...`, `/home/...`) → `<local-path>`
- 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

- **Specialized** Improvements: komplett entfernen (nicht in Output aufnehmen)
- **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** Improvements. 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-improvements lesen

Die raw-improvements-Datei kann **tausende Zeilen** lang sein. Skills, Scripts und neue Capabilities 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+ Capabilities sollte die Rate bei **15–30%** liegen (bezogen auf Capabilities mit mindestens einer Evolution, nicht auf Improvements-Gesamtzahl).

## Regeln zur Diff-Analyse

> ⚠️ **Wichtig: Commits haben oft eine dominante + eine versteckte Änderung.**

Gehe für jeden Commit wie folgt vor:

1. **Commit-Message ignorieren** – sie beschreibt nur die dominante Änderung
2. **Jeden geänderten Hunk einzeln bewerten** – auch wenn der Commit-Titel z.B. "rename" lautet, können einzelne Hunks inhaltliche Verbesserungen enthalten
3. **Rename-Churn erkennen**: Commit A ändert Pfad X→Y, Commit B ändert Y→X = beide Specialized. Erst wenn der finale Wert stabil ist, ist es eine Evolution
4. **Nicht zu früh aggregieren**: Ein Commit mit 10 Datei-Diffs kann 2 Specialized + 1 Evolution enthalten – trenne sie

**Häufige versteckte Evolutions-Muster:**

- Absolute Pfade (`C:\...`, `x:\...`) → relative Pfade (`.github/...`) → Evolution Score 8
- 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

Schreibe das Ergebnis in `.github/knowledge-conduit/output/distilled-insights.md` mit folgendem Format:

````markdown
# Distilled Insights

**Quelle:** <repo-name>
**Zeitraum:** <aus raw-improvements übernehmen>
**Distilliert:** <aktuelles Datum>
**Ergebnis:** X Critical, Y Evolution (Z Specialized entfernt)

---

## 🔴 Critical

### Capability: `<capability-key>`

**Score:** N/10
**Zusammenfassung:** <1-Satz was gefixt wurde>

```diff
<bereinigter Diff>
```
````

---

## 🟡 Evolution

### Capability: `<capability-key>`

**Score:** N/10
**Zusammenfassung:** <1-Satz was verbessert wurde>
**Pattern:** <abstrahiertes Pattern, das andere übernehmen können>

```diff
<bereinigter Diff>
```

```

## Regeln

- Fasse mehrere Commits an derselben Capability zu EINEM Improvement zusammen, wenn sie dasselbe verbessern
- Bei Score < 4: nicht aufnehmen (zu wenig Übertragungswert)
- Sortiere innerhalb jeder Klasse absteigend nach Score
- Halte Zusammenfassungen auf 1 Satz
- Das "Pattern"-Feld bei Evolution beschreibt die **generalisierte Verbesserung**, nicht den konkreten Change
- Diffs dürfen gekürzt werden – nur die relevanten Hunks behalten
- Schreibe am Ende einen **Analyse-Bericht** in den Chat (nicht in die Datei): `Capabilities: N | Improvements: M | Critical: A | Evolution: B | Specialized entfernt: C | Churn-Commits übersprungen: D`
```