Encoding: Ansible-Projekt und Grundzustand für gn-encoding eingerichtet und verifiziert.

llm-server/encoding/ansible/ verwaltet mit video-encoding.yml und der Rolle
video_encoding den CPU-Only-Grundzustand des gesperrten Kontos gn-encoding
(UID/GID 982): Konto-Identität und Passwortsperre, subordinate ID-Bereiche,
Verzeichnisstruktur, Quadlet-Verzeichnis, Linger, getrennter rootless
Podman-Store sowie verwehrter GPU-Zugriff (keine render/video-Gruppe, kein
Lesezugriff auf /dev/kfd oder DRM-Render-Nodes). Ohne beschlossene
Encoder-Entscheidungen stellt die Rolle sicher, dass kein Workload definiert
ist. Check-Mode und zwei Läufe auf ghostnet-ki: jeweils ok=30 changed=0
failed=0. Preflight, host.yml (2x ok=55 changed=0) und ROCm-Probe
(ok=33 changed=0) nach der Projekt-Aufteilung erneut bestanden.
GNENC-000/001, GNAI-000 und GNAI-013 aktualisiert.

Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>

docs/platform/llm-server/encoding/GNENC-000-DOC_Index.md

@@ -22,6 +22,9 @@
   automatisch ausgeführt werden.
 - Das gesperrte Servicekonto `gn-encoding` mit UID/GID 982 und eigenem
   rootless Podman-Store ist eingerichtet und verifiziert.
+- Das Encoding-Ansible-Projekt unter `llm-server/encoding/ansible/` verwaltet
+  und verifiziert den Encoding-Grundzustand (Konto, Pfade, CPU-Isolation,
+  rootless Store); Check-Mode und Idempotenzlauf meldeten jeweils `changed=0`.
 - Es sind noch kein Encoding-Image, kein Container, keine Quadlet-Unit und kein
   Timer eingerichtet.
 

docs/platform/llm-server/encoding/GNENC-001-PLAN_Architecture.md

@@ -24,7 +24,7 @@ unabhängig konkurrierende Sollzustände auf denselben Host anwenden.
 | Repository | Host- und Deployment-Ansible bleibt im bestehenden Infrastructure-Repository | angenommen |
 | Dokumentation | Encoding liegt unter `docs/platform/llm-server/encoding/` und verwendet die Kennung `GNENC` | umgesetzt |
 | Ausführungsidentität | eigenes gesperrtes Konto `gn-encoding`, UID/GID 982 | eingerichtet und mit rootless Podman geprüft |
-| Containertrennung | eigener rootless Podman-Store und eigener rootverwalteter Quadlet-Pfad | eingerichtet; noch keine Workload definiert |
+| Containertrennung | eigener rootless Podman-Store und eigener rootverwalteter Quadlet-Pfad | eingerichtet; Grundzustand per Ansible verwaltet und verifiziert; noch keine Workload definiert |
 | Rechenressource | Encoding ist nach Betreiberfestlegung rein CPU-basiert und erhält keinen GPU-Zugriff | Planungsentscheidung; reale Last noch nicht gemessen |
 | Parallelität | darf parallel zu AI Production oder AI Testing laufen | Planungsentscheidung |
 | Zeitsteuerung | automatische Ausführung ausschließlich außerhalb der Stoßzeiten, zunächst nachts | Richtung festgelegt; konkrete Uhrzeiten fehlen |
@@ -77,29 +77,39 @@ in GPU-Gruppen und keine `/dev/kfd`- oder `/dev/dri`-Weitergabe.
 
 ## 5. Repository-Grenzen
 
