Phase 2 Drei-Welten-Plan: No-Progress-Bremse + Betrieb-Playbook + mem0-Lern-Buendelung

- no-progress-bremse.py: generische, turn-uebergreifende Schleifenbremse (pre/post_tool_call);
  Muster-Hash statt hartkodierter Fehler-Strings, Selbst-Lernen via neue-signaturen.jsonl.
  Schliesst die Luecke der nativen guardrails (pro Turn, nur klassifizierte Fehler).
- ensure-profile-hooks.py: kann Eintraege in BESTEHENDE Event-Bloecke einfuegen
  (zweiter pre_tool_call-Key haette den Tabu-Guard lautlos verschluckt) + registriert Bremse.
- betrieb-playbook-Skill: SSH-/Deploy-Diagnose-Checklisten (Passphrase-Falle zuerst),
  Triage-Regel im Steckbrief-Hook; Skill wird in alle Profile gesynct.
- mc2-memory: Lern-Extraktion gebuendelt (4 Turns oder 180 s idle = EIN Lauf) statt pro Turn -
  Extraktion konkurrierte mit Lucys Hirn um die Slots.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Hitonabi
2026-07-19 14:21:18 +02:00
parent 331aafa25d
commit 903f3bc074
6 changed files with 290 additions and 24 deletions
+44
View File
@@ -0,0 +1,44 @@
---
name: betrieb-playbook
description: Betrieb-Bahn-Playbook fuer SSH-, Deploy- und Dienst-Aufgaben auf Box/pve/LXCs. IMMER laden, bevor du per SSH auf eine Kiste gehst, einen Dienst anfasst oder etwas deployst — es enthaelt die Diagnose-Checklisten, die teure Schleifen verhindern.
---
# Betrieb-Playbook (Bahn: BETRIEB)
## Triage zuerst
Jede Aufgabe gehoert in GENAU eine Bahn: **Denken** (Konzept/Plan → Konzept-Fliessband),
**Bauen** (Code/Feature → Werkstatt-Karte), **Betrieb** (SSH/Deploy/Dienst → DIESES Playbook).
Wenn deine Aufgabe Code SCHREIBT, ist sie Bauen — nicht Betrieb. Mischformen aufteilen.
## Eiserne Regeln
1. **Erster Versuch sitzt:** Vor dem ersten Befehl 30 Sekunden Lage klaeren (welcher Host,
welcher User, welcher Key, welcher Dienst). Zeit = Schleifen × Kontext.
2. **Maximal 3 Anlaeufe pro Hindernis.** Liefert ein Befehl 3x dasselbe Ergebnismuster
(auch als "Erfolg" getarnt wie `Permission denied` in der Ausgabe): STOPP — Diagnose
nach Checkliste, sonst blocked/Karte mit EXAKTEM Fehlertext an den Commander.
Die No-Progress-Bremse erzwingt das mechanisch — arbeite MIT ihr, nicht gegen sie.
3. **Verify ist Pflicht:** Nach jeder Aenderung den Zielzustand BEWEISEN
(systemctl is-active, ss -tlnp, curl mit HTTP-Code) und in den Bericht schreiben.
4. **Backup vor Aenderung:** Config/Datei erst `.bak`-kopieren, dann anfassen.
Rollback-Weg im Kopf haben, BEVOR du aenderst.
## SSH-Diagnose-Checkliste (die teuer gelernte Reihenfolge)
1. **Passphrase-Falle ZUERST:** `ssh-keygen -y -f <key> </dev/null` — scheitert das,
ist der Key passphrase-verschluesselt und non-interaktiv nutzlos
(stilles `Permission denied` TROTZ korrektem Pubkey; Wurzel des 36-min-Marathons 18.07.).
2. Richtiger Key erzwungen? `ssh -o IdentitiesOnly=yes -i <key> user@host`
eine ~/.ssh/config-Wildcard kann den falschen Key aufzwingen.
3. `Host key verification failed` = known_hosts-Problem des AUFRUFERS, nicht der Gegenseite
(`ssh-keyscan host >> ~/.ssh/known_hosts` nach Pruefung des Fingerprints).
4. Gegenseite LESEN statt raten: pve/LXC-Auth-Log via `journalctl _COMM=sshd-session`;
Dienststatus `systemctl status <dienst>`; Erreichbarkeit `ss -tlnp` am Ziel.
5. LXCs ohne SSH-Weg: `ssh pve` + `pct exec <id> -- <cmd>` / `pct push` (Dateien erst
per scp auf pve zwischenlagern). authorized_keys auf pve IMMER in /root/.ssh UND
/etc/pve/priv pflegen.
## Deploy-Checkliste (Box/LXC)
1. Quelle = Git-Branch, nie lose Dateien. Clone nach /tmp, nach Erfolg aufraeumen.
2. Zielzustand vorher erfassen (laeuft ein Alt-Prozess lose? Unit vorhanden/enabled?).
3. Dateien uebertragen → Alt-Prozess sauber stoppen → Unit `daemon-reload` +
`enable --now` → Verify (Schritt 3 der Eisernen Regeln).
4. Secrets (.env) NIE durchs Repo, NIE in Karten — liegen am Ziel oder kommen vom Commander.