Chemenu 2.1.0 - deterministischer Wissenskompiler

Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki:
raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht
tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren
Grenzen in Code durchgesetzt sind statt im Prompt.

Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige
Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses
Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44
Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist.

Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den
Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er
dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs.

Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte.
Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet -
siehe NOTICE.

kb/entities/technologies/Arch Linux.md

@@ -0,0 +1,135 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [operating-system, linux, arch, package-management, encryption, storage]
+created: 2026-07-25
+modified: 2026-08-29
+related: [Docker, Gitea Actions, AUR, makepkg, Aura, GPG, Disk Encryption, LVM, Wine]
+sources: [Source - Arch Linux Cheat Sheet]
+confidence: 0.90
+confidence_base: 0.90
+provenance: sourced
+summary: Schlanke Rolling-Release-Linux-Distribution, genutzt als Basis für CI/CD-Paketbau-Umgebungen und Infrastruktur.
+---
+# Arch Linux
+
+**Typ:** Technology (Betriebssystem)
+
+## Beschreibung
+
+Arch Linux ist eine leichte, Rolling-Release-Linux-Distribution, bekannt für ihre Einfachheit, Minimalismus und benutzerorientiertes Design. In der CI/CD-Infrastruktur wird Arch Linux als Basis-Image für Szenario A (Arch-Paketbau) verwendet.
+
+Arch Linux bietet hervorragende Unterstützung für Disk-Verschlüsselung (dm-crypt/LUKS), LVM und SSD-TRIM-Optimierung und eignet sich ideal für Entwicklungs- und Produktionsumgebungen mit Sicherheitsanforderungen.
+
+## Kerndaten
+
+- **Typ:** Linux-Distribution
+- **Release-Modell:** Rolling Release
+- **Status:** Aktiv
+- **Zweck:** Paketbau-Umgebung
+- **Paketmanager:** pacman
+- **Build-Tool:** [[makepkg]]
+- **AUR-Helfer:** [[Aura]]
+- **Verschlüsselung:** [[Disk Encryption]] (dm-crypt/LUKS)
+
+## Verwendung in der Infrastruktur
+
+### Szenario A: Arch-Paketbau
+- **Basis-Image:** `archlinux:base-devel`
+- **Zweck:** Arch-Linux-Pakete bauen
+- **Herausforderung:** `makepkg` erfordert Root-Rechte
+- **Lösung:** Erstelle im Workflow einen Benutzer `builder` ohne Root-Rechte
+
+### Docker-Image
+```dockerfile
+FROM archlinux:base-devel
+
+# Build-Kontext enthält base-devel-Pakete:
+# - gcc, make, autoconf, automake, binutils, bison, fawk, flex, 
+#   gawk, gettext, groff, libtool, m4, pacman, patch, pkgconf, sed, texinfo
+```
+
+### Workflow-Muster
+```yaml
+jobs:
+  build-arch-package:
+    runs-on: linux-docker
+    container:
+      image: archlinux:base-devel
+    steps:
+      - name: Create builder user
+        run: |
+          useradd -m builder
+          echo "builder ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
+          su - builder -c "cd /workspace && makepkg"
+      
+      - name: Upload artifacts
+        uses: actions/upload-artifact@v3
+        with:
+          name: arch-packages
+          path: /workspace/*.pkg.tar.zst
+```
+
+## Workaround für Root-Beschränkung
+
+### Das Problem
+`makepkg` (Arch's Build-Tool) erfordert traditionell Root für:
+- Installation von Build-Abhängigkeiten
+- Erstellung von Paketen
+- Verwaltung der Paketdatenbank
+
+### Die Lösung
+Der Workflow erstellt einen Benutzer `builder` ohne Root-Rechte und:
+1. Gewährt passwortloses sudo via `/etc/sudoers`
+2. Wechselt zu Benutzer `builder` mit `su - builder`
+3. Führt `makepkg` im Builder-Kontext aus
+4. Lädt entstehende `.pkg.tar.zst`-Dateien als Artifacts hoch
+
+## Warum nicht Alpine?
+
+Für Szenario A ist Alpine Linux nicht geeignet, da:
+1. **Anderes Paketformat:** Alpine verwendet `.apk`-Pakete, nicht Arch's `.pkg.tar.zst`
+2. **Inkompatible Build-Tools:** `makepkg` ist Arch-spezifisch
+3. **musl libc:** Obwohl nicht direkt ein Problem für `makepkg`, ist es nicht kompatibel mit 1Password CLI
+
+## Beziehungen
+
+(Szenario A-Workflows)
+- **Läuft in:** [[Docker]]-Containern
+(für verschiedene Build-Szenarien)
+- **Teil von:** [[Gitea Actions]]-Workflow-Ökosystem
+
+## Hinweis zum Artifact-Upload
+
+### Gitea Actions v4 Einschränkung
+- **Problem:** Gitea Actions v4 unterstützt Artifact-Upload/Download nicht vollständig
+- **Symptom:** GHES (GitHub Enterprise Server)-Fehler bei Verwendung von v4
+- **Workaround:** Verwende `actions/upload-artifact@v3` explizit
+- **Auswirkung:** Szenario A muss auf v3 pinnen, bis Gitea Actions v4 reif ist
+
+## Speicher- und Verschlüsselungsfunktionen
+
+Arch Linux hat robuste Unterstützung für Speichertechnologien:
+
+- **Disk-Verschlüsselung:** Vollständige Unterstützung für [[Disk Encryption]] via dm-crypt und LUKS
+- **LVM:** Integrierte [[LVM]]-Unterstützung (Logical Volume Manager)
+- **SSD TRIM:** Hervorragende [[SSD TRIM]]-Unterstützung, auch für verschlüsselte SSDs
+- **Dateisysteme:** Unterstützt ext4, XFS, Btrfs und andere moderne Dateisysteme mit TRIM
+- **Anwendungskompatibilität:** Unterstützt [[Wine]] zum Ausführen von Windows-Anwendungen, mit Konfigurationsoptionen zur Verhinderung von systemweiten Dateibindungen
+
+## Siehe auch
+
+- CI-VM mit Arch-basierten Builds
+- [[Docker]] - Container-Laufzeit
+- [[Gitea Actions]] - CI/CD-Plattform
+- Alternatives Basis-Image
+Konzept
+- [[AUR]] - Arch User Repository
+- [[makepkg]] - Build-Tool
+- [[Aura]] - AUR-Helfer
+- [[GPG]] - GNU Privacy Guard
+- [[Disk Encryption]] - dm-crypt/LUKS
+- [[LVM]] - Logical Volume Manager
+- [[SSD TRIM]] - SSD-Optimierung
+- [[Source - Arch Linux Cheat Sheet]]
+

kb/entities/technologies/Disk Encryption.md

@@ -0,0 +1,157 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [encryption, storage, security, dm-crypt, luke, linux]
+created: 2026-07-31
+modified: 2026-08-29
+related: [Arch Linux, LVM, SSD TRIM, AUR, makepkg]
+sources: [Source - Arch Linux Cheat Sheet]
+confidence: 0.90
+confidence_base: 0.90
+provenance: sourced
+summary: Schutz ruhender Daten über das Kernelmodul dm-crypt und die LUKS-Schlüsselverwaltung zur transparenten Verschlüsselung von Speichergeräten unter Linux.
+---
+# Disk Encryption
+
+**Typ:** technology
+
+## Beschreibung
+
+Disk-Verschlüsselung bietet Schutz ruhender Daten auf Speichergeräten durch kryptographische Algorithmen. Unter Linux wird dies hauptsächlich durch das **dm-crypt** Kernel-Modul kombiniert mit **LUKS** (Linux Unified Key Setup) zur Schlüsselverwaltung implementiert. Diese Technologie schützt sensible Daten auf SSDs und HDDs vor unbefugtem Zugriff, besonders wichtig für Laptops, externe Laufwerke und Server mit physischen Zugriffsproblemen.
+
+## Kerndaten
+
+- **Zweck:** Verschlüsselung gesamter Festplatte und Partitionen
+- **Status:** Aktiv, weit verbreitet
+- **Kernel-Modul:** dm-crypt (device-mapper Crypto Target)
+- **Schlüsselverwaltung:** LUKS (Linux Unified Key Setup)
+- **Verschlüsselungsalgorithmen:** AES, XTS, Serpent, Twofish, Camellia
+- **Hash-Algorithmen:** SHA-256, SHA-512, SHA-1 (Legacy)
+
+## Komponenten
+
+### dm-crypt
+Das device-mapper Crypto Target, das transparente Verschlüsselung von Block-Geräten bietet. Es arbeitet auf der Block-Geräte-Ebene und verschlüsselt/entschlüsselt Daten im laufenden Betrieb.
+
+**Hauptmerkmale:**
+- Transparente Verschlüsselung/Entschlüsselung
+- Unterstützt mehrere Verschlüsselungsmodi (ECB, CBC, XTS usw.)
+- Funktioniert mit beliebigen Block-Geräten
+- Kann gesamte Festplatten oder einzelne Partitionen verschlüsseln
+
+### LUKS (Linux Unified Key Setup)
+Eine Spezifikation für Disk-Verschlüsselung, die eine standardisierte Methode zur Verwaltung von Verschlüsselungsschlüsseln bietet. LUKS fügt einen Header zum verschlüsselten Gerät hinzu, das die Schlüssel-Slots, Metadaten und Checksummen enthält.
+
+**Hauptmerkmale:**
+- Mehrere Schlüssel-Slots (bis zu 8 in LUKS1, mehr in LUKS2)
+- Schlüssel-Slot-Verwaltung (hinzufügen, entfernen, Passphrasen ändern)
+- Header-Backup und -Wiederherstellung
+- Unterstützung für Schlüsseldateien
+- Anti-Forensik-Funktionen (LUKS2)
+
+## Einrichtung und Konfiguration
+
+### Erstellen einer verschlüsselten Partition
+
+```bash
+# Erstelle LUKS-Container
+cryptsetup luksFormat /dev/sdX1
+
+# Öffne (entsperre) die verschlüsselte Partition
+cryptsetup open /dev/sdX1 crypted
+
+# Erstelle Dateisystem auf entschlüsseltem Gerät
+mkfs.ext4 /dev/mapper/crypted
+
+# Hänge das Dateisystem ein
+mount /dev/mapper/crypted /mnt
+```
+
+### Ändern der Größe verschlüsselter Partitionen
+
+Bei Verwendung von LUKS mit LVM (häufige Konfiguration) ist der Arbeitsablauf zum Größenändern:
+
+1. **Ändere die Größe des zugrunde liegenden Block-Geräts** (z.B. VM-Festplatte erweitern)
+2. **Ändere die Größe des LUKS-Containers**
+3. **Ändere die Größe des LVM Physical Volume**
+4. **Ändere die Größe des LVM Logical Volume**
+5. **Ändere die Größe des Dateisystems**
+
+**Beispiel für ESXi/SCSI:**
+```bash
+# SCSI-Bus neu scannen, um erweiterte Festplatte zu sehen
+echo "1" > /sys/class/block/sdb/device/rescan
+
+# Prüfe Festplattengröße
+fdisk -l /dev/xyz
+
+# Ändere Größe des LUKS-Containers
+cryptsetup status crypted
+cryptsetup resize crypted
+cryptsetup status crypted
+
+# Ändere Größe des LVM PV (siehe [[LVM]])
+pvresize /dev/mapper/crypted
+```
+
+## SSD-TRIM-Unterstützung
+
+SSD TRIM ermöglicht es dem Betriebssystem, der SSD mitzuteilen, welche Blöcke nicht mehr in Gebrauch sind und verbessert damit Leistung und Haltbarkeit. Bei verschlüsselten Festplatten erfordert TRIM-Unterstützung eine sorgfältige Konfiguration.
+
+### Aktivieren von TRIM auf verschlüsselten SSDs
+
+**Wichtig:** Das Zulassen von discard (TRIM) auf verschlüsselten Geräten kann Informationen über verwendete Blöcke verraten. Bedenke die Sicherheitsauswirkungen.
+
+**Optionen:**
+1. **Erlaube discard auf LUKS-Ebene:**
+   ```bash
+   cryptsetup reencrypt --encrypt --reduce-device-size 16M --allow-discards /dev/sdX
+   ```
+
+2. **Verwende fstrim auf gemountettem Dateisystem:**
+   ```bash
+   fstrim /mount/point
+   ```
+
+3. **Konfiguriere periodisches TRIM:**
+   ```bash
+   # Aktiviere systemd-Timer
+   systemctl enable fstrim.timer
+   systemctl start fstrim.timer
+   ```
+
+**Referenz:** https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)
+
+## Beziehungen
+
+- **Verwendet mit:** [[Arch Linux]] (häufige Distribution für Verschlüsselung)
+- **Ergänzt:** [[LVM]] (Logical Volume Manager)
+- **Verbessert durch:** [[SSD TRIM]] (Leistungsoptimierung)
+und anderen Systemen
+Ansatz
+
+## Sicherheitsaspekte
+
+### Best Practices
+
+1. **Verwende starke Passphrasen:** Lange, komplexe Passphrasen mit hoher Entropie
+2. **Backup LUKS-Header:** `cryptsetup luksHeaderBackup /dev/sdX1 --header-backup-file header.img`
+3. **Mehrere Schlüssel-Slots:** Speichere Backup-Schlüssel in separaten Slots
+4. **Schlüsseldateien:** Erwäge Schlüsseldateien für headless-Systeme
+5. **Vermeide discard:** Für maximale Sicherheit, deaktiviere TRIM auf verschlüsselten Geräten
+
+### Einschränkungen
+
+- **Schützt nicht vor:** Evil-Maid-Angriffen, Keyloggern, Schulter-Blicken
+- **Leistungs-Overhead:** Verschlüsselung/Entschlüsselung fügt CPU-Overhead hinzu (typischerweise 5-10%)
+- **Wiederherstellung:** Verlorene Passphrase = verlorene Daten (kein Hintertür)
+
+## Siehe auch
+
+- [[LVM]] - Logical Volume Manager
+- [[SSD TRIM]] - TRIM-Optimierung für SSDs
+- [[Arch Linux]] - Distribution mit hervorragender Verschlüsselungsunterstützung
+- [[Source - Arch Linux Cheat Sheet]]
+- https://wiki.archlinux.org/title/Dm-crypt
+- https://wiki.archlinux.org/title/LUKS
+- https://gitlab.com/cryptsetup/cryptsetup

