PiSystem — Session Handover

Diese Datei dient als Kontext-Übergabe zwischen Sessions. Neue Session: Lies diese Datei zuerst.

Projekt: Pi-Orchestrator-Infrastruktur — deterministisch, maschinenübergreifend

Verzeichnis: /media/xray/NEU/Code/PiSystem20260602/

Ziel: Alle Pi-Orchestrator-Infrastrukturkomponenten in einem Git-Repo zentralisieren, sodass auf jedem Rechner via git clone + ./install.sh exakt derselbe Stand entsteht. Kein Drift mehr zwischen Maschinen, keine unterschiedlichen Fehlersymptome.

Kontext: Warum dieses Repo

Bisher war die Infrastruktur verteilt auf:

~/bin/Sub* — SubAgenten, SubStatus, SubWatcher
~/.pi/agent/extensions/ — confirm-deletion, arbeitsweise-guard, etc.
~/.pi/agent/memory/ — arbeitsweise, subagent-autocheck
~/.pi/agent/AGENTS.md — Orchestrator-Instruktionen

Jeder Rechner hatte einen anderen Stand. Das PiSystem-Repo ist die Single Source of Truth.

Architektur des Stasis-Detektors (SubConfirm)

Problem: Der Orchestrator bemerkte nicht, wenn ein Subagent auf Bestätigung wartete. Ursache: SubWatcher nutzte Keyword-Matching — confirm-deletion.ts-Dialoge wurden nicht erkannt. Lösung: SubConfirm — prüft alle 30s ob Session-Output stasis ist (unverändert), schreibt dann den vollständigen Pane-Inhalt in /tmp/.pi-subagent-alert. Die Extension arbeitsweise-guard.ts zeigt das dem Orchestrator beim nächsten Tool-Call. Kein Keyword-Matching — der Orchestrator beurteilt selbst.

Datenfluss:

SubConfirm (Bash-Daemon) → /tmp/.pi-subagent-alert → arbeitsweise-guard.ts → Orchestrator

✅ Entscheidungen

#	Entscheidung	Begründung	Datum
1	Stasis-Erkennung statt Keyword-Matching	Genereller, funktioniert für alle Dialog-Typen — nicht nur bekannte	2026-06-02
2	Alert-File-Mechanismus (`/tmp/.pi-subagent-alert`)	bestehende Infrastruktur in arbeitsweise-guard.ts, keine neue Komponente nötig	2026-06-02
3	`intercom` ist kein Shell-Binary	intercom ist ein Pi-internes Tool (Extension), kein bash-Kommando — SubConfirm nutzt daher Alert-File	2026-06-02
4	SubConfirm via `--skip` die Orchestrator-Session ausschließen	Orchestrator-Session soll nicht als Stasis erkannt werden	2026-06-02
5	install.sh idempotent mit Backups	Mehrfaches Ausführen sicher, bestehende Dateien werden mit Timestamp gesichert	2026-06-02

🔜 Nächste Schritte

#	Aktion	Priorität	Status
1	Repo auf Forgejo pushen (neues Repo `pi-system` anlegen)	1 (sofort)	⬜
2	Forgejo-Repos MyPi und AgentPi prüfen — nützliche Inhalte übernehmen	1 (sofort)	⬜
3	SubConfirm auf aktuellem Rechner deployen: `cp bin/SubConfirm ~/bin/ && chmod +x ~/bin/SubConfirm`	2	⬜
4	AGENTS.md auf aktuellem Rechner deployen: `./install.sh` (nur AGENTS.md + memory)	2	⬜
5	SubConfirm in SubAgenten einbauen: beim ersten SubAgent-Start automatisch starten wenn noch nicht läuft	3	⬜
6	Auf zweitem/drittem Rechner: `git clone <forgejo-url> && ./install.sh` testen	3	⬜

Session: 2026-06-02 11:55

Erreichtes

Root Cause analysiert: SubWatcher hat confirm-deletion.ts-Dialoge nicht erkannt weil Keyword-Patterns fehlten — aber Keyword-Matching ist generell der falsche Ansatz
SubConfirm geschrieben (bin/SubConfirm): Stasis-Detektor, 30s-Intervall, schreibt Pane-Inhalt in Alert-File, kein Keyword-Matching
AGENTS.md erweitert: Neuer Abschnitt "SubConfirm — Reaktionslogik" mit konkreten tmux send-keys-Befehlen für Yes/No
subagent-autocheck.md aktualisiert: Verweist jetzt auf SubConfirm statt manuelle Befehle
install.sh erstellt: Deterministisch, idempotent, mit Dry-Run-Modus, prüft Voraussetzungen
Git-Repo initialisiert: Erster Commit fb3daab

Offene Fragen

Forgejo-Repos MyPi und AgentPi enthalten möglicherweise weitere nützliche Infrastruktur die übernommen werden sollte — wurde noch nicht geprüft
SubConfirm wurde noch nicht auf dem aktuellen Rechner deployed (nur ins Repo geschrieben)
Autostart von SubConfirm in SubAgenten noch nicht eingebaut

Kontext für nächste Session

Die nächste Session soll:

Forgejo-Repos MyPi und AgentPi lesen (via CrowdBrain/Forgejo-API)
Relevante Inhalte ins PiSystem-Repo übernehmen
Dann Forgejo-Repo pi-system anlegen und pushen

4.4 KiB Raw Blame History