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>
cluster-knaster
Ein starkes LLM erarbeitet neue Aufgaben und destilliert sie zu Skills. Danach übernehmen kleinere, selbst gehostete Modelle diese Aufgaben. Embeddings erkennen wieder, routen und treffen einfache Entscheidungen. Betrieb auf einem Proxmox-Cluster mit gemischten GPUs, gesteuert über n8n, mit halbautomatischer Pflege (Human-in-the-Loop).
Anfrage → n8n → Router-Service ──▶ Stufe 3 Embedding-Classifier (CPU)
│ ├─▶ Stufe 2 Programm (CPU)
│ ├─▶ Stufe 1 schwaches LLM + Skill (+LoRA) über LiteLLM → vLLM
│ └─▶ Stufe 0 starkes LLM über LiteLLM → OpenRouter
└─ Verifier → bestanden: Antwort + Fall speichern
→ nicht bestanden: Eskalation + Präferenzpaar
Dokumentation
| Dokument | Inhalt |
|---|---|
| docs/PLAN.md | Architektur und Betrieb: Proxmox, Pflege, Autohealing, Lifecycle, Finetuning, Problemerkennung, Portabilität |
| docs/adr/ | Architekturentscheidungen |
| docs/spec/ | Spezifikationen der Komponenten |
| docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md | Aufbauplan auf echter Hardware: Phasen, Entscheidungen D1–D5, Zuordnung zu Planner Epic 7 |
| docs/IMPLEMENTATION.md | Arbeitspakete, Teststrategie, Stand der Verifikation |
| ontology/know.yaml | Ontologie der Datenhaltung (Quelle); Pflege und Abgleich in SPEC-ontology |
| docs/reference/KNOW-schema.md | Bestehende n8n-Wissensdatenbank KNOW/KGW: Tabellen, wer schreibt und liest, Auffälligkeiten |
| docs/BETRIEB.md | Skill-Lebenszyklus, Rolle von Hermes, Pflege per Prompt, Dry-Run aufheben, Rollback |
| n8n/README.md | Workflows und Import |
| platform/proxmox/README.md | Proxmox-Ablauf (OpenTofu + Ansible) |
Repo-Struktur
core/ Python-Paket `knaster` (Router-Service) + Tests
config/ Policy, Healer-Regeln, Grenzwerte (portabel)
catalog/ Modell- und Rollenkatalog mit Hardware-Anforderungen
skills/ SKILL.md-Bibliothek
deploy/ Docker Compose pro Rolle, LiteLLM, Prometheus, Alertmanager
n8n/workflows/ importierbare n8n-Workflows
platform/proxmox/ OpenTofu + Ansible
sites/knaster/ standortspezifisch: Inventar, Registry
Entwicklung
make dev # venv + Abhängigkeiten
make test # Unit- und Integrationstests
make lint # ruff
make validate # Konsistenz Registry/Skills/LiteLLM/Healer/Policy/Katalog + Placement
make compose-check # docker compose config für alle Rollen
Alle Aktionen gegen Infrastruktur laufen standardmäßig im Dry-Run (KNASTER_DRY_RUN=true).