docs: Session 2026-06-02 18:44 — Härtung verifiziert+gepusht, Handover für Luisa-Deploy (Windows-Warnung)

SESSION_HANDOVER.md

@@ -252,3 +252,58 @@ max. 1 Weckung/60s.
    ~/.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.