# Wiederkehrende lokale Probleme (Persistent Issues)

**Erstellt:** 2026-05-24
**Standort:** `~/.pi/agent/memory/persistent-issues.md`
**Spiegel:** CrowdBrain `persistent-issues.md`

---

## Regel: Wann ist ein Problem WIRKLICH gelöst?

Ein Problem gilt erst dann als **erledigt**, wenn es **mehrere Tage hintereinander nicht mehr aufgetreten** ist.
Ein Fix, der einmal funktioniert, ist kein gelöster Bug — er ist eine Hypothese, die sich über Zeit beweisen muss.

**Vor jedem Schließen eines Tickets prüfen:**
1. Wie viele Resume-/Reboot-Zyklen hat der Fix überlebt? (Minimum: 3)
2. Ist das Problem in dieser Session reproduzierbar NICHT aufgetreten?
3. Gab es einen System-Update, der den Fix unwirksam machen könnte?

---

## 🟢 Problem 1: Spracherkennung nach Standby-Resume

**Status:** In Bewährung (Fix vom 2026-05-24)

**Status-Änderung (2026-05-24):**
- Aktueller Stand: Persistence Mode (GPU) aktiviert
- `Standby`-Skript modifiziert (stoppt Dienst vor Suspend)
- Auto-Resume-Trigger (`crowd-nvidia-speech-resume.service`) eingerichtet
- Implementierung eines „Wait-for-GPU“-Checks (`/usr/local/bin/Speech-Auto-Start`) anstelle fester Wartezeit (Test steht aus)
- Service-Korrektur: `Environment=CUDA_VISIBLE_DEVICES=0` (zwingt GPU-Nutzung)

**Bewährungsprüfung (Erfolgs-Kriterien):**
- [ ] 3 Suspend-/Resume-Zyklen hintereinander erfolgreich (Startet auf GPU, performant)?
- [ ] Keine CPU-Fallback-Warnungen im Log?
- [ ] Die neue Warte-Logik startet den Speech-Dienst zuverlässig erst NACH Treiber-Bereitschaft?

---

## 🟡 Problem 2: Session-Header Extension (UI-kritisch)

**Erstmals erstellt:** 2026-05-23
**Status:** ✅ Funktioniert aktuell (2026-05-24)

### Was es tut
Die Extension `~/.pi/agent/extensions/session-header.ts` zeigt in gelber Schrift eine vom LLM generierte Zusammenfassung der Session-Intention oberhalb des Pi-Editors an.

### Warum es hier gelistet ist
Dies ist ein **kritisches UI-Element**: Wenn es unbemerkt kaputtgeht, kann der Benutzer in der falschen Session die falschen Befehle eingeben. Es darf nicht stillschweigend ausfallen.

### Prüf-Checkliste (bei jeder Session)
- [ ] Gelbe Statusleiste sichtbar?
- [ ] Zeigt die korrekte Session-Intention?
- [ ] Kein „warte auf erste Eingabe…“-Fallback in einer laufenden Session?

### Was tun bei Ausfall?
1. Extension-Log prüfen
2. Fallback: `truncate(text)` zeigt den Originaltext an — das ist okay als Notlösung
3. Nicht ohne Ersatz weiterarbeiten

---

## 🔴 Problem 3: Tickets werden zu früh geschlossen (Metaprozess)

**Erstmals dokumentiert:** 2026-05-24
**Status:** ❌ SYSTEMISCHES PROBLEM

### Muster
1. Problem tritt auf → Ticket wird erstellt
2. Fix wird implementiert → Fix funktioniert einmal
3. Ticket wird als „erledigt“ markiert
4. Problem tritt Tage/Wochen später wieder auf
5. Ticket ist bereits geschlossen → wird nicht erneut geöffnet
6. Benutzer muss Problem erneut melden

### Bekannte Vorfälle
- Spracherkennung nach Standby (siehe Problem 1)
- Weitere? (Liste wächst mit jedem neuen Vorfall)

### Systemische Lösung
- **Mindest-Bewährungszeit:** 3 Resume-/Reboot-Zyklen oder 3 Tage ohne Wiederauftreten
- **Status „Bewährung“** statt „Erledigt“: Ein neuer Status zwischen „Offen“ und „Erledigt“
- **Diese Datei ist der Kanon**: Was hier als ungelöst steht, ist ungelöst — egal was in todos.md steht

---

## 🔴 Problem 4: Pi Skills landen im falschen Verzeichnis (strukturiert)

**Erstmals dokumentiert:** 2026-05-24
**Status:** ✅ GEFIXT (2026-05-24) — in Bewährung

### Symptom
Pi las seine Skills aus `~/.claude/skills/` (Verzeichnis des Claude-Code-Agenten) statt aus `~/.pi/agent/skills/`. Dadurch:
- Agenten schrieben Skills in das falsche Verzeichnis
- Andere Agenten oder globale Befehle lasen aus dem richtigen Verzeichnis → alter Stand
- Nach Session-Neustarts waren Änderungen "verschwunden" weil die falsche Datei gelesen wurde
- Dies war die **Root Cause** für mehrfache Fehlschläge bei Skill-Updates (Video-Analyse, Session-Header, etc.)

