rorappandClaude Opus 5.5
9442cc49d1
ci / test (push) Successful in 27s
- ontology/know.yaml: 49 Klassen, 66 Beziehungen, 12 Vokabulare (72 Konzepte); erzeugt: know.ttl (OWL + SKOS), Ansicht aus viewer.html.tmpl - knaster.ontology: Modell + Prüfung, Export, Momentaufnahme der n8n-Workflows (nur GET; KNOW-Spezifikation aus dem Workflow-Code, Aufrufe inkl. Laufzeit- Operationen, direktes SQL), Abgleich, Übernahme von Entscheidungen - Service-Routine Schritt 8: Verstöße als Befunde, Ontologie-Änderungen als Vorschläge ontology_change (immer Freigabe); „ordne P-x <konzept> zu“; Entscheidungen in ontology_decisions, `knaster ontology apply` schreibt sie in die YAML (Version +1) - CLI: knaster ontology validate|export|snapshot|check|apply; knaster validate prüft Modell und Aktualität der Turtle-Datei - Gegen echten n8n-Export geprüft: neue Befunde B31–B33 (verified/confirmed, KAN ruft unbekannte Operation, MPA ordnet Projektereignisse nie ein) - SPEC-ontology, BETRIEB §6, Router-Image enthält die Ontologie Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
104 lines
5.4 KiB
Markdown
104 lines
5.4 KiB
Markdown
# Betrieb: Skill-Lebenszyklus, Hermes, Pflege, Freischaltung
|
||
|
||
## 1. Lebenszyklus eines Skills
|
||
|
||
```
|
||
Hermes schreibt SKILL.md
|
||
│
|
||
draft ──(Mensch/Agent: aktivieren)──▶ active, Stufe 0
|
||
│ läuft auf dem starken Modell mit Skill-Text,
|
||
│ sammelt verifizierte Fälle
|
||
Service-Routine: stabil ≥ 95 % ────┤
|
||
▼
|
||
request_graduation (Freigabe)
|
||
│ Hermes erzeugt Varianten →
|
||
│ POST /v1/skills/{name}/graduate
|
||
▼
|
||
promote_skill (Freigabe) ──▶ active, Stufe 1 (schwaches Modell)
|
||
│
|
||
Drift (Pass-Rate < 80 %) ──▶ demote_skill (automatisch) ──▶ demoted (Stufe 0)
|
||
│
|
||
≥ 300 Trainingsfälle, Stufe-1-Rate < 90 % ─▶ train_adapter (Freigabe) ──▶ Lifecycle-Pipeline
|
||
```
|
||
|
||
Stufe 2 (Programm) und Stufe 3 (Classifier) gibt es, wenn der Skill `execution: program|classifier` deklariert und die passende Stufe freigegeben ist. Programme liegen in `knaster/programs.py` und gehen wie normaler Code durch ein Review. Classifier entstehen aus gelabelten Fällen (`EmbeddingClassifier.train`) und liegen unter `config/classifiers/<name>.json`.
|
||
|
||
## 2. Rolle von Hermes
|
||
|
||
Hermes läuft als Skill-Autor mit dem starken Modell. Er zeigt auf LiteLLM, Alias `tier0-strong`. Hermes steht **nicht** im Pfad jeder Anfrage.
|
||
|
||
| Auslöser | Hermes tut | Schnittstelle |
|
||
|---|---|---|
|
||
| Job `graduate_skill` (über n8n `knaster-jobs`) | 10–30 realistische Varianten erzeugen, Graduierung aufrufen. Schlägt sie fehl, den Skill anhand von `failures` überarbeiten | `POST /v1/skills/{name}/graduate` |
|
||
| Job `merge_skills` | zwei Skills zu einem zusammenführen, alten Skill auf `retired` setzen | Git-Commit in `skills/`, dann `POST /v1/skills/reload` |
|
||
| Neue Aufgabenklasse (häufige `no_skill`-Fälle) | neuen `SKILL.md`-Entwurf schreiben (`status: draft`) | Git-Commit + Reload |
|
||
|
||
Skills sind Dateien im Repo. Jede Änderung ist dadurch ein nachvollziehbarer Commit und lässt sich zurückdrehen.
|
||
|
||
## 3. Pflege per Prompt (Beispiele)
|
||
|
||
```
|
||
> routine
|
||
Service-Routine
|
||
Befunde:
|
||
- Drift: zusammenfassung Pass-Rate 72% (n=40)
|
||
Automatisch erledigt:
|
||
- P-12: Skill zusammenfassung auf Stufe 0 zurückstufen → Skill zusammenfassung auf Stufe 0 zurückgestuft
|
||
Offene Vorschläge (genehmige P-x / lehne P-x ab):
|
||
- P-13 [low] LoRA-Adapter für rechnungen trainieren – 412 verifizierte Fälle, Stufe-1-Rate 86%
|
||
|
||
> genehmige P-13
|
||
P-13 executed: Kandidat 7f3e… (adapter) angelegt und Build gestartet
|
||
|
||
> wechsle tier1-general auf qwen3-32b-awq
|
||
Vorschlag P-14 [medium] Basismodell von tier1-general auf qwen3-32b-awq wechseln …
|
||
Bestätige mit „genehmige P-14“.
|
||
```
|
||
|
||
Freitext, der keinem Befehl entspricht, bildet ein kleines Modell auf einen Befehl ab. Der Agent fragt dann mit „Meinst du …?“ zurück.
|
||
|
||
## 4. Dry-Run aufheben (schrittweise)
|
||
|
||
1. Eine Woche mit `KNASTER_DRY_RUN=true` laufen lassen. Die Healer-Ergebnisse stehen als `[dry-run] …` in den Antworten bzw. Logs.
|
||
2. `KNASTER_DRY_RUN=false` setzen. Interne Aktionen (Slot-Status, Skill-Stufen, Kandidaten) liefen schon vorher. Jetzt werden auch Jobs per Webhook verschickt.
|
||
3. Infrastruktur-Aktionen einzeln freischalten, über `config/healer-rules.yaml` → `enabled_actions: [restart_container]`, später `restart_vm`. `reboot_host` bleibt freigabepflichtig (Policy) und läuft nur im Wartungsfenster.
|
||
|
||
## 5. Rollback-Wege
|
||
|
||
| Was | Wie |
|
||
|---|---|
|
||
| Adapter/Basismodell | Prompt `rollback <slot>` → Freigabe |
|
||
| Skill-Stufe | Prompt `stufe <skill> zurück` bzw. Git-Revert der SKILL.md |
|
||
| Treiber/Engine | Proxmox-Snapshot der GPU-VM (vor jedem Update anlegen) |
|
||
| Konfiguration | Git-Revert und Neustart des Router-Containers |
|
||
|
||
## 6. Ontologie pflegen
|
||
|
||
Die Ontologie (`ontology/know.yaml`) beschreibt die Begriffe der Datenhaltung. Details in `docs/spec/SPEC-ontology.md`.
|
||
|
||
- **Kern** (Klassen, Beziehungen) ändert sich nur per Commit.
|
||
- **Vokabulare** wachsen über die Service-Routine. Sie gleicht n8n nur lesend mit der Ontologie ab und schlägt neue Werte vor:
|
||
|
||
```
|
||
> routine
|
||
Befunde:
|
||
- Ontologie [high]: KAN - Kanbau API Gateway ruft `get_kanbau_project_patterns` auf, die Operation gibt es in KNOW nicht
|
||
Offene Vorschläge:
|
||
- P-21 [low] Mail-Kategorie: neuer Wert „bauvorhaben“
|
||
- P-22 [low] Mail-Kategorie: neuer Wert „MPA“
|
||
|
||
> genehmige P-21 → neues Konzept
|
||
> ordne P-21 sonstiges zu → „bauvorhaben“ wird Schreibweise von „sonstiges“
|
||
> lehne P-22 ab: Workflow-Name → Wert wird verworfen und nicht wieder vorgeschlagen
|
||
```
|
||
|
||
Danach im Repo übernehmen, z. B. wöchentlich:
|
||
|
||
```
|
||
knaster ontology apply # Entscheidungen → know.yaml, Version +1
|
||
knaster ontology export --ttl ontology/know.ttl
|
||
git commit -am "ontology: Entscheidungen übernommen"
|
||
```
|
||
|
||
Ohne `N8N_HOST`/`N8N_API_KEY` (oder `KNASTER_ONTOLOGY_SNAPSHOT`) ist der Abgleich aus. Fällt n8n aus, läuft die Routine weiter und meldet das.
|