bfa1f2b649
Gesamtes System umbenannt: - .github/genome/ → .github/knowledge-conduit/ - .github/skills/genome/ → .github/skills/knowledge-conduit/ - genome-extract.py → kc-extract.py - genome.prompt.md → knowledge-conduit.prompt.md - genome-distill.prompt.md → kc-distill.prompt.md - genome-propagate.prompt.md → kc-transfer.prompt.md - Concept Genome Engine.md → Concept.md - Alle internen Referenzen aktualisiert - .gitignore aktualisiert
181 lines
8.3 KiB
Markdown
181 lines
8.3 KiB
Markdown
---
|
||
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`
|
||
```
|