pi-system/SESSION_HANDOVER.md

# 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 | **Socket Firewall installieren** — `npx socket` als Pre-Install-Hook für pnpm/npm, via Subagent (`socket-firewall-install/` Ordner liegt bereits im Repo, noch uncommitted) | 1 | ⬜ |
| 2 | Verbleibende 5 PNPM-Sicherheitstipps aus Video umsetzen (Block Git-Dependencies, etc.) | 2 | ⬜ |
| 3 | **pi-web Session-Store auf SQLite umstellen** — `connect-sqlite3`, DB `/root/.pi-web/sessions.db` (keine Eile, Workaround: sign-out → sign-in) | 3 | ⬜ |
| 4 | Forgejo-Repos **MyPi** und **AgentPi** prüfen — nützliche Inhalte ins PiSystem-Repo übernehmen | 4 | ⬜ |
| 5 | SubConfirm in SubAgenten einbauen: beim ersten SubAgent-Start automatisch starten wenn noch nicht läuft | 5 | ⬜ |

---

## 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

---

## Session: 2026-06-02 15:27

### Erreichtes

- **pi.ccpn.cc Modell auf `minimax-m3:cloud` umgestellt** (war `kimi-k2.6` — down): settings.json + index.html gesetzt, pi-web neugestartet. Modell steht bereit, wird aber aktuell nicht aktiv genutzt.

- **Session-Loss-Bug verstanden:** `express-session` in pi-web nutzt In-Memory-Store → nach jedem `docker restart pi-web` sind alle Sessions weg → WebSocket bekommt 401 → Enter/Senden funktioniert nicht. Workaround: `https://pi.ccpn.cc/logto/sign-out` → neu einloggen.

- **AGENTS.md erweitert (autorisierte Änderungen durch Orchestrator heute):**
  - Session-Start-Checkliste Punkte 5–8: CrowdBrain-Skill immer laden, watch_subagents, SubConfirm
  - Kommunikationsstil: max. 3–4 Zeilen, keine Tabellen/Zusammenfassungen
  - Selbst-Lesen verboten: Orchestrator liest keine Logs/Quellcode selbst
  - Orchestrator-Scope: nur tun was explizit beauftragt wurde
  - **Installationen immer delegieren (W10):** npm/npx/pip/apt nie direkt ausführen — immer Subagent

- **confirm-deletion.ts gefixt:** `SubAgenten`-Aufrufe wurden als Package-Installation erkannt, weil die Aufgabenbeschreibung `npx socket` enthielt → `SubAgenten` zu `SAFE_PACKAGE_COMMANDS` hinzugefügt

- **PNPM-Sicherheitssetup:** pnpm 11.5.1 installiert, 7-Tage Release-Age-Gating aktiv (`registry.age=7`)

### Offene Fragen

- Ob `minimax-m3:cloud` auf pi.ccpn.cc stabil läuft muss noch bestätigt werden (Frontend nach Login testen)
- 5 weitere PNPM-Sicherheitstipps aus Video noch nicht umgesetzt (Block Git-Dependencies, Socket Firewall, Pre-Install-Audit, etc.)
- Socket Firewall Installation abgebrochen — noch ausständig

### Wichtige Pfade (Server: agentserver 116.203.222.129:2222, User: xray)

- Pi-Web Quellcode: `/home/xray/pi-web/` (server.js, public/index.html)
- Pi-Web Container: `pi-web` (docker)
- Pi-Agent Container: `pi-agent` (docker, teilt Volume `/home/xray/.pi`)
- Settings (shared Volume): `/home/xray/.pi/agent/settings.json`
- SSH: `ssh -o ControlPath=~/.ssh/sockets/xray@116.203.222.129-2222 agentserver "<cmd>"`

### Kontext für nächste Session

1. **Zuerst:** pi-web Session-Store auf SQLite umstellen (Priorität 1 — wiederkehrender Schmerz)
2. Dann Socket Firewall via Subagent installieren
3. Nach jedem pi-web-Neustart bis zum Fix: `https://pi.ccpn.cc/logto/sign-out` → neu einloggen

---

## Session: 2026-06-02 15:33 — Session-Abbruch wegen Kontext-Durcheinander

### Was passiert ist

Claude hat in dieser Session angefangen, pnpm-bezogene Arbeiten (Socket Firewall) fortzuführen, obwohl der Benutzer das Gespräch neu begonnen hatte. Der Benutzer hat das Durcheinander bemerkt und die Session sauber beendet.

