Hitonabi
1570b2fc71
User-Auftrag 12.07. ("bau das alles ein im Sinne der Autonomie. Auch muss
Lucy selbst bemerken wenn sich etwas aendert"):
- deploy/selbst-inventur.sh (Cron 03:35): SELBST-STECKBRIEF wird LIVE aus
der Realitaet GENERIERT (Versionen, Dienste, Timer, Modelle, Crons,
Queue, Karten -> ~/.hermes/state/selbst-steckbrief.md) statt von Hand
gepflegt. Diff gegen gestern => die Box BEMERKT SELBST Aenderungen an
sich (stille Chronik-Karte + kurze Telegram-Zeile; sonst still).
- deploy/karten-gutachter.sh (Cron 04:00): stempelt jede neue Karte mit
"Empfehlung: ANNEHMEN/ABLEHNEN/UNKLAR + ein ehrlicher Satz" (prueft
Redundanz gegen den Steckbrief, Risiko, Nutzen; Ein-Schuss-Richter
gpt-oss/GLM; Stempel = Meinung, kein Gate; neuer Commit entwertet den
alten Stempel). Backend mischt den Stempel in /api/auftragsbuch,
UI zeigt ihn farbig auf der Karte.
- Ablehnen mit Grund (Lern-Klick): UI-Inline-Feld beim Ablehnen ->
/srv/models/mc2-ablehnungen.jsonl -> Idle-Radar bekommt die Gruende
als "NIE wieder vorschlagen"-Material vorgelegt.
- idle-radar-feed.sh: Material + Raster erweitert um Selbst-Steckbrief,
Inventur-Diff und Ablehn-Gruende (Fehlerfall 12.07.: redundanter
Gateway-Restart-Vorschlag waere damit gestorben).
- werkstatt-SOUL Regel 7 + wartung-Skill: REALITAETS-CHECK - existiert es
schon? Dann kanban_block statt Branch (ein Branch fuer Ueberfluessiges
ist ein gescheiterter Lauf).
- hermes-release-radar-feed.sh: echter Treffer legt zusaetzlich EINE rohe
Idee in die Queue (idempotent je Release-Tag) - der Blick nach draussen
fuettert denselben Kreislauf.
- deploy.sh: kopiert beide neuen Skripte; Doku AUFTRAGSBUCH.md +
wissen/OFFENE-FAEDEN.md; frontend/dist frisch gebaut (tsc+vite gruen,
UI gegen Live-Box verifiziert).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
120 lines
7.8 KiB
Markdown
120 lines
7.8 KiB
Markdown
---
|
||
name: wartung
|
||
description: "Werkstatt-Kreislauf der AI-Box: einen KLEINEN Wartungsauftrag (Config-Migration, Dependency-Bump, Ein-/Zwei-Datei-Patch) eigenständig umsetzen — Branch im Box-Checkout, Patch, separater Reviewer-Subagent, Gate, Telegram-Merge-Vorschlag. Merge/Deploy NIE selbst."
|
||
version: 1.0.0
|
||
author: MC2 (Autonomie E6)
|
||
platforms: [linux]
|
||
metadata:
|
||
hermes:
|
||
tags: [wartung, werkstatt, maintenance, mc2]
|
||
---
|
||
|
||
# Werkstatt — Selbstwartungs-Kreislauf der Box
|
||
|
||
Nutze diesen Skill, wenn ein kleiner, klar umrissener Wartungsauftrag für das MC2-Repo
|
||
(`~/mission-control-v2`) vorliegt — vom Evolution-Radar oder direkt vom User.
|
||
|
||
**Scope-Check zuerst:** Klein = Config-Schlüssel-Migration, Dependency-Bump (Lockfile),
|
||
Patch in 1–2 Dateien. Alles Größere (Architektur, mehrere Module, neue Features):
|
||
NICHT pauschal ablehnen, sondern den **Etappen-Weg** gehen (Großbau-Entscheid 10.07.2026):
|
||
einen Etappen-Plan in den Vorschlag schreiben (jede Etappe für sich lauffähig + annehmbar)
|
||
und NUR Etappe 1 als eigenen Vorschlags-Branch bauen; Folge-Etappen als neue Aufgaben in
|
||
die Ideen-Queue (`hermes kanban create "<Projekt> — Etappe <n>: <was>" --triage`). NIE auf
|
||
unangenommene Branches aufbauen — erst wenn die Vor-Etappe in main ist, kommt die nächste.
|
||
|
||
## Leitplanken (nicht verhandelbar)
|
||
|
||
- NIEMALS auf `main` committen. NIEMALS mergen. NIEMALS deployen oder Dienste neu starten.
|
||
- Security-Config ist TABU: keine Tokens, approvals, ufw, sudoers anfassen.
|
||
- **Realitäts-Check zuerst (12.07.2026):** Existiert das schon? Selbst-Steckbrief
|
||
(`~/.hermes/state/selbst-steckbrief.md`) und Live-System LESEN, bevor du baust. Stellt
|
||
sich der Auftrag als schon erledigt/überflüssig heraus → ehrlich melden und abbrechen,
|
||
KEINEN Branch liefern.
|
||
- **Hermes-first (10.07.2026):** Bevor du NEUE Infrastruktur baust oder vorschlägst (Skript,
|
||
Dienst, Tool, Cron), prüfe ob hermes-agent das nativ kann — erst in die Eigenbau-Landkarte
|
||
schauen (`~/wissens-vault/eigenbau-landkarte.md`: Eigenbauten ↔ nativ, Verdikte), notfalls
|
||
`bash -lc 'hermes --help'`. Den Prüf-Befund in den Vorschlag schreiben („nativ vorhanden:
|
||
nein/ja, weil …"). Weniger Eigenkreationen = weniger Wartungsberg.
|
||
- Die Live-Instanz (`~/mission-control-v2`) bleibt unberührt — gearbeitet wird NUR im Worktree.
|
||
- Am Ende steht IMMER ein Telegram-Vorschlag; die Entscheidung trifft der User.
|
||
- Gate rot oder Reviewer dagegen → trotzdem ehrlich melden (Branch bleibt liegen), nichts beschönigen.
|
||
|
||
## Ablauf
|
||
|
||
1. **Worktree anlegen** (Slug = kurzer Kebab-Case-Name des Auftrags):
|
||
`cd ~/mission-control-v2 && git fetch origin && git worktree add /tmp/wartung-<slug> -b wartung/<slug> origin/main`
|
||
2. **Patch** nur im Worktree. Minimal-invasiv, Stil der umgebenden Datei übernehmen
|
||
(deutsche Kommentare, bestehende Muster).
|
||
3. **Selbst-Gate** (was zutrifft):
|
||
- Python geändert → `python3 -m py_compile <dateien>`
|
||
- Shell geändert → `bash -n <dateien>`
|
||
- Frontend (`frontend/src/...`) geändert → auf der Box gibt es KEIN Node. Im Vorschlag
|
||
ausweisen: „Gate eingeschränkt: tsc/Build läuft erst beim Merge auf dem PC."
|
||
- **Live-Checkout unberührt (PFLICHT, zwei Beweise):**
|
||
- `git -C ~/mission-control-v2 status --porcelain -uno` **muss LEER sein** — kein einziges
|
||
geändertes/staged Tracked-File im Live-Checkout. (Nur so ist bewiesen, dass du wirklich
|
||
ausschließlich im Worktree gearbeitet hast; ein grüner Health-curl allein reicht NICHT,
|
||
weil der laufende Dienst den alten Code im Speicher hält und eine schmutzige Datei auf
|
||
der Platte nicht bemerkt — genau diese Lücke ist am 03.07. aufgefallen.)
|
||
- `curl -sf http://127.0.0.1:9001/api/health` muss grün bleiben.
|
||
- Ist der `git status` NICHT leer: du hast die Leitplanke verletzt → die fremden Änderungen
|
||
im Live-Checkout mit `git -C ~/mission-control-v2 checkout -- <datei>` zurücknehmen (deine
|
||
Arbeit liegt ja sicher im Worktree/Branch) und im Vorschlag ehrlich erwähnen.
|
||
4. **Fremd-Modell-Review über `fremdblick.sh`** (Härtung 04.07., korrigiert 04.07.). Der Patch
|
||
muss von einem ANDEREN Modell gegengelesen werden als dem, das ihn geschrieben hat. Grund:
|
||
„Ein Agent, der seine eigenen Hausaufgaben benotet, stimmt sich meistens selbst zu" — genau
|
||
das ist am 03.07. passiert. Zwei verschiedene Modelle teilen NICHT dieselben blinden Flecken.
|
||
|
||
**NICHT `delegate_task` benutzen.** `delegate_task` läuft über `delegation.model` (= `heavy`
|
||
/ gpt-oss), und heavy ist als Kritiker DOPPELT disqualifiziert: (a) Hermes screent Delegations-
|
||
Ziele gegen `MINIMUM_CONTEXT_LENGTH=64000`, heavy hat nur 32k → fällt raus; (b) heavy (60 GB)
|
||
stirbt beim Laden neben dem VL-30B-Warm-Set (Health-Check-Timeout). Die Fremd-Prüfung würde
|
||
dann still ausfallen. Stattdessen den bereitgestellten Ein-Schuss-Kritiker nutzen:
|
||
|
||
```
|
||
printf '%s' "AUFTRAG (Bug-Beschreibung im Wortlaut):
|
||
<der Auftrag>
|
||
|
||
GIT-DIFF des Worktrees:
|
||
<git -C /tmp/wartung-<slug> diff origin/main>" | FREMDBLICK_MODE=code ~/.hermes/scripts/fremdblick.sh
|
||
```
|
||
|
||
Das läuft auf `Qwen3-Coder-Next` (128k, code-stark, anderes Modell als der Qwen3.6-Worker,
|
||
lädt klein neben dem Warm-Set) mit einem Code-Review-Raster. **Warte auf die Ausgabe.** Der
|
||
Kritiker leitet den Fehlerfall SELBST aus der Bug-Beschreibung ab (glaubt dem Autor nicht),
|
||
spielt den geänderten Code durch und beginnt mit `URTEIL: <ABGELEHNT | FREIGABE-MIT-VORBEHALT
|
||
| FREIGABE>`. (E2E geprüft 04.07.: kaputter Patch → ABGELEHNT mit Reproduktion; sauberer Fix
|
||
→ FREIGABE.)
|
||
|
||
**REPRODUZIERT-ODER-ABGELEHNT (harte Regel, im Raster verankert):** Eine Freigabe ist nur
|
||
gültig, wenn der Kritiker den konkreten Übergang belegt — „Eingabe X → VOR Patch: Y (Bug
|
||
sichtbar) → NACH Patch: Z (behoben)". Ein „sieht gut aus" OHNE diesen Vorher/Nachher-Beleg =
|
||
ABGELEHNT. So kann ein Durchwinken gar nicht erst passieren.
|
||
|
||
**Umgang mit dem Urteil:**
|
||
- `ABGELEHNT` oder `FREIGABE-MIT-VORBEHALT` mit berechtigter Kritik → nachbessern (max. 2
|
||
Runden), dann erneut prüfen. Bleibt es kritisch: die Kritik in den Vorschlag schreiben,
|
||
Branch bleibt liegen, Entscheidung dem Commander.
|
||
- `FREMDBLICK FEHLGESCHLAGEN`/`ABGESCHNITTEN` → einmal wiederholen; klappt es nicht, im
|
||
Vorschlag ehrlich „⚠ Fremd-Review fiel aus — Patch UNGEPRÜFT" vermerken (NICHT als Freigabe
|
||
behandeln). Der Ein-Schuss-Kritiker hand-simuliert (führt keinen Code aus) — für kleine
|
||
1–2-Datei-Patches reicht das zusammen mit dem Selbst-Gate (py_compile/bash -n) aus Schritt 3.
|
||
- Schreibe das Urteil im Telegram-Vorschlag KONKRET aus („durchgespielt mit Eingabe X →
|
||
Ergebnis Y"), nicht nur „Reviewer: ok".
|
||
5. **Commit im Worktree** (Message `Werkstatt: <Auftrag kurz>` + 2–4 Zeilen Was/Warum),
|
||
dann **Branch zu Gitea pushen:** `git push origin wartung/<slug>` (die Box hat einen
|
||
eigenen scoped Token, seit 02.07. hinterlegt). Push fehlgeschlagen? Nicht schlimm —
|
||
Branch bleibt lokal, im Vorschlag erwähnen.
|
||
6. **Telegram-Vorschlag** über `bash ~/mission-control-v2/deploy/notify.sh -s "[Werkstatt]" "<text>"`:
|
||
In LUCYS Stimme an den Commander (nicht als anonymer Job): erst 1–2 Sätze, was gemacht wurde
|
||
und was er jetzt entscheiden soll — dann knapp: geänderte Dateien · Kern des Diffs ·
|
||
Gate-Ergebnis · Reviewer-Urteil · Branch-Name · Frage „merge oder verwerfen?"
|
||
7. **Nichts löschen:** Worktree + Branch bleiben liegen, bis der User entschieden hat.
|
||
|
||
## Nach dem User-Entscheid (kommt als neuer Auftrag)
|
||
|
||
- „verwerfen" → `git worktree remove /tmp/wartung-<slug> --force && git branch -D wartung/<slug>`
|
||
(+ Remote-Branch löschen, falls gepusht: `git push origin --delete wartung/<slug>`)
|
||
- „merge" → das Mergen nach main + Deploy macht der PC/Claude (Frontend-Builds gibt es
|
||
nur dort). Du pushst NIE nach main — auch nicht mit Token.
|