kb/entities/technologies/Docker.md

@@ -0,0 +1,136 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [containers, containerization, docker, runtime]
+created: 2026-07-25
+modified: 2026-09-01
+related: [Act Runner, Gitea Actions]
+sources: [Source - Docker Cheatsheet]
+confidence: 0.95
+confidence_base: 0.95
+provenance: sourced
+summary: Container-Plattform als Industriestandard für CI/CD-Infrastruktur, mit BuildKit-Daemon und entfernter Docker-Verwaltung über SSH.
+---
+# Docker
+
+**Typ:** Technology (Container Platform)
+
+## Beschreibung
+
+Docker ist die Industrie-Standard-Container-Plattform, die in der gesamten CI/CD-Infrastruktur für Container-Laufzeit, Build-Ausführung und Service-Bereitstellung verwendet wird. Sie bietet die Grundlage für die Ausführung von Containern auf `ci-runner.example.net` und `docker-host.example.net`.
+
+## Kerndaten
+
+- **Typ:** Container-Plattform
+- **Status:** Aktiv
+- **Zweck:** Container-Laufzeit und Build-Ausführung
+- **Lizenz:** Apache 2.0
+- **Geschrieben in:** Go
+
+## Architektur in der Infrastruktur
+
+### Auf ci-runner.example.net
+- **Docker-Daemon:** Docker-Service auf Host-Ebene
+- **Runner-Container:** `act_runner` läuft als Docker-Container
+- **BuildKit-Daemon:** `moby/buildkitd` läuft als Docker-Container auf Port 1234
+- **Job-Container:** Kurzlebige Container pro CI-Job in isolierten Bridge-Netzen
+
+### Auf dem Docker-Host
+- **Legacy-Container:** Werden von `ci-runner.example.net` aus remote verwaltet
+- **Docker-Daemon:** Standard Docker-Service
+- **Zugriff:** Via SSH aus CI-Workflows
+
+## Konfigurationsdetails
+
+### Docker-Socket-Anbindung
+- **Ort:** `/var/run/docker.sock`
+- **Angebunden an:** `act_runner`-Container (für BuildKit-Verwaltung)
+- **NICHT angebunden an:** Job-Container (Sicherheit: vermeidet DinD-Risiken)
+
+### Network-Modi
+- **Runner:** `host`-Network-Modus für Cache-Anbindung
+- **Jobs:** Isolierte temporäre Bridge-Netze (leeres `container.network`)
+- **BuildKit:** `bridge`-Netz mit Port 1234 freigegeben
+
+## Fernverwaltung
+
+### SSH-basierte Docker-Kontrolle
+CI-Workflows auf `ci-runner.example.net` verwalten Docker auf `docker-host.example.net`:
+
+```bash
+# Set Docker host to remote via SSH
+export DOCKER_HOST=ssh://ci@192.0.2.10
+
+# Execute Docker commands remotely
+docker ps
+docker-compose up -d
+```
+
+### Authentifizierung
+- **SSH-Schlüssel:** Ed25519-Schlüssel aus 1Password "CI-CD"-Vault
+- **Benutzer:** ci
+- **Methode:** Standard-SSH-Authentifizierung
+
+## Sicherheitsaspekte
+
+### Docker-in-Docker (DinD) - Vermeidung
+Traditioneller DinD-Ansatz:
+```bash
+# NOT USED - Security risk
+docker run -v /var/run/docker.sock:/var/run/docker.sock ...
+```
+
+**Stattdessen:**
+- BuildKit-Daemon läuft separat
+- Job-Container verbinden sich via TCP
+- Kein Zugriff auf Host Docker-Socket in Jobs
+
+### Vorteile
+- **Isolation:** Job-Container können nicht auf Host Docker zugreifen
+- **Sicherheit:** Reduzierte Angriffsfläche
+- **Kontrolle:** Zentralisierte Build-Infrastruktur
+
+## Beziehungen
+
+- **Verwendet von:** [[Act Runner]], [[Gitea Actions]]
+- **Teil von:** Kerninfrastruktur
+
+## Version und Kompatibilität
+
+### Kompatibilitätshinweise
+- **Debian 13:** Exzellente Docker-Unterstützung (Referenzplattform)
+- **Arch Linux:** Gute Docker-Unterstützung für Build-Szenarien
+- **Alpine Linux:** Unterstützt, aber eingeschränkt durch musl libc für einige Tools
+
+### 1Password CLI-Kompatibilität
+- **Funktioniert:** glibc-basierte Distributionen (Debian, Arch)
+- **Funktioniert nicht:** musl libc-basierte Distributionen (Alpine) mit Exitcode 127
+- **Auswirkung:** Container-Build-Jobs verwenden `debian:trixie-slim` anstelle von Alpine
+
+## Volume-Verwaltung und Fehlerbehebung
+
+### Overlay-FS-Auflösung
+Bei der Fehlerbehebung von Backup-Problemen, gesperrten Dateien oder Berechtigungsproblemen können Sie Overlay-Dateisystem-Verzeichnisse ihren Containern zuordnen:
+
+```bash
+for container in $(docker ps --all --quiet --format '{{ .Names }}'); do
+   echo "$(docker inspect $container --format '{{.GraphDriver.Data.MergedDir }}' | grep -Po '^.+?(?=/merged)'  ) = $container"
+done
+```
+
+**Ausgabe:** Listet alle Overlay-Verzeichnisse unter `/var/lib/docker/overlay2/` mit ihren entsprechenden Container-Namen auf.
+
+**Anwendungsfall:** Identifiziert, welcher Container ein bestimmtes Overlay-Verzeichnis besitzt (z. B. `/var/lib/docker/overlay2/768... = starwars`).
+
+## Siehe auch
+
+- Primärer Docker-Host
+- Legacy Docker-Host
+- Build-System mit Docker
+- [[Act Runner]] - Docker-Container
+- [[Gitea Actions]] - CI/CD mit Docker
+- Verwendet Docker als Laufzeit
+concept
+concept
+- [[Source - Docker Cheatsheet]]
+