-Vorgesehene Ansible-Struktur:
+Am 19.10.2026 wurde das LLM-Server-Projekt fachlich in ein Hauptverzeichnis pro
+Aufgabe aufgeteilt; die Struktur folgt den Bereichen unter
+`docs/platform/llm-server/`:
 
 ```text
-llm-server/ansible/
-├── playbooks/
-│   ├── host.yml
-│   ├── ai.yml
-│   ├── video-encoding.yml
-│   └── site.yml
-└── roles/
-    ├── host_baseline/
-    ├── podman_runtime/
-    ├── workload_accounts/
-    ├── ai_stack/
-    ├── ai_environment_switch/
-    └── video_encoding/
+llm-server/
+├── host/ansible/                 # gemeinsame Plattform des physischen Servers
+│   ├── playbooks/
+│   │   ├── host.yml              # host_baseline, podman_runtime (shared), workload_accounts, amd_gpu_access
+│   │   ├── preflight.yml
+│   │   ├── bootstrap-deploy-account.yml
+│   │   ├── verify-deploy-access.yml
+│   │   └── verify-rocm-container.yml
+│   └── roles/
+│       ├── host_baseline/
+│       ├── workload_accounts/
+│       ├── amd_gpu_access/
+│       └── rocm_container_probe/
+├── llm/                          # LLM-Stack; entsteht mit dem AI-Vertical-Slice (GNAI-001 Meilenstein 2)
+└── encoding/ansible/             # CPU-Encoding-Workload
+    ├── playbooks/
+    │   └── video-encoding.yml    # video_encoding
+    └── roles/
+        └── video_encoding/
 ```
 
-`host.yml` verwaltet ausschließlich gemeinsame Plattformzustände.
-`ai.yml` darf nur KI-Zustände verändern. `video-encoding.yml` verwaltet nur das
-Konto `gn-encoding`, seine Pfade, Images, Quadlets, Timer und Health Checks. Ein
-späteres `site.yml` kann die unterstützte Gesamtkonfiguration in definierter
-Reihenfolge anwenden.
+`host.yml` verwaltet ausschließlich gemeinsame Plattformzustände; die
+ gemeinsame Rolle `workload_accounts` legt dabei auch das Konto `gn-encoding`
+an. `video-encoding.yml` verwaltet den Encoding-spezifischen Zustand des Kontos
+`gn-encoding` — seine Pfade, Images, Quadlets, Timer und Health Checks — und
+setzt die Host-Baseline voraus. Ein künftiges `ai.yml` im `llm/`-Projekt darf nur
+KI-Zustände verändern. Ein späteres `site.yml` kann die unterstützte
+Gesamtkonfiguration in definierter Reihenfolge anwenden.
 
 Ein separates Quellcode-Repository wird erst benötigt, wenn eigene
 Encoding-Software, eine Oberfläche oder ein Queue-Dienst entwickelt wird. Ein
@@ -126,6 +136,17 @@ dank Linger unabhängig von einer Anmeldung. Der Podman-Store wurde als
 rootless und getrennt von beiden KI-Stores geprüft. Es wurden noch keine Images
 oder Container angelegt.
 
+Am 19.10.2026 wurde das Encoding-Ansible-Projekt unter
+`llm-server/encoding/ansible/` eingerichtet. `video-encoding.yml` verwaltet und
+verifiziert seitdem den Encoding-Grundzustand: Konto-Identität und Passwort-
+sperre, subordinate ID-Bereiche, Verzeichnisstruktur, Quadlet-Verzeichnis,
+Linger und aktiver User-Manager, getrennter rootless Podman-Store sowie die
+CPU-Isolation (keine GPU-Gruppenmitgliedschaft, kein Lesezugriff auf `/dev/kfd`
+oder DRM-Render-Nodes). Solange die offenen Entscheidungen in Abschnitt 7 nicht
+getroffen sind, stellt die Rolle zusätzlich sicher, dass weder Quadlet-Dateien
+noch Container für `gn-encoding` existieren. Check-Mode und zwei
+aufeinanderfolgende Läufe meldeten jeweils `ok=30 changed=0 failed=0`.
+
 ## 7. Offene Entscheidungen
 
 1. Welcher Encoder und welches fest versionierte Container-Image werden genutzt?