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>
53 lines
2.9 KiB
Markdown
53 lines
2.9 KiB
Markdown
# 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](docs/PLAN.md) | Architektur und Betrieb: Proxmox, Pflege, Autohealing, Lifecycle, Finetuning, Problemerkennung, Portabilität |
|
||
| [docs/adr/](docs/adr/) | Architekturentscheidungen |
|
||
| [docs/spec/](docs/spec/) | Spezifikationen der Komponenten |
|
||
| [docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](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](docs/IMPLEMENTATION.md) | Arbeitspakete, Teststrategie, Stand der Verifikation |
|
||
| [ontology/know.yaml](ontology/know.yaml) | **Ontologie der Datenhaltung** (Quelle); Pflege und Abgleich in [SPEC-ontology](docs/spec/SPEC-ontology.md) |
|
||
| [docs/reference/KNOW-schema.md](docs/reference/KNOW-schema.md) | Bestehende n8n-Wissensdatenbank KNOW/KGW: Tabellen, wer schreibt und liest, Auffälligkeiten |
|
||
| [docs/BETRIEB.md](docs/BETRIEB.md) | Skill-Lebenszyklus, Rolle von Hermes, Pflege per Prompt, Dry-Run aufheben, Rollback |
|
||
| [n8n/README.md](n8n/README.md) | Workflows und Import |
|
||
| [platform/proxmox/README.md](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
|
||
|
||
```bash
|
||
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`).
|