Robert RappandClaude Opus 5.5 23d6e36028
ci / test (push) Successful in 28s
gpu-vms: DHCP-Client-ID auf MAC, Docker-Runtime als Aufgabe, Zugang nach Neustart auffrischen
Nach dem Treiber-Neustart hatten gpu-pve44 und gpu-pve46 ihre DHCP-Adressen
getauscht; die strenge Hostschlüssel-Prüfung hat den Lauf gestoppt. netplan
nutzt jetzt die MAC als Client-ID (Voraussetzung für Reservierungen, D5).
Der Handler für nvidia-ctk ist eine idempotente Aufgabe, vor dem Neustart
werden Handler ausgeführt. scripts/refresh-vm-access.sh holt Adressen aus
dem Agenten, schreibt das Inventar und trägt die Hostschlüssel ein.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 19:39:25 +02:00

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
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).

S
Description
No description provided
Readme
1.4 MiB
Languages
Python 83.2%
Go Template 7.3%
Shell 4.9%
HCL 2.1%
Dockerfile 1.3%
Other 1.2%