**Keine Code-Änderungen wurden in dieser Session gemacht.**

### Uncommitted Ordner im Repo (git status)

```
?? socket-firewall-install/    # Arbeitsergebnis aus Session 15:27 — noch nicht committed
?? terminal-flackern-analyse/  # Analyse-Ordner — noch nicht committed
```

Diese Ordner müssen in der nächsten Session entweder committed oder entschieden werden.

### Kontext für nächste Session

**Diese Datei zuerst lesen**, dann:

1. **`socket-firewall-install/` prüfen** — was ist drin? Wenn fertig → committen. Wenn unvollständig → Socket Firewall via Subagent fertigstellen (Priorität 1 aus Nächste-Schritte-Tabelle oben).
2. **`terminal-flackern-analyse/` prüfen** — relevanter Inhalt? Wenn ja committen, sonst löschen.
3. Weiter nach der Prioritätsliste oben (pi-web Session-Store, PNPM-Sicherheitstipps, etc.)

**Wichtige Erinnerung:** Nächste Session MIT DEM RICHTIGEN PROJEKT starten — immer zuerst diese Datei lesen: `/media/xray/NEU/Code/PiSystem20260602/SESSION_HANDOVER.md`

---

## Session: 2026-06-02 15:56 — Regel-Enforcement und Extension-Fixes

### Erreichtes

- **Repo bereinigt:** `socket-firewall-install/`, `terminal-flackern-analyse/`, `pi-web-session-debug/` aus dem Repo-Verzeichnis nach `/media/xray/NEU/Code/20260602/` verschoben — diese Ordner gehören nicht ins Pi-System-Repo

- **Extension-Bug gefixt** (`session-header.ts` + `session-index.ts`): Pi's `setWidget`-API erwartet als zweiten Parameter eine Factory-Funktion `(_ui, theme) => widget`, nicht direkt das Widget-Objekt. Beide Extensions übergaben direkt `makeWidget(...)` → "content is not a function". Fix: alle `setWidget`-Aufrufe auf `(_ui, theme) => makeWidget(...)` umgestellt. Deployed + committed.

- **AGENTS.md: 5 neue Regeln dokumentiert** (W06–W10):
  - **W06** Kein internes Deliberieren ("Let me check...", "Actually...", "Weil ich...") in User-Output
  - **W07** Subagenten-Strategie nie eigenständig aufgeben — Benutzer informieren, auf Anweisung warten
  - **W08** Erlaubte Edit-Pfade: nur `~/.pi/agent/` und CWD direkt editierbar, `~/.bashrc` etc. immer via Subagent
  - **W09** `sleep` in jeder Form verboten — `watch_subagents` nutzen
  - **W10** Subagent nie doppelt starten — einmal starten, dann warten

- **Neue Extension `rule-enforcer.ts`** deployed nach `~/.pi/agent/extensions/`:
  - `before_agent_start`: injiziert W06–W10 + WATCH-Regel in **jeden** System-Prompt-Turn (nicht nur beim Session-Start)
  - `message_end`: scannt Pi's Ausgabe auf Deliberations-Muster, setzt Korrektur-Flag für nächsten Turn
  - `setInterval` 30s: Background-Check auf tmux-Bestätigungs-Dialoge, unabhängig von Pi's Tool-Calls → schreibt in `/tmp/.pi-subagent-alert`
  - `before_agent_start` liest Alert-File und zeigt 🚨-Hinweis prominent im System-Prompt

### Entscheidungen

| # | Entscheidung | Begründung | Datum |
|---|---|---|---|
| 6 | rule-enforcer.ts als eigene Extension statt arbeitsweise-guard.ts-Erweiterung | Trennung der Verantwortlichkeiten: arbeitsweise-guard blockiert Tools, rule-enforcer enforced Output-Verhalten | 2026-06-02 |
| 7 | setInterval 30s in Extension statt nur SubConfirm | SubConfirm kann nicht laufen — Extension läuft immer im Pi-Prozess | 2026-06-02 |
| 8 | before_agent_start systemPrompt-Injection statt nur AGENTS.md | AGENTS.md wird einmal beim Start geladen, before_agent_start feuert bei jedem Turn — Regeln bleiben im Context-Window frisch | 2026-06-02 |

### Noch nicht getestet

