Hitonabi
ab8d651efc
- deploy/skills/wartung/SKILL.md: Selbstwartungs-Kreislauf (Worktree -> Patch -> Reviewer-Subagent -> Gate -> Telegram-Merge-Vorschlag); Leitplanken hart codiert (nie main/merge/deploy/Security-Config); deploy.sh installiert nach ~/.hermes/skills/ - Box hat bewusst KEINE Gitea-Push-Rechte (Token = offener User-Entscheid) -> v1 endet beim Merge-Vorschlag mit lokalem Branch - docs/RUNBOOK.md: 1 Seite Mensch-Anleitung (Telegram-Meldungen, Box tot, Pins, einmalige sudo-Session, Automatik-Fahrplan) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.3 KiB
3.3 KiB
name, description, version, author, platforms, metadata
| name | description | version | author | platforms | metadata | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| wartung | 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. | 1.0.0 | MC2 (Autonomie E6) |
|
|
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): NUR einen Plan liefern (Text im Telegram-Vorschlag), KEINEN Code.
Leitplanken (nicht verhandelbar)
- NIEMALS auf
maincommitten. NIEMALS mergen. NIEMALS deployen oder Dienste neu starten. - Security-Config ist TABU: keine Tokens, approvals, ufw, sudoers anfassen.
- 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
- 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 - Patch nur im Worktree. Minimal-invasiv, Stil der umgebenden Datei übernehmen (deutsche Kommentare, bestehende Muster).
- 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-Check:
curl -sf http://127.0.0.1:9001/api/health(muss grün bleiben — beweist, dass du die Live-Instanz nicht angefasst hast).
- Python geändert →
- Reviewer-Subagent (frischer Kontext, Worker/Reviewer-Muster):
delegate_taskmit role=leaf. Gib ihm den AUFTRAG im Wortlaut +git diffdes Worktrees. Seine Fragen: Erfüllt der Diff den Auftrag? Minimal-invasiv? Risiken/Nebenwirkungen? — Bei berechtigter Kritik: nachbessern (max. 2 Runden), sonst Kritik in den Vorschlag schreiben. - Commit im Worktree: Message
Werkstatt: <Auftrag kurz>+ 2–4 Zeilen Was/Warum. - Telegram-Vorschlag über
bash ~/mission-control-v2/deploy/notify.sh -s "[Werkstatt]" "<text>": Auftrag · geänderte Dateien · Kern des Diffs (2–5 Zeilen) · Gate-Ergebnis · Reviewer-Urteil · Branch-Name · Frage „merge oder verwerfen?" - 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> - „merge" → heute merged/deployt der PC (die Box hat bewusst keine Gitea-Push-Rechte; eigener Token = offener User-Entscheid). Sobald der Token existiert: Branch pushen und den PC-Schritt melden statt ausführen.