### Was passiert ist
In `~/.pi/agent/settings.json` war konfiguriert:
```json
"skills": ["~/.claude/skills"]
```
Das ist das Skills-Verzeichnis von Anthropic Claude Code (einem völlig anderen Tool). Pi hat dort gelesen und geschrieben.

### Fix (2026-05-24)
- `settings.json` korrigiert: `"skills": ["~/.pi/agent/skills"]`
- AGENTS.md um Regel ergänzt: Skills gehören AUSSCHLIESSLICH nach `~/.pi/agent/skills/`
- Video-Analyse-Skill neu geschrieben und in alle drei Orte synchronisiert

### Bewährungsprüfung
- [ ] Nächste Session: Prüfen ob Pi Skills aus `~/.pi/agent/skills/` liest
- [ ] Skill-Änderung überlebt Session-Neustart?
- [ ] Globale Befehle (Videoanalyse etc.) funktionieren mit dem neuen Stand?
- Minimum: 3 Session-Wechsel ohne Rückfall

### Verwandte Einträge
- AGENTS.md — Abschnitt "Skill-Verzeichnis-Regel"
- Problem 3 (Tickets zu früh geschlossen) — dieses Muster war eine Folge dieses Problems

---

## 🟡 Problem 5: Session-Index zeigt keine Handover-Links (für 20260524-Projekt)

**Erstmals dokumentiert:** 2026-05-24
**Status:** ❌ NICHT GELÖST

### Symptom
Die Extension `session-index.ts` erzeugt korrekt einen Rolling Index der letzten 10 Sessions (`SESSION_INDEX.md`). Aber:
- Alle Sessions heißen „(unbenannt)" — keine Session-Namen gesetzt
- Handover-Links werden nicht gefunden, obwohl `SESSION_HANDOVER.md` im Projektverzeichnis liegt
- Die Extension fragt beim Start NICHT ob das Handover geladen werden soll
- Ergebnis: Jede neue Session startet blind, Benutzer muss Kontext manuell rekonstruieren

### Betroffene Komponenten
- `~/.pi/agent/extensions/session-index.ts` — Rolling Session Index
- `~/.pi/agent/extensions/session-header.ts` — Session-Namen setzen
- `~/.pi/agent/SESSION_INDEX.md` — generierter Index
- `<projekt>/SESSION_HANDOVER.md` — Handover-Datei

### Vermutete Ursachen
1. **Handover-Pfad-Auflösung:** Die Funktion `findHandover()` rekonstruiert den Projektpfad aus dem Verzeichnis-Slug. Für `--media-xray-NEU-Code-20260524--` muss sie `/media/xray/NEU/Code/20260524/SESSION_HANDOVER.md` finden — das klappt nicht.
2. **Session-Namen:** `getSessionName()` sucht nach `header.name` — aber die Session-Header-Extension setzt den Namen möglicherweise zu spät oder in einem anderen Feld.

### Nächste Schritte
1. Debug: Warum wird der Handover für das 20260524-Projekt nicht gefunden?
2. Debug: Warum bleiben Session-Namen auf „(unbenannt)"?
3. Fix und testen

---

## 🔴 Problem 6: OpenRouter DeepSeek-V4-Pro Provider-Routing (nicht wie erwartet)

**Erstmals dokumentiert:** 2026-05-24
**Status:** ❌ NICHT GELÖST

### Symptom
OpenRouter listet den nativen DeepSeek-Provider für `deepseek/deepseek-v4-pro` (preis: $0.435/1M Input), aber Requests mit `provider.only: ["deepseek"]` oder `provider.order: ["deepseek"]` schlagen mit 404 fehl: "No endpoints available matching your guardrail restrictions and data policy."

Andere Provider (DeepInfra $1.30, SiliconFlow $0.858, Together) funktionieren.

### Vermutete Ursache (Hypothesen)
- Privacy/Guardrail-Einstellungen auf https://openrouter.ai/settings/privacy blockieren den DeepSeek-Provider
- Geografische Einschränkung (DeepSeek-Provider nur in bestimmten Regionen)
- Account-Tier reicht nicht für diesen Provider

### Workaround (aktiv)
- `openRouterRouting` aus der Model-Config entfernt → OpenRouter wählt automatisch den günstigsten verfügbaren Provider

### Nächste Schritte
1. OpenRouter Privacy-Einstellungen prüfen
2. Im OpenRouter Dashboard nachsehen, ob DeepSeek-Provider für diesen Account verfügbar ist
3. Ggf. OpenRouter-Support kontaktieren

---

## 🟡 Problem 7: Git-Remotes mit HTTPS-Tokens statt SSH (Hygiene)

**Erstmals dokumentiert:** 2026-05-24
**Status:** ❌ NICHT ERLEIDGT

### Symptom
~35 Repos in `/media/xray/NEU/Code/` nutzen HTTPS-Remotes mit eingebetteten Forgejo-Tokens:
```
https://xray:TOKEN@forgejo.ccpn.cc/xray/repo.git
```

