Hitonabi
903f3bc074
- 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>
45 lines
2.8 KiB
Markdown
45 lines
2.8 KiB
Markdown
---
|
||
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.
|