Commit graph

7 commits

Author SHA1 Message Date
6371fb9f60 fix/extensions: rule-enforcer — setInterval gegen uncaught exceptions härten
Pis Loader (loader.js:298-311) kapselt nur die synchrone Factory-Ausführung.
Das 30s-setInterval feuert später und läge außerhalb dieses Schutzes — eine
Exception dort wäre uncaught und könnte den Pi-Prozess beenden. Daher: gesamter
Intervall-Rumpf in try/catch.

Empirisch verifiziert (Pi-SDK createAgentSession, agentDir=~/.pi/agent):
- rule-enforcer.ts lädt mit 0 Fehlern (10/10 Extensions geladen)
- absichtlich kaputte Test-Extension crasht Pi NICHT — Fehler isoliert, gesunde
  Extensions laden weiter, Session startet normal
2026-06-02 18:40:44 +02:00
aa1539c744 fix/extensions: rule-enforcer erzwingt Invariante — Orchestrator nie idle während Subagent läuft
Root Cause (log-belegt, 36,6-min-Lücke 15:25–16:01): watch_subagents ist
ein Polling-Tool; die Überwachung lebt nur solange das LLM es neu aufruft.
Eine User-Zwischenfrage riss die Schleife ab, der Orchestrator ging idle.
Der passive Alert-File-Pfad (nur in before_agent_start gelesen) feuert bei
idle nie → Orchestrator schlief 36 min bis der Mensch tippte.

Fix: 30s-Check erkennt laufende Subagenten per Prozessbaum (lebt ein pi-Kind
unter dem tmux-Pane?), nicht per Keyword. Idle + laufender Subagent → aktive
Weckung via pi.sendUserMessage() (löst garantiert einen Turn aus) + ui.notify.
Idle-Erkennung zeitbasiert (45s, > 30s Pollintervall), ctx-unabhängig.

Verifiziert: Syntax, Modul-Load, Handler-Registrierung, Prompt-Injection,
W06, Prozessbaum-Erkennung an echten Sessions. NICHT verifiziert: Live-Weckpfad
(erfordert Orchestrator-Test). Plan: doku/fix-plan-orchestrator-wecker-v2026-06-02-18-19.md
2026-06-02 18:33:02 +02:00
fed300c170 feat/extensions: rule-enforcer.ts — before_agent_start + message_end + 30s-Check
- before_agent_start: injiziert W06/W07/W09/W10 + WATCH-Regel in jeden System-Prompt-Turn,
  Selbstkorrektur wenn letzter Turn W06 verletzt, Subagenten-Alerts prominent eingeblendet
- message_end: scannt Pi-Output auf Deliberations-Muster, setzt Korrektur-Flag
- setInterval 30s: prüft tmux-Sessions auf offene Bestätigungs-Dialoge unabhängig
  von Pi's Tool-Calls, schreibt in Alert-File für nächsten Turn
2026-06-02 16:02:03 +02:00
1f2c3ecae8 fix/extensions: setWidget erwartet Factory-Funktion, nicht Widget-Objekt
Pi's setWidget-API ruft den zweiten Parameter als content(ui, theme) auf.
session-header.ts und session-index.ts übergaben direkt das Widget-Objekt
— jetzt als (_ui, theme) => makeWidget(...) gewrappt.
2026-06-02 15:47:39 +02:00
5057f500a0 feat/guard: watch_subagents Custom-Tool — proaktiver 30s-Watcher ohne externen Prozess
pi.registerTool('watch_subagents'): wartet 30s (respektiert AbortSignal),
gibt dann tmux-Status aller Sessions zurück. AGENTS.md: Orchestrator MUSS
das Tool nach jedem Return sofort neu aufrufen — permanente Polling-Schleife.
Kein SubConfirm, kein tmux send-keys, kein externer Prozess nötig.
2026-06-02 12:17:13 +02:00
3e4e1a4bff fix/guard: tail-1 → tail-5 — Orchestrator sieht jetzt Bestätigungs-Dialoge in Subagenten
Root Cause: tmuxSubagentenStatus() holte nur die letzte Zeile (tail -1),
das war immer der Pi-Status-Bar, nie der Dialog-Inhalt. Jetzt tail -5
mit expliziter Dialog-Erkennung (Erlauben?, → Yes, ACHTUNG:).
2026-06-02 12:03:41 +02:00
fb3daab33f feat/init: PiSystem Infrastruktur-Repo mit SubConfirm
Enthält alle Pi-Orchestrator-Infrastrukturkomponenten:
- bin/Sub* Skripte (SubAgenten, SubStatus, SubWatcher, SubConfirm)
- extensions/ (arbeitsweise-guard, confirm-deletion, etc.)
- memory/ (arbeitsweise, subagent-autocheck)
- agent/AGENTS.md mit SubConfirm-Reaktionslogik
- install.sh: deterministisches, idempotentes Setup für neue Maschinen

SubConfirm (neu): Stasis-Detektor der alle 30s tmux-Sessions prüft.
Bei unverändertem Output sendet er den vollständigen Pane-Inhalt
an die Alert-Datei — der Orchestrator beurteilt selbst ob Handlung nötig.
Kein Keyword-Matching.
2026-06-02 11:53:37 +02:00