Files

T

Hitonabi 903f3bc074 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>

2026-07-19 14:21:18 +02:00

2.8 KiB

Raw Blame History

name, description

name	description
betrieb-playbook	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

Erster Versuch sitzt: Vor dem ersten Befehl 30 Sekunden Lage klaeren (welcher Host, welcher User, welcher Key, welcher Dienst). Zeit = Schleifen × Kontext.
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.
Verify ist Pflicht: Nach jeder Aenderung den Zielzustand BEWEISEN (systemctl is-active, ss -tlnp, curl mit HTTP-Code) und in den Bericht schreiben.
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)

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.).
Richtiger Key erzwungen? ssh -o IdentitiesOnly=yes -i <key> user@host — eine ~/.ssh/config-Wildcard kann den falschen Key aufzwingen.
Host key verification failed = known_hosts-Problem des AUFRUFERS, nicht der Gegenseite (ssh-keyscan host >> ~/.ssh/known_hosts nach Pruefung des Fingerprints).
Gegenseite LESEN statt raten: pve/LXC-Auth-Log via journalctl _COMM=sshd-session; Dienststatus systemctl status <dienst>; Erreichbarkeit ss -tlnp am Ziel.
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)

Quelle = Git-Branch, nie lose Dateien. Clone nach /tmp, nach Erfolg aufraeumen.
Zielzustand vorher erfassen (laeuft ein Alt-Prozess lose? Unit vorhanden/enabled?).
Dateien uebertragen → Alt-Prozess sauber stoppen → Unit daemon-reload + enable --now → Verify (Schritt 3 der Eisernen Regeln).
Secrets (.env) NIE durchs Repo, NIE in Karten — liegen am Ziel oder kommen vom Commander.

2.8 KiB Raw Blame History Unescape Escape