docs: SESSION_HANDOVER.md hinzugefügt
This commit is contained in:
parent
fb3daab33f
commit
71bb9893c2
1 changed files with 91 additions and 0 deletions
91
SESSION_HANDOVER.md
Normal file
91
SESSION_HANDOVER.md
Normal file
|
|
@ -0,0 +1,91 @@
|
||||||
|
# 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:
|
||||||
|
1. Forgejo-Repos MyPi und AgentPi lesen (via CrowdBrain/Forgejo-API)
|
||||||
|
2. Relevante Inhalte ins PiSystem-Repo übernehmen
|
||||||
|
3. Dann Forgejo-Repo `pi-system` anlegen und pushen
|
||||||
Loading…
Add table
Reference in a new issue