pi-system/memory/persistent-issues.md

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:

"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