### Risiko
- Nicht akut (HTTPS verschlüsselt den Transport)
- Aber: Token liegt lesbar in `.git/config`, könnte versehentlich committed werden
- Cloudflare könnte HTTPS auf `forgejo.ccpn.cc` blockieren wie bei Port 2220

### Ziel
Alle Remotes auf SSH via `forgejo-git` umstellen:
```
ssh://git@forgejo-git/xray/repo.git
```

### Nächste Schritte
1. Skript schreiben, das alle HTTPS-Remotes erkennt und umstellt
2. Nach der Umstellung Tokens in Forgejo rotieren
3. Alte Tokens aus Infisical entfernen

## 🔴 Problem 9: Orchestrator startet eigenmächtig Änderungs-SubAgenten (NEU 2026-05-30)

**Erstmals dokumentiert:** 2026-05-30
**Status:** ❌ NICHT GELÖST (Regel eingeführt, muss sich bewähren)

### Symptom
Der Orchestrator erkennt ein Problem an einem funktionierenden System (z.B. Spracherkennung läuft auf CPU statt CUDA) und startet eigenmächtig — **ohne Rückfrage beim Benutzer** — einen SubAgenten, der das System überschreiben/modifizieren soll.

### Konkreter Vorfall (2026-05-30)
- **System:** CrowdNVIDIASpeech (Spracherkennung) — lief auf CPU statt CUDA nach Neustart
- **Problem:** ctranslate2 war als CPU-only-Version installiert, CUDA-Device-Count = 0
- **Mein Fehler:** Ich startete SubAgent "speech-cuda-fix" mit dem Auftrag, ctranslate2 neu zu installieren
- **Warum falsch:** Die Spracherkennung FUNKTIONIERTE (auf CPU, wenn auch langsam). Ein Eingriff riskierte eine funktionierende Lösung ohne Not
- **Gestoppt:** Der SubAgent wurde gestoppt, bevor er Änderungen vornahm

### Ursache
- Keine klare Regel, wann der Orchestrator eigenständig handeln darf
- Falsche Priorisierung: "Läuft nicht optimal" ≠ "Muss sofort gefixt werden"
- Fehlende Reflexion: „Ist das System aktuell funktional und gebrauchsfähig?" wurde nicht gestellt

### Regel (eingeführt 2026-05-30 in arbeitsweise.md §6)

**Der Orchestrator startet NIEMALS eigenmächtig einen SubAgenten, der eine funktionierende Lösung überschreiben, ersetzen oder modifizieren soll.**

Korrekter Ablauf:
1. Diagnostizieren (erlaubt)
2. Befund präsentieren (erlaubt)
3. Benutzer entscheiden lassen (PFLICHT)
4. Dann delegieren

### Bewährungsprüfung
- [ ] Orchestrator fragt vor Änderungen an funktionierenden Systemen zurück
- [ ] Kein unerlaubter SubAgent-Start in dieser Session
- [ ] Regel ist im Arbeitsgedächtnis verankert (nicht nur in Datei)

---

## 🟡 Problem 8: Intercom-Rückmeldung von Subagenten schlägt fehl (Orchestrator-ID)

**Erstmals dokumentiert:** 2026-05-29
**Status:** ❌ NICHT GELÖST

### Symptom
Subagenten versuchen, sich nach Abschluss per intercom an "orchestrator" zu melden.
Die Nachricht kommt nicht an, weil die echte Orchestrator-Session eine zufällige ID hat (z.B. `3c56b8b8`).

Fehler: `Message to "orchestrator" was not delivered: Session not found`

### Ursache
Der Subagent hat im instruktionstext kein Wissen über die aktuelle Orchestrator-Session-ID.
Er rät "orchestrator" als Ziel, aber das ist kein gültiger Session-Name/ID.

### Fix (2026-05-29)
- AGENTS.md aktualisiert: Jede Subagenten-Aufgabe MUSS die aktuelle Orchestrator-ID enthalten
- Template erweitert um INTERCOM-Abschnitt mit ID
- `subagent-start` wird nicht geändert (bleibt generisch), stattdessen Aufgabe mit ID anreichern

### Nächste Schritte
1. Alle Subagenten-Aufgaben-Templates prüfen ob sie die Orchestrator-ID enthalten
2. Ggf. `subagent-start`-Skript erweitern, dass es automatisch die Orchestrator-ID in die Aufgabe einflicht
3. Bewährungszeit: 3 Subagenten-Durchläufe ohne Fehlschlag

### Betroffene Stellen
- AGENTS.md — Abschnitt "Korrektes Sub-Agent-Muster" (aktualisiert)
- `SubAgenten`-Skript (/home/xray/bin/SubAgenten)
- Jede manuelle Subagenten-Start-Aufgabe

---

## 📋 Prozess bei Wiederauftreten eines Problems

1. Dieses Dokument öffnen
2. Datum des Wiederauftretens eintragen
3. Symptome dokumentieren (Log-Auszüge, Fehlermeldungen)
4. Nächsten Schritt definieren
5. CrowdBrain `persistent-issues.md` synchron aktualisieren