docs: Aufbauplan auf echter Hardware, zusammengeführt mit Planner Epic 7

Chronologischer Plan (Phasen 0-9) für pve44/46/48/52/61 mit
Entscheidungen D1-D5 (ZFS, GPU-VM pro Knoten, Ada unter Windows,
ein LiteLLM mit PSE, IP-Plan), Duplikat-Zuordnung zu Epic 7 und
Parallelspur NEX. PLAN §8 und IMPLEMENTATION "Gemeinsames
Deployment" als abgelöst markiert.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -18,7 +18,8 @@ Anfrage → n8n → Router-Service ──▶ Stufe 3  Embedding-Classifier (CPU)
 | [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/IMPLEMENTATION.md](docs/IMPLEMENTATION.md) | Arbeitspakete, Teststrategie, Stand der Verifikation, Ablauf des Deployments |
+| [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 |
 | [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) |

docs/IMPLEMENTATION.md

@@ -49,6 +49,8 @@ Vorgehen pro Baustein: **Spec → Implementierung → Tests → Commit**. Bis zu
 
 ## Gemeinsames Deployment (später)
 
+> **Abgelöst** durch [docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](superpowers/plans/2026-10-12-aufbau-cluster-knaster.md). Dort steht der Ablauf auf der echten Hardware, zusammengeführt mit Planner Epic 7. Die Liste unten bleibt nur zur Nachvollziehbarkeit stehen.
+
 1. Inventarlauf auf allen Nodes → `sites/knaster/inventory.yaml` ergänzen → `knaster placement plan`
 2. Proxmox: ZFS-Pools, Resource Mappings, Templates (`platform/proxmox`)
 3. Infra-LXC: `deploy/compose/infra` mit `KNASTER_DRY_RUN=true`

docs/PLAN.md

@@ -279,6 +279,8 @@ Die Portabilität beruht also auf den **Daten und der Pipeline**, nicht auf Gewi
 
 ## 8. Roadmap
 
+> **Abgelöst** durch [superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](superpowers/plans/2026-10-12-aufbau-cluster-knaster.md). Dort ist der chronologische Ablauf auf der echten Hardware beschrieben, mit den Entscheidungen D1–D5 und der Zuordnung zu Planner Epic 7. Die Tabelle unten bleibt nur zur Nachvollziehbarkeit stehen (Zuordnung: 0 → Phasen 0–5, 1 → 6, 2 → 7, 3–6 → 9).
+
 | Phase | Inhalt | Fertig, wenn … |
 |---|---|---|
 | **0 Fundament** | Proxmox-Templates, Resource Mappings, OpenTofu/Ansible, Monitoring-Stack | eine GPU-VM lässt sich per Code neu erzeugen, Grafana zeigt GPU- und Proxmox-Metriken |

docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md

@@ -0,0 +1,362 @@
+# Aufbau Cluster „knaster“ – zusammengeführter Umsetzungsplan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Die fünf installierten Proxmox-Knoten werden Schritt für Schritt zum Cluster „knaster“ ausgebaut, auf dem die Architektur aus `docs/PLAN.md` läuft. Grundlage sind die echte Hardware und die Aufgaben aus Planner Epic 7.
+
+**Architecture:** Fünf Proxmox-Knoten mit ZFS bilden einen Cluster. Jeder GPU-Knoten bekommt **eine** Ubuntu-VM, an die alle seine Karten durchgereicht werden; darin laufen Docker-Container pro Rolle. Die Infrastruktur (Router, Postgres, Monitoring) läuft als LXC mit Docker und HA. Die beiden RTX-4000-Ada-Rechner bleiben Windows-Arbeitsplätze und stellen ihre Leistung über die vorhandene Worker-Registry v2 bereit. Starke Modelle laufen ausschließlich über den LiteLLM mit PSE auf appsrv08.
+
+**Tech Stack:** Proxmox VE 9.2 (Debian 13, ZFS), Ubuntu 24.04 in den GPU-VMs, NVIDIA R580 (Maxwell/Pascal), llama.cpp, whisper.cpp, Docker Compose, OpenTofu (`bpg/proxmox`), Ansible, Prometheus/Alertmanager/Grafana, Proxmox Backup Server, n8n (n8n.mindboost.app), LiteLLM (appsrv08), Python-Paket `knaster`.
+
+**Spec/Quellen (bei der Umsetzung mitlesen):**
+- `docs/PLAN.md`, `docs/adr/0001`–`0006`, `docs/IMPLEMENTATION.md`, `docs/BETRIEB.md` (dieses Repo)
+- Planner „Epic 7 — CCO KI-Agent Infrastruktur“ (Plan `NLQ0gHCZkUmdMv3ko__DmZgAHU_S`, Bucket `IeG9IcsEG0-_ZEW5unBaiZgAEtoE`)
+- `C:\Users\r.rapp\it\proxmox\STAND-2026-10-08.md` und `healthcheck-2026-10-08.txt` (Ist-Stand der Knoten)
+- Repo `mygodel/nex`: `docs/plans/2026-10-07-nex-stt-gpu.md` (Whisper im Haus), `docs/plans/2026-09-29-nex-worker-registry-v2.md` (Ada-Worker)
+
+Dieser Plan **löst** die Abläufe in `docs/PLAN.md` §8 („Roadmap“) und `docs/IMPLEMENTATION.md` („Gemeinsames Deployment“) **ab**. Deren Phasen sind unten zugeordnet.
+
+---
+
+## Ausgangslage (Stand 12.10.2026)
+
+| Knoten | IP | Hardware | Platten | GPUs | Besonderheit |
+|---|---|---|---|---|---|
+| pve44 | 192.168.100.210 | ThinkStation P310, i7-6700, 32 GB | 2× 256 GB (sdb: altes Windows, NTFS) | M4000 + P2000 | – |
+| pve46 | 192.168.100.209 | ThinkStation P310, i7-6700, 32 GB | 1× 256 GB | M4000 + P2000 | bootet Legacy statt UEFI |
+| pve48 | 192.168.100.212 | **unbekannt** | unbekannt | unbekannt | kein SSH (Passwort aus `.env` falsch) |
+| pve52 | 192.168.100.207 | ThinkStation P320, i7-7700, 32 GB | 2× 256 GB (sdb: altes Windows, **BitLocker „GODEL55“**) | M4000 (P2000 nicht erkannt) | – |
+| pve61 | 192.168.100.214 | Surface Book, i5-8350U, 8 GB | 1× 256 GB NVMe | Intel UHD 620 | LAN nur über USB-NIC im Lenovo-Dock, 2 Akkus |
+
+Alle Knoten: PVE 9.2.2, Kernel 7.0.2, **ext4 + LVM-thin auf einer SSD (kein ZFS)**, 1 GbE, kein Cluster. VT-x und VT-d sind aktiv. IOMMU ist geprüft: Jede Karte liegt mit ihrer Audio-Funktion in einer eigenen Gruppe (M4000 in Gruppe 1, P2000 in Gruppe 8), Passthrough ist also möglich.
+
+Außerhalb des Clusters:
+- **GODE-PC-05/06:** je eine RTX 4000 Ada mit 20 GB, Windows, tagsüber Arbeitsplätze. Sie laufen heute schon als LLM-Worker (`LocalLLMWorker.ps1`).
+- **appsrv08 (.29):** GRP produktiv, NEX und LiteLLM mit PSE-Filter.
+- **n8n:** n8n.mindboost.app.
+- **Gitea:** gitea.mindboost.team.
+
+---
+
+## Global Constraints
+
+- **Starke Modelle (tier0, OpenRouter) nur über den LiteLLM mit PSE auf appsrv08.** Kein zweiter Gateway-Weg nach außen, sonst wird die Pseudonymisierung umgangen (Epic 7 „LiteLLM Swarm: PSE-Fix“).
+- **Netz:** flach `192.168.100.0/24`, Gateway `.1`, DNS `.120`. Feste IP-Literale, kein DNS-Name in Konfigurationen, vorerst kein VLAN.
+- **Container zuerst:** Dienste laufen als Docker-Container, in LXC oder in einer VM. Eine VM gibt es nur dort, wo sie ein Treiberproblem löst (GPU-VM pro Knoten, D2) oder ein Produkt sie verlangt.
+- **Dry-Run:** Alle knaster-Aktionen gegen Infrastruktur starten mit `KNASTER_DRY_RUN=true` und werden erst nach einer Woche Beobachtung einzeln freigeschaltet.
+- **STT:** `whisper-server` auf Port 8178, nur von `192.168.100.29` erreichbar. `stt.openai.base_url` nur als IP-Literal (nex-STT-Plan, Annahmen).
+- **Ada-Rechner:** Windows bleibt, Mitarbeitende haben tagsüber Vorrang, kein Proxmox darauf.
+- **Datacenter-weite Einstellungen** (Benutzer, 2FA, Firewall, Benachrichtigungen, Pools, Metriken) erst, wenn alle Knoten im Cluster sind.
+- **Alte Windows-SSDs** (pve44 sdb, pve52 sdb) nur nach ausdrücklicher Freigabe löschen (D1).
+- **Geheimnisse** nie ins Repo. Zugangsdaten liegen in `C:\Users\r.rapp\it\proxmox\.env`, der Schlüssel unter `…\proxmox\keys\`.
+- **Planner-Webhook `tdo-codex-update`:** pro Aufruf nur **eine** Aktualisierung, vorhandene Titel nie umbenennen (Abgleich läuft über den Titel, Schwelle 0.8).
+
+## Review Focus
+
+1. **Eine Neuinstallation löscht die Einrichtung vom 08.10.** Betroffen sind Schlüssel, Paketquellen, Dock-Bindung und SSH-Hostschlüssel. Erwartung: Das Bootstrap-Skript stellt alles wieder her, und `ssh -o BatchMode=yes pveXX hostname` klappt danach ohne Nachfrage (Task 1.1, Test im Skript).
+2. **Der Cluster-Beitritt ersetzt `authorized_keys`.** Erwartung: Nach jedem `pvecm add` funktioniert der Laptop-Zugang auf allen Knoten weiter (Task 2.1, Prüfschritt).
+3. **Die USB-NIC von pve61 verschwindet nach einem Stromausfall oder einem Umstecken des Docks.** Erwartung: `vmbr0` hängt danach wieder an der Karte, ohne Eingriff (Task 1.3, Test: Dock aus- und einstecken).
+4. **Ein Ada-Worker ist tagsüber belegt oder aus.** Erwartung: tier1-Anfragen landen ohne Fehler bei tier0 über PSE (Task 6.4, Unit-Test im Router).
+5. **Die Rolle `pve-host` sperrt NVIDIA und setzt VFIO.** Erwartung: Das passiert nur auf GPU-Knoten. pve61 behält seine iGPU für den Kiosk (Task 3.1, Ansible-Gruppen, Prüfung `lspci -k`).
+
+---
+
+## Entscheidungen (vor der jeweiligen Phase bestätigen)
+
+| # | Frage | Empfehlung | Begründung | Alternative |
+|---|---|---|---|---|
+| **D1** | Speicher | **Alle Knoten mit ZFS neu installieren:** RAID1 auf Knoten mit zwei SSDs (pve44, pve52, ggf. pve48), Einzel-ZFS auf pve46 und pve61. Gast-Speicher ist überall `local-zfs`. | Es steht noch nichts auf den Knoten, ein Neuaufbau kostet etwa 30 Min. pro Knoten. Gleicher Speichername überall ermöglicht Replikation und HA zwischen beliebigen Knoten. Dazu kommen Snapshots und Ausfallsicherheit der Systemplatte. pve46 kommt dabei auf UEFI. Das Video empfiehlt ZFS RAID1. Kapazität: 256 GB je Knoten reichen für das Speicherbudget aus PLAN §1.4. | Kein Neuaufbau: SSD2 als Einzel-ZFS `tank` nur auf pve44 und pve52, Replikation nur zwischen diesen beiden. pve46 und pve61 bleiben ohne ZFS. |
+| **D2** | GPU als VM oder LXC | **Pro GPU-Knoten eine Ubuntu-24.04-VM mit allen Karten des Knotens**, darin Docker Compose pro Rolle. | Der Host-Kernel (7.0) bleibt ohne NVIDIA, Proxmox-Updates gefährden den Treiber nicht. R580 kommt als Ubuntu-Paket und ist per Snapshot rückrollbar. IOMMU-Gruppen sind geprüft. Eine VM pro Knoten statt pro Rolle (ADR-0001) spart RAM. Das Argument „gemischte Generationen“ aus ADR-0001 gilt im Cluster nicht mehr, alle Karten sind Maxwell/Pascal. Kosten: 2–5 % CPU, fest reservierter VM-RAM (12–16 GB von 32 GB). | LXC mit Host-Treiber: braucht R580 auf Kernel 7.0 oder einen festgehaltenen älteren Kernel. |
+| **D3** | Ada-Rechner | **Windows bleibt.** `LocalLLMWorker.ps1` mit llama-server (CUDA) meldet sich über die Worker-Registry v2. Die knaster-Slots `tier1-general`/`tier1-flex` lösen auf einen Worker auf, der online ist, sonst tier0. | Die Registry v2 ist fast fertig (44 von 55 Schritten). Mitarbeitende werden nicht gestört. vLLM läuft unter Windows nicht nativ, Multi-LoRA, QLoRA und Qwen3-TTS kommen deshalb erst mit einer späteren WSL2-Entscheidung (Phase 9). | Dual-Boot mit Proxmox: scheidet aus, die Rechner werden tagsüber genutzt. |
+| **D4** | LiteLLM | **Kein eigener LiteLLM im knaster-Infra.** Der Router nutzt den LiteLLM auf appsrv08 (mit PSE), die lokalen Slots werden dort als Modelle eingetragen. | Es läuft bereits ein dritter LiteLLM; noch einer würde PSE für tier0 umgehen. Ein Modellwechsel bleibt eine Datenänderung. | Eigener LiteLLM nur für lokale Slots, ohne OpenRouter-Zugang. |
+| **D5** | IP-Plan | **Knoten behalten .207–.214.** Gäste bekommen einen festen Block außerhalb des DHCP-Bereichs. Vorschlag `.220–.239`, wird in Task 0.3 gegen den DHCP-Bereich geprüft. | Die STT-Konfiguration braucht IP-Literale. Die alten GODEL-DNS-Einträge zeigen, dass die Knoten-IPs aus DHCP stammen, deshalb Reservierungen anlegen. | VLAN `svc` (PLAN §1.4) später, wenn der Switch das zulässt. |
+
+---
+
+## Phase 0 – Bestandsaufnahme und Repo an die Wirklichkeit anpassen
+
+Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeinsames Deployment“ Schritt 1.
+
+### Task 0.1: Zugang zu pve48 und Inventar aller Knoten
+
+**Wo:** Teil a vor Ort an der Konsole von pve48, Teil b remote · **Planner:** „Proxmox: pve48 root-Passwort klären und SSH-Schlüssel nachtragen“
+
+- [ ] **a (vor Ort):** An pve48 als root anmelden, gegebenenfalls `passwd`, neuen Wert in `.env` (`PVE48_PASS`) eintragen.
+- [ ] **b:** Schlüssel verteilen (Verfahren vom 08.10., `push_keys.py`) und Paketquellen umstellen.
+  Prüfung: `ssh -o BatchMode=yes pve48 hostname` → `pve48`.
+- [ ] **c:** Gesundheitscheck auf pve48 ausführen und `healthcheck-2026-10-08.txt` ergänzen. Notieren: CPU, RAM, Platten, GPUs, IOMMU-Gruppen.
+- [ ] **d (vor Ort, falls nötig):** pve52 – steckt neben der M4000 eine P2000? Falls ja: Sitz und Steckplatz prüfen, bis `lspci | grep -c NVIDIA` zwei VGA-Geräte zeigt. Verbleib von Godel45 klären (im STT-Plan aufgeführt).
+
+### Task 0.2: DHCP-Bereich und IP-Plan (D5)
+
+**Wo:** remote (DHCP-Server, vermutlich DC `.120` oder UniFi) · **Planner:** „PVE-Config: Netzwerk prüfen – Bridge, VLAN-Fähigkeit und NIC-Kompatibilität“
+
+- [ ] DHCP-Bereich auslesen. Für .207, .209, .210, .212 und .214 Reservierungen auf die MACs der Knoten anlegen (MACs stehen im Healthcheck).
+- [ ] Gäste-Block festlegen (Vorschlag `.220–.239`) und als Ausschluss im DHCP eintragen.
+  Prüfung: `ping` auf jede Adresse des Blocks → keine Antwort. DHCP-Ausschluss sichtbar.
+
+### Task 0.3: Entscheidungen D1–D5 bestätigen
+
+**Wo:** Gespräch mit dem Nutzer
+
+- [ ] D1: Ausdrückliche Freigabe zum Löschen von pve44 sdb (NTFS) und pve52 sdb (BitLocker „GODEL55“). Vorher klären, ob Daten oder Recovery-Key gebraucht werden.
+- [ ] D2–D5 bestätigen. Ergebnis als Abschnitt „Entscheidungen 2026-10“ in `docs/PLAN.md` §9 eintragen.
+
+### Task 0.4: Site-Dateien, Ansible-Inventar und ADRs an die echte Hardware anpassen
+
+**Wo:** remote, Repo · **Files:**
+- Modify: `sites/knaster/inventory.yaml`, `sites/knaster/proxmox.yaml`, `sites/knaster/registry.yaml`, `platform/proxmox/ansible/inventory.yml`, `docs/PLAN.md` §1.3, §1.4 und §9
+- Modify: `docs/adr/0001-gpu-vms-infra-lxc.md` (eine VM pro Knoten), `docs/adr/0002-storage-zfs-kein-ceph.md` (D1), `docs/adr/0006-legacy-gpus-llamacpp-tts-auf-ada.md` (Ada unter Windows, D3)
+- Test: `core/tests/test_inventory_validate.py`
+
+**Interfaces:**
+- Produces: Knotennamen `pve44`, `pve46`, `pve48`, `pve52`, `pve61`. PCI-Mappings `gpu-m4000-pve44`, `gpu-p2000-pve44`, `gpu-m4000-pve46`, `gpu-p2000-pve46`, `gpu-m4000-pve52` (plus pve48 nach Task 0.1). GPU-VMs `gpu-pve44` (vmid 244), `gpu-pve46` (246), `gpu-pve52` (252). Infra-LXC `infra` (vmid 101). Ansible-Gruppen `pve_all`, `pve_gpu_hosts`, `pve_kiosk`.
+
+- [ ] **Step 1: Failing test.** In `test_inventory_validate.py` den Test `test_site_knaster_matches_real_nodes` anlegen: Die Inventar-Knoten sind genau `{pve44, pve46, pve48, pve52, pve61}`, `proxmox.yaml` enthält keine IP aus `10.20.0.0/24`, und jedes `pci_mappings[*].node` ist ein Inventar-Knoten.
+- [ ] **Step 2:** `make test` → FAIL (alte Annahmen `pve-ada`, `pve1`–`pve4`).
+- [ ] **Step 3:** Site-Dateien umschreiben. Werte für IDs und Pfade aus `lspci -nn` und dem Healthcheck: M4000 `10de:13f1` auf `0000:01:00`, P2000 `10de:1c30` auf `0000:02:00`. Gateway `192.168.100.1`, DNS `192.168.100.120`, keine `vlan_svc`, Gast-IPs aus D5. Die M4000 bleiben `disabled: true` bis zum Benchmark-Tag (Task 3.5). Die Ada-Slots zeigen auf `engine: worker-registry` (siehe Task 6.4).
+- [ ] **Step 4:** `make test && make validate` → PASS. `knaster placement plan --inventory sites/knaster/inventory.yaml` liefert eine Zuordnung ohne Fehler.
+- [ ] **Step 5:** Commit `sites: Inventar und Zielbild an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 ergänzt`.
+
+---
+
+## Phase 1 – Knoten-Grundlage (vor dem Cluster)
+
+### Task 1.1: Bootstrap-Skript für einen frischen Knoten
+
+**Wo:** remote · **Planner:** „PVE-Config: Erst-Update aller Knoten (apt full-upgrade)“ · **Files:** Create `platform/proxmox/scripts/bootstrap-node.sh`, Create `platform/proxmox/scripts/README.md`
+
+**Interfaces:**
+- Produces: `bootstrap-node.sh <knoten>`, idempotent. Ausgabe endet mit `BOOTSTRAP OK <hostname>` oder Exit ≠ 0.
+
+- [ ] **Step 1:** Das Skript (läuft auf dem Laptop, Git-Bash) erledigt Folgendes:
+  - alten Hostschlüssel mit `ssh-keygen -R <ip>` entfernen
+  - Schlüssel per Passwort aus `.env` eintragen, mit dem SSH_ASKPASS-Verfahren vom 08.10. (nur anhängen, `grep -qxF`)
+  - Enterprise-Quellen auf `Enabled: no` setzen, `proxmox.sources` mit `pve-no-subscription` anlegen, vorher sichern
+  - `apt-get update && apt-get -y full-upgrade`
+  - Pakete `ethtool lm-sensors` installieren
+  - Prüfen: `timedatectl show -p NTPSynchronized` = `yes`
+- [ ] **Step 2:** Zweiter Lauf gegen denselben Knoten → keine Änderung, wieder `BOOTSTRAP OK`.
+- [ ] **Step 3:** Commit.
+
+### Task 1.2: Neuinstallation mit ZFS (nur wenn D1 = Empfehlung)
+
+**Wo:** **vor Ort**, USB-Stick mit PVE 9.2 (ISO und Prüfsumme in `C:\Users\r.rapp\it\proxmox`) · **Planner:** „Proxmox: Speicher aller Knoten richtig konfigurieren“, „PVE-Config: RAM-Planung je Knoten (Host-Reserve, ZFS-ARC, KSM, Swap)“
+
+Reihenfolge: **pve46** (eine Platte, Legacy → UEFI), dann pve44, pve52, pve48 und zuletzt **pve61 mit angestecktem Dock** (der USB-C-Adapter ist zurückgegeben).
+
+- [ ] Pro Knoten: BIOS auf UEFI, Secure Boot aus, iGPU als primäre Anzeige (GPU-Knoten). Installer: gleicher Hostname und gleiche IP wie bisher, `ZFS (RAID1)` bzw. `ZFS (RAID0)` bei einer Platte, `ashift=12`, `compress=on`.
+- [ ] Danach `bootstrap-node.sh <knoten>` → `BOOTSTRAP OK`.
+- [ ] ZFS-ARC begrenzen: `zfs_arc_max` = 4 GiB auf 32-GB-Knoten, 1 GiB auf pve61 (`/etc/modprobe.d/zfs.conf`, `update-initramfs -u`).
+  Prüfung: `zpool status` → `ONLINE`. `pvesm status` → `local-zfs active`. `cat /sys/module/zfs/parameters/zfs_arc_max` → `4294967296` bzw. `1073741824`.
+
+### Task 1.3: pve61 – Netzwerk am Dock robust machen, Akku schonen
+
+**Wo:** remote, Akku-Einstellung vor Ort · **Planner:** Teil von „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“
+
+- [ ] NIC des Docks per systemd-`.link` auf den Namen `nic0` festlegen, Zuordnung über die MAC `3c:e1:a1:c0:83:9d`. `bridge-ports nic0` in `/etc/network/interfaces`. Nach dem Ausstecken hängt ein `udev`-Hook `ifup`/`ifreload` die Karte wieder an `vmbr0`.
+- [ ] **Test (vor Ort):** Dock 10 s ausstecken und wieder einstecken → nach höchstens 30 s `ping 192.168.100.214` vom Laptop ok.
+- [ ] Surface-UEFI „Battery Limit“ einschalten (Lauter-Taste + Einschalten).
+  Prüfung: `grep . /sys/class/power_supply/BAT*/capacity` pendelt bei etwa 50 %.
+
+---
+
+## Phase 2 – Cluster
+
+Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.
+
+### Task 2.1: Cluster „knaster“ bilden
+
+**Wo:** remote · **Planner:** „GPU-Knoten 3: Cluster mit QDevice (Container auf appsrv08), NVIDIA-Treiber, GPU-Container“ (Teil Cluster)
+
+- [ ] Auf pve44: `pvecm create knaster --link0 192.168.100.210`.
+- [ ] Nacheinander auf pve46, pve48, pve52 und pve61: `pvecm add 192.168.100.210 --link0 <eigene IP>`. Nach **jedem** Beitritt den Laptop-Schlüssel in `/etc/pve/priv/authorized_keys` prüfen und gegebenenfalls einmal ergänzen.
+  Prüfung: `pvecm status` → `Quorate: Yes`, `Total votes: 5`. `for n in pve44 pve46 pve48 pve52 pve61; do ssh -o BatchMode=yes $n hostname; done` → fünf Namen.
+- [ ] Datacenter-Optionen: Migrationsnetz `192.168.100.0/24`, Typ `secure`.
+
+### Task 2.2: HA-Regeln und Replikation
+
+**Wo:** remote
+
+- [ ] Node-Affinity-Regeln: Infra-Dienste nur auf pve44, pve48, pve52. **pve61** bekommt keine HA-Gäste, GPU-VMs bleiben an ihrem Knoten.
+- [ ] Replikationspartner festlegen: Infra-LXC von seinem Knoten auf einen zweiten, `*/15`.
+  Prüfung: `ha-manager rules config` bzw. `ha-manager groupconfig` zeigt die Regeln.
+
+---
+
+## Phase 3 – GPU-Grundlage und Benchmark-Tag
+
+### Task 3.1: Steuerrechner „ops“ und Host-Rolle nur für GPU-Knoten
+
+**Wo:** remote · **Files:** Modify `platform/proxmox/ansible/inventory.yml`, `platform/proxmox/ansible/playbooks/site.yml`, Create `platform/proxmox/README.md` (Abschnitt ops-LXC)
+
+- [ ] LXC `ops` (Debian 13, vmid 100, auf pve44, IP aus D5) mit `ansible-core`, `opentofu`, `git` und dem Repo-Clone. Ansible läuft nicht auf dem Windows-Laptop.
+- [ ] `site.yml`: `pve-host` nur für `pve_gpu_hosts` (pve44, pve46, pve52, ggf. pve48). pve61 steht in `pve_kiosk` ohne VFIO und Blacklist.
+- [ ] `ansible-playbook playbooks/site.yml --limit pve_gpu_hosts --check`, danach der echte Lauf. Knoten **einzeln** neu starten.
+  Prüfung: `lspci -nnk -s 01:00.0` auf jedem GPU-Knoten → `Kernel driver in use: vfio-pci`. Auf pve61: `lspci -k -s 00:02.0` → `i915`.
+
+### Task 3.2: Resource Mappings, Template und GPU-VMs
+
+**Wo:** remote (ops-LXC) · **Planner:** „GPU-Knoten 3 …“ (Teil NVIDIA, GPU-Container)
+
+- [ ] PCI-Resource-Mappings aus `sites/knaster/proxmox.yaml` anlegen (Namen aus Task 0.4).
+- [ ] Ubuntu-24.04-Cloud-Template vmid 9000 auf jedem GPU-Knoten.
+- [ ] `tofu plan` und dann `tofu apply` für `gpu-pve44`, `gpu-pve46` und `gpu-pve52`: alle Karten des Knotens, 12 GB RAM, 4 Kerne, Systemplatte 40 GB und Modellplatte 60 GB auf `local-zfs`, IPs aus D5.
+- [ ] `ansible-playbook … --limit gpu_vms` (Rollen `docker-host` und `gpu-node`, `driver_generation: legacy` = R580).
+  Prüfung in jeder VM: `nvidia-smi -L` → beide Karten. `docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu24.04 nvidia-smi` → beide Karten.
+
+### Task 3.3: Benchmark-Tag (fasst drei Pläne zusammen)
+
+**Wo:** remote, **Strommessung vor Ort** (Messgerät an der Steckdose) · **Planner:** „GPU-Knoten 4: Geschwindigkeitstests (Gate) auf M4000 und P2000“ · ersetzt außerdem den „Benchmark-Tag“ aus IMPLEMENTATION und den Gate-Task 1 des nex-STT-Plans
+
+- [ ] `llama-bench` je Kartentyp: Embedding-Modell, 3–4B Q4 (verifier/signature), 7B Q4. Tokens/s und VRAM messen.
+- [ ] whisper.cpp `large-v3-turbo`, Sprache `de`: Sekunden je 10 s Diktat auf M4000 und P2000. Klärt, ob CC 5.2 überhaupt rechnet. Zusätzlich die Dialekt-Testsätze.
+- [ ] `knaster bench tts` (Piper, CPU).
+- [ ] Strom je Knoten: Leerlauf und Volllast beider Karten (400-W-Netzteil, erwartet etwa 300 W).
+- [ ] Ergebnis eintragen in `catalog/models.yaml` und `sites/knaster/registry.yaml`, in ADR-0006 „M4000 wieder aufnehmen ja/nein“ und in die STT-Entscheidung D131/D133 (nex). Commit.
+  Prüfung: `make validate` → PASS, Placement ordnet jede aktive Rolle einer gemessenen Karte zu.
+
+---
+
+## Phase 4 – Cluster-Grundkonfiguration (erst wenn alle Knoten drin sind)
+
+**Wo:** remote. Jede Aufgabe hier entspricht einer Planner-Aufgabe.
+
+- [ ] **4.1 Benutzer und Token** („PVE-Config: Persönlicher Admin-Benutzer, Rollen und API-Token anlegen“): Admin-Benutzer und Gruppe, root@pam nur als Notfallzugang. Token `monitoring@pve!prom` (PVEAuditor), `healer@pve!knaster` (nur `VM.PowerMgmt` auf GPU-VMs, PLAN §3), `tofu@pve!ops`.
+- [ ] **4.2 2FA** („PVE-Config: Zwei-Faktor-Authentifizierung für Admin-Konten aktivieren“): TOTP für root@pam und Admin. Recovery-Keys offline ablegen.
+- [ ] **4.3 Benachrichtigungen** („PVE-Config: Benachrichtigungen (Notification Center) einrichten“): SMTP-Ziel Büro-Postfach, Matcher für Backup, Fencing und Updates. Testnachricht kommt an.
+- [ ] **4.4 Firewall** („PVE-Config: Firewall auf Datacenter- und Knotenebene einrichten“): IP-Set `admin` (Laptop) und `appsrv08` (.29). Zuerst Allow-Regeln für 8006, 22 und ICMP, **dann** aktivieren. Konsole als Rückfall bereithalten. Prüfung: Weboberfläche vom Laptop ok, von einem anderen Rechner gesperrt.
+- [ ] **4.5 Ordnung** („PVE-Config: Ressourcenpools und Tags festlegen“, „PVE-Config: Standard für neue LXC-Container festlegen“): Pools `infra`, `gpu`, `test`. Tags `gpu`, `infra`, `test`. LXC-Standard: unprivilegiert, Debian-13-Vorlage, Nesting nur für Docker.
+- [ ] **4.6 Zertifikat** („PVE-Config: Web-GUI-Zertifikat festlegen (niedrige Priorität)“): `/etc/pve/pve-root-ca.pem` auf dem Laptop als vertrauenswürdig importieren.
+- [ ] **4.7 Update-Routine** („PVE-Config: Update- und Neustart-Routine festlegen (rollierend, Knoten für Knoten)“): Ablauf in `docs/BETRIEB.md` eintragen (Wartungsmodus, ein Knoten nach dem anderen, GPU-VMs vorher sauber stoppen).
+
+---
+
+## Phase 5 – Backup und Monitoring
+
+### Task 5.1: Proxmox Backup Server
+
+**Wo:** remote, Speicherort vor Ort · **Planner:** „Proxmox: Backup-System überlegen“ (beantwortet PLAN §9, offener Punkt 6)
+
+- [ ] Ziel-Speicher entscheiden. Empfehlung: externer Datenträger oder NAS, **nicht** die Toshiba-Platte „BACKUP“ des Nutzers. PBS als VM `pbs` (vmid 110), Datastore auf dem Ziel.
+- [ ] Jobs: nächtlich Infra-LXC, ops-LXC und GPU-VMs (ohne Modellplatte), Aufbewahrung 7 Tage, 4 Wochen und 6 Monate. Dazu ein wöchentlicher Verify-Job.
+- [ ] **Restore-Test:** Infra-LXC als Kopie zurückspielen.
+  Prüfung: Die Kopie startet, `docker ps` zeigt die Dienste.
+
+### Task 5.2: Infra-LXC mit Monitoring (ein Stack)
+
+**Wo:** remote · **Planner:** „Proxmox: Grafana-Dashboard für den Cluster“, „PVE-Config: Verfügbarkeits-Monitoring und Log-Kontrolle ergänzen“ · **Files:** Modify `deploy/compose/infra/docker-compose.yml`, `deploy/prometheus/prometheus.yml`
+
+- [ ] `deploy/compose/infra` ohne den Dienst `litellm` (D4). Router zeigt auf `http://192.168.100.29:<LiteLLM-Port>`. Image-Tags pinnen (offener Punkt aus IMPLEMENTATION).
+- [ ] LXC `infra` (vmid 101, Nesting, 4 Kerne, 12 GB) mit HA und Replikation (Task 2.2). Compose mit `KNASTER_DRY_RUN=true`.
+- [ ] Prometheus-Ziele: `pve-exporter` (Token aus 4.1), `node-exporter` und `nvidia_gpu_exporter` in den GPU-VMs, Router.
+- [ ] Grafana: Dashboards für Proxmox, Knoten, GPU (Community-JSON) und knaster. Konto `kiosk` mit Rolle Viewer.
+- [ ] Alertmanager an den Router (Healer, Dry-Run) und an n8n `knaster-notify`. Der Workflow wird inaktiv importiert, dann aktiviert.
+  Prüfung: Grafana zeigt alle 5 Knoten und alle GPUs. Ein Test-Alert (`amtool alert add test`) erscheint im Kanal.
+
+### Task 5.3: Kiosk auf pve61
+
+**Wo:** remote, Abnahme vor Ort · **Planner:** „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“
+
+- [ ] Empfehlung: minimaler Kiosk **direkt auf dem Host** (`cage` + `chromium` als eigener Benutzer, systemd-Dienst, Bildschirmschoner aus). Das ist eine bewusste kleine Ausnahme von „Container zuerst“, weil ein Kiosk Bildschirm und Eingabe des Geräts braucht.
+- [ ] URL: Grafana-Playlist im Kiosk-Modus mit Konto `kiosk`.
+  Prüfung: Nach einem Neustart von pve61 zeigt der Bildschirm ohne Eingriff das Dashboard.
+
+---
+
+## Phase 6 – Data Plane
+
+Ersetzt PLAN §8 „1 Data Plane“.
+
+- [ ] **6.1 GPU-Rollen:** `deploy/compose/gpu-llamacpp` in den GPU-VMs nach der Zuordnung aus Task 3.3, also Embedding und Rerank redundant auf zwei Knoten, Chat für verifier und signature. Prüfung: Canary-Checks grün (`knaster` Canary-Prober).
+- [ ] **6.2 STT** (nex-STT-Plan Tasks 2–4): `whisper-server` als zusätzlicher Dienst in der GPU-VM des in Task 3.3 gewählten Knotens. Neuer Slot `stt-de` im Katalog. Port 8178 nur von `192.168.100.29` (Firewall der VM bzw. des Gasts). Prüfung: Von appsrv08 liefert `curl -F file=@probe.wav http://<IP>:8178/v1/audio/transcriptions` deutschen Text, von einem anderen Rechner wird der Zugriff abgelehnt.
+- [ ] **6.3 Lokale Slots in LiteLLM (D4):** `embed-default`, `rerank-default`, `verifier-small` und `signature-extractor` als Modelle im LiteLLM auf appsrv08 eintragen (IP-Literale). Prüfung: `curl http://192.168.100.29:<port>/v1/models` listet die Slots, ein Aufruf je Slot antwortet.
+- [ ] **6.4 Ada-Worker (D3)** · **Planner:** „LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette“
+  - Offene Schritte der Worker-Registry v2 im Repo `mygodel/nex` abschließen.
+  - Gefilterte Ports auf GODE-PC-05/06 freigeben (nex-STT-Plan, Anhang A).
+  - Im knaster-Router `engine: worker-registry` umsetzen: `GET /webhook/llm-worker-list` lesen und einen Worker wählen, der online ist; sonst Eskalation auf tier0.
+  - Tests in `core/tests/test_router.py`:
+    - `test_worker_registry_slot_uses_online_worker`
+    - `test_worker_registry_slot_falls_back_to_tier0_when_list_empty`
+    - `test_worker_registry_slot_falls_back_when_list_unreachable`
+  - Prüfung: `make test` PASS. Live tagsüber geht eine tier1-Anfrage an tier0, nachts an GODE-PC-05.
+
+---
+
+## Phase 7 – Kernpfad
+
+Ersetzt PLAN §8 „2 Kernpfad“.
+
+- [ ] n8n-Workflows `knaster-request`, `knaster-jobs` und `knaster-service-routine` inaktiv importieren und Credentials setzen (`n8n/README.md`).
+- [ ] Ende-zu-Ende: Eine Anfrage läuft über Router, Verifier und Eskalation über den PSE-LiteLLM. Die Dry-Run-Woche beginnt.
+- [ ] Nex-STT-Plan Tasks 5–8: Hermes-Overlay `stt.openai.base_url` mit IP-Literal, Rückfall auf CPU, Abnahme.
+- [ ] Offen und hier zu entscheiden: Langfuse (PLAN §2.4) steht nicht im Infra-Compose.
+
+## Phase 8 – GRP als Testdienst
+
+**Planner:** „Proxmox: GRP als Testservice in einen LXC-Container umziehen“ · **Voraussetzung:** PBS (Task 5.1)
+
+- [ ] LXC `grp-test` (Pool `test`, Docker) mit einer Kopie der GRP-Daten von appsrv08. Die Produktion bleibt unangetastet. Feste IP aus D5, Zugriff nur intern.
+  Prüfung: Die Testinstanz läuft, das Backup des Containers ist im PBS sichtbar.
+
+## Phase 9 – knaster-Ausbau (eigene Pläne folgen)
+
+Die Software-Phasen aus PLAN §8 bleiben inhaltlich gültig und bekommen jeweils einen eigenen Plan:
+- „3 Skills“: Hermes als Skill-Autor
+- „4 Robustheit“: Healer live, Aktionen einzeln freischalten
+- „5 Lifecycle“: QLoRA-Training. Voraussetzung ist die Entscheidung über WSL2 bzw. vLLM auf den Ada-Rechnern nachts (D3, Folgeentscheidung).
+- „6 Portabilität“
+
+Am Ende von Phase 9 wird das Betriebshandbuch abgeschlossen („PVE-Config: Betriebshandbuch und Testvorgehen anlegen“). Das geschieht als Erweiterung von `docs/BETRIEB.md`, nicht als neues Dokument.
+
+---
+
+## Parallelspur NEX (ohne Cluster-Bezug, nach Dringlichkeit)
+
+| # | Planner-Aufgabe | Warum jetzt |
+|---|---|---|
+| P1 | LiteLLM Swarm: PSE-Fix ausrollen (Klartext-Abfluss) | Datenschutz-Leck; Voraussetzung für D4 |
+| P2 | NEX: Startpasswort astreit ändern | Passwort lag lesbar in S:\IT\Nex |
+| P3 | NEX aufräumen: Testinstanz, Schlüsseldateien | `ca.key` liegt ungeschützt |
+| P4 | NEX: Gitea/Portainer-Schritte für Port je Agent und Registry (Teil 1 der Checkliste) | blockiert nex-admin |
+| P5 | nex-admin 1: eigene Tokens anlegen und Stack nex deployen → nex-admin 2 → nex-admin 3 → nex-admin 4 | in dieser Reihenfolge |
+| P6 | NEX - Admin Mail in n8n anlegen und Wächter-Mail testen | nach nex-admin 1 |
+| P7 | Arbeitsplatz-Setup-Skript am eigenen PC testen | unabhängig |
+| P8 | NEX Websuche: eigenes SearXNG im Stack nex | unabhängig |
+
+---
+
+## Zuordnung Epic 7 → Plan (Duplikate zusammengeführt)
+
+| Planner-Aufgabe (exakter Titel) | Im Plan | Planner-Aktion nach Freigabe |
+|---|---|---|
+| Proxmox: pve48 root-Passwort klären und SSH-Schlüssel nachtragen | Task 0.1 | bleibt |
+| PVE-Config: Netzwerk prüfen – Bridge, VLAN-Fähigkeit und NIC-Kompatibilität | Task 0.2 (D5), VLAN später | bleibt, Beschreibung ergänzen |
+| Proxmox: Konfiguration aller Knoten durcharbeiten | aufgeteilt auf 0.1, 1.1–1.3 | schließen mit Verweis auf diesen Plan |
+| PVE-Config: Erst-Update aller Knoten (apt full-upgrade) | Task 1.1 | bleibt |
+| Proxmox: Speicher aller Knoten richtig konfigurieren | D1, Task 1.2 | bleibt |
+| PVE-Config: RAM-Planung je Knoten (Host-Reserve, ZFS-ARC, KSM, Swap) | Task 1.2 (ARC), Task 3.2 (VM-RAM) | **zusammengeführt** in „Speicher …“, schließen |
+| GPU-Knoten 3: Cluster mit QDevice (Container auf appsrv08), NVIDIA-Treiber, GPU-Container | Tasks 2.1, 2.2, 3.1, 3.2 | bleibt (Titel unverändert), Beschreibung: kein QDevice, GPU als VM |
+| GPU-Knoten 4: Geschwindigkeitstests (Gate) auf M4000 und P2000 | Task 3.3 (mit knaster-Benchmark-Tag und STT-Gate) | bleibt, Beschreibung ergänzen |
+| PVE-Config: Persönlicher Admin-Benutzer, Rollen und API-Token anlegen | 4.1 | bleibt |
+| PVE-Config: Zwei-Faktor-Authentifizierung für Admin-Konten aktivieren | 4.2 | bleibt |
+| PVE-Config: Benachrichtigungen (Notification Center) einrichten | 4.3 | bleibt |
+| PVE-Config: Firewall auf Datacenter- und Knotenebene einrichten | 4.4 | bleibt |
+| PVE-Config: Ressourcenpools und Tags festlegen | 4.5 | bleibt |
+| PVE-Config: Standard für neue LXC-Container festlegen | 4.5 | **zusammengeführt** in „Ressourcenpools …“, schließen |
+| PVE-Config: Web-GUI-Zertifikat festlegen (niedrige Priorität) | 4.6 | bleibt |
+| PVE-Config: Update- und Neustart-Routine festlegen (rollierend, Knoten für Knoten) | 4.7 | bleibt |
+| Proxmox: Backup-System überlegen | Task 5.1 | bleibt |
+| Proxmox: Grafana-Dashboard für den Cluster | Task 5.2 (knaster-Stack statt InfluxDB) | bleibt, Beschreibung ändern |
+| PVE-Config: Verfügbarkeits-Monitoring und Log-Kontrolle ergänzen | Task 5.2 (Alertmanager, Healer) | **zusammengeführt** in „Grafana-Dashboard …“, schließen |
+| Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk | Tasks 1.3, 5.3 | bleibt |
+| LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette | Task 6.4 | bleibt, Beschreibung: Registry v2 + knaster-Brücke |
+| Proxmox: GRP als Testservice in einen LXC-Container umziehen | Phase 8 | bleibt |
+| PVE-Config: Betriebshandbuch und Testvorgehen anlegen | Phase 9 (`docs/BETRIEB.md`) | bleibt |
+| P1–P8 (NEX-Aufgaben) | Parallelspur | bleiben |
+
+**Neu anzulegen** (nach Freigabe): „knaster: Entscheidungen D1–D5 bestätigen“ (0.3), „knaster: Site-Dateien an echte Hardware“ (0.4), „knaster: Cluster bilden“ (2.1/2.2), „knaster: GPU-VMs und Resource Mappings“ (3.1/3.2), „knaster: Infra-LXC mit Monitoring“ (5.2), „knaster: STT-Dienst whisper-server“ (6.2), „knaster: lokale Slots in LiteLLM“ (6.3), „knaster: Kernpfad Ende-zu-Ende“ (Phase 7).
+
+**Zuordnung der knaster-Roadmap (PLAN §8):** 0 Fundament → Phasen 0–5 · 1 Data Plane → Phase 6 · 2 Kernpfad → Phase 7 · 3–6 → Phase 9.
+
+**Zuordnung nex-STT-Plan:** Task 0 erledigt · Task 1 → 3.3 · Tasks 2–4 → 6.2 · Tasks 5–8 → Phase 7.