kb/entities/technologies/GRUB.md

@@ -0,0 +1,45 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: []
+created: 2026-08-02
+modified: 2026-08-29
+related: []
+sources: []
+confidence: 0.50
+confidence_base: 0.50
+provenance: general
+summary: GNU-Bootloader für Linux-Systeme; übernimmt das Laden des Kernels und die Boot-Konfiguration.
+---
+# GRUB
+
+**Typ:** technology
+
+## Beschreibung
+
+GRUB (GNU GRUB) ist der Standard-Bootloader für Linux-Systeme und verwaltet das initiale Kernel-Laden und die Boot-Zeit-Konfiguration. Es unterstützt Multi-Boot-Umgebungen und komplexe Partitionierungsschemas.
+
+## Kerndaten
+
+- **Zweck:** TODO
+- **Status:** TODO
+- **Version:** TODO
+- **Sprache/Technik:** TODO
+- **Verantwortlich:** TODO
+- **Repository:** TODO
+
+## Beziehungen
+
+- **Bezogen auf:** TODO
+
+## Details
+
+TODO
+
+## Historie
+
+- 2026-08-02 - Seite via wikitool erstellt
+
+## Siehe auch
+
+- TODO

kb/entities/technologies/Gitea Actions.md

@@ -0,0 +1,285 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [ci-cd, workflows, automation, gitea]
+created: 2026-07-25
+modified: 2026-09-01
+related: [Gitea, Act Runner, Docker, Gitea MCP Server, Ambient Environment Dependency, CI Integration]
+sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31, Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]
+confidence: 0.90
+confidence_base: 0.90
+provenance: sourced
+summary: CI/CD-Workflow-Plattform, in Gitea integriert; fuehrt YAML-Workflows ueber den Act Runner aus, samt Release-Pipeline, belegten paths-ignore-Filtern und einem nightly.yml-Drift-Check, dessen schedule-Ausloesung seit 2026-09-01 (Run 90) belegt ist
+---
+# Gitea Actions
+
+**Typ:** Technology (CI/CD Platform)
+
+## Beschreibung
+
+Gitea Actions ist das CI/CD-Workflow-Automatisierungssystem, das in Gitea integriert ist. Es ermöglicht die Definition von Build-, Test- und Deployment-Pipelines als Code in YAML-Workflow-Dateien. Die Workflows werden vom [[Act Runner]] ausgeführt.
+
+## Kerndaten
+
+- **Typ:** CI/CD-Workflow-Automatisierung
+- **Status:** Aktiv (Stand 2026-07-12)
+- **Runner:** [[Act Runner]]
+- **Workflow-Syntax:** GitHub Actions kompatibles YAML
+
+## Architektur
+
+### Workflow-Ausführung
+1. **Auslöser:** Push, PR, Zeitplan oder manuelle Auslösung
+2. **Runner-Auswahl:** Basierend auf Routing-Labels (`linux-docker`, `container-builder`, `k3s-deploy`)
+3. **Job-Container:** Isoliertes Bridge-Netz pro Job
+4. **Secret-Injektion:** Runtime-Abruf aus 1Password
+5. **Cache:** Built-in Actions Cache Server auf Port 8088
+
+### Schlüsselkomponenten
+- **Runner:** `act_runner`-Docker-Container im Host-Network-Modus
+- **Cache Server:** Built-in, zugänglich via statische IP-Konfiguration
+- **Job-Container:** Kurzlebige Docker-Container pro Workflow-Job
+- **Actions:** Wiederverwendbare Workflow-Komponenten
+
+## Konfiguration
+
+### Cache-Konfiguration
+```yaml
+# In act_runner config.yaml
+cache:
+  enabled: true
+  host: "192.0.2.10"  # static IP of ci-runner.example.net
+  port: 8088
+```
+
+**Wichtig:** `cache.host` ist die Adresse, die Job-Container verwenden, um den Cache-Server zu erreichen, nicht die Listen-Adresse des Servers.
+
+### Workflow-Beispiel
+```yaml
+name: Build and Deploy
+
+on: [push]
+
+permissions:
+  packages: write  # Required for registry pushes
+
+jobs:
+  build:
+    runs-on: linux-docker
+    steps:
+      - uses: actions/checkout@v4
+      
+      - name: Load secrets
+        uses: 1password/load-secrets-action@v2
+        with:
+          vault: CI-CD
+        env:
+          REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}
+      
+      - name: Build with BuildKit
+        run: |
+          docker buildx create --driver remote tcp://$HOST_IP:1234
+          docker buildx build --push ...
+```
+
+## Validierte Szenarien
+
+### Szenario A: Arch-Paketbuilds
+- **Basis-Image:** `archlinux:base-devel`
+- **Herausforderung:** `makepkg` benötigt Root
+- **Lösung:** Erstelle non-Root-Benutzer `builder` on-the-fly
+- **Artefakte:** `actions/upload-artifact@v3` (v4 nicht vollständig unterstützt)
+- **Hinweis:** Gitea Actions v4 hat begrenzte Artefakt-Unterstützung
+
+### Szenario B: Container-Builds
+- **Basis-Image:** `debian:trixie-slim` (Standard)
+- **Vermeidet:** Alpine Linux (musl libc inkompatibel mit 1Password CLI)
+- **Verbindung:** Dynamische IP-Erkennung via `ip route | awk '/default/ { print $3 }'`
+
+### Szenario C: K3s-Deployments
+-Cluster
+- **Authentifizierung:** Kubeconfig aus 1Password-Vault
+- **Muster:** `kubectl wait --for=delete pod -l ...` für zuverlässige Ressourcenverwaltung
+
+### Szenario D: Test- und Release-Pipeline eines Python-Werkzeugs
+
+- **Basis-Image:** `debian:trixie-slim`, trägt python3 3.13[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
+- **Erster Schritt:** `apt-get install nodejs`, **vor** dem Checkout - Voraussetzung für jede
+  JavaScript-Action, siehe [[Act Runner]][^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
+- **Checkout:** `actions/checkout@v7`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
+- **Release:** `${{ gitea.token }}` genügt für das Anlegen von Release und Tag sowie für
+  Asset-Uploads; kein Actions-Secret mit `write:repository`
+  nötig[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
+- **Auslöser des Release-Workflows:** eine Änderung an der `VERSION`-Datei, siehe
+  [[KB Stack Versioning]]
+
+### Läufe eines Workflows auf ihre Ursache prüfen
+
+Bei einem privaten Repository lässt sich der Lauf-Zustand nicht anonym über HTTP feststellen;
+[[Gitea]] antwortet einem anonymen Aufrufer identisch mit `404`, ob das Repository unsichtbar
+oder nicht vorhanden
+ist[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Läufe, ihr
+Ausgang und ihre Logs werden über den [[Gitea MCP Server]] gelesen.
+
+## Auslöser filtern
+
+`paths-ignore` schließt Pfade von einem Workflow aus. Für die Filterlisten gelten hier drei
+Festlegungen, die alle Ableitungen aus Undokumentiertem
+vermeiden[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]:
+
+- **Keine YAML-Anker**, um eine Liste zwischen zwei Workflows zu teilen. GitHubs Parser lehnt
+  Anker ab, und für Gitea ist nicht dokumentiert, dass er sie annimmt. Die Liste steht lieber
+  zweimal.
+- **Keine negierten Muster** wie `!**/CONTRACT.md`. Gitea dokumentiert die Unterstützung
+  negierter Filtermuster nicht.
+- **Die Muster scheitern offen.** Alles Unvorhergesehene löst weiterhin einen Lauf aus; das ist
+  die richtige Richtung für einen Filter, dessen Auswertung nicht bewiesen ist.
+
+Dass die Filter greifen, ist seit 2026-08-31 beobachtet und nicht mehr angenommen. Commit
+`f916376` war ein reiner Content-Publish - `kb/index.md`, `kb/log.md`, `kb/provenance.md`, acht
+Seiten unter `kb/*/**` und eine Datei unter `raw/notes/`, sämtlich auf der Ignore-Liste - und
+erzeugte zu seiner `head_sha` keinen einzigen Lauf[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]:
+
+| Commit | Inhalt | Läufe |
+|---|---|---|
+| `6f54c31` | Stack (1.1.0) | 59 |
+| `adfa220` | Stack (1.1.1) | 60, 61 |
+| `f916376` | nur `kb/` und `raw/` | keine |
+| `40adbb7` | Stack (1.2.0) | 62, 63 |
+
+Die Stack-Commits davor und danach erzeugten je zwei Läufe, CI und Release, weil `VERSION` sich
+bewegt hatte. Der Unterschied ist also der Filter und kein untätiger Runner; Gitea wertet diese
+Muster wie GitHub aus[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]. Der Befund steht im Kommentarkopf von
+`.gitea/workflows/ci.yml`, damit er nicht erneut für eine Annahme gehalten wird, und schloss
+Gitea-Issue #11[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
+
+Als Folgewirkung bleibt die stärkste Hälfte der Begründung für den nächtlichen Drift-Check
+(Issue #9) stehen: Weil der Filter greift, läuft `lint --fail-on-error` bei einem
+Content-Publish tatsächlich nicht mehr. Ob dieser Gitea-Build `on: schedule` überhaupt
+auswertet, ist davon unberührt - ~~und weiter offen~~ (Stand 2026-08-31; seit 2026-09-01
+geklärt, siehe unten)[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
+
+`.gitea/workflows/nightly.yml` (seit 2026-08-31) implementiert diesen Drift-Check: `on:
+schedule` (`17 3 * * *` UTC) plus `workflow_dispatch`, kein Push-Trigger, dieselbe Runner-Form
+wie `ci.yml`. Diese Gitea-Instanz läuft **1.26.1** - weit über der 1.20-Version, die
+Actions-Schedules einführte, was den Trigger plausibel, aber nicht bewiesen
+macht[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+Zwei `workflow_dispatch`-Testläufe bestätigten zunächst nur, dass der Job selbst durchläuft
+(Run 85, alle sieben Schritte grün) - ~~keiner davon ist ein `schedule`-Lauf. **Offen bleibt
+weiterhin**, ob der Cron-Trigger auf diesem Stand tatsächlich feuert - frühestens ab
+2026-09-01 03:17 UTC zu beobachten, an einem Lauf mit `"event":"schedule"`, nicht an einem
+weiteren `workflow_dispatch`-Erfolg~~ (Stand
+2026-08-31)[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+
+**Bestätigt seit 2026-09-01:** Run 90 ist der erste Lauf der Repository-Historie mit
+`"event":"schedule"` - gestartet `2026-09-01T03:17:35Z`, exakt zur konfigurierten Cron-Zeit,
+abgeschlossen `03:17:38Z`, alle sieben Schritte grün. Dieser Gitea-1.26.1-Stand wertet
+`on: schedule` auf dem Default-Branch also tatsächlich aus; der im Issue vorgesehene externe
+Fallback (ein externer Cron gegen die Actions-API) war nicht nötig.
+Gitea-Issue #9 ist damit
+geschlossen.
+
+## Bekannte Probleme und Lösungen
+
+### Der Job-Container ist keine konfigurationsfreie Maschine (Beobachtet 2026-08-31)
+
+**Beobachtung:** `actions/checkout@v7` legt im Job-Container selbst eine globale
+git-Konfiguration an. Aus dem Log von Lauf 79 des Chemenu-CI (damals `llm-wiki-test1`):
+`Copying '/root/.gitconfig' to '/tmp/<uuid>/.gitconfig'` und `Temporarily overriding
+HOME='/tmp/<uuid>' before making global git config changes`. Ein `git config --global --add
+safe.directory` im eigenen Setup-Schritt schreibt zusätzlich
+hinein[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31].
+
+**Warum das zählt:** Ein CI-Container gilt gern als neutrale Umgebung - "hier ist nichts
+konfiguriert, also fällt auf, was von der Maschine gelesen wird". Für git stimmt das nicht mehr.
+Ein Test oder Guard, der sich darauf verlässt, hört still auf zu greifen: kein roter Lauf, keine
+Meldung, nur eine Prüfung, die nichts mehr prüft.
+
+**Konsequenz:** Wer Umgebungsunabhängigkeit prüfen will, stellt sie explizit her
+(`GIT_CONFIG_GLOBAL=/dev/null`, eigenes `HOME`) statt sie vom Container zu erwarten. Siehe
+[[Ambient Environment Dependency]].
+
+### `doctor` prüft eine Instanz, ein Checkout ist noch keine (Behoben 2026-08-31)
+
+**Problem:** Der erste `workflow_dispatch`-Lauf von `nightly.yml` scheiterte am `doctor`-Schritt:
+`FAIL git-identity: 'git config user.name' is not set` und `FAIL skills: No skills published
+yet`[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+
+**Grundursache:** `doctor` fragt, ob eine *arbeitsfähige Instanz* korrekt konfiguriert ist, nicht
+ob ein Checkout vollständig ist. `.agents/skills/` und `.claude/skills/` sind generiert und
+bewusst nicht committet (siehe `instructions/bootstrap.md`), existieren also erst nach
+`wikitool instructions sync`; und der Job-Container hat keine git-Konfiguration, unabhängig
+davon, ob `WIKI_AUTHOR` gesetzt ist - das deckt nur die separate `author`-Prüfung, nicht
+`git-identity`[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+Weil `doctor` den Job abbrach, wurde `instructions verify` nie erreicht - der Fehlschlag stand
+vor dem eigentlichen Prüfzweck des Laufs, nicht in
+ihm[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+
+**Lösung:** Vor `doctor` eine echte git-Identität setzen (`git config --global user.name/
+user.email`) und `tools/wikitool instructions sync` laufen lassen - ein Mechanismus deckt beide
+Prüfungen ab, statt zwei separate (git-Identität, `WIKI_AUTHOR`) je eine. Jeder Workflow, der
+`doctor` oder `instructions verify` auf einem frischen Checkout aufruft, braucht denselben
+Bootstrap[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+
+### JavaScript-Actions ohne `node` im Job-Image (Behoben 2026-08-30)
+
+**Problem:** Jeder Lauf scheiterte an `actions/checkout` mit
+`exec: "node": executable file not found in $PATH` und `exitcode '127'`.
+
+**Grundursache:** act_runner führt JavaScript-Actions mit `node` im Job-Container aus; das
+gepinnte `debian:trixie-slim` bringt keins mit. Das Runner-Label `linux-docker` war nie das
+Problem - es routete und startete den Container von Anfang
+an[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
+
+**Lösung:** `nodejs` als erster Schritt vor dem Checkout installieren, Checkout auf
+`actions/checkout@v7` heben. Ausführlich auf der Seite [[Act Runner]].
+
+### Actions Cache Server-Konnektivität (Behoben 2026-07-12)
+**Problem:** `setup-go@v6` und andere Cache-verwendende Actions zeigten Timeout bei Versuch, den Cache-Server unter `172.18.0.2:39329` (interne Docker-Bridge-IP) zu erreichen.
+
+**Grundursache:** Runner-Container befand sich in seinem eigenen Bridge-Netz (`act_runner_default`), während sich jeder Job-Container in einem isolierten temporären Bridge-Netz befand. Diese Netze konnten ohne Host-Routing nicht miteinander kommunizieren.
+
+**Lösung:**
+1. Änderte Runner-Container zu `network_mode: host`
+2. Setzte `cache.host` auf statische IP `192.0.2.10`
+3. Cache-URL automatisch als `ACTIONS_CACHE_URL` injiziert
+4. Vollständiger Neustart erforderlich: `docker compose down && docker compose up -d`
+
+## Beziehungen
+
+- **Teil von:** [[Gitea]]-Ökosystem
+- **Ausgeführt von:** [[Act Runner]]
+- **Nutzt:** [[Docker]] für Container
+- **beobachtet über:** [[Gitea MCP Server]]
+- **zeigte:** [[Ambient Environment Dependency]]
+- **implementiert:** [[CI Integration]]
+
+## Vorteile
+
+- GitHub Actions kompatible Syntax
+- Selbstgehostet, volle Kontrolle
+- Integriert mit Gitea-Ökosystem
+- Zero-Trust-ready mit 1Password-Integration
+- Keine Vendor-Lock-in
+
+## Siehe auch
+
+- [[Gitea]] - Git-Dienst
+- [[Act Runner]] - Runner-Implementierung
+- Host-VM
+- Secrets-Verwaltung
+- Build-System
+- [[Docker]] - Container-Plattform
+concept
+- [[Gitea MCP Server]]
+- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
+- [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
+- [[Ambient Environment Dependency]]
+- [[CI Integration]]
+
+## Fußnoten
+
+[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
+[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]: [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
+[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31]: [[Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]]
+[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]: [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]

kb/entities/technologies/Gitea.md

@@ -0,0 +1,91 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [git, version-control, self-hosted, ci-cd]
+created: 2026-07-25
+modified: 2026-08-29
+related: [Act Runner, Gitea Actions]
+sources: [Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
+confidence: 0.90
+confidence_base: 0.90
+provenance: sourced
+summary: Selbst gehosteter Git-Dienst auf docker-host.example.net; bietet Repository-Verwaltung und CI/CD über Gitea Actions mit Act Runner.
+---
+# Gitea
+
+**Typ:** Technology (Git Service)
+
+## Beschreibung
+
+Gitea ist ein selbst gehosteter Git-Dienst, der Quellcode-Verwaltung und CI/CD-Funktionen durch Gitea Actions bietet. Die Instanz läuft auf `docker-host.example.net` unter http://192.0.2.10:3000.
+
+## Kerndaten
+
+- **Typ:** Git-Dienst / Quellcode-Verwaltung
+- **Status:** Aktiv
+- **Instanz-URL:** http://192.0.2.10:3000
+- **Lizenz:** MIT
+- **Geschrieben in:** Go
+
+## Funktionen
+
+### Kernfunktionen
+- Git-Repository-Hosting
+- Issue-Tracking
+- Pull Requests
+- Wiki
+- Projektmanagement
+
+### CI/CD-Funktionen (via Gitea Actions)
+- Workflow-Ausführung via [[Act Runner]]
+- Actions-Marketplace
+- Container Registry
+- Secrets-Verwaltung
+
+## Konfiguration
+
+### app.ini-Einstellungen
+```ini
+[actions]
+ENABLE_ACTIONS_TOKEN = true
+```
+
+Dies ermöglicht Workflows, `${{ gitea.token }}` zur Authentifizierung zu verwenden.
+
+### Runner-Registrierung
+- **Token:** `GITEA_RUNNER_REGISTRATION_TOKEN`
+- **Runner-Name:** ci-vm-runner
+
+## Beziehungen
+
+- **Verwendet Runner:** [[Act Runner]]
+- **Bietet:** [[Gitea Actions]]-CI/CD-Funktionalität
+- **Verbunden mit:** Container Registry für Image-Speicherung
+
+## Container Registry
+
+- **Zweck:** Speichert Container-Images, die von CI/CD-Workflows erstellt werden
+- **Authentifizierung:** Verwendet `${{ gitea.token }}` mit `packages: write`-Berechtigung
+- **Zugriffsmuster:** Workflows pushen Images während des Build-Prozesses
+
+## Workflow-Berechtigungen
+
+Erforderlich für Registry-Pushes:
+```yaml
+permissions:
+  packages: write
+```
+
+## Siehe auch
+
+- Dedizierte CI-VM
+- Host-System
+- [[Act Runner]] - Gitea Actions Runner
+- [[Gitea Actions]] - CI/CD-Plattform
+concept
+- Dotfile-Manager mit Gitea für Repository-Hosting
+- System, das YADM-Repository beherbergt
+- Workstation mit YADM und Gitea
+- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
+- [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
+

kb/entities/technologies/Go.md

@@ -0,0 +1,135 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [programming-language, compiled, backend, systems]
+created: 2026-07-25
+modified: 2026-08-29
+related: [ha-core, gdeploy, plugnburn-edl, BCDModule, goresponsiveness, hacs-e3dc]
+sources: []
+confidence: 0.95
+confidence_base: 0.95
+provenance: general
+summary: Quelloffene Programmiersprache von Google für Systemprogrammierung und Backend-Dienste, mit eingebauter Nebenläufigkeit über Goroutines und Channels.
+---
+# Go
+
+**Typ:** Technology (Programming Language)
+
+## Beschreibung
+
+Go (häufig als Golang bezeichnet) ist eine Open-Source-, statisch typisierte, kompilierte Programmiersprache, die von Google entwickelt wurde. Sie ist für die Erstellung einfacher, schneller und zuverlässiger Software konzipiert.
+
+Go ist besonders gut geeignet für Systemprogrammierung, Backend-Services und nebenläufige Anwendungen aufgrund seiner integrierten Unterstützung für Nebenläufigkeit (Goroutines und Channels), schnelle Kompilierung und effiziente Laufzeit.
+
+## Kerndaten
+
+- **Typ:** Programmiersprache
+- **Paradigma:** Prozedural, nebenläufig
+- **Erste Erscheinung:** 2009
+- **Entworfen von:** Robert Griesemer, Rob Pike, Ken Thompson bei Google
+- **Lizenz:** BSD-ähnlich
+- **Website:** https://golang.org
+- **Aktuelle stabile Version:** 1.22+ (Stand 2026)
+
+## Beziehungen
+
+- **Verwendet von:** [[ha-core]], [[gdeploy]], [[plugnburn-edl]], [[BCDModule]], [[goresponsiveness]], [[hacs-e3dc]]
+- **Konkurriert mit:** Rust, Java, C++, Python (für Backend)
+- **Beeinflusst von:** C, Pascal, Oberon
+- **Beeinflusst:** Viele moderne Sprachen
+
+## Schlüsselfunktionen
+
+### Sprachfunktionen
+
+- **Statische Typisierung** - Typsicherheit mit Typinferenz
+- **Nebenläufigkeit** - Goroutines (leichte Threads) und Channels
+- **Garbage Collection** - Automatische Speicherverwaltung
+- **Interfaces** - Implizite Implementierung (Duck Typing)
+- **Pakete** - Modulare Organisation
+- **Tooling** - Built-in Build-, Test-, Format- und Dokumentations-Tools
+
+### Leistung
+
+- Schnelle Kompilierung
+- Effiziente Ausführung (native Binärdateien)
+- Niedrige Latenz
+- Gut für CPU-intensive und I/O-intensive Aufgaben
+
+### Ökosystem
+
+- **Pakerverwaltung:** Go Modules (seit Go 1.11)
+- **Standardbibliothek:** Umfangreich und gut konzipiert
+- **Pakete von Drittanbietern:** Wachsendes Ökosystem auf pkg.go.dev
+
+## Anwendungsfälle
+
+Basierend auf der Repository-Struktur wird Go verwendet für:
+
+1. **Hausautomation** - [[ha-core]]
+2. **Deployment-Tools** - [[gdeploy]]
+3. **EDL-bezogene Tools** - [[plugnburn-edl]], [[andybalholm-edl]]
+4. **Modulsysteme** - [[BCDModule]]
+6. **Performance-Testing** - [[goresponsiveness]]
+
+## Vor- und Nachteile
+
+### Vorteile
+
+- Schnelle Kompilierung und Ausführung
+- Exzellente Standardbibliothek
+- Integrierte Unterstützung für Nebenläufigkeit
+- Einfache Syntax
+- Starkes Tooling-Ökosystem
+- Plattformübergreifende Kompilierung
+- Gut für Microservices und CLI-Tools
+
+### Nachteile
+
+- Weniger flexibel als dynamisch typisierte Sprachen
+- Keine Generics (bis Go 1.18)
+- Error Handling kann verbose sein
+- Begrenzte Meta-Programmierungsfunktionen
+
+## Lernressourcen
+
+- **Offiziell:** https://golang.org/doc
+- **Tour:** https://go.dev/tour/
+- **Effective Go:** https://go.dev/doc/effective_go
+- **Blog:** https://go.dev/blog/
+
+## Toolchain
+
+- `go build` - Pakete und Abhängigkeiten kompilieren
+- `go test` - Tests ausführen
+- `go fmt` - Code formatieren
+- `go mod` - Modul-Verwaltung
+- `go doc` - Dokumentation
+- `go run` - Kompilieren und ausführen
+- `godep` - Abhängigkeits-Tool (älter)
+
+## Best Practices
+
+1. **Formatierung:** Immer `go fmt` verwenden
+2. **Testen:** Tests mit dem Testing-Paket schreiben
+3. **Error Handling:** Explizite Fehlerprüfung
+4. **Nebenläufigkeit:** Channels für Kommunikation verwenden
+5. **Interfaces:** Kleine, fokussierte Interfaces entwerfen
+
+## Historie
+
+- [2009] - Erste öffentliche Veröffentlichung
+- [2012] - Go 1.0 veröffentlicht
+- [2015] - Go 1.5 mit Self-Hosting-Compiler
+- [2018] - Go 1.11 mit Modulen
+- [2020] - Go 1.15 mit verbessertem Linker
+- [2022] - Go 1.18 mit Generics
+- [2026-07-25] - Entity-Seite erstellt
+
+## Siehe auch
+
+- [[ha-core]] - Verwendet Go für E3DC-Integration
+- [[gdeploy]] - Go-basiertes Deployment-Tool
+- [[Rust]] - Alternative Systemsprache
+- [[Python]] - Alternative Skriptsprache
+- Systems Programming concept

kb/entities/technologies/Home Assistant.md

@@ -0,0 +1,45 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: []
+created: 2026-08-02
+modified: 2026-08-29
+related: [E3DC, Modbus, ha-core]
+sources: []
+confidence: 0.50
+confidence_base: 0.50
+provenance: general
+summary: Quelloffene Plattform zum Aufbau von Hausautomationssystemen mit Gerätesteuerung und Automatisierung.
+---
+# Home Assistant
+
+**Typ:** technology
+
+## Beschreibung
+
+Home Assistant ist eine Python-basierte Open-Source-Hausautomationsplattform, die die Kontrolle von Smart-Home-Geräten vieler Hersteller hinter einer einzigen Schnittstelle vereinheitlicht. ha-core integriert es mit E3DC-Energiespeichersystemen zur Überwachung und Kontrolle.
+
+## Kerndaten
+
+- **Zweck:** TODO
+- **Status:** TODO
+- **Version:** TODO
+- **Sprache/Technik:** TODO
+- **Verantwortlich:** TODO
+- **Repository:** TODO
+
+## Beziehungen
+
+- **Bezogen auf:** TODO
+
+## Details
+
+TODO
+
+## Historie
+
+- 2026-08-02 - Seite via wikitool erstellt
+
+## Siehe auch
+
+- TODO

kb/entities/technologies/Kernel PM Governors.md

@@ -0,0 +1,94 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [kernel, power-management, cpu, governor]
+created: 2026-07-31
+modified: 2026-08-29
+related: [Linux Kernel, amd-pstate, acpi-cpufreq, CPPC]
+sources: [Source - AMD Powermanagement CPU]
+confidence: 0.95
+confidence_base: 0.95
+provenance: sourced
+summary: Power-Management-Module des Linux-Kernels, die die CPU-Frequenz dynamisch nach Systemlast und Leistungsanforderung skalieren.
+---
+# Kernel PM Governors
+
+**Typ:** technology
+
+## Beschreibung
+
+Kernel-PM-Governoren (Power Management) sind Richtlinienmodule innerhalb des Linux-Kernels, die bestimmen, wie die CPU-Frequenzskalierung durchgeführt wird. Sie bewerten die Systemauslastung und Leistungsanforderungen, um geeignete CPU-Leistungszustände auszuwählen und dabei Leistung und Energieeffizienz auszugleichen.
+
+## Kerndaten
+
+- **Zweck:** Dynamische CPU-Frequenzskalierungsrichtlinien
+- **Status:** Aktiv
+- **Typ:** Kernel-Governor-Module
+- **Schnittstelle:** Funktioniert mit cpufreq-Treibern (amd-pstate, acpi-cpufreq)
+
+## Beziehungen
+
+- **Hängt ab von:** [[Linux Kernel]]
+- **Verwendet von:** [[amd-pstate]], [[acpi-cpufreq]]
+- **Bewertet:** [[CPPC]]-Ziele und Hinweise (bei Verwendung von amd-pstate)
+- **Verwandt mit:** CPU-Power-Management-Subsystem
+
+## Details
+
+### Governor-Typen
+
+Der Linux-Kernel umfasst mehrere Governoren, wobei die folgenden am relevantesten sind:
+
+#### schedutil
+
+- **Beschreibung:** Standard-Governor in modernen Linux-Kernels
+- **Ansatz:** Verwendet Scheduler-Auslastungsdaten, um Frequenzskalierungsentscheidungen zu treffen
+- **Merkmale:**
+  - Niedrige Latenz
+  - Geeignet für universelle Arbeitslasten
+  - Funktioniert gut mit sowohl acpi-cpufreq als auch amd-pstate
+  - Kann CPPC-Leistungsziele und Hinweise bewerten, wenn amd-pstate verwendet wird
+
+#### ondemand
+
+- **Beschreibung:** Skaliert Frequenz basierend auf aktueller CPU-Auslastung
+- **Ansatz:** Erhöht die Frequenz, wenn die CPU-Auslastung steigt, senkt sie ab, wenn keine Last vorhanden ist
+- **Merkmale:**
+  - Einfach und effektiv
+  - Kann CPPC-Hinweise bewerten, wenn amd-pstate verwendet wird
+  - Geeignet für Systeme, bei denen Leistung Priorität hat
+  - Weniger aggressive Energieersparnisse als conservative
+
+#### Andere Governoren
+
+- **conservative:** Konservativere Frequenzskalierung, priorisiert Energieersparnisse
+- **powersave:** Wählt immer die niedrigste Frequenz
+- **performance:** Wählt immer die höchste Frequenz
+- **userspace:** Ermöglicht User-Space-Anwendungen, die Frequenz zu steuern
+
+### Governoren mit amd-pstate
+
+Bei Verwendung des **amd-pstate**-Treibers erhalten Governoren wie **schedutil** und **ondemand** zusätzliche Funktionen:
+
+- Können **CPPC-Leistungsziele** bewerten, die von der Hardware bereitgestellt werden
+- Können **CPPC-Hinweise** interpretieren, um fundiertere Entscheidungen zu treffen
+- Ermöglichen **feinkörnige Regulierung** des Systems
+- Führen zu verbesserter **Energieeffizienz** und verlängerter Batterielebensdauer auf mobilen Geräten
+
+### Governoren mit acpi-cpufreq
+
+Bei Verwendung des **acpi-cpufreq**-Treibers sind Governoren auf die Auswahl aus verfügbaren **P-States** beschränkt (normalerweise 3 Zustände für AMD):
+- P-State 0 (vollständige Leistung)
+- P-State 1 (Zwischen)
+- P-State 2 (niedrigste Leistung)
+
+Dies führt zu grobkörnigerer Kontrolle im Vergleich zu amd-pstate + CPPC.
+
+## Siehe auch
+
+- [[Linux Kernel]]
+- [[amd-pstate]]
+- [[acpi-cpufreq]]
+- [[CPPC]]
+- [[Source - AMD Powermanagement CPU]]
+

kb/entities/technologies/LVM.md

@@ -0,0 +1,188 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [storage, volume-management, linux, disks]
+created: 2026-07-31
+modified: 2026-08-29
+related: [Arch Linux, Disk Encryption, AUR]
+sources: [Source - Arch Linux Cheat Sheet]
+confidence: 0.90
+confidence_base: 0.90
+provenance: sourced
+summary: Device-Mapper-Framework unter Linux für flexible Datenträgerverwaltung mit Logical Volumes, Snapshots und Online-Vergrößerung jenseits klassischer Partitionierung.
+---
+# LVM
+
+**Typ:** technology
+
+## Beschreibung
+
+Logical Volume Manager (LVM) ist ein Device-Mapper-Framework für Linux, das eine logische Volumenverwaltung für Festplattenspeicher bietet. Es ermöglicht flexible Speicherzuweisung, Größenänderung und Verwaltung über die Grenzen traditioneller Partitionierungsschemata hinaus.
+
+## Kerndaten
+
+- **Vollständiger Name:** Logical Volume Manager
+- **Zweck:** Flexible Disk-Speicherverwaltung
+- **Status:** Aktiv, reife Technologie
+- **Kernel-Komponente:** Device Mapper
+- **Upstream:** Teil des Linux-Kernels
+- **Paket:** `lvm2` in den meisten Distributionen
+
+## Komponenten
+
+### Physical Volumes (PV)
+Roh-Speichergeräte oder Partitionen, die für LVM-Nutzung initialisiert werden. Dies sind die Bausteine von LVM-Speicherpools.
+
+### Volume Groups (VG)
+Sammlungen von physischen Volumes, die einen Speicherpool bilden. Mehrere PVs können in einem einzigen VG kombiniert werden.
+
+### Logical Volumes (LV)
+Virtuelle Partitionen, die aus Volume Groups erstellt werden. LVs erscheinen dem System als normale Block-Geräte.
+
+## Funktionen
+
+- **Flexible Größenanpassung:** Größe von Volumes online ändern (auch während des Betriebs)
+- **Dynamische Zuweisung:** Speicher nach Bedarf zuweisen
+- **Snapshots:** Zeitpunktgenaue Kopien von Volumes erstellen
+- **Thin Provisioning:** Speicher bei Bedarf zuweisen
+- **Striping:** Daten auf mehrere Festplatten für Leistung verteilen
+- **Mirroring:** Redundante Kopien für Zuverlässigkeit erstellen
+
+## Häufige Befehle
+
+### Physical Volumes
+
+```bash
+# Initialize a disk or partition as PV
+pvcreate /dev/sdX1
+
+# Display PV information
+pvdisplay
+pvs
+
+# Remove PV
+pvremove /dev/sdX1
+```
+
+### Volume Groups
+
+```bash
+# Create VG from one or more PVs
+vgcreate myvg /dev/sdX1 /dev/sdX2
+
+# Display VG information
+vgdisplay
+vgs
+
+# Extend VG with additional PV
+vgextend myvg /dev/sdX3
+
+# Remove VG
+vgremove myvg
+```
+
+### Logical Volumes
+
+```bash
+# Create LV
+lvcreate -n mylv -L 10G myvg
+
+# Display LV information
+lvdisplay
+lvs
+
+# Resize LV
+lvresize -L +5G myvg/mylv
+lvresize -L 15G myvg/mylv
+
+# Remove LV
+lvremove myvg/mylv
+```
+
+## Ändern der Größe verschlüsselter LVM-Disks
+
+Bei Verwendung von LVM mit LUKS-Verschlüsselung (häufige Konfiguration) ist der vollständige Größenänderungs-Workflow:
+
+**Example from [[Source - Arch Linux Cheat Sheet]]:**
+
+```bash
+# 1. Expand the disk in virtualization layer (ESXi, etc.)
+# 2. Rescan SCSI bus to see expanded disk
+echo "1" > /sys/class/block/sdb/device/rescan
+
+# 3. Verify disk size
+fdisk -l /dev/xyz
+
+# 4. Check LUKS status
+cryptsetup status crypted
+
+# 5. Resize LUKS container
+cryptsetup resize crypted
+
+# 6. Verify LUKS status
+cryptsetup status crypted
+
+# 7. Resize LVM Physical Volume
+pvresize /dev/mapper/crypted
+
+# 8. Verify PV size
+pvdisplay
+
+# 9. Allocate additional space to Logical Volume
+lvresize -L+750g /dev/isp/owncloud
+
+# 10. Verify LV size
+lvs
+
+# 11. Resize filesystem
+resize2fs /dev/mapper/isp-owncloud
+
+# 12. Verify
+ df -h
+```
+
+## Snapshot-Verwaltung
+
+```bash
+# Create snapshot
+lvcreate -L 1G -s -n mysnap /dev/myvg/mylv
+
+# Mount snapshot (read-only)
+mount /dev/myvg/mysnap /mnt/snapshot
+
+# Remove snapshot
+lvremove /dev/myvg/mysnap
+```
+
+## Thin Provisioning
+
+```bash
+# Create thin pool
+lvcreate -L 100G --thinpool mypool myvg
+
+# Create thin LV
+lvcreate -V 10G --thin mypool -n mythinlv
+```
+
+## Beziehungen
+
+- **Verwendet mit:** [[Disk Encryption]] (dm-crypt/LUKS) für verschlüsselte Volumes
+- **Läuft auf:** [[Arch Linux]] und andere Linux-Distributionen
+und andere Infrastruktur
+- **Teil von:** Speicherverwaltung in Linux-Systemen
+
+## Bewährte Praktiken
+
+1. **Aussagekräftige Namen verwenden:** VG- und LV-Namen sollten ihren Zweck beschreiben
+2. **Freien Speicher überwachen:** `vgs` und `lvs` regelmäßig verwenden
+3. **Metadaten sichern:** `vgcfgbackup` und `vgcfgrestore`
+4. **Partitionen ausrichten:** Richtige Ausrichtung für SSDs verwenden (normalerweise 1 MiB)
+5. **Redundanz erwägen:** Mirroring für kritische Daten verwenden
+
+## Siehe auch
+
+- [[Disk Encryption]] - dm-crypt/LUKS für verschlüsselte LVM
+- [[Arch Linux]] - Distribution mit LVM-Unterstützung
+- [[Source - Arch Linux Cheat Sheet]]
+- https://wiki.archlinux.org/title/LVM
+- https://sourceware.org/lvm2/

kb/entities/technologies/Linux Kernel.md

@@ -0,0 +1,63 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [os, kernel, linux]
+created: 2026-07-31
+modified: 2026-08-29
+related: [amd-pstate, acpi-cpufreq, Kernel PM Governors, CPPC]
+sources: [Source - AMD Powermanagement CPU]
+confidence: 0.95
+confidence_base: 0.95
+provenance: sourced
+summary: Quelloffener Betriebssystemkern; verwaltet Systemressourcen und Hardware-Abstraktion, einschließlich Power Management und CPU-Frequenzskalierung.
+---
+# Linux Kernel
+
+**Typ:** technology
+
+## Beschreibung
+
+Der Linux-Kernel ist der Open-Source-Betriebssystem-Kernel, der das Kernstück von Linux-Distributionen darstellt. Er verwaltet Systemressourcen, Hardware-Abstraktion, Prozessverwaltung und bietet die Schnittstelle zwischen Hardware und User-Space-Anwendungen.
+
+## Kerndaten
+
+- **Zweck:** Zentrale Betriebssystem-Komponente mit Hardware-Abstraktion und Ressourcenverwaltung
+- **Status:** Aktiv, laufend entwickelt
+- **Version:** 5.17+ (für amd-pstate-Unterstützung)
+- **Sprache/Technik:** C, Assembler
+- **Repository:** https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+
+## Beziehungen
+
+- **Verwendet von:** [[amd-pstate]], [[acpi-cpufreq]], [[Kernel PM Governors]]
+- **Implementiert:** [[CPPC]]-Unterstützung über amd-pstate-Treiber
+- **Verwandt mit:** Power-Management-Subsystemen
+
+## Details
+
+### Power Management im Linux-Kernel
+
+Der Linux-Kernel bietet ein umfassendes Power-Management-Framework, das Folgendes umfasst:
+
+- **CPU-Frequenzskalierung:** Ermöglicht die dynamische Anpassung der CPU-Taktgeschwindigkeiten zur Ausbalancierung von Leistung und Stromverbrauch
+- **CPU-Leerlaufzustände:** Verwaltet CPU-Leistungszustände bei Untätigkeit (C-States)
+- **Leistungszustände:** Verwaltet CPU-Leistungszustände (P-States)
+- **Governoren:** Richtlinien, die bestimmen, wie die Frequenzskalierung durchgeführt wird
+
+### Verbesserungen in Version 5.17
+
+Der Linux-Kernel 5.17 führte bedeutende Verbesserungen zum AMD-CPU-Power-Management ein:
+
+- Neuer **amd-pstate**-Treiber für AMD-Prozessoren
+- Unterstützung für CPPC (Collaborative Processor Performance Control)
+- Feinkörnigere Power-Management-Kontrolle
+- Bessere Energieeffizienz für mobile Geräte
+
+## Siehe auch
+
+- [[amd-pstate]]
+- [[acpi-cpufreq]]
+- [[Kernel PM Governors]]
+- [[CPPC]]
+- [[Source - AMD Powermanagement CPU]]
+

kb/entities/technologies/MQTT.md

@@ -0,0 +1,45 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: []
+created: 2026-08-02
+modified: 2026-08-28
+related: [Modbus]
+sources: []
+confidence: 0.50
+confidence_base: 0.50
+provenance: general
+summary: Leichtgewichtiges Publish-Subscribe-Protokoll für die Kommunikation von IoT-Geräten über TCP/IP-Netze.
+---
+# MQTT
+
+**Typ:** technology
+
+## Beschreibung
+
+MQTT ist ein offenes, standardisiertes Messaging-Protokoll für die Kommunikation zwischen IoT- und anderen Geräten. Es ermöglicht leichtgewichtiges Publish-Subscribe-Messaging zwischen Geräten und zentralen Brokern über TCP/IP-Netze und wird häufig zusammen mit Home Assistant eingesetzt.
+
+## Kerndaten
+
+- **Zweck:** TODO
+- **Status:** TODO
+- **Version:** TODO
+- **Sprache/Technik:** TODO
+- **Verantwortlich:** TODO
+- **Repository:** TODO
+
+## Beziehungen
+
+- **Verwandt mit:** TODO
+
+## Details
+
+TODO
+
+## Historie
+
+- 2026-08-02 - Page created via wikitool
+
+## Siehe auch
+
+- TODO

kb/entities/technologies/OPC UA.md

@@ -0,0 +1,45 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: []
+created: 2026-08-02
+modified: 2026-08-29
+related: [Modbus]
+sources: []
+confidence: 0.50
+confidence_base: 0.50
+provenance: general
+summary: Industrieprotokoll für sichere, standardisierte Gerätekommunikation mit semantischer Datenmodellierung.
+---
+# OPC UA
+
+**Typ:** technology
+
+## Beschreibung
+
+OPC UA (OPC Unified Architecture) ist ein modernes Industrieprotokoll, das sichere Geräte-zu-Geräte-Kommunikation mit reichhaltiger Datentypisierung und semantischer Modellierung bietet. Es ersetzt veraltete OPC-Protokolle für Industrial-IoT-Anwendungen und wird zusammen mit Modbus erwähnt.
+
+## Kerndaten
+
+- **Zweck:** TODO
+- **Status:** TODO
+- **Version:** TODO
+- **Sprache/Technik:** TODO
+- **Verantwortlich:** TODO
+- **Repository:** TODO
+
+## Beziehungen
+
+- **Verwandt mit:** TODO
+
+## Details
+
+TODO
+
+## Historie
+
+- 2026-08-02 - Seite über wikitool erstellt
+
+## Siehe auch
+
+- TODO

kb/entities/technologies/Python.md

@@ -0,0 +1,45 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: []
+created: 2026-08-02
+modified: 2026-08-29
+related: [Go, ha-core]
+sources: []
+confidence: 0.50
+confidence_base: 0.50
+provenance: general
+summary: Interpretierte Programmiersprache, weit verbreitet für Backend-Dienste und Hausautomationsplattformen.
+---
+# Python
+
+**Typ:** technology
+
+## Beschreibung
+
+Python ist eine höhere interpretierte Programmiersprache, bekannt für Lesbarkeit und schnelle Entwicklung. Sie ist die Implementierungssprache von Home Assistant und wird umfangreich in ha-core verwendet.
+
+## Kerndaten
+
+- **Zweck:** TODO
+- **Status:** TODO
+- **Version:** TODO
+- **Sprache/Technik:** TODO
+- **Verantwortlich:** TODO
+- **Repository:** TODO
+
+## Beziehungen
+
+- **Verwandt mit:** TODO
+
+## Details
+
+TODO
+
+## Historie
+
+- 2026-08-02 - Seite erstellt via wikitool
+
+## Siehe auch
+
+- TODO

kb/entities/technologies/Rust.md

@@ -0,0 +1,45 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: []
+created: 2026-08-02
+modified: 2026-08-29
+related: [Go]
+sources: []
+confidence: 0.50
+confidence_base: 0.50
+provenance: general
+summary: Systemprogrammiersprache, die Speichersicherheit ohne Garbage Collection bietet.
+---
+# Rust
+
+**Typ:** technology
+
+## Beschreibung
+
+Rust ist eine Systemprogrammiersprache, die Speichersicherheit und sichere Parallelität betont. Sie bietet starke Speichergarantien ohne Garbage Collection mit einer Leistung vergleichbar mit C/C++; Aura verwendet sie zur Implementierung eines sicheren AUR-Helpers.
+
+## Kerndaten
+
+- **Zweck:** TODO
+- **Status:** TODO
+- **Version:** TODO
+- **Sprache/Technik:** TODO
+- **Verantwortlich:** TODO
+- **Repository:** TODO
+
+## Beziehungen
+
+- **Verwandt mit:** TODO
+
+## Details
+
+TODO
+
+## Historie
+
+- 2026-08-02 - Seite erstellt via wikitool
+
+## Siehe auch
+
+- TODO

kb/entities/technologies/Wine GE.md

@@ -0,0 +1,61 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [wine, compatibility, gaming, glorious-eggroll]
+created: 2026-08-01
+modified: 2026-08-29
+related: [Wine, Bottles, Proton, Wine-Staging, Lutris]
+sources: [Source - Wine]
+confidence: 0.85
+confidence_base: 0.85
+provenance: sourced
+summary: Eigene Wine-Builds von GloriousEggroll mit zusätzlichen Patches und Optimierungen für bessere Kompatibilität von Windows-Anwendungen und -Spielen unter Linux.
+---
+# Wine GE
+
+**Typ:** technology
+
+## Beschreibung
+
+Wine GE (GloriousEggroll) ist eine Sammlung benutzerdefinierter [[Wine]]-Builds, gepflegt von GloriousEggroll, mit zusätzlichen Patches und Optimierungen zur Verbesserung der Kompatibilität mit Windows-Anwendungen und Spielen unter Linux. Diese Builds enthalten häufig Patches aus Wine-Staging sowie zusätzliche spielfokussierte Verbesserungen.
+
+## Kerndaten
+
+- **Zweck:** Erweiterte Wine-Builds für Gaming- und Anwendungskompatibilität
+- **Status:** Aktiv, von der Community gepflegt
+- **Maintainer:** GloriousEggroll
+- **Website:** https://github.com/GloriousEggroll/wine-ge-custom
+
+## Beziehungen
+
+- **Erweitert:** [[Wine]]
+- **Enthält:** [[Wine-Staging]]-Patches (typischerweise)
+- **Verwendet in:** [[Bottles]] (GE Wine und GE Proton Runtimes)
+- **Verwandt mit:** [[Proton]], [[Lutris]], [[Bottles]]
+
+## Details
+
+### Bottles-Integration
+
+Wine GE ist in [[Bottles]] über zwei Runtimes verfügbar:
+
+- **GE Wine:** Reiner Wine GE Build
+- **GE Proton:** Wine Valve + Wine-Staging + Proton + Steam (verwendet GE-Patches)
+
+### Kernfunktionen
+
+- Gaming-fokussierte Optimierungen
+- Zusätzliche Direct3D-Patches
+- Verbesserungen des Media-Foundation
+- Bessere Controller-Unterstützung
+- Verschiedene anwendungsspezifische Fixes
+
+## Siehe auch
+
+- [[Wine]]
+- [[Bottles]]
+- [[Proton]]
+- [[Wine-Staging]]
+- [[Lutris]]
+- [[Source - Wine]]
+

kb/entities/technologies/Wine-Staging.md

@@ -0,0 +1,62 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [wine, compatibility, patches, gaming]
+created: 2026-08-01
+modified: 2026-08-29
+related: [Wine, Bottles, Proton, Wine GE]
+sources: [Source - Wine]
+confidence: 0.85
+confidence_base: 0.85
+provenance: sourced
+summary: Experimenteller Entwicklungszweig von Wine mit ungetesteten Patches und Funktionen vor der Aufnahme upstream; dient als Erprobungsfeld für neue Wine-Funktionalität.
+---
+# Wine-Staging
+
+**Typ:** technology
+
+## Beschreibung
+
+Wine-Staging ist ein Entwicklungszweig von [[Wine]], der experimentelle Patches und Features enthält, die noch nicht in den Haupt-Wine-Baum integriert wurden. Diese Patches enthalten häufig Leistungsverbesserungen, Bugfixes und neue Funktionalität, die vor der Upstream-Akzeptanz getestet werden.
+
+## Kerndaten
+
+- **Zweck:** Testfeld für Wine-Patches und Features
+- **Status:** Aktiv, experimentell
+- **Betreuer:** Wine-Staging-Team
+- **Website:** https://wine-staging.github.io/
+
+## Beziehungen
+
+- **Erweitert:** [[Wine]]
+- **Verwendet von:** [[Bottles]] (enthalten in Soda, Caffe, Vaniglia, GE Proton Runtimes)
+- **Verwandt mit:** [[Proton]], [[Wine GE]], [[Arch Linux]]
+
+## Details
+
+### Aufnahme in Bottles-Runtimes
+
+Wine-Staging-Patches sind in den folgenden [[Bottles]]-Runtimes enthalten:
+
+- **Soda:** Wine Valve + Wine-Staging + Proton
+- **Caffe:** Wine Upstream + Wine-Staging + Proton
+- **Vaniglia:** Wine Upstream + Wine-Staging
+- **GE Proton:** Wine Valve + Wine-Staging + Proton + Steam
+
+### Patch-Kategorien
+
+Wine-Staging-Patches enthalten typischerweise:
+- Leistungsoptimierungen
+- Direct3D-Verbesserungen
+- Media-Foundation-Unterstützung
+- Verschiedene Bugfixes für bestimmte Anwendungen und Spiele
+- Experimentelle Features, die auf Upstream-Überprüfung warten
+
+## Siehe auch
+
+- [[Wine]]
+- [[Bottles]]
+- [[Proton]]
+- [[Wine GE]]
+- [[Source - Wine]]
+

kb/entities/technologies/acpi-cpufreq.md

@@ -0,0 +1,79 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [kernel, driver, power-management, acpi, cpu]
+created: 2026-07-31
+modified: 2026-08-29
+related: [Linux Kernel, amd-pstate, Kernel PM Governors, amd-pstate vs acpi-cpufreq]
+sources: [Source - AMD Powermanagement CPU]
+confidence: 0.95
+confidence_base: 0.95
+provenance: sourced
+summary: Linux-Kerneltreiber für die CPU-Frequenzskalierung von Prozessoren nach dem ACPI-Standard.
+---
+# acpi-cpufreq
+
+**Typ:** technology
+
+## Beschreibung
+
+acpi-cpufreq ist ein Linux-Kerneltreiber, der CPU-Frequenzskalierung für Prozessoren mit dem ACPI-Standard (Advanced Configuration and Power Interface) implementiert. Er war der primäre Energieverwaltungstreiber für AMD-CPUs vor der Einführung von amd-pstate.
+
+## Kerndaten
+
+- **Zweck:** CPU-Frequenzskalierung und Energieverwaltung
+- **Status:** Aktiv (Legacy für AMD, wird noch als Fallback verwendet)
+- **Typ:** Kerneltreiber
+- **Standard:** ACPI (Advanced Configuration and Power Interface)
+- **Schnittstelle:** sysfs
+
+## Beziehungen
+
+- **Hängt ab von:** [[Linux Kernel]]
+- **Verwendet von:** AMD-CPUs (vor amd-pstate)
+- **Ersetzt durch:** [[amd-pstate]] für neuere AMD-CPUs
+- **Arbeitet mit:** [[Kernel PM Governors]] (schedutil, ondemand, conservative, powersave, performance)
+- **Fallback für:** [[amd-pstate]] auf inkompatiblen Systemen
+- **Verglichen in:** [[amd-pstate vs acpi-cpufreq]]
+
+## Details
+
+### Leistungszustände (P-States)
+
+acpi-cpufreq reguliert CPU-Leistung mit diskreten **P-States** (Performance States):
+
+- **P-State 0:** Volle Leistung (maximale Frequenz)
+- **P-State 1:** Zwischenlleistung
+- **P-State 2:** Niedrigste Leistung (minimale Frequenz)
+
+Bei AMD-Prozessoren war acpi-cpufreq auf diese **3 P-States** beschränkt, was eine grobe Kontrolle über CPU-Leistung und Stromverbrauch bot.
+
+### Betrieb
+
+Der Treiber:
+1. Liest verfügbare P-States aus ACPI-Tabellen
+2. Stellt diese Status über sysfs-Schnittstelle bereit
+3. Erlaubt Governoren, passende P-States basierend auf Systemlast auszuwählen
+4. Behandelt Übergänge zwischen Zuständen
+
+### Einschränkungen für AMD
+
+- Nur 3 Leistungszustände verfügbar (grobe Granularität)
+- Weniger effizient als CPPC-basierte Ansätze
+- Begrenzte Möglichkeit zur Optimierung für Energieeffizienz auf modernen AMD-Prozessoren
+
+### Aktueller Status
+
+Während amd-pstate jetzt der bevorzugte Treiber für AMD-CPUs mit CPPC-Unterstützung ist, bleibt acpi-cpufreq wichtig als:
+- **Fallback-Treiber** wenn amd-pstate nicht initialisiert werden kann
+- **Treiber für ältere Hardware** ohne CPPC-Unterstützung
+- **Referenzimplementierung** für ACPI-basierte CPU-Frequenzskalierung
+
+## Siehe auch
+
+- [[Linux Kernel]]
+- [[amd-pstate]]
+- [[Kernel PM Governors]]
+- [[Source - AMD Powermanagement CPU]]
+- [[amd-pstate vs acpi-cpufreq]]
+

kb/entities/technologies/amd-pstate.md

@@ -0,0 +1,77 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [kernel, driver, power-management, amd, cpu]
+created: 2026-07-31
+modified: 2026-08-29
+related: [Linux Kernel, acpi-cpufreq, Kernel PM Governors, CPPC, amd-pstate vs acpi-cpufreq]
+sources: [Source - AMD Powermanagement CPU]
+confidence: 0.95
+confidence_base: 0.95
+provenance: sourced
+summary: Linux-Kerneltreiber für das Power Management von AMD-Prozessoren über die CPPC-Schnittstelle; löst acpi-cpufreq ab.
+---
+# amd-pstate
+
+**Typ:** technology
+
+## Beschreibung
+
+amd-pstate ist ein Linux-Kerneltreiber, der in Version 5.17 eingeführt wurde und Energieverwaltung für AMD-Prozessoren mithilfe der CPPC-Schnittstelle (Collaborative Processor Performance Control) bietet. Er ersetzt den älteren ACPI-basierten Ansatz mit einem feingranularerem und effizienteren Mechanismus zur Steuerung von CPU-Leistung und Stromverbrauch.
+
+## Kerndaten
+
+- **Zweck:** CPU-Energieverwaltung für AMD-Prozessoren
+- **Status:** Aktiv (eingeführt in Linux 5.17)
+- **Typ:** Kerneltreiber
+- **Schnittstelle:** sysfs
+- **Hardware-Anforderung:** AMD-CPUs mit CPPC-Unterstützung (neuere Generationen, sowie einige Zen2- und Zen3-Modelle)
+- **Kernel-Commit:** [c22760885fd6](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c22760885fd6)
+- **Dokumentation:** Documentation/admin-guide/pm/amd-pstate.rst
+
+## Beziehungen
+
+- **Hängt ab von:** [[Linux Kernel]] 5.17+
+- **Implementiert:** [[CPPC]] (Collaborative Processor Performance Control)
+- **Ersetzt:** [[acpi-cpufreq]] für AMD-CPUs auf unterstützter Hardware
+- **Verwendet von:** [[Kernel PM Governors]] (schedutil, ondemand)
+- **Fällt zurück auf:** [[acpi-cpufreq]] auf inkompatiblen Systemen
+- **Verglichen in:** [[amd-pstate vs acpi-cpufreq]]
+
+## Details
+
+### Funktionen
+
+- **Feinere Granularität:** Bietet präzisere Kontrolle über CPU-Leistungszustände im Vergleich zu den 3 P-States, die acpi-cpufreq anbietet
+- **Hardware-Hinweise:** CPPC-Hardware bietet Leistungsziele und Hinweise, die Governor auswerten können
+- **Dynamische Regulierung:** Ermöglicht feingranulare Systemregulation basierend auf Workload und Stromanforderungen
+- **Energieeffizienz:** Reduziert Stromverbrauch, besonders vorteilhaft für mobile Geräte, wo es die Akkulaufzeit verlängert
+
+### Kompatibilität
+
+- **Unterstützte Hardware:** Neuere AMD-CPU-Generationen, sowie einige Zen2- und Zen3-Modelle
+- **Fallback-Mechanismus:** Wenn amd-pstate nicht initialisiert werden kann oder auf inkompatible Hardware läuft, fällt der Kernel automatisch auf acpi-cpufreq zurück
+- **Governor-Unterstützung:** Funktioniert mit vorhandenen Kernel-Governoren wie schedutil und ondemand
+
+### Verwendung
+
+Der Treiber stellt seine Konfiguration und Status über die sysfs-Schnittstelle bereit und ermöglicht:
+- Anzeigen von aktuellen Leistungszuständen
+- Anpassung von Energieverwaltungsparametern
+- Überwachung von CPPC-bezogenen Metriken
+
+## Historie
+
+- **2022-03-20:** Eingeführt in Linux Kernel 5.17
+- **2022:** Initiale Bereitstellung auf AMD Zen2- und Zen3-Prozessoren
+
+## Siehe auch
+
+- [[Linux Kernel]]
+- [[acpi-cpufreq]]
+- [[Kernel PM Governors]]
+- [[CPPC]]
+- [Kernel Commit c22760885fd6](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c22760885fd6)
+- [[Source - AMD Powermanagement CPU]]
+- [[amd-pstate vs acpi-cpufreq]]
+

kb/entities/technologies/iii Engine.md

@@ -0,0 +1,51 @@
+---
+type: types/entity.md
+entity_type: technology
+tags: [engine, framework, memory, llm]
+created: 2026-07-26
+modified: 2026-08-29
+related: [Agent Memory, LLM Wiki Pattern]
+sources: [Source - LLM Wiki v2]
+confidence: 0.90
+confidence_base: 0.90
+provenance: sourced
+summary: Kern-Engine, die die Infrastruktur für persistente Speicher von KI-Agenten und die Umsetzung des Wissensgraphen bereitstellt.
+---
+# iii Engine
+
+**Typ:** Technology (Engine/Framework)
+
+## Beschreibung
+
+[iii-engine](https://github.com/iii-hq/iii) ist das zugrundeliegende Engine-/Framework, auf dem [agentmemory](https://github.com/rohitg00/agentmemory) aufgebaut ist. Es bietet die Kerninfrastruktur zur Implementierung von persistenten Speicher- und Wissensverwaltungssystemen für AI-Agenten.
+
+## Kerndaten
+
+- **Zweck:** Core Engine für AI-Agent-Memory- und Wissenssysteme
+- **Status:** Aktiv
+- **Repository:** [github.com/iii-hq/iii](https://github.com/iii-hq/iii)
+- **Verwendet von:** [[Agent Memory]]
+
+## Funktionen
+
+Die iii-engine ermöglicht die Implementierung von:
+
+- Persistenter Speicherung und Abruf
+- Knowledge-Graph-Strukturen
+- Entity-Extraktion und Beziehungsverwaltung
+- Event-gesteuerte Automatisierungs-Hooks
+- Skalierbare Suchfunktionen
+
+## Beziehungen
+
+- **Verwendet von:** [[Agent Memory]]
+- **Implementiert:** [[LLM Wiki Pattern]]-Infrastruktur
+- **Unterstützt:** [[Knowledge Graph]]-Strukturen
+- **Ermöglicht:** [[Event-Driven Automation]]
+
+## Siehe auch
+
+- [[Agent Memory]]
+- [[LLM Wiki Pattern]]
+- [[Knowledge Graph]]
+- [[Event-Driven Automation]]