- `rule-enforcer.ts` wurde noch **nicht live getestet** — Pi muss neu gestartet werden damit die Extension geladen wird
- Ob der W06-Scan die richtigen Phrases erkennt ohne False Positives muss im Betrieb validiert werden
- Ob `before_agent_start` systemPrompt wirklich appended (nicht replaced) muss beim ersten Start beobachtet werden

### Kontext für nächste Session

**Sofort nach Session-Start:**
1. Pi neu starten (damit `rule-enforcer.ts` geladen wird): `OrchestratorPi` aufrufen
2. Beobachten ob W06-Violations weniger werden — wenn rule-enforcer falsch-positive erzeugt: Muster in `DELIBERATIONS_MUSTER` Array anpassen ([extensions/rule-enforcer.ts](extensions/rule-enforcer.ts) Zeile ~50)

**Danach:**
3. pi-web Session-Store auf SQLite umstellen (wiederkehrender Schmerz — nach jedem `docker restart pi-web` müssen User sich neu einloggen)
4. Forgejo-Repos MyPi und AgentPi prüfen — nützliche Inhalte ins PiSystem-Repo übernehmen

---

## Session: 2026-06-02 18:33 — Orchestrator-Idle-Bug (Root Cause + Fix)

### Vorfall (log-belegt)

Orchestrator reagierte ~36 min nicht, während Subagent `lexware-arbeitsamt` lief und
zuletzt auf einen „Erlauben?"-Dialog wartete. Beweis im Orchestrator-Log
(`…locosoft-recherche…jsonl`): Lücke **15:25:00 (assistant „SubAgent läuft") → 16:01:33
(user)** — 36,6 min ohne jede Aktivität. Erst die User-Eingabe weckte ihn.

### Root Cause (bewiesen, nicht vermutet)

`watch_subagents` ist ein Polling-Tool (kehrt nach ~30s zurück). Die Überwachung lebt nur,
solange das LLM es immer wieder neu aufruft. Eine User-Zwischenfrage um 15:24:27 riss die
Schleife ab; der Orchestrator kündigte den Subagenten an und ging idle. Der passive
Alert-File-Pfad (`/tmp/.pi-subagent-alert`) wird **nur in `before_agent_start` gelesen**,
das bei idle nie feuert → Alert blieb ungelesen.

### Benutzer-Einwand (zentral)

„Warum sollte der Orchestrator idle sein, wenn noch Subagenten laufen?" → Die korrekte
Invariante: **Solange ein Subagent läuft, darf der Orchestrator NICHT idle sein.** Der
offene Dialog war nur ein Spezialfall (= noch lebender pi-Prozess).

### Fix (committed `aa1539c`, deployed)

`extensions/rule-enforcer.ts` neu: 30s-Check erkennt laufende Subagenten per **Prozessbaum**
(lebt ein `pi`-Kind unter dem tmux-Pane? — `pane_current_command` ist unbrauchbar, meldet
`bash`). Idle (zeitbasiert, 45s) + laufender Subagent → aktive Weckung via
`pi.sendUserMessage()` (löst garantiert einen Turn aus) + `ui.notify`. Selbstterminierend,
max. 1 Weckung/60s.

- **Deployed:** `~/.pi/agent/extensions/rule-enforcer.ts`, Backup `*.bak-20260602-183309`
- **Greift erst nach Pi-Neustart / `/reload`** — laufender Orchestrator hat noch die alte Version!
- **Verifiziert:** Syntax, Modul-Load, 9 Handler, Prompt-Injection, W06, Prozessbaum an echten Sessions
- **NICHT verifiziert:** Live-Weckpfad — Test nötig (siehe `doku/fix-plan-orchestrator-wecker-v2026-06-02-18-19.md` §8)

### Offen / nächste Session

1. **Live-Test des Weckers:** Pi neu starten → Subagent mit Bestätigungs-Dialog starten →
   Orchestrator idle lassen → kommt binnen ~30–75s eine Auto-Weckung? (Erwartet: ja)
2. Rollback bei Fehlverhalten: `cp ~/.pi/agent/extensions/rule-enforcer.ts.bak-20260602-183309
   ~/.pi/agent/extensions/rule-enforcer.ts` + `git checkout aa1539c~1 -- extensions/rule-enforcer.ts`
3. **Trade-off beobachten:** Hält der Orchestrator die Schleife trotz Weckung nicht, wird er
   ~1×/60s erneut geweckt (Kontext-Bloat). Im Normalfall nur 1 Weckung.

---

## Session: 2026-06-02 18:44 — Fix gehärtet + gepusht, Handover für Luisa-Deploy

### Erreichtes

- **Sicherheits-Härtung** `extensions/rule-enforcer.ts`: gesamter `setInterval`-Rumpf in
  try/catch. Grund: Pis Loader (`loader.js:298-311`) kapselt nur die *synchrone*
  Factory-Ausführung; das später feuernde Intervall läge außerhalb → uncaught exception hätte
  Pi crashen können. Commit `6371fb9`.
- **Empirisch verifiziert (Pis echter SDK-Loader, `createAgentSession`, agentDir=~/.pi/agent):**
  - `rule-enforcer.ts` lädt mit **0 Fehlern** (10/10 Extensions geladen, kein Crash)
  - **Absichtlich kaputte Test-Extension crasht Pi NICHT** — Fehler wird isoliert, gesunde
    Extensions laden weiter, Session startet normal. → Multi-Rechner-Rollout ist abgesichert:
    eine kaputte Extension brickt Pi nicht.
- **Gepusht:** alle Commits auf Forgejo-Remote `origin` (Repo `xray/pi-system`), `origin/main`
  == lokal (0/0). Letzte Commits: `aa1539c` (Fix) · `115cc61` (Doku) · `6371fb9` (Härtung).
- **Lokal deployed** (nur dieser Rechner): `~/.pi/agent/extensions/rule-enforcer.ts`, Backups
  `*.bak-20260602-183309` und `*.bak-20260602-184044`.

### Offen — Live-Test (unverändert)

Der **Live-Weckpfad** (`pi.sendUserMessage` weckt echt-idle Orchestrator) ist NICHT live
getestet, nur per Typdefinition belegt. Test braucht echten Orchestrator + Subagent mit
Bestätigungs-Dialog. Schritte: `doku/fix-plan-orchestrator-wecker-v2026-06-02-18-19.md` §8.
Selbst im schlechtesten Fall (Wecker greift nicht) ist der Stand nicht schlechter als vorher.

### 🔜 NÄCHSTE AUFGABE: Deploy auf Luisa-Laptop — ACHTUNG WINDOWS

Benutzer will die aktuelle Version (Commit `6371fb9`) auf den **Luisa-Laptop** deployen.
**Vor jedem Deploy-Schritt Machbarkeit klären — das ist KEIN einfacher Datei-Copy:**

Luisa-Fakten (Quelle CrowdBrain `ssh.md` + `neue-maschine.md`, Stand 2026-05-23):
- **Windows 11**, SSH-Alias `luisa`, LAN-IP `192.168.2.229`, Port `22`, User `xray`,
  Key `~/.ssh/id_ed25519`. Default-Shell ist **`cmd` — KEIN bash**. Befehle via
  `ssh luisa "powershell -Command \"...\""`.
- **Kein NetBird** → nur aus dem Heimnetz (192.168.2.0/24) erreichbar.
- **Pi/PiSystem dort NICHT als installiert dokumentiert** (nur `q4-office` 0.75.1 und `xps`
  haben Pi laut server-inventory). Verifizieren, nicht annehmen (P39).

**Showstopper / Klärungsbedarf VOR Implementierung:**
1. `install.sh` ist ein **Bash-Skript → läuft auf Windows nicht**. Deploy-Weg muss neu gedacht
   werden (PowerShell-Variante? Git Bash auf Luisa? WSL?).
2. Pi-Agent-Verzeichnis auf Windows ist **nicht** `~/.pi/agent` — Pfad erst ermitteln
   (vermutlich `%USERPROFILE%\.pi\agent`), erst prüfen ob Pi überhaupt installiert ist.
3. Falls Pi dort fehlt: Das wäre eine **Windows-Erstinstallation** (im Wiki nicht beschrieben)
   — eigene Aufgabe, nicht Teil eines „Deploys".

**Empfohlene erste Schritte nächste Session (in dieser Reihenfolge, je via Subagent):**
1. Erreichbarkeit + Pi-Status prüfen:
   `ssh luisa "powershell -Command \"Test-Path $HOME\.pi\agent; pi --version\""`
2. Ergebnis dem Benutzer vorlegen, Deploy-Weg abstimmen (Git-Clone auf Luisa? Manueller
   Datei-Transfer? PowerShell-Install-Skript schreiben?). NICHT raten.
3. Erst nach Klärung deployen — mit Backup der dortigen Datei, dann verifizieren.