Merge branch 'phase/041-doppelte-hosts'

feat(hosts): Doppelte Hosts erkennen und stilllegen (#041 )
Zwei Eintraege desselben Namens beim selben Kunden entstehen, wenn sich die Kennung aus /etc/machine-id aendert - Neuinstallation, geklonter Container, zurueckgespielte Sicherung. Dieselbe Maschine meldet sich dann als neuer Host, der alte Eintrag bleibt stehen. Zwei getrennte Maschinen mit gleichem Namen sind aber genauso moeglich. Neue dreizehnte Warnregel meldet den Fall und nennt die IP-Adressen zum Unterscheiden; gleiche Namen bei verschiedenen Kunden bleiben still. Dazu die bis dahin fehlende Moeglichkeit, einen Host loszuwerden: Stilllegen blendet ihn aus Listen, Zahlen, Suche und Warnungen aus und schliesst seine offenen Warnungen, laesst Laufzeiten und Rechnungen aber unberuehrt. Endgueltig loeschen geht nur ohne Laufzeiten - Buchhaltung wirft man nicht weg. Kein automatisches Zusammenfuehren: Es muesste raten, welcher Eintrag welche Rechnung erbt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-10-03 17:57:18 +02:00 · 2026-10-03 17:57:18 +02:00 · 2026-10-03 17:43:55 +02:00 · 2026-10-03 17:43:55 +02:00 · 2026-10-03 17:08:54 +02:00 · 2026-10-03 17:08:54 +02:00
230 changed files with 15321 additions and 658 deletions
@@ -0,0 +1,11 @@
 node_modules
 .next
 dist
 .git
 .env
 .env.*
 !.env.example
 data
 docs/anleitung/bilder
 coverage
 *.log
@@ -1,4 +1,10 @@
-# Datenbank (lokal über docker-compose.dev.yml, Port 5433)
+# Für docker-compose.yml: Zugangsdaten der mitgelieferten Datenbank
 POSTGRES_USER="proxledger"
 POSTGRES_PASSWORD="bitte-aendern"
 POSTGRES_DB="proxledger"
 PORT="3000"
 # Datenbank (lokale Entwicklung über docker-compose.dev.yml, Port 5433)
 DATABASE_URL="postgresql://proxledger:proxledger@localhost:5433/proxledger?schema=public"
 # Eigene Datenbank für automatisierte Tests
@@ -9,9 +15,28 @@ ADMIN_EMAIL="admin@example.de"
 ADMIN_NAME="Administrator"
 ADMIN_PASSWORD="bitte-aendern"
-# Öffentlich erreichbare Adresse des Dashboards (für install.sh und E-Mails)
+# Schlüssel für Sitzungs-Cookies (mindestens 32 Zeichen): openssl rand -base64 48
 APP_SECRET="bitte-eigenen-wert-erzeugen-mindestens-32-zeichen"
 # Anmeldung über OIDC (optional, z. B. authentik). Ohne diese Werte gibt es nur den lokalen Zugang.
 OIDC_ISSUER=""
 OIDC_CLIENT_ID=""
 OIDC_CLIENT_SECRET=""
 OIDC_NAME="authentik"
 # Öffentlich erreichbare Adresse des Dashboards (für install.sh und E-Mails).
 # Lässt sich später unter Einstellungen → System überschreiben.
 APP_URL="http://localhost:3000"
 # Zeitplan des Workers (Standard: stündlich zur vollen Stunde)
 WORKER_CRON="0 * * * *"
 # Zeitplan der Zusammenfassung (Standard: täglich 07:00 Uhr)
 ZUSAMMENFASSUNG_CRON="0 7 * * *"
 # Zeitplan fürs Aufräumen alter Reports und Protokolleinträge (Fristen: Einstellungen → System)
 AUFRAEUM_CRON="30 3 * * *"
 # Ablage für hochgeladene Rechnungs-PDFs
 UPLOAD_DIR="./data/uploads"
@@ -0,0 +1,75 @@
 # Prüft jeden Push und jede Pull-Request-Änderung.
 # Läuft mit Gitea Actions (act_runner); die Syntax entspricht GitHub Actions.
 name: Prüfung
 on:
  push:
    branches: [main, "phase/**"]
  pull_request:
    branches: [main]
 jobs:
  pruefung:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:17-alpine
        env:
          POSTGRES_USER: proxledger
          POSTGRES_PASSWORD: proxledger
          POSTGRES_DB: proxledger_test
        options: >-
          --health-cmd "pg_isready -U proxledger"
          --health-interval 5s
          --health-timeout 5s
          --health-retries 10
        ports:
          - 5432:5432
    env:
      DATABASE_URL: postgresql://proxledger:proxledger@localhost:5432/proxledger_test?schema=public
      TEST_DATABASE_URL: postgresql://proxledger:proxledger@localhost:5432/proxledger_test?schema=public
      APP_SECRET: ci-geheimnis-mit-mindestens-32-zeichen-laenge
      APP_URL: http://localhost:3000
    steps:
      - name: Quelltext holen
        uses: actions/checkout@v4
      - name: Node einrichten
        uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: npm
      - name: Abhängigkeiten installieren
        run: npm ci
      - name: Prisma-Client erzeugen
        run: npx prisma generate
      - name: Code-Stil prüfen
        run: npm run lint
      - name: Typen prüfen
        run: npm run typecheck
      - name: Tests
        run: npm test
      - name: Anwendung bauen
        run: npm run build
      - name: Worker bauen
        run: npm run build:worker
      - name: Agent-Skripte prüfen
        run: |
          sudo apt-get update -qq
          sudo apt-get install -y -qq shellcheck
          shellcheck --severity=warning agent/*.sh deploy/*.sh
      - name: Dokumentation und Versionen prüfen
        run: npm run pruefe:doku
@@ -53,3 +53,4 @@ Thumbs.db
 *.pem
 /src/generated/prisma
 dist/
@@ -17,6 +17,285 @@ und dieses Projekt folgt [Semantic Versioning](https://semver.org/lang/de/).
 ### Sicherheit
 ## [0.24.0] – 2026-10-03
 ### Hinzugefügt
 - Dreizehnte Warnregel: Mehrere Hosts desselben Kunden tragen denselben Namen – mit IP-Adressen zum Unterscheiden (#041)
 - Hosts lassen sich **stilllegen**: Sie verschwinden aus Listen, Zahlen, Suche und Warnungen, ihre Laufzeiten und Rechnungen bleiben erhalten (#041)
 - Endgültiges Löschen für Hosts, an denen keine Laufzeit hängt (#041)
 - Schalter „stillgelegte Hosts zeigen“ in der Host-Liste (#041)
 ## [0.23.0] – 2026-10-03
 ### Hinzugefügt
 - Schlagworte stehen jetzt in der Host-Liste und oben im Host-Detail; ein Klick darauf filtert die Liste (#040)
 - Filter „Alle Schlagworte“ in der Host-Liste (#040)
 - Eine vorhandene Notiz zeigt ein Zettel-Symbol in der Liste; der Text erscheint beim Überfahren und steht oben im Host-Detail (#040)
 - Suche und globale Suche finden Hosts auch über Schlagwort und Notiztext (#040)
 ## [0.22.2] – 2026-10-03
 ### Behoben
 - **Auf dem Telefon führte kein Weg zu den Rechnungsformularen**: Im Reiter *Rechnungen* der Host-Detailansicht war die Laufzeit nicht verlinkt, und in der Rechnungsliste ist diese Spalte erst ab 992 px sichtbar (#039)
 - Der Reiter *Rechnungen* rechnete den Einkauf noch ohne Rabatt (#039)
 ### Geändert
 - Der Reiter *Rechnungen* nutzt auf dem Telefon das Kartenlayout (#039)
 ## [0.22.1] – 2026-10-03
 ### Behoben
 - **Die ganze Seite wurde auf dem Telefon herausgezoomt**, sobald die Warnungen geöffnet wurden oder eine Host-Detailansicht eine lange Server-ID enthielt. Ursache war jeweils ein Element breiter als das Fenster (#038)
 - Die Laufzeit-Detailseite rechnete noch mit dem Listenpreis statt mit dem Betrag nach Rabatt – Marge und der Vorschlag für die Kundenrechnung waren um den Rabatt zu hoch (#037)
 ### Hinzugefügt
 - `npm run screenshots -- --mobil name=/pfad` für gezielte Aufnahmen in Telefonbreite (#038)
 ## [0.22.0] – 2026-10-03
 ### Geändert
 - **Der Rabatt gehört jetzt zur Rechnungsposition statt zur Rechnung** – so, wie Proxmox abrechnet: je Subscription-Key eine Zeile mit Listenpreis und eine mit „Client Discount“. Nur so bleibt er bei einer Sammelrechnung dem richtigen Host zugeordnet (#037)
 - Der Rechnungsbetrag ist die Summe der Positionen nach Abzug ihrer Rabatte; Marge und Summen rechnen mit dem tatsächlich gezahlten Betrag (#037)
 - Eigener Steuersatz für den Einkauf, Vorgabe 0 % wegen Reverse Charge (#037)
 - Das Betragsfeld heißt „Listenpreis netto“ und zeigt beim Tippen, womit gerechnet wird (#037)
 ### Hinzugefügt
 - Zwölfte Warnregel `kunde-bezahlt-einkauf-offen`: Der Kunde hat bezahlt, die Proxmox-Rechnung ist noch offen – der Moment, an dem man selbst zahlt (#037)
 ### Behoben
 - Der Rabatt wurde bisher **nirgends abgezogen**, weder in der Summe noch in der Marge (#037)
 ## [0.21.0] – 2026-10-03
 ### Hinzugefügt
 - Standort eines Hosts lässt sich in der Detailansicht setzen; die Auswahl richtet sich nach dem gewählten Kunden (#036)
 - Breite Tabellen werden auf dem Telefon zu Karten: jede Angabe mit ihrer Beschriftung, statt rechts abgeschnitten zu sein (#035)
 ### Behoben
 - **Jede Kundenzuweisung löschte den Standort des Hosts**, weil das Formular ihn nicht mitsendete, die Aktion ihn aber las (#036)
 - Ein Standort, der zu einem anderen Kunden gehört, wird nicht mehr gespeichert (#036)
 - Kartenköpfe mit Knöpfen liefen auf dem Telefon über den Rand (#035)
 - Das Kontrollkästchen für den Rechnungsstatus wurde auf dem Telefon zum 44 Pixel hohen leeren Kasten (#035)
 ## [0.20.2] – 2026-10-03
 ### Behoben
 - **Das Seitenmenü ließ sich auf dem Handy nicht schließen.** Es gab weder eine Fläche zum Antippen noch ein Schließen beim Navigieren – das Markup stammt von AdminLTE, dessen JavaScript wir bewusst nicht einbinden (#034)
 - Die Dashboard-Tabelle war auf dem Telefon rechts abgeschnitten; sie zeigt dort jetzt Host und Ablauf, den Kunden klein darunter (#034)
 ### Hinzugefügt
 - Schließen-Knopf im Menükopf, Schließen per Escape, und der Inhalt hinter dem offenen Menü scrollt nicht mehr mit (#034)
 ## [0.20.1] – 2026-10-03
 ### Behoben
 - **Abmelden führte auf `0.0.0.0:3000`** und damit ins Leere. Next.js macht Weiterleitungen aus Server Actions serverseitig absolut und nahm dafür die Lausch-Adresse des Servers. Betroffen waren Abmelden, die Sitzungsprüfung und das Löschen eines Kunden (#033)
 - Eine als Lausch-Adresse eingetragene `APP_URL` (`0.0.0.0`, `::`) wird jetzt übergangen statt übernommen (#033)
 - Die LXC-Installation brach mit *404 – Could not fetch install/proxledger-install.sh* ab: Ein per curl geladenes ct-Skript kennt seine Herkunft nicht und suchte bei den community-scripts (#032)
 ### Geändert
 - Vorgabe für den Arbeitsspeicher des LXC von 2 auf 4 GB – `next build` scheitert sonst während der Installation am Speicher (#032)
 ## [0.20.0] – 2026-10-03
 ### Hinzugefügt
 - `deploy/update.sh` und `deploy/backup.sh` erkennen die Installationsart selbst und beherrschen jetzt auch die Installation als Dienst (Node und PostgreSQL direkt im Container) – nicht mehr nur Docker (#031)
 - Eine fehlgeschlagene Sicherung bricht die Aktualisierung ab, bevor etwas verändert wird (#031)
 ### Behoben
 - Die Zustandsprüfung des Web-Containers konnte nie gelingen: Next bindet im Standalone-Modus an die Adresse aus `HOSTNAME`, und Docker setzt dort den Containernamen – der Server lauschte nur auf der Container-IP. `web` blieb dauerhaft auf „health: starting“ (#031)
 ## [0.19.2] – 2026-10-03
 ### Sicherheit
 - Next.js auf 16.3.8 angehoben. Für 16.2.0 bis 16.3.5 wurde eine als **kritisch** eingestufte Lücke in `next/og` gemeldet (Remote Code Execution, GHSA-vcvr-r3jv-pc5j). ProxLedger nutzt `next/og` nicht, war also nicht angreifbar – die Fassung gehört trotzdem aktualisiert, bevor etwas produktiv läuft
 - `@simplewebauthn/server` auf 14.0.3
 ## [0.19.1] – 2026-09-19
 ### Hinzugefügt
 - Anleitung für den netbird Reverse Proxy (Beta): Dienst anlegen, Zertifikat, private Dienste – samt Warnung, dass eine Anmeldehürde vor dem Dienst auch die Agents aussperrt (#030)
 ## [0.19.0] – 2026-09-19
 ### Hinzugefügt
 - `docs/betrieb/`: Inbetriebnahme, Reverse Proxy (nginx Proxy Manager und netbird), OIDC mit authentik und Sicherung – jeweils Schritt für Schritt (#029)
 ### Behoben
 - Die OIDC-Rückkehradresse berücksichtigte die im Dashboard eingetragene Adresse nicht, sondern nur `APP_URL` (#029)
 - Beim Einlösen des OIDC-Codes wurde hinter einem Reverse Proxy die interne Adresse verwendet; der Tausch wäre am Anbieter gescheitert (#029)
 ## [0.18.0] – 2026-09-19
 ### Hinzugefügt
 - Drei Rollen: Administrator, Techniker und Kunde. Kundenkonten sehen nur die eigenen Hosts und Rechnungen – ohne Einkaufspreise und Marge – und dürfen Notizen schreiben sowie Warnungen quittieren (#027)
 - Benutzerverwaltung unter *Einstellungen → Benutzer*: anlegen, Rolle ändern, sperren, Passwort setzen, löschen (#027)
 - Anmeldung mit Passkeys (WebAuthn), gleichwertig neben Passwort und OIDC; eigene Seite *Meine Passkeys* (#028)
 - Einstellung, welche Rolle automatisch angelegte OIDC-Konten bekommen (#027)
 ### Behoben
 - Neu über OIDC angelegte Konten hätten die Vorgabe des Datenmodells geerbt und wären Administratoren geworden; Vorgabe ist jetzt *Techniker* (#027)
 - Das Screenshot-Skript meldete sich mit einem erfundenen Konto an – seit der Sitzungsprüfung gegen die Datenbank landete es auf der Anmeldeseite (#027)
 ## [0.17.0] – 2026-09-19
 ### Hinzugefügt
 - `deploy/update.sh`: sichert, baut neu, migriert und prüft, ob das Dashboard wieder antwortet (#026)
 - Installationsskripte nach Art der Proxmox VE Helper-Scripts unter `deploy/community-scripts/` – Container mit Node und PostgreSQL, ohne Docker (#026)
 - `docs/roadmap.md`: was bis 1.0.0 fehlt und was danach lohnt (#026)
 - Zustandsprüfung für den Worker im Docker-Stack (#026)
 ### Behoben
 - Nach der Anmeldung führte die Weiterleitung im Container auf den internen Containernamen (`http://<container-id>:3000`) statt auf die erreichbare Adresse – hinter einem Reverse Proxy landete man damit im Nichts. Beim Prüfen des Docker-Stapels aufgefallen (#026)
 ### Geändert
 - README auf den tatsächlichen Stand gebracht: Der Feldtest ist erledigt, der Hinweis „noch nicht erprobt“ war überholt (#026)
 ## [0.16.0] – 2026-09-18
 ### Hinzugefügt
 - *Einstellungen → System*: Dashboard-Adresse, Melderhythmus und Selbstaktualisierung der Agents, kaufmännische Vorgaben, Sicherheitsgrenzen, Firmenangaben und Zeitzone (#025)
 - Die Dashboard-Adresse und der Melderhythmus landen im ausgelieferten Installations-Einzeiler und im systemd-Timer (#025)
 - OIDC lässt sich auf bestimmte E-Mail-Domänen begrenzen; das automatische Anlegen unbekannter Konten ist abschaltbar (#025)
 - Nächtliches Aufräumen nach einstellbaren Aufbewahrungsfristen für Reports und Protokoll – der jüngste Report jedes Hosts bleibt erhalten (#025)
 - Firmenangaben erscheinen im Kopf der PDF-Ausgaben (#025)
 ### Geändert
 - Steuersatz, Zahlungsziel und Aufschlag kommen aus den Einstellungen statt aus fest eingetragenen 19 % (#025)
 ## [0.15.0] – 2026-09-18
 ### Hinzugefügt
 - `docs/sicherheit.md`: Zuordnung aller Maßnahmen zu den OWASP Top 10, samt der Punkte, die bewusst offen bleiben (#024)
 - Content-Security-Policy mit frischem Nonce je Anfrage (#024)
 - Sitzungen lassen sich widerrufen: gesperrtes Konto oder neues Passwort beendet laufende Sitzungen sofort (#024)
 - Benutzerverwaltung auf der Kommandozeile: `npm run benutzer -- liste|sperren|entsperren|passwort` (#024)
 ### Behoben
 - Server Actions verließen sich allein auf den Schutz in `proxy.ts`; jede der 27 Aktionen prüft die Sitzung jetzt selbst (#024)
 - Die Anmeldung prüfte die Herkunft des Formulars nicht – damit war Login-CSRF möglich (#024)
 - `npm audit` meldete vier hohe Schwachstellen in Beiwerk von Prisma (`mysql2`, `deepmerge-ts`); über `overrides` angehoben, jetzt ohne Befund (#024)
 ## [0.14.1] – 2026-09-18
 ### Behoben
 - Auf Proxmox Backup Server las der Agent **keine einzige Angabe** aus: `proxmox-backup-manager subscription get` gibt eine Rahmentabelle aus, keine `feld: wert`-Zeilen. Jetzt wird für PBS `--output-format json` genutzt, und die Tabelle wird als Rückfall ausgewertet (#023)
 - Die PBS-Version enthielt die laufende Fassung ein zweites Mal (#023)
 - Der Agent meldete eine „neue Version“, auch wenn die installierte neuer war als die des Dashboards (#023)
 ### Geändert
 - Agent-Version 0.2.1; die Tests prüfen die Versionsangabe jetzt gegen die Konstante des Dashboards statt gegen eine abgeschriebene Zahl (#023)
 ## [0.14.0] – 2026-09-18
 ### Hinzugefügt
 - Der Agent meldet die Mitglieder seines Proxmox-Clusters; das Dashboard warnt bei Knoten ohne eigenen Agent (#022)
 - Host-Detail zeigt alle Cluster-Knoten mit Zustand „meldet sich“ oder „kein Agent“ (#022)
 - Wartezeiten zwischen Sendeversuchen über `PROXLEDGER_WARTEZEITEN` einstellbar, damit sich der Zwischenspeicher testen lässt (#018)
 ### Behoben
 - Die Produktversion enthielt bei Proxmox VE den Kernel ein zweites Mal (#018)
 - Die Bilder des Handbuchs zeigten allesamt die Anmeldeseite: Firefox verwirft fremd erzeugte Cookie-Dateien stillschweigend. Das Skript nutzt jetzt einen lokalen Vermittler, der die Sitzung mitschickt, und bricht ab, wenn alle Aufnahmen gleich groß sind (#016)
 ## [0.13.1] – 2026-09-17
 ### Sicherheit
 - SMTP-Passwort und Webhook-Geheimnis werden verschlüsselt in der Datenbank abgelegt (AES-256-GCM, Schlüssel aus `APP_SECRET`); eine Sicherung gibt sie damit nicht mehr im Klartext preis (#021)
 - Werte aus der Zeit davor werden weiterhin gelesen und beim nächsten Speichern umgeschlüsselt (#021)
 ## [0.13.0] – 2026-09-17
 ### Hinzugefügt
 - Prüfung bei jedem Push über Gitea Actions: Lint, Typen, Tests gegen PostgreSQL, Build, ShellCheck und Dokumentationsprüfung (#019)
 - `npm run pruefe:doku` vergleicht Version, Issue-Übersicht und Handbuch-Bilder auf Konsistenz (#019)
 ## [0.12.1] – 2026-09-17
 ### Hinzugefügt
 - Symbole für Browser-Tab (SVG und ICO), iOS-Startbildschirm und Web-Manifest, erzeugt mit `npm run icons` aus den SVG-Vorlagen in `assets/` (#017)
 ## [0.12.0] – 2026-09-17
 ### Hinzugefügt
 - Handbuch mit Bildern: Installation, Agent-Rollout, Zuweisung, Rechnungen, Warnungen, Benachrichtigungen, Exporte, Sicherung und Fehlersuche (#016)
 - `npm run screenshots` erzeugt alle Bilder des Handbuchs neu, auch im dunklen Design und in der Mobilansicht (#016)
 ## [0.11.1] – 2026-09-17
 ### Behoben
 - Nach der Anmeldung führte jeder Klick zurück zur Anmeldeseite: Das Sitzungs-Cookie erhielt im Produktionsbau immer das Merkmal `Secure` und wurde über `http://` vom Browser verworfen. Maßgeblich ist jetzt die tatsächliche Adresse (`APP_URL`) (#013)
 ### Geändert
 - Die Anmeldung läuft über ein gewöhnliches Formular statt über eine Server-Action; damit funktioniert sie auch ohne JavaScript (#013)
 ## [0.11.0] – 2026-09-17
 ### Geändert
 - Auswertung der Warnregeln um den Faktor 13 beschleunigt: neue Warnungen entstehen sammelweise (#015)
 - Aufgaben-Karte auf dem Dashboard zeigt höchstens zwölf Punkte und verweist für den Rest auf die Rechnungsliste (#015)
 - Große Tabellen blenden auf schmalen Bildschirmen gestaffelt Spalten aus, statt quer zu scrollen (#015)
 ### Behoben
 - Das Logo war im dunklen Design praktisch unsichtbar; seine Farben folgen jetzt dem Farbschema (#015)
 ## [0.10.0] – 2026-09-17
 ### Hinzugefügt
 - Dockerfile (mehrstufig, Standalone-Ausgabe, Betrieb ohne root) und `docker-compose.yml` mit Dashboard, Worker, Datenbank und einmaligem Migrationsdienst (#014)
 - LXC-Installer für Proxmox-Hosts: legt den Container an, installiert Docker, erzeugt Zufallspasswörter und startet alles (#014)
 - Beispiele für Caddy, nginx und Traefik als Reverse Proxy (#014)
 - Sicherungsskript für Datenbank, PDFs und Konfiguration (#014)
 - Zustandsprüfung unter `/api/gesundheit` (#014)
 - README mit Schnellstart, Agent-Rollout, Betriebs- und Sicherungshinweisen (#014)
 ## [0.9.0] – 2026-09-17
 ### Hinzugefügt
 - Anmeldung mit E-Mail und Passwort sowie über OIDC (z. B. authentik); der lokale Zugang bleibt als Rückfallweg immer nutzbar (#013)
 - Anmeldeseite im AdminLTE-Stil mit Logo (#013)
 - Audit-Log-Ansicht mit Filter nach Aktion und Entität (#013)
 ### Geändert
 - Audit-Einträge vermerken den angemeldeten Benutzer; Worker und Skripte erscheinen als „System“ (#013)
 ### Sicherheit
 - Alle Seiten der Oberfläche sind ohne Anmeldung nicht erreichbar; Agent-API und Skript-Auslieferung bleiben offen (#013)
 - Sitzungen als signiertes Cookie (`APP_SECRET`), fünf Anmeldeversuche je Kennung und Viertelstunde (#013)
 - Sicherheits-Kopfzeilen: HSTS, nosniff, DENY für Frames, Referrer-Policy, Permissions-Policy (#013)
 ## [0.8.0] – 2026-09-17
 ### Hinzugefügt
 - E-Mail-Versand über SMTP mit STARTTLS, abgestimmt auf Microsoft 365 (#012)
 - Generischer Webhook mit JSON-Nutzdaten und optionaler HMAC-Signatur (#012)
 - Tägliche oder wöchentliche Zusammenfassung mit offenen Warnungen, Rechnungspunkten und bald ablaufenden Subscriptions (#012)
 - Einstellungsseite mit Testversand und Versandprotokoll (#012)
 ### Sicherheit
 - Benachrichtigungen werden je Warnung nur einmal verschickt; fehlgeschlagene Versuche werden protokolliert und später wiederholt (#012)
 ## [0.7.0] – 2026-09-17
 ### Hinzugefügt
 - Zehn Warnregeln: Ablauf in 30/14/7 Tagen, Status nicht aktiv, Socket-Abweichung, keine Meldung seit 48 Stunden, geänderte Server-ID, mehrfach gemeldeter Key, Host ohne Kunde, fällige Proxmox-Rechnung, fehlende und überfällige Kundenrechnung (#011)
 - Worker-Prozess (`npm run worker`), der die Regeln stündlich auswertet; zusätzlich Auswertung nach jedem eingehenden Report (#011)
 - Seite „Warnungen“ mit Filter offen/erledigt, Quittieren, Schließen und sofortiger Prüfung (#011)
 - Einstellungsseite für Regeln und Schwellwerte (#011)
 ### Geändert
 - Warnungen schließen sich automatisch, sobald die Ursache behoben ist; Titel und Beschreibung werden laufend nachgeführt (#011)
 ## [0.6.0] – 2026-09-17
 ### Hinzugefügt
 - Jahresbahn mit zwölf Monaten, Heute-Linie und Gruppierung nach Kunde, aus echten Daten (#009)
 - Ablauf-Kalender für die nächsten 90 Tage samt Rechnungsstatus und eine Übersicht bereits abgelaufener Subscriptions (#009)
 - CSV-Export für Kundenübersicht und Rechnungsliste, PDF-Export für Hosts, Kunden und Rechnungen (#010)
 - Kundenunterlage als PDF: Hosts, Laufzeiten, Summen pro Jahr und Marge eines Kunden (#010)
 ### Geändert
 - Die Oberfläche arbeitet vollständig mit der Datenbank; Beispieldaten dienen nur noch dem Seed (#009)
 ## [0.5.0] – 2026-09-17
 ### Hinzugefügt
@@ -2,7 +2,7 @@
 ## Zeitübersicht
-**Gesamt:** 3 h 23 min
+**Gesamt:** 22 h 33 min
 | Issue | Zeit |
 |---|---|
@@ -15,6 +15,38 @@
 | #007 Host-Tabelle und Detailansichten | 0 h 25 min |
 | #020 Issues nach Gitea übertragen | 0 h 20 min |
 | #008 Laufzeiten und Rechnungen | 0 h 35 min |
 | #009 Jahresbahn und Ablauf-Kalender | 0 h 15 min |
 | #010 Export CSV und PDF | 0 h 20 min |
 | #011 Warnregeln | 0 h 30 min |
 | #012 Benachrichtigungen | 0 h 25 min |
 | #013 Authentifizierung | 0 h 30 min |
 | #014 Deployment | 0 h 40 min |
 | #015 Feinschliff | 0 h 35 min |
 | #016 Handbuch | 0 h 30 min |
 | #017 Favicons | 0 h 15 min |
 | #019 CI-Pipeline | 0 h 20 min |
 | #021 Geheimnisse verschlüsseln | 0 h 20 min |
 | #018 Feldtest auf echten Hosts | 0 h 40 min |
 | #022 Cluster-Abgleich | 0 h 25 min |
 | #023 Feldtest PBS | 0 h 35 min |
 | #024 OWASP-Härtung | 0 h 45 min |
 | #025 Einstellungen | 1 h 10 min |
 | #026 Auslieferung | 0 h 40 min |
 | #027 Rollen und Benutzerverwaltung | 1 h 20 min |
 | #028 Passkeys | 0 h 45 min |
 | #029 Einrichtungsdokumentation | 0 h 40 min |
 | #030 netbird Reverse Proxy | 0 h 20 min |
 | #031 Update für beide Varianten | 0 h 45 min |
 | #032 LXC-Installation korrigiert | 0 h 20 min |
 | #033 Weiterleitung auf Lausch-Adresse | 0 h 30 min |
 | #034 Bedienung auf dem Handy | 0 h 40 min |
 | #035 Tabellen als Karten | 0 h 50 min |
 | #036 Standort am Host | 0 h 30 min |
 | #037 Rabatt je Position | 0 h 55 min |
 | #038 Überbreite auf dem Handy | 0 h 40 min |
 | #039 Zugang zur Laufzeit | 0 h 30 min |
 | #040 Schlagworte sichtbar | 0 h 40 min |
 | #041 Doppelte Hosts | 0 h 50 min |
 | Meilenstein | Zeit |
 |---|---|
@@ -25,12 +57,19 @@
 | v0.4.1 | 0 h 10 min | **abgeschlossen**
 | v0.4.2 | 0 h 10 min | **abgeschlossen**
 | v0.5.0 | 0 h 35 min | **abgeschlossen**
 | v0.6.0 | 0 h 35 min | **abgeschlossen**
 | v0.7.0 | 0 h 30 min | **abgeschlossen**
 | v0.8.0 | 0 h 25 min | **abgeschlossen**
 | v0.9.0 | 0 h 30 min | **abgeschlossen**
 | v0.10.0 | 0 h 40 min | **abgeschlossen**
 | v0.11.0 | 0 h 35 min | **abgeschlossen**
 | v0.12.0 | 0 h 30 min | **abgeschlossen**
 ---
 ## 2026-09-17 · Sitzung 1 · 19:36–laufend
 **Issue:** #001–#007 (Meilensteine v0.1.0 bis v0.4.0)
-**Version:** 0.5.0
+**Version:** 0.24.0
 ### Erledigt
 - Auftrag gelesen, Rückfragen gestellt
@@ -56,8 +95,32 @@
 - Alles nach Gitea gepusht: main bei 51243c2, Tags v0.1.0 bis v0.4.1
 - #008 abgeschlossen: Laufzeit-Vorschläge bestätigen oder verwerfen, Rechnungen mit Positionen erfassen, PDF-Upload, Häkchen direkt in der Tabelle, Filter nach Status, Kunde und Jahr; Aufgabenliste auf dem Dashboard setzt jetzt echte Status
 - Meilenstein v0.5.0 abgeschlossen; 78 Tests
 - #009 abgeschlossen: Jahresbahn und Ablauf-Kalender (90 Tage) aus der Datenbank, dazu eine Karte für bereits abgelaufene Subscriptions; die Oberfläche nutzt keine Beispieldaten mehr
 - #010 abgeschlossen: CSV- und PDF-Export für Hosts, Kunden, einzelne Kundenunterlage und Rechnungsliste; PDFs serverseitig ohne Browser
 - Meilenstein v0.6.0 abgeschlossen
 - #011 abgeschlossen: zehn Warnregeln als reine Funktionen, Abgleich mit offenen Warnungen, Worker mit stündlichem Zeitplan, Auswertung nach jedem Report, Warnungsliste und Einstellungsseite; 123 Tests
 - Meilenstein v0.7.0 abgeschlossen
 - #012 abgeschlossen: SMTP (Microsoft 365), generischer Webhook mit Signatur, Zusammenfassung, Versandprotokoll, Testversand; keine Doppelmeldungen dank Prüfung gegen das Protokoll
 - Issue #021 angelegt: Zugangsdaten liegen noch unverschlüsselt in der Datenbank
 - Meilenstein v0.8.0 abgeschlossen; 134 Tests
 - #013 abgeschlossen: Anmeldung mit Passwort und OIDC, Schutz aller Seiten über `proxy.ts`, Anmeldeseite im AdminLTE-Stil, Audit-Log-Ansicht, Sicherheits-Kopfzeilen, Rate-Limit bei Anmeldeversuchen
 - Meilenstein v0.9.0 abgeschlossen; 147 Tests
 - #014 abgeschlossen: Dockerfile (Standalone, Non-root), Compose mit web/worker/postgres/migrate, LXC-Installer, Reverse-Proxy-Beispiele, Sicherungsskript, README mit Schnellstart und Betriebshinweisen
 - Container-Stapel wirklich gebaut und geprüft: Agent registriert sich, Report kommt an, Warnung entsteht automatisch
 - Meilenstein v0.10.0 abgeschlossen
 - #015 abgeschlossen: Dark-Mode geprüft (Logo war unsichtbar – behoben), Mobilansicht ohne Querscrollen, Lasttest mit 200 Hosts und 365.000 Reports, Auswertung der Warnregeln von 3813 auf 293 ms beschleunigt, Sicherheitsdurchsicht
 - Als v0.11.0 veröffentlicht statt 1.0.0: Feldtest, Handbuch, Favicons, CI und Verschlüsselung der Zugangsdaten stehen noch aus
 - 0.11.1: Anmeldefehler behoben (Secure-Cookie über http)
 - #016 abgeschlossen: Handbuch mit elf Kapiteln und 16 Bildern, dazu `npm run screenshots` zum Auffrischen
 - #017 abgeschlossen: Symbole für Tab, Startbildschirm und Manifest, erzeugt mit `npm run icons` aus SVG-Vorlagen
 - #019 abgeschlossen: Gitea-Actions-Workflow mit Lint, Typen, Tests, Build, ShellCheck und Doku-Prüfung
 - #021 abgeschlossen: SMTP-Passwort und Webhook-Geheimnis liegen verschlüsselt in der Datenbank (AES-256-GCM, Schlüssel aus APP_SECRET)
 ### Entscheidungen
 - **Warnungen sammelweise anlegen:** Einzelne Upserts kosteten bei 737 neuen Warnungen 3,8 s; mit `createMany` sind es 0,3 s.
 - **Keine 1.0.0 ohne Feldtest:** Solange der Agent auf keinem echten Proxmox-Host lief, wäre die Zahl ein falsches Versprechen.
 - **Kein Auth.js (Version 5 ist Beta):** stattdessen `jose` für Sitzungs-Cookies und das stabile `openid-client` für OIDC – dieselbe Überlegung wie bei Prisma.
 - **Warnstufen im Fingerabdruck** (`…:7`): Der Wechsel 30 → 14 → 7 schließt die alte Warnung und öffnet eine neue. Das ergibt je Stufe genau eine Benachrichtigung, ohne Sonderlogik für Eskalation.
 - **Rechnungsnummer als Schlüssel für Sammelrechnungen:** Dieselbe Nummer bei einer zweiten Laufzeit hängt eine Position an – kein eigener Dialog für „Sammelrechnung anlegen“ nötig.
 - **PDF-Prüfung am Dateianfang** statt am gemeldeten Typ; abgelegt wird unter der Prüfsumme, gleiche Datei also nur einmal.
 - **Screenshots mit Firefox headless** statt Playwright: Firefox ist vorhanden, es muss kein Browser samt Systembibliotheken nachinstalliert werden (dafür wäre root nötig).
@@ -77,11 +140,78 @@
 - **Server Actions rufen Services auf**, damit die Regeln ohne Next.js-Laufzeit testbar bleiben.
 ### Probleme / offene Fragen
 - Von Florian im Betrieb gemeldet: Nach der Anmeldung führte jeder Klick zurück zur Anmeldeseite. Ursache: `Secure`-Cookie über `http://`. Behoben in 0.11.1.
 - Der LXC-Installer ist ungetestet (kein Proxmox-Host verfügbar); gleiches gilt für den Agent im Feld (#018).
 - Prisma-Client erzeugte in der Produktionsumgebung bei jedem Zugriff einen neuen Verbindungspool → „too many clients“. Behoben: Client wird im Modul festgehalten.
 - Docker wurde von Florian installiert; die Entwicklungsdatenbank läuft auf Port 5433 (5432 bleibt für lokale Instanzen frei).
 - Favicon-Dateien (.ico/PNG) fehlen noch, weil kein SVG-Konverter installiert ist.
 - Der Agent wurde noch auf keinem echten Proxmox-Host installiert; die Tests arbeiten mit nachgebauten Befehlen.
 - Offen: Rolle „readonly“ zusätzlich zu Admin? (vorläufig vorgesehen)
 - #018 abgeschlossen: Feldtest auf zwei echten PVE-9.2-Hosts (einer mit, einer ohne Subscription, einer im Cluster); Installation, Timer, Zwischenspeicher und Nachsenden geprüft
 - #022 abgeschlossen: Cluster-Abgleich – jeder Agent meldet die Mitglieder, das Dashboard warnt bei Knoten ohne Agent
 - **Fehler im eigenen Werkzeug gefunden:** Alle Handbuch-Bilder waren in Wahrheit die Anmeldeseite. Firefox verwirft eine selbst angelegte Cookie-Datei stillschweigend. Jetzt läuft ein lokaler Vermittler mit, und das Skript bricht ab, wenn alle Aufnahmen gleich groß sind.
 - Feldtest auf einem echten Proxmox Backup Server (#023): der Agent hätte dort **nichts** gelesen – PBS gibt eine Rahmentabelle aus, kein `feld: wert`. Behoben, mit den echten Ausgaben als Testfälle
 - Der erfundene PBS-Testfall hatte den Fehler verdeckt. Lehre: ausgedachte Testdaten bestätigen nur die eigene Annahme
 - Uninstall zum ersten Mal auf einem echten Host geprüft – restlos sauber, damit ist #018 vollständig
 - Durchsicht nach OWASP (#024): drei echte Lücken gefunden – Server Actions ohne eigene Zugriffsprüfung, Login-CSRF und fehlende CSP. Alle behoben und mit Tests abgesichert
 - Erkenntnis: Der Schutz lag vollständig in einer einzigen Schicht (`proxy.ts`). Das fällt erst auf, wenn man die Endpunkte einzeln betrachtet statt die Oberfläche
 - Einstellungen im Dashboard (#025): vier Bereiche, alle Werte wirken auch wirklich – der Melderhythmus zum Beispiel bis in den erzeugten systemd-Timer hinein, live geprüft
 - Dabei die OIDC-Lücke aus #024 geschlossen: Domänenliste und Schalter gegen automatisch angelegte Konten
 - Bewusst nicht gebaut: „stumm nach X Tagen“ (steht schon bei den Warnregeln) und die Währung in der Browseransicht
 - Auslieferung finalisiert (#026): Docker-Weg mit Update-Skript, dazu Skripte nach Art der Helper-Scripts für einen LXC ohne Docker
 - Recherche dazu: Das Gerüst der community-scripts liegt inzwischen in einem eigenen Repository, und neue Skripte gehören zuerst nach ProxmoxVED. Eine Einreichung setzt öffentlichen Quelltext voraus – deshalb vorerst intern
 - Roadmap geschrieben: Bis 1.0.0 fehlt kein Code mehr, sondern Erprobung (PMG, PBS mit Lizenz, ein Monat Dauerbetrieb, einmal eine Sicherung zurückspielen)
 - Rollen und Benutzerverwaltung (#027): Die Einschränkung sitzt in den Abfragen selbst, damit keine Seite vergessen kann, sie weiterzugeben. Sechs Tests prüfen, dass ein Kundenkonto weder fremde Hosts noch Einkaufspreise sieht
 - Dabei aufgefallen: Neu angelegte OIDC-Konten hätten die Modellvorgabe ADMIN geerbt – behoben, mit eigener Einstellung und Test
 - Passkeys (#028): passwortlos, mehrere je Konto, Aufgabe in einem kurzlebigen Cookie. Nur über HTTPS nutzbar – die Seite sagt es, statt still zu scheitern
 - Einrichtungsdokumentation (#029): Beim Aufschreiben des OIDC-Wegs fielen zwei Fehler auf, die nur hinter einem Reverse Proxy auftreten – Rückkehradresse und Code-Einlösung nahmen die interne Adresse. Beides behoben
 - Erkenntnis: Eine Anleitung Schritt für Schritt aufzuschreiben findet Fehler, die kein Test findet, weil sie nur in einer bestimmten Betriebsform auftreten
 - netbird Reverse Proxy (#030) in die Anleitung aufgenommen – Florians Hinweis, dass die Beta gut läuft. Beim Durchgehen der Möglichkeiten fiel der Fallstrick auf: Eine Anmeldehürde vor dem Dienst trifft auch `/api/agent` und legt alle Agents still
 ### 03.10.2026 – Prüfung vor dem Einsatz
 - `npm audit` vor der Freigabe erneut laufen lassen: In den zwei Wochen seit dem letzten Stand kam eine kritische Meldung zu Next.js dazu (RCE in `next/og`). Wir nutzen `next/og` nicht, waren also nicht angreifbar – angehoben auf 16.3.8, Tests und Build grün
 - Lehre für den Betrieb: Vor jedem Produktivgang und danach regelmäßig `npm audit` prüfen, nicht nur bei Änderungen am Code
 - Update- und Sicherungsskript für beide Installationsarten (#031). Beim Durchspielen zwei Fehler gefunden: Die Zustandsprüfung des Web-Containers konnte nie gelingen (Next bindet an `HOSTNAME`, Docker setzt dort den Containernamen), und eine fehlgeschlagene Sicherung hielt die Aktualisierung nicht auf
 - Lehre: Ein Skript, das nie unter echten Bedingungen gelaufen ist, ist eine Behauptung. Erst der Durchlauf gegen einen laufenden Stapel hat beide Fehler gezeigt
 - Erster echter Einsatz durch Florian – und prompt zwei Fehler, die kein Test gezeigt hatte (#032, #033)
 - #033 war hausgemacht: Mein `HOSTNAME=0.0.0.0` aus #031 hat den Healthcheck repariert und dafür alle Weiterleitungen aus Server Actions auf `0.0.0.0` gelenkt. Vorher stand dort der Containername – derselbe Fehler, nur unauffälliger
 - Lehre: Weiterleitungen gehören aus der konfigurierten Adresse gebaut, nie aus dem, was der Server über sich selbst weiß
 - Mobile Bedienung (#034): Das Menü ließ sich auf dem Telefon nicht schließen – AdminLTE-Markup ohne AdminLTE-JavaScript. Eigener Zustand, abdunkelnde Fläche, Schließen beim Navigieren und mit Escape
 - Lehre: Die Mobilansicht war mit Screenshots geprüft, nicht mit den Fingern. Ein Bild zeigt nicht, dass etwas nicht wieder weggeht
 - Breite Tabellen werden auf dem Telefon zu Karten (#035); dabei fiel auf, dass `pl-touch-target` am Kontrollkästchen selbst saß und es zum leeren Kasten aufblies
 - Standort am Host (#036): Die Meldung lautete „kann man nicht einstellen“ – tatsächlich löschte jede Kundenzuweisung den vorhandenen Standort, weil das Formular ihn nicht mitsendete und die Aktion ihn trotzdem las
 - Beide Fehler kamen aus dem echten Einsatz, nicht aus den Tests. Das bleibt die ergiebigste Quelle
 - Eine echte Proxmox-Rechnung hat drei Fehler im Rechnungsteil aufgedeckt (#037): Rabatt an der falschen Ebene, nirgends abgezogen, und 19 % USt als Vorgabe, wo Reverse Charge gilt
 - Florians Schilderung des Ablaufs (unbezahlte Rechnung → Kundenrechnung → Kunde zahlt → selbst zahlen → PAID-Fassung) ergab die zwölfte Warnregel
 - Lehre: Ein Beleg aus der Praxis sagt mehr über das Datenmodell als jede Annahme darüber, wie Rechnungen aussehen
 - Überbreite auf dem Handy (#038): Drei Verursacher, ein Muster – ein Element breiter als das Fenster zoomt die ganze Seite heraus
 - Dabei einen eigenen Fehler aus #037 gefunden: Die Detailseite rechnete weiter mit dem Listenpreis. Beim Ändern einer Rechengröße reicht es nicht, die Abfragen anzupassen – auch die Seiten rechnen selbst
 - Das Aufnahme-Skript kann jetzt gezielt in Telefonbreite aufnehmen; damit ließ sich die Behebung belegen statt nur behaupten
 - #039: Auf dem Telefon führte kein Weg zu den Rechnungsformularen – die Laufzeit war nicht verlinkt und die Spalte erst ab 992 px sichtbar
 - Dritte Stelle, die den Einkauf ohne Rabatt rechnete. Beim Ändern einer Rechengröße gehört jede Stelle gesucht, die sie selbst bildet – nicht nur die Abfragen
 - Bootstraps `d-*`-Klassen setzen `display` mit `!important`; für Spalten in der Kartenansicht braucht es eigene Klassen
 - Schlagworte und Notizen sichtbar gemacht (#040). Beides gab es längst – nur eben versteckt in einem Reiter, und damit nutzlos zum Unterscheiden gleichnamiger Hosts
 - Kein neues Feld gebaut: Ein zweites „Kommentar“ hätte dieselbe Angabe an zwei Orten gehalten
 - Doppelte Hosts (#041): Zwei Einträge desselben Namens beim selben Kunden entstehen, wenn sich die Maschinenkennung ändert. Neue Warnregel plus die bis dahin fehlende Möglichkeit, einen Host überhaupt loszuwerden
 - Bewusst kein automatisches Zusammenführen: Es müsste raten, welcher Eintrag welche Rechnung erbt
 ### Nächster Schritt
- #009 Kundenübersicht, Ablauf-Kalender und Jahresbahn auf Datenbankbasis
+- #016 Benutzerhandbuch mit Screenshots, danach #017 Favicons und #019 CI-Pipeline
 - Für 1.0.0 fehlt noch: PMG (kein Host verfügbar) und der Fall „aktive Subscription auf PBS“ (#023)
@@ -0,0 +1,53 @@
 # ProxLedger – Abbild für Dashboard und Worker.
 # Beide Dienste teilen sich dieses Abbild und unterscheiden sich nur im Startbefehl.
 FROM node:24-alpine AS basis
 WORKDIR /app
 # openssl wird von Prisma benötigt, tini beendet Prozesse sauber.
 RUN apk add --no-cache openssl tini
 # ---------------------------------------------------------------- Abhängigkeiten
 FROM basis AS abhaengigkeiten
 COPY package.json package-lock.json ./
 COPY prisma ./prisma
 COPY prisma7.config.ts ./
 RUN npm ci --ignore-scripts
 # ---------------------------------------------------------------- Bauen
 FROM abhaengigkeiten AS bauen
 COPY . .
 RUN npx prisma generate \
 && npm run build \
 && npm run build:worker
 # ---------------------------------------------------------------- Laufzeit
 FROM basis AS laufzeit
 ENV NODE_ENV=production
 ENV PORT=3000
 # Ohne diese Zeile nimmt Next den von Docker gesetzten HOSTNAME als Bindeadresse und lauscht
 # nur auf der Container-IP. Die Zustandsprüfung über 127.0.0.1 schlägt dann immer fehl.
 ENV HOSTNAME=0.0.0.0
 RUN addgroup -g 1001 -S proxledger && adduser -S proxledger -u 1001 -G proxledger
 # Next.js im Standalone-Modus bringt seine eigenen Abhängigkeiten mit.
 COPY --from=bauen --chown=proxledger:proxledger /app/.next/standalone ./
 COPY --from=bauen --chown=proxledger:proxledger /app/.next/static ./.next/static
 COPY --from=bauen --chown=proxledger:proxledger /app/public ./public
 # Agent-Skripte werden zur Laufzeit ausgeliefert.
 COPY --from=bauen --chown=proxledger:proxledger /app/agent ./agent
 # Worker als gebündelte Datei. Migrationen übernimmt der eigene Dienst „migrate“
 # (Stufe „bauen“), damit dieses Abbild schlank bleibt und keine CLI mitschleppt.
 COPY --from=bauen --chown=proxledger:proxledger /app/dist ./dist
 COPY --chown=proxledger:proxledger deploy/start.sh ./start.sh
 RUN mkdir -p /data/uploads && chown -R proxledger:proxledger /data
 VOLUME ["/data"]
 ENV UPLOAD_DIR=/data/uploads
 USER proxledger
 EXPOSE 3000
 ENTRYPOINT ["/sbin/tini", "--"]
 CMD ["./start.sh", "web"]
@@ -3,7 +3,56 @@
 Zentrales Dashboard für den Subscription-Status aller Proxmox-Hosts (VE, Backup Server, Mail Gateway).
 Auf jedem Host meldet ein schlanker Agent täglich per HTTPS seinen Status (Push-Modell) – auch aus Kundennetzen hinter NAT.
-> **Status:** in Entwicklung (0.1.0-dev). Noch nicht produktiv einsetzen.
+> **Status:** einsatzbereit. Der Agent ist auf echten Hosts erprobt – Proxmox VE 9.2 mit und ohne
 > Subscription, im Cluster und einzeln, sowie Proxmox Backup Server 4.2 (#018, #023).
 > Ungeprüft: Mail Gateway und eine aktive Subscription auf PBS. Was bis 1.0 fehlt, steht in
 > [docs/roadmap.md](docs/roadmap.md).
 ## Schnellstart
 Auf einem Rechner mit Docker:
 ```bash
 git clone https://git.wilde-server.de/florian.wilde/ProxLedger.git proxledger && cd proxledger
 cp .env.example .env
 # Pflichtangaben setzen: APP_SECRET, POSTGRES_PASSWORD, ADMIN_PASSWORD, APP_URL
 docker compose up -d
 ```
 Beim ersten Start legt der Dienst `migrate` das Schema an und erzeugt den Administrator aus der `.env`.
 Danach ist das Dashboard unter `APP_URL` erreichbar.
 Aktualisieren geht mit einem Befehl – er sichert vorher, baut neu, migriert und prüft zum Schluss,
 ob das Dashboard wieder antwortet:
 ```bash
 bash deploy/update.sh
 ```
 **Auf einem Proxmox-Host** gibt es zwei Wege zu einem fertigen LXC-Container:
 ```bash
 bash deploy/lxc-installer.sh          # eigener Installer: Container mit Docker darin
 ```
 ```bash
 # Nach Art der Proxmox VE Helper-Scripts: Container mit Node und PostgreSQL direkt darin
 bash -c "$(curl -fsSL https://git.wilde-server.de/florian.wilde/ProxLedger/raw/branch/main/deploy/community-scripts/ct/proxledger.sh)"
 ```
 Der zweite Weg folgt den Konventionen von [community-scripts.org](https://community-scripts.org) und
 braucht kein Docker; Einzelheiten und die Voraussetzungen für eine Einreichung stehen in
 [deploy/community-scripts/README.md](deploy/community-scripts/README.md).
 ### Agent ausrollen
 1. Im Dashboard unter *Einstellungen → Agent-Tokens* einen Enrollment-Token erzeugen
 2. Auf jedem Proxmox-Host als root:
   ```bash
   curl -fsSL https://<dashboard>/install.sh | bash -s -- --token <ENROLL_TOKEN>
   ```
 3. Der Host meldet sich sofort und danach täglich. Unter *Hosts → Nicht zugeordnet* einem Kunden zuweisen –
   oder den Token gleich mit Kundenbindung erzeugen, dann entfällt der Schritt.
 ## Entwicklung
@@ -22,7 +71,27 @@ npm run typecheck
 npm test           # legt bei Bedarf die Testdatenbank an
 ```
-Weitere Skripte: `npm run db:studio` (Datenbank-Oberfläche), `npm run db:down` (Container stoppen).
+Der Worker wertet die Warnregeln stündlich aus und läuft als eigener Prozess:
 ```bash
 npm run worker        # Dauerbetrieb
 npm run alerts:check  # einmalige Auswertung
 ```
 Weitere Skripte:
 | Befehl | Zweck |
 |---|---|
 | `npm run db:studio` | Datenbank-Oberfläche |
 | `npm run db:down` | Datenbank-Container stoppen |
 | `npm run icons` | Symbole aus den SVG-Vorlagen erzeugen |
 | `npm run screenshots -- --alle` | Bilder für das Handbuch auffrischen |
 | `npm run pruefe:doku` | Doku, Versionen und Bilder auf Konsistenz prüfen |
 | `npm run lasttest` | Abfragen mit 200 Hosts und fünf Jahren Reports messen |
 Jeder Push wird von [Gitea Actions](.gitea/workflows/ci.yml) geprüft: Lint, Typen, Tests gegen eine
 PostgreSQL-Instanz, Build, ShellCheck für die Agent-Skripte und die Konsistenz der Dokumentation.
 Dafür muss auf dem Gitea-Server ein `act_runner` eingerichtet sein.
 ## Agent auf einem Proxmox-Host installieren
@@ -45,6 +114,56 @@ Protokoll: `journalctl -t proxledger`. Ist das Dashboard nicht erreichbar, versu
 wachsendem Abstand und legt den Report danach unter `/var/lib/proxledger/spool/` ab; beim nächsten Lauf wird er
 nachgesendet.
 ## Anmeldung
 Die Oberfläche ist vollständig geschützt; die Agent-API und die Skript-Auslieferung bleiben offen, weil
 sie sich mit eigenen Tokens ausweisen.
 - **Lokaler Zugang:** E-Mail und Passwort aus dem Seed (`ADMIN_EMAIL`, `ADMIN_PASSWORD`). Fünf Fehlversuche
  je Kennung und Viertelstunde, danach Sperre (einstellbar unter *Einstellungen → System*).
  Benutzer sperren oder Passwort setzen: `npm run benutzer -- sperren <email>`.
 - **Passkey:** passwortlos über WebAuthn, mehrere je Konto, Verwaltung unter *Meine Passkeys*. Setzt HTTPS voraus (außer `localhost`).
 - **OIDC (z. B. authentik):** `OIDC_ISSUER`, `OIDC_CLIENT_ID`, `OIDC_CLIENT_SECRET` setzen – Schritt für Schritt in [docs/betrieb/authentik.md](docs/betrieb/authentik.md). Rückkehradresse
  ist `<APP_URL>/api/auth/oidc/callback`. Ohne diese Werte erscheint nur der lokale Zugang – der bleibt
  absichtlich immer nutzbar, falls der Anmeldedienst ausfällt. Unter *Einstellungen → System* lässt sich
  einschränken, welche E-Mail-Domänen zugelassen sind und ob unbekannte Konten angelegt werden dürfen.
 - **`APP_SECRET`** (mindestens 32 Zeichen) signiert die Sitzungs-Cookies. Ändert sich der Wert, sind alle
  Sitzungen ungültig.
 ## Einrichtung im Betrieb
 | Anleitung | Inhalt |
 |---|---|
 | [Inbetriebnahme](docs/betrieb/inbetriebnahme.md) | von null zum meldenden Host, in der richtigen Reihenfolge |
 | [Reverse Proxy](docs/betrieb/reverse-proxy.md) | HTTPS mit nginx Proxy Manager, netbird Reverse Proxy (Beta) oder netbird pur |
 | [authentik](docs/betrieb/authentik.md) | Anmeldung über OIDC, samt Fehlerbildern |
 | [Sicherung](docs/betrieb/sicherung.md) | was gesichert wird – und wie man es zurückspielt |
 ## Einstellungen
 Die meisten Betriebswerte stehen unter *Einstellungen → System* und wirken sofort: Dashboard-Adresse,
 Melderhythmus und Selbstaktualisierung der Agents, Steuersatz, Zahlungsziel und Aufschlag,
 Sitzungsdauer und Anmeldeversuche, OIDC-Beschränkungen, Aufbewahrungsfristen sowie Firmenangaben und
 Zeitzone für die PDF-Ausgaben.
 In der Umgebung bleiben nur `APP_SECRET` und `DATABASE_URL` – beide werden gebraucht, bevor die
 Anwendung die Datenbank lesen kann.
 Wie die Anwendung gegen die OWASP Top 10 dasteht (einschließlich der Punkte, die bewusst offen
 bleiben), steht in [docs/sicherheit.md](docs/sicherheit.md).
 ## Exporte
 | Ansicht | CSV | PDF |
 |---|---|---|
 | Hosts | `/hosts/export` | `/hosts/export?format=pdf` |
 | Kunden | `/kunden/export` | `/kunden/export?format=pdf` |
 | Einzelner Kunde | – | `/kunden/<id>/export` (Anlage für Kundenunterlagen) |
 | Rechnungen | `/rechnungen/export` | `/rechnungen/export?format=pdf` |
 Alle Exporte übernehmen die Filter der jeweiligen Ansicht. CSV kommt als UTF-8 mit BOM und Semikolon,
 öffnet sich also ohne Umwege in Excel.
 ## Issues nach Gitea übertragen
 Die Issues werden als Markdown-Dateien in `docs/issues/` gepflegt – sie liegen damit im Repo und wandern mit
@@ -63,8 +182,51 @@ zusätzlich das Recht `issue:write`. Wer beides trennen möchte, setzt `GITEA_UR
 Der Abgleich legt Labels und Meilensteine an, erkennt vorhandene Issues an der Nummer im Titel,
 aktualisiert sie und schließt erledigte. Ein zweiter Lauf erzeugt keine Dubletten.
 ## Betrieb
 **Dienste:** `web` (Dashboard), `worker` (Warnregeln und Benachrichtigungen), `postgres`, dazu `migrate`,
 der nur beim Start läuft.
 ```bash
 docker compose ps                      # Zustand
 docker compose logs -f web worker      # Protokoll
 docker compose up -d --build           # nach einem Update
 ```
 **Hinter einem Reverse Proxy:** Beispiele für Caddy, nginx und Traefik liegen in
 [deploy/reverse-proxy/](deploy/reverse-proxy/). Wichtig ist, dass `X-Forwarded-For` durchgereicht wird –
 darauf stützt sich das Rate-Limit der Agent-API. `APP_URL` muss auf die öffentliche Adresse zeigen,
 sonst stimmen die Links in E-Mails und im Installations-Einzeiler nicht.
 **Zustandsprüfung:** `GET /api/gesundheit` antwortet mit `{"ok":true}`, solange die Datenbank erreichbar ist.
 ## Sicherung
 [deploy/backup.sh](deploy/backup.sh) sichert Datenbank, hochgeladene PDFs und die `.env`:
 ```bash
 ./deploy/backup.sh /var/backups/proxledger
 ```
 Für regelmäßige Sicherungen in die Crontab eintragen:
 ```
 30 2 * * * /opt/proxledger/deploy/backup.sh /var/backups/proxledger
 ```
 Zum Zurückspielen:
 ```bash
 gunzip -c datenbank-20260917-023000.sql.gz | docker compose exec -T postgres psql -U proxledger proxledger
 ```
 **Wichtig:** `APP_SECRET` mitsichern und sicher aufbewahren. Der Wert signiert die Sitzungen **und**
 verschlüsselt die Zugangsdaten für SMTP und Webhook in der Datenbank. Geht er verloren, müssen diese
 Zugangsdaten neu eingetragen werden; eine Sicherung allein gibt sie nicht preis.
 ## Dokumentation
 - **[Handbuch mit Bildern](docs/anleitung/README.md)** – Installation, Agent-Rollout, Rechnungen, Warnungen, Fehlersuche
 - [Architektur- und Umsetzungsplan](docs/architektur.md)
 - [Issues](docs/issues/README.md)
 - [Changelog](CHANGELOG.md) · [Devlog](DEVLOG.md)
@@ -16,9 +16,17 @@ set -o nounset
 set -o pipefail
 DASHBOARD_URL="${PROXLEDGER_URL:-@@DASHBOARD_URL@@}"
 # Melderhythmus und Streuung setzt das Dashboard beim Ausliefern ein (Einstellungen → System).
 # Wird das Skript unverändert aus dem Quelltext ausgeführt, bleiben die Platzhalter stehen;
 # dann gelten die Vorgaben.
 TIMER_ONCALENDAR="@@TIMER_ONCALENDAR@@"
 TIMER_STREUUNG="@@TIMER_STREUUNG@@"
 case "$TIMER_ONCALENDAR" in *@@*) TIMER_ONCALENDAR="daily" ;; esac
 case "$TIMER_STREUUNG" in *@@*) TIMER_STREUUNG="4h" ;; esac
 TOKEN=""
 CA_CERT=""
-AUTO_UPDATE="no"
+AUTO_UPDATE="@@AUTO_UPDATE@@"
 case "$AUTO_UPDATE" in yes | no) ;; *) AUTO_UPDATE="no" ;; esac
 AKTION="install"
 CONFIG_VERZEICHNIS="/etc/proxledger"
@@ -202,14 +210,14 @@ ProtectSystem=full
 ProtectHome=true
 UNIT
-cat >"${SYSTEMD_VERZEICHNIS}/proxledger.timer" <<'UNIT'
+cat >"${SYSTEMD_VERZEICHNIS}/proxledger.timer" <<UNIT
 [Unit]
-Description=Täglicher ProxLedger-Report
+Description=ProxLedger-Report
 [Timer]
-OnCalendar=daily
+OnCalendar=${TIMER_ONCALENDAR}
-# Verteilt die Meldungen aller Hosts über vier Stunden.
+# Verteilt die Meldungen aller Hosts über diesen Zeitraum.
-RandomizedDelaySec=4h
+RandomizedDelaySec=${TIMER_STREUUNG}
 Persistent=true
 Unit=proxledger.service
@@ -219,7 +227,7 @@ UNIT
 systemctl daemon-reload
 systemctl enable --now proxledger.timer >/dev/null
-erfolg "systemd-Timer aktiviert (täglich, zufällig um bis zu 4 Stunden versetzt)."
+erfolg "systemd-Timer aktiviert (${TIMER_ONCALENDAR}, zufällig um bis zu ${TIMER_STREUUNG} versetzt)."
 hinweis "Sende ersten Report …"
 if "$AGENT_PFAD" --report; then
@@ -12,11 +12,12 @@
 set -o nounset
 set -o pipefail
-AGENT_VERSION="0.2.0"
+AGENT_VERSION="0.2.1"
 CONFIG_DATEI="${PROXLEDGER_CONFIG:-/etc/proxledger/agent.conf}"
 SPOOL_VERZEICHNIS="${PROXLEDGER_SPOOL:-/var/lib/proxledger/spool}"
 SPOOL_MAXIMUM=30
-WARTEZEITEN=(30 120 480)
+# Wartezeiten zwischen den Versuchen; für Tests über PROXLEDGER_WARTEZEITEN kürzbar.
 read -r -a WARTEZEITEN <<<"${PROXLEDGER_WARTEZEITEN:-30 120 480}"
 # --------------------------------------------------------------------- Protokoll
@@ -105,15 +106,24 @@ produkt_erkennen() {
 }
 subscription_ausgabe() {
  local ausgabe=""
  case "$1" in
    # PVE kennt --output-format nicht (geprueft auf 9.2), liefert aber "feld: wert".
    pve) pvesubscription get 2>/dev/null ;;
-    pbs) proxmox-backup-manager subscription get 2>/dev/null ;;
+    # PBS gibt ohne --output-format eine Rahmentabelle aus, aus der sich schlecht lesen laesst.
    # JSON kann es (geprueft auf 4.2); aeltere Fassungen faengt die Tabellenauswertung ab.
    pbs)
      ausgabe=$(proxmox-backup-manager subscription get --output-format json 2>/dev/null)
      [ -n "$ausgabe" ] || ausgabe=$(proxmox-backup-manager subscription get 2>/dev/null)
      printf '%s' "$ausgabe"
      ;;
    pmg) pmgsubscription get 2>/dev/null ;;
    *) printf '' ;;
  esac
 }
-# Liest ein Feld aus der Subscription-Ausgabe. Unterstützt "feld: wert" und JSON.
+# Liest ein Feld aus der Subscription-Ausgabe. Unterstuetzt "feld: wert", JSON und die
 # Rahmentabelle von PBS ("| feld | wert |" mit Unicode-Strichen).
 feld_lesen() {
  local feld="$1" text="$2" wert
  wert=$(printf '%s\n' "$text" | sed -n "s/^[[:space:]]*${feld}[[:space:]]*:[[:space:]]*//p" | head -n1)
@@ -121,6 +131,15 @@ feld_lesen() {
    wert=$(printf '%s\n' "$text" |
      sed -n "s/.*\"${feld}\"[[:space:]]*:[[:space:]]*\"\{0,1\}\([^\",}]*\)\"\{0,1\}.*/\1/p" | head -n1)
  fi
  if [ -z "$wert" ]; then
    # Tabellenzeile: Trennzeichen ist U+2502; awk zerlegt daran und liefert die zweite Spalte.
    wert=$(printf '%s\n' "$text" |
      awk -F'\xe2\x94\x82' -v feld="$feld" '
        NF >= 3 {
          name = $2; gsub(/^[ \t]+|[ \t]+$/, "", name)
          if (name == feld) { wert = $3; gsub(/^[ \t]+|[ \t]+$/, "", wert); print wert; exit }
        }')
  fi
  # Umschließende Anführungszeichen und Leerzeichen entfernen.
  wert=${wert%\"}
  wert=${wert#\"}
@@ -128,9 +147,13 @@ feld_lesen() {
 }
 produkt_version() {
  # Bei PVE hängt die Kernel-Angabe mit im String ("… (running kernel: …)").
  # Der Kernel wird separat gemeldet, deshalb hier abschneiden.
  case "$1" in
-    pve) pveversion 2>/dev/null | head -n1 ;;
+    pve) pveversion 2>/dev/null | head -n1 | sed 's/ (running kernel.*//' ;;
-    pbs) proxmox-backup-manager version 2>/dev/null | head -n1 ;;
+    # PBS haengt die laufende Fassung an ("… 4.2.6-1 running version: 4.2.1");
    # gemeldet wird die installierte.
    pbs) proxmox-backup-manager version 2>/dev/null | head -n1 | sed 's/ running version.*//' ;;
    pmg) pmgversion 2>/dev/null | head -n1 ;;
    *) printf '' ;;
  esac
@@ -150,6 +173,14 @@ cluster_name() {
  fi
 }
 # Namen aller Cluster-Mitglieder laut corosync. Auch Knoten ohne Agent stehen hier –
 # daraus erkennt das Dashboard vergessene Knoten (#022).
 cluster_mitglieder() {
  if command -v pvecm >/dev/null 2>&1; then
    pvecm nodes 2>/dev/null | awk '/^[[:space:]]*[0-9]+[[:space:]]+[0-9]+/ {print $3}' | sed 's/ *(local)//'
  fi
 }
 node_name() {
  if command -v pvecm >/dev/null 2>&1 && pvecm status >/dev/null 2>&1; then
    hostname -s 2>/dev/null
@@ -220,6 +251,7 @@ report_erzeugen() {
    "ips": $(ip_adressen | json_liste),
    "clusterName": $(json_text "$(cluster_name)"),
    "nodeName": $(json_text "$(node_name)"),
    "clusterMitglieder": $(cluster_mitglieder | json_liste),
    "kernel": $(json_text "$(uname -r 2>/dev/null)"),
    "uptimeSekunden": $(json_zahl "$(uptime_sekunden)"),
    "cpuModell": $(json_text "$(cpu_modell)"),
@@ -383,8 +415,15 @@ aktion_test() {
  [ "$(printf '%s' "$antwort" | tail -n1)" = "200" ]
 }
 # Ist $1 eine neuere Fassung als $2? `sort -V` vergleicht Versionsnummern der Reihe nach.
 version_neuer() {
  [ "$1" != "$2" ] && [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
 }
 version_pruefen() {
-  if [ -n "${NEUESTE_VERSION:-}" ] && [ "$NEUESTE_VERSION" != "$AGENT_VERSION" ]; then
+  # Nur melden, wenn das Dashboard wirklich eine neuere Fassung kennt. Sonst warnt ein Agent,
  # der einer Testinstallation vorauseilt, gegen sich selbst (im Feldtest #023 aufgefallen).
  if [ -n "${NEUESTE_VERSION:-}" ] && version_neuer "$NEUESTE_VERSION" "$AGENT_VERSION"; then
    protokoll notice "Neue Agent-Version verfügbar: ${NEUESTE_VERSION} (installiert: ${AGENT_VERSION})."
    if [ "$AUTO_UPDATE" = "yes" ]; then
      aktion_update
@@ -0,0 +1,4 @@
 <!-- Fassung für 16 px: nur das P. -->
 <svg viewBox="0 0 48 48" xmlns="http://www.w3.org/2000/svg">
  <path fill-rule="evenodd" d="M6 2h21a14 14 0 0 1 0 28H18v16H6zM18 13h8a3 3 0 0 1 0 6h-8z" fill="#1E2A44"/>
 </svg>
@@ -0,0 +1,5 @@
 <!-- Fassung für 32 px: eine Linie, kräftigere Formen. -->
 <svg viewBox="0 0 48 48" xmlns="http://www.w3.org/2000/svg">
  <path fill-rule="evenodd" d="M7 3h20a13 13 0 0 1 0 26H17v16H7zM17 12h9a4 4 0 0 1 0 8h-9z" fill="#1E2A44"/>
  <path d="M24 38h19" stroke="#17A2B8" stroke-width="5" stroke-linecap="round"/>
 </svg>
@@ -0,0 +1,8 @@
 <!-- Fassung für Startbildschirm-Symbole: Monogramm auf dunklem Grund mit Rand. -->
 <svg viewBox="0 0 180 180" xmlns="http://www.w3.org/2000/svg">
  <rect width="180" height="180" rx="34" fill="#1E2A44"/>
  <g transform="translate(34 30) scale(2.3)">
    <path fill-rule="evenodd" d="M8 4h19a12 12 0 0 1 0 24H16v16H8zM16 11h10a5 5 0 0 1 0 10H16z" fill="#FFFFFF"/>
    <path d="M22 36h20M22 43h14" stroke="#17A2B8" stroke-width="3.5" stroke-linecap="round"/>
  </g>
 </svg>
@@ -0,0 +1,5 @@
 <!-- ProxLedger-Monogramm, Standardfassung (heller Grund). Quelle für alle abgeleiteten Dateien. -->
 <svg viewBox="0 0 48 48" xmlns="http://www.w3.org/2000/svg">
  <path fill-rule="evenodd" d="M8 4h19a12 12 0 0 1 0 24H16v16H8zM16 11h10a5 5 0 0 1 0 10H16z" fill="#1E2A44"/>
  <path d="M22 36h20M22 43h14" stroke="#17A2B8" stroke-width="3.5" stroke-linecap="round"/>
 </svg>
@@ -0,0 +1,72 @@
 #!/usr/bin/env bash
 # Sichert Datenbank, hochgeladene PDFs und die Konfiguration von ProxLedger.
 # Erkennt selbst, ob die Installation mit Docker oder als Dienst im Container läuft.
 #
 #   ./backup.sh /pfad/zum/sicherungsordner
 #
 # Für regelmäßige Sicherungen in die Crontab eintragen, z. B. täglich um 02:30 Uhr:
 #   30 2 * * * /opt/proxledger/deploy/backup.sh /var/backups/proxledger
 set -o errexit
 set -o nounset
 set -o pipefail
 ZIEL="${1:-/var/backups/proxledger}"
 AUFBEWAHRUNG_TAGE="${AUFBEWAHRUNG_TAGE:-30}"
 STAND=$(date +%Y%m%d-%H%M%S)
 VERZEICHNIS="${COMPOSE_VERZEICHNIS:-$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)}"
 mkdir -p "$ZIEL"
 cd "$VERZEICHNIS"
 # Siehe deploy/update.sh – der Dienst ist das eindeutigere Merkmal.
 if systemctl cat proxledger.service >/dev/null 2>&1; then
  ART="dienst"
 else
  ART="docker"
 fi
 echo "Sichere ProxLedger (${ART}) nach ${ZIEL} …"
 if [ "$ART" = "docker" ]; then
  echo "Sichere Datenbank …"
  docker compose exec -T postgres pg_dump -U "${POSTGRES_USER:-proxledger}" "${POSTGRES_DB:-proxledger}" \
    | gzip > "${ZIEL}/datenbank-${STAND}.sql.gz"
  echo "Sichere hochgeladene Dateien …"
  docker compose run --rm -T --entrypoint tar web -czf - /data/uploads > "${ZIEL}/uploads-${STAND}.tar.gz" 2>/dev/null || true
 else
  # DATABASE_URL steht in der .env; pg_dump versteht sie direkt.
  # shellcheck disable=SC1091
  set -o allexport
  . ./.env
  set +o allexport
  [ -n "${DATABASE_URL:-}" ] || {
    echo "DATABASE_URL fehlt in der .env – ohne sie keine Sicherung." >&2
    exit 1
  }
  echo "Sichere Datenbank …"
  pg_dump "$DATABASE_URL" | gzip > "${ZIEL}/datenbank-${STAND}.sql.gz"
  echo "Sichere hochgeladene Dateien …"
  UPLOADS="${UPLOAD_DIR:-${VERZEICHNIS}/data/uploads}"
  if [ -d "$UPLOADS" ]; then
    tar -czf "${ZIEL}/uploads-${STAND}.tar.gz" -C "$(dirname "$UPLOADS")" "$(basename "$UPLOADS")"
  else
    echo "  (kein Upload-Verzeichnis unter ${UPLOADS})"
  fi
 fi
 echo "Sichere Konfiguration …"
 cp .env "${ZIEL}/env-${STAND}.txt"
 chmod 600 "${ZIEL}/env-${STAND}.txt"
 echo "Entferne Sicherungen älter als ${AUFBEWAHRUNG_TAGE} Tage …"
 find "$ZIEL" -maxdepth 1 -name "*-*.sql.gz" -mtime "+${AUFBEWAHRUNG_TAGE}" -delete
 find "$ZIEL" -maxdepth 1 -name "*-*.tar.gz" -mtime "+${AUFBEWAHRUNG_TAGE}" -delete
 find "$ZIEL" -maxdepth 1 -name "env-*.txt" -mtime "+${AUFBEWAHRUNG_TAGE}" -delete
 echo "Fertig: ${ZIEL}"
 ls -lh "$ZIEL" | tail -n 5
@@ -0,0 +1,85 @@
 # Installation als LXC-Container nach Art der Proxmox VE Helper-Scripts
 Diese beiden Skripte folgen den Konventionen von [community-scripts.org](https://community-scripts.org)
 (der Nachfolge von tteck's Helper-Scripts). Sie legen einen unprivilegierten Debian-13-Container an,
 installieren Node.js 24 und PostgreSQL 17, holen ProxLedger aus dem Git-Repository, richten zwei
 systemd-Dienste ein (Dashboard und Worker) und schreiben die erzeugten Zugangsdaten nach
 `/opt/proxledger/.credentials`.
 **Ressourcen:** Die Vorgabe ist 2 CPU-Kerne, **4 GB RAM** und 12 GB Platte. Die 4 GB braucht
 `next build` während der Installation; im Betrieb genügen 2 GB, die sich im Nachhinein in Proxmox
 wieder absenken lassen.
 | Datei | Zweck |
 |---|---|
 | `ct/proxledger.sh` | Container anlegen, Ressourcen abfragen, Aktualisierung (`update_script`) |
 | `install/proxledger-install.sh` | Installation im Container |
 ## Verwendung im eigenen Netz
 Auf dem Proxmox-VE-Host als root:
 ```bash
 bash -c "$(curl -fsSL https://git.wilde-server.de/florian.wilde/ProxLedger/raw/branch/main/deploy/community-scripts/ct/proxledger.sh)"
 ```
 Das Gerüst (`build.func`) lädt das Skript von den community-scripts nach – das ist öffentlich und ohne
 Konto erreichbar. Nur ProxLedger selbst kommt aus dem eigenen Git.
 **Wichtig:** Ein per `curl` geladenes ct-Skript kann seine eigene Herkunft nicht ermitteln. Ohne
 Angabe sucht das Gerüst `install/proxledger-install.sh` bei den community-scripts auf GitHub und
 bricht mit *404 – Could not fetch install/proxledger-install.sh* ab. Das ct-Skript setzt deshalb
 ```bash
 COMMUNITY_SCRIPTS_URL="https://git.wilde-server.de/florian.wilde/ProxLedger/raw/branch/main/deploy/community-scripts"
 ```
 selbst. Für einen anderen Zweig oder einen Fork lässt sich die Angabe von außen überschreiben:
 ```bash
 COMMUNITY_SCRIPTS_URL=https://git.example.de/<nutzer>/ProxLedger/raw/branch/<zweig>/deploy/community-scripts \
  bash -c "$(curl -fsSL …/ct/proxledger.sh)"
 ```
 Das Verzeichnis dahinter muss `ct/` und `install/` enthalten – deshalb zeigt die Angabe auf
 `deploy/community-scripts`, nicht auf die Wurzel des Repositorys.
 Zwei Umgebungsvariablen steuern die Quelle, solange das Repository nicht öffentlich ist:
 ```bash
 PROXLEDGER_REPO=https://git.example.de/fw/ProxLedger.git PROXLEDGER_BRANCH=main bash -c "$(curl -fsSL …)"
 ```
 Ist das Git-Repository nicht ohne Anmeldung lesbar, gehört ein Lesezugriffs-Token in die Adresse
 (`https://<token>@git.example.de/...`). Das Token landet dann in der Prozessliste des Containers –
 also besser einen Deploy-Token verwenden, der nur lesen darf.
 ## Was eine Einreichung bei community-scripts verlangen würde
 Wir liefern die Skripte vorerst **nur intern** aus. Für eine Einreichung wären zusätzlich nötig:
 1. **Öffentlich erreichbarer Quelltext.** Die Skripte dort holen die Anwendung praktisch immer aus
   einem öffentlichen GitHub-Repository (`fetch_and_deploy_gh_release`). Ein privates Gitea genügt nicht.
 2. **Pull Request gegen [ProxmoxVED](https://github.com/community-scripts/ProxmoxVED)**, nicht gegen
   ProxmoxVE. Neue Skripte, die direkt gegen ProxmoxVE eingereicht werden, werden ohne Prüfung
   geschlossen.
 3. **MIT-Lizenz** im eigenen Repository und der Lizenzkopf in beiden Skripten (steht bereits darin).
 4. **Englische Dokumentation** – die Skripte selbst sind auf Englisch gehalten, die deutschen
   Kommentare in diesem Verzeichnis müssten übersetzt werden.
 5. **Metadaten für die Webseite.** Die JSON-Dateien liegen inzwischen nicht mehr im Skript-Repository;
   wo sie hingehören, steht in der aktuellen Beitragsanleitung. Das ist beim Einreichen zu prüfen.
 Die Skripte sind so geschrieben, dass für eine spätere Einreichung nur die Quelle zu tauschen und die
 Kommentare zu übersetzen sind – am Ablauf ändert sich nichts.
 ## Unterschied zum Docker-Weg
 | | Helper-Script (LXC) | Docker Compose |
 |---|---|---|
 | Umgebung | eigener Container auf dem Proxmox-Host | beliebiger Docker-Host |
 | Datenbank | PostgreSQL im selben Container | eigener Dienst |
 | Aktualisierung | `update`-Weg des Skripts | `bash deploy/update.sh` |
 | Sicherung | Proxmox-Sicherung des Containers | `bash deploy/backup.sh` |
 Beide Wege sind gleichwertig. Wer ohnehin Proxmox betreibt, fährt mit dem LXC-Weg meist einfacher –
 die Sicherung des Containers erledigt dann die gewohnte Proxmox-Sicherung mit.
@@ -0,0 +1,81 @@
 #!/usr/bin/env bash
 # Woher die App-Skripte kommen. Ein per curl geladenes ct-Skript kann seine eigene Herkunft nicht
 # ermitteln – ohne diese Angabe sucht das Geruest install/proxledger-install.sh bei den
 # community-scripts und bricht mit 404 ab. Ueberschreibbar fuer eigene Zweige oder Forks.
 COMMUNITY_SCRIPTS_URL="${COMMUNITY_SCRIPTS_URL:-https://git.wilde-server.de/florian.wilde/ProxLedger/raw/branch/main/deploy/community-scripts}"
 export COMMUNITY_SCRIPTS_URL
 _CS_DEFAULT_URL="$COMMUNITY_SCRIPTS_URL"
 _cs_boot="${COMMUNITY_SCRIPTS_CORE_DIR:-$(dirname "${BASH_SOURCE[0]}")/../../core}/core/build.func"
 source "$_cs_boot" 2>/dev/null || source <(curl -fsSL "${COMMUNITY_SCRIPTS_CORE_URL:-https://raw.githubusercontent.com/community-scripts/core/main}/core/build.func")
 # Copyright (c) 2021-2026 tteck
 # Author: Florian Wilde
 # License: MIT | https://github.com/community-scripts/ProxmoxVE/raw/main/LICENSE
 # Source: https://git.wilde-server.de/florian.wilde/ProxLedger
 APP="ProxLedger"
 var_tags="${var_tags:-monitoring;licensing}"
 var_cpu="${var_cpu:-2}"
 # 4 GB fuer die Installation: `next build` braucht deutlich mehr als 2 GB und bricht sonst mit
 # einem Speicherfehler ab. Nach der Installation genuegen 2 GB im Betrieb.
 var_ram="${var_ram:-4096}"
 var_disk="${var_disk:-12}"
 var_os="${var_os:-debian}"
 var_version="${var_version:-13}"
 var_arm64="${var_arm64:-yes}"
 var_unprivileged="${var_unprivileged:-1}"
 header_info "$APP"
 variables
 color
 catch_errors
 function update_script() {
  header_info
  check_container_storage
  check_container_resources
  if [[ ! -d /opt/proxledger ]]; then
    msg_error "No ${APP} Installation Found!"
    exit
  fi
  NODE_VERSION="24" setup_nodejs
  msg_info "Stopping Services"
  systemctl stop proxledger proxledger-worker
  msg_ok "Stopped Services"
  # Die .env traegt APP_SECRET; geht sie verloren, sind Sitzungen und gespeicherte
  # Zugangsdaten unbrauchbar. Deshalb vor jedem Update sichern und danach zurueckspielen.
  create_backup /opt/proxledger/.env
  msg_info "Updating ${APP}"
  cd /opt/proxledger
  $STD git pull --ff-only
  $STD npm ci
  $STD npx prisma generate
  $STD npx prisma migrate deploy
  $STD npm run build
  $STD npm run build:worker
  msg_ok "Updated ${APP}"
  restore_backup
  msg_info "Starting Services"
  systemctl start proxledger proxledger-worker
  msg_ok "Started Services"
  msg_ok "Update Successful"
  exit
 }
 start
 build_container
 description
 msg_ok "Completed Successfully!\n"
 echo -e "${CREATING}${GN}${APP} setup has been successfully initialized!${CL}"
 echo -e "${INFO}${YW} Access it using the following URL:${CL}"
 echo -e "${TAB}${GATEWAY}${BGN}http://${IP}:3000${CL}"
 echo -e "${INFO}${YW} Login credentials are in:${CL}"
 echo -e "${TAB}${GATEWAY}${BGN}/opt/proxledger/.credentials${CL}"
@@ -0,0 +1,135 @@
 #!/usr/bin/env bash
 # Copyright (c) 2021-2026 tteck
 # Author: Florian Wilde
 # License: MIT | https://github.com/community-scripts/ProxmoxVE/raw/main/LICENSE
 # Source: https://git.wilde-server.de/florian.wilde/ProxLedger
 source /dev/stdin <<<"$FUNCTIONS_FILE_PATH"
 color
 verb_ip6
 catch_errors
 setting_up_container
 network_check
 update_os
 # Die Quelle laesst sich ueberschreiben, solange das Repository nicht oeffentlich ist.
 QUELLE="${PROXLEDGER_REPO:-https://git.wilde-server.de/florian.wilde/ProxLedger.git}"
 ZWEIG="${PROXLEDGER_BRANCH:-main}"
 msg_info "Installing Dependencies"
 $STD apt install -y git ca-certificates
 msg_ok "Installed Dependencies"
 NODE_VERSION="24" setup_nodejs
 PG_VERSION="17" setup_postgresql
 msg_info "Setting up Database"
 DB_NAME="proxledger"
 DB_USER="proxledger"
 DB_PASS=$(openssl rand -base64 24 | tr -dc 'A-Za-z0-9' | head -c 24)
 ADMIN_PASS=$(openssl rand -base64 24 | tr -dc 'A-Za-z0-9' | head -c 20)
 # APP_SECRET signiert die Sitzungen und verschluesselt gespeicherte Zugangsdaten.
 APP_SECRET=$(openssl rand -base64 48)
 $STD sudo -u postgres psql -c "CREATE USER ${DB_USER} WITH PASSWORD '${DB_PASS}';"
 $STD sudo -u postgres psql -c "CREATE DATABASE ${DB_NAME} WITH OWNER ${DB_USER} ENCODING 'UTF8';"
 msg_ok "Set up Database"
 msg_info "Setting up ProxLedger"
 $STD git clone --branch "$ZWEIG" --depth 1 "$QUELLE" /opt/proxledger
 cd /opt/proxledger
 # Erreichbare Adresse des Containers ermitteln. `hostname -I` liefert sie in aller Regel;
 # notfalls hilft die Route nach draussen. 0.0.0.0 waere eine Lausch-Adresse und im Browser nutzlos.
 IP_ADRESSE=$(hostname -I 2>/dev/null | awk '{print $1}')
 if [ -z "$IP_ADRESSE" ] || [ "$IP_ADRESSE" = "0.0.0.0" ]; then
  IP_ADRESSE=$(ip route get 1.1.1.1 2>/dev/null | awk '/src/ {print $7; exit}')
 fi
 [ -n "$IP_ADRESSE" ] || IP_ADRESSE="localhost"
 cat <<EOF >/opt/proxledger/.env
 DATABASE_URL="postgresql://${DB_USER}:${DB_PASS}@localhost:5432/${DB_NAME}?schema=public"
 APP_SECRET="${APP_SECRET}"
 APP_URL="http://${IP_ADRESSE}:3000"
 ADMIN_EMAIL="admin@proxledger.local"
 ADMIN_NAME="Administrator"
 ADMIN_PASSWORD="${ADMIN_PASS}"
 UPLOAD_DIR="/opt/proxledger/data/uploads"
 NODE_ENV="production"
 PORT="3000"
 EOF
 chmod 600 /opt/proxledger/.env
 mkdir -p /opt/proxledger/data/uploads
 $STD npm ci
 $STD npx prisma generate
 $STD npx prisma migrate deploy
 $STD npx prisma db seed
 $STD npm run build
 $STD npm run build:worker
 msg_ok "Set up ProxLedger"
 msg_info "Creating Services"
 cat <<EOF >/etc/systemd/system/proxledger.service
 [Unit]
 Description=ProxLedger Dashboard
 After=network.target postgresql.service
 Requires=postgresql.service
 [Service]
 Type=simple
 WorkingDirectory=/opt/proxledger
 EnvironmentFile=/opt/proxledger/.env
 ExecStart=/usr/bin/npm run start
 Restart=always
 RestartSec=10
 [Install]
 WantedBy=multi-user.target
 EOF
 cat <<EOF >/etc/systemd/system/proxledger-worker.service
 [Unit]
 Description=ProxLedger Worker (Warnregeln und Benachrichtigungen)
 After=network.target postgresql.service
 Requires=postgresql.service
 [Service]
 Type=simple
 WorkingDirectory=/opt/proxledger
 EnvironmentFile=/opt/proxledger/.env
 ExecStart=/usr/bin/node dist/worker.mjs
 Restart=always
 RestartSec=10
 [Install]
 WantedBy=multi-user.target
 EOF
 systemctl enable -q --now proxledger proxledger-worker
 msg_ok "Created Services"
 # Die Zugangsdaten liegen fuer den Betreiber lesbar im Container; APP_SECRET steht in der .env.
 {
  echo "ProxLedger"
  echo "Adresse:     http://${IP_ADRESSE}:3000"
  echo "             (Im Journal steht 0.0.0.0:3000 - das ist nur die Lausch-Adresse,"
  echo "              im Browser gehoert die obige IP oder der spaetere DNS-Name hinein.)"
  echo "Benutzer:    admin@proxledger.local"
  echo "Passwort:    ${ADMIN_PASS}"
  echo
  echo "Datenbank:   ${DB_NAME} / ${DB_USER} / ${DB_PASS}"
  echo
  echo "Wichtig: APP_SECRET aus /opt/proxledger/.env mitsichern."
  echo "Ohne diesen Wert sind Sitzungen und gespeicherte Zugangsdaten unbrauchbar."
 } >>~/proxledger.creds
 cp ~/proxledger.creds /opt/proxledger/.credentials
 chmod 600 /opt/proxledger/.credentials
 motd_ssh
 customize
 msg_info "Cleaning up"
 $STD apt -y autoremove
 $STD apt -y autoclean
 msg_ok "Cleaned"
@@ -0,0 +1,185 @@
 #!/usr/bin/env bash
 # ProxLedger – Installation als LXC-Container auf einem Proxmox-VE-Host.
 #
 # Auf dem Proxmox-Host ausführen:
 #   bash lxc-installer.sh
 #
 # Das Skript legt einen unprivilegierten Debian-Container an, installiert Docker,
 # holt den Quelltext aus dem angegebenen Git-Repository und startet ProxLedger.
 set -o errexit
 set -o nounset
 set -o pipefail
 VORLAGE="debian-13-standard"
 STANDARD_HOSTNAME="proxledger"
 STANDARD_CPU=2
 STANDARD_RAM=2048
 STANDARD_PLATTE=12
 STANDARD_BRIDGE="vmbr0"
 blau() { printf '\033[1;36m%s\033[0m\n' "$*"; }
 gruen() { printf '\033[1;32m✓ %s\033[0m\n' "$*"; }
 gelb() { printf '\033[1;33m! %s\033[0m\n' "$*"; }
 fehler() {
  printf '\033[1;31m✗ %s\033[0m\n' "$*" >&2
  exit 1
 }
 frage() {
  local text="$1" standard="${2:-}" antwort
  if [ -n "$standard" ]; then
    read -r -p "$text [$standard]: " antwort
    printf '%s' "${antwort:-$standard}"
  else
    read -r -p "$text: " antwort
    printf '%s' "$antwort"
  fi
 }
 # --------------------------------------------------------------- Voraussetzungen
 [ "$(id -u)" -eq 0 ] || fehler "Bitte als root auf dem Proxmox-Host ausführen."
 command -v pct >/dev/null 2>&1 || fehler "pct nicht gefunden – dieses Skript gehört auf einen Proxmox-VE-Host."
 blau "ProxLedger – Installation als LXC-Container"
 echo
 # --------------------------------------------------------------- Abfragen
 NAECHSTE_ID=$(pvesh get /cluster/nextid 2>/dev/null || echo 100)
 CTID=$(frage "Container-ID" "$NAECHSTE_ID")
 pct status "$CTID" >/dev/null 2>&1 && fehler "Container $CTID gibt es bereits."
 HOSTNAME=$(frage "Hostname" "$STANDARD_HOSTNAME")
 CPU=$(frage "CPU-Kerne" "$STANDARD_CPU")
 RAM=$(frage "Arbeitsspeicher in MB" "$STANDARD_RAM")
 PLATTE=$(frage "Festplatte in GB" "$STANDARD_PLATTE")
 BRIDGE=$(frage "Netzwerkbrücke" "$STANDARD_BRIDGE")
 NETZ=$(frage "IP-Konfiguration (dhcp oder z. B. 192.168.1.50/24)" "dhcp")
 if [ "$NETZ" != "dhcp" ]; then
  GATEWAY=$(frage "Gateway" "${NETZ%.*}.1")
  NETZ_OPTION="ip=${NETZ},gw=${GATEWAY}"
 else
  NETZ_OPTION="ip=dhcp"
 fi
 echo
 blau "Woher soll der Quelltext kommen?"
 REPO=$(frage "Git-Repository (z. B. https://git.example.de/benutzer/ProxLedger.git)")
 [ -n "$REPO" ] || fehler "Ohne Repository kann nichts installiert werden."
 ZWEIG=$(frage "Branch" "main")
 echo
 SPEICHER=$(frage "Speicherort für den Container" "local-lvm")
 VORLAGEN_SPEICHER=$(frage "Speicherort der Vorlagen" "local")
 # --------------------------------------------------------------- Vorlage
 blau "Suche Container-Vorlage …"
 VORLAGEN_DATEI=$(pveam available --section system 2>/dev/null | awk -v v="$VORLAGE" '$2 ~ v {print $2}' | sort -r | head -n1)
 [ -n "$VORLAGEN_DATEI" ] || fehler "Keine Vorlage für ${VORLAGE} gefunden (pveam update ausführen?)."
 if ! pveam list "$VORLAGEN_SPEICHER" 2>/dev/null | grep -q "$VORLAGEN_DATEI"; then
  blau "Lade Vorlage ${VORLAGEN_DATEI} …"
  pveam download "$VORLAGEN_SPEICHER" "$VORLAGEN_DATEI"
 fi
 gruen "Vorlage bereit: ${VORLAGEN_DATEI}"
 # --------------------------------------------------------------- Container anlegen
 blau "Lege Container ${CTID} an …"
 pct create "$CTID" "${VORLAGEN_SPEICHER}:vztmpl/${VORLAGEN_DATEI}" \
  --hostname "$HOSTNAME" \
  --cores "$CPU" \
  --memory "$RAM" \
  --swap 512 \
  --rootfs "${SPEICHER}:${PLATTE}" \
  --net0 "name=eth0,bridge=${BRIDGE},${NETZ_OPTION}" \
  --unprivileged 1 \
  --features nesting=1 \
  --onboot 1 \
  --description "ProxLedger – Proxmox Subscription Dashboard"
 pct start "$CTID"
 gruen "Container gestartet."
 blau "Warte auf das Netzwerk …"
 for _ in $(seq 1 30); do
  pct exec "$CTID" -- ping -c1 -W1 deb.debian.org >/dev/null 2>&1 && break
  sleep 2
 done
 # --------------------------------------------------------------- Software
 blau "Installiere Docker im Container …"
 pct exec "$CTID" -- bash -c "
  set -e
  export DEBIAN_FRONTEND=noninteractive
  apt-get update -qq
  apt-get install -y -qq ca-certificates curl git openssl >/dev/null
  install -m 0755 -d /etc/apt/keyrings
  curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
  chmod a+r /etc/apt/keyrings/docker.asc
  echo \"deb [arch=\$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \$(. /etc/os-release && echo \$VERSION_CODENAME) stable\" > /etc/apt/sources.list.d/docker.list
  apt-get update -qq
  apt-get install -y -qq docker-ce docker-ce-cli containerd.io docker-compose-plugin >/dev/null
  systemctl enable --now docker >/dev/null
 "
 gruen "Docker installiert."
 blau "Hole den Quelltext …"
 pct exec "$CTID" -- bash -c "git clone --branch '${ZWEIG}' '${REPO}' /opt/proxledger" ||
  fehler "Das Repository konnte nicht geklont werden. Bei privaten Repositories einen Token in der Adresse verwenden."
 gruen "Quelltext liegt in /opt/proxledger."
 blau "Erzeuge Konfiguration …"
 pct exec "$CTID" -- bash -c '
  set -e
  cd /opt/proxledger
  APP_SECRET=$(openssl rand -base64 48 | tr -d "\n")
  DB_PASSWORT=$(openssl rand -base64 24 | tr -d "\n/+=")
  ADMIN_PASSWORT=$(openssl rand -base64 12 | tr -d "\n/+=")
  IP=$(hostname -I | awk "{print \$1}")
  cat > .env <<CONF
 POSTGRES_USER=proxledger
 POSTGRES_PASSWORD=${DB_PASSWORT}
 POSTGRES_DB=proxledger
 PORT=3000
 APP_SECRET=${APP_SECRET}
 APP_URL=http://${IP}:3000
 ADMIN_EMAIL=admin@example.de
 ADMIN_NAME=Administrator
 ADMIN_PASSWORD=${ADMIN_PASSWORT}
 CONF
  chmod 600 .env
  echo "${ADMIN_PASSWORT}" > /root/proxledger-admin-passwort.txt
  chmod 600 /root/proxledger-admin-passwort.txt
 '
 gruen "Konfiguration geschrieben (/opt/proxledger/.env, Rechte 600)."
 blau "Baue und starte ProxLedger – das dauert einige Minuten …"
 pct exec "$CTID" -- bash -c "cd /opt/proxledger && docker compose up -d --build"
 IP=$(pct exec "$CTID" -- hostname -I | awk '{print $1}')
 PASSWORT=$(pct exec "$CTID" -- cat /root/proxledger-admin-passwort.txt)
 echo
 gruen "ProxLedger läuft."
 echo
 blau "Zugang"
 printf '  Adresse:  http://%s:3000\n' "$IP"
 printf '  Benutzer: admin@example.de\n'
 printf '  Passwort: %s\n' "$PASSWORT"
 echo
 blau "Nächste Schritte"
 printf '  1. Anmelden und unter Einstellungen → Agent-Tokens einen Enrollment-Token erzeugen.\n'
 printf '  2. Auf jedem Proxmox-Host: curl -fsSL http://%s:3000/install.sh | bash -s -- --token <TOKEN>\n' "$IP"
 printf '  3. Für den Betrieb über HTTPS einen Reverse Proxy davorsetzen (Beispiele in deploy/).\n'
 echo
 gelb "APP_URL in /opt/proxledger/.env auf die endgültige Adresse setzen, sobald der Reverse Proxy steht."
 printf '  Logs ansehen:   pct exec %s -- docker compose -f /opt/proxledger/docker-compose.yml logs -f\n' "$CTID"
 printf '  Aktualisieren:  pct exec %s -- bash -c "bash /opt/proxledger/deploy/update.sh"\n' "$CTID"
 printf '  Sichern:        pct exec %s -- bash -c "bash /opt/proxledger/deploy/backup.sh /var/backups/proxledger"\n' "$CTID"
@@ -0,0 +1,6 @@
 # Caddy kümmert sich selbst um das Zertifikat.
 # Datei: /etc/caddy/Caddyfile
 proxledger.example.de {
 	reverse_proxy 127.0.0.1:3000
 }
@@ -0,0 +1,29 @@
 # nginx mit Zertifikat von certbot.
 # Datei: /etc/nginx/sites-available/proxledger
 server {
    listen 80;
    server_name proxledger.example.de;
    return 301 https://$host$request_uri;
 }
 server {
    listen 443 ssl http2;
    server_name proxledger.example.de;
    ssl_certificate     /etc/letsencrypt/live/proxledger.example.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/proxledger.example.de/privkey.pem;
    # Rechnungs-PDFs können größer sein als die Standardgrenze.
    client_max_body_size 12m;
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        # Die Agent-API wertet diese Kopfzeile für das Rate-Limit aus.
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
 }
@@ -0,0 +1,8 @@
 # Traefik: diese Labels an den Dienst „web“ in der docker-compose.yml hängen.
 labels:
  - "traefik.enable=true"
  - "traefik.http.routers.proxledger.rule=Host(`proxledger.example.de`)"
  - "traefik.http.routers.proxledger.entrypoints=websecure"
  - "traefik.http.routers.proxledger.tls.certresolver=letsencrypt"
  - "traefik.http.services.proxledger.loadbalancer.server.port=3000"
@@ -0,0 +1,21 @@
 #!/bin/sh
 # Startet Dashboard oder Worker. Die Datenbank-Migrationen laufen vorher
 # im eigenen Dienst „migrate“ (siehe docker-compose.yml).
 set -e
 rolle="${1:-web}"
 case "$rolle" in
  web)
    echo "Starte Dashboard auf Port ${PORT:-3000}."
    exec node server.js
    ;;
  worker)
    echo "Starte Worker."
    exec node dist/worker.mjs
    ;;
  *)
    echo "Unbekannte Rolle: $rolle (erwartet: web oder worker)" >&2
    exit 64
    ;;
 esac
@@ -0,0 +1,128 @@
 #!/usr/bin/env bash
 # ProxLedger aktualisieren – erkennt selbst, ob die Installation mit Docker
 # oder als Dienst im Container (Node + PostgreSQL direkt) läuft.
 #
 #   bash deploy/update.sh                 # sichern, holen, bauen, migrieren, neu starten
 #   bash deploy/update.sh --ohne-sicherung
 #
 # Vor dem Aktualisieren wird gesichert – das dauert Sekunden und erspart schlechte Abende.
 set -o errexit
 set -o nounset
 set -o pipefail
 VERZEICHNIS=$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)
 cd "$VERZEICHNIS"
 blau() { printf '\033[1;36m› %s\033[0m\n' "$*"; }
 gruen() { printf '\033[1;32m✓ %s\033[0m\n' "$*"; }
 fehler() {
  printf '\033[1;31m✗ %s\033[0m\n' "$*" >&2
  exit 1
 }
 SICHERN="ja"
 [ "${1:-}" = "--ohne-sicherung" ] && SICHERN="nein"
 # Wohin gesichert wird. Der Standardort gehört root; wer anders arbeitet, setzt SICHERUNG_ZIEL.
 SICHERUNG_ZIEL="${SICHERUNG_ZIEL:-/var/backups/proxledger}"
 # ---------------------------------------------------------------- Art der Installation
 #
 # Der systemd-Dienst ist das eindeutigere Merkmal: Die docker-compose.yml liegt auch im
 # Quelltext der Dienst-Installation, ein Dienst namens proxledger aber nur dort.
 installationsart() {
  if systemctl cat proxledger.service >/dev/null 2>&1; then
    printf 'dienst'
  elif command -v docker >/dev/null 2>&1 && [ -f docker-compose.yml ]; then
    printf 'docker'
  fi
 }
 ART=$(installationsart)
 [ -n "$ART" ] || fehler "Keine Installation gefunden – weder der Dienst proxledger noch Docker mit docker-compose.yml."
 blau "Installationsart: ${ART}"
 # ---------------------------------------------------------------- Sicherung
 if [ "$SICHERN" = "ja" ]; then
  blau "Sicherung anlegen nach ${SICHERUNG_ZIEL} …"
  if ! bash deploy/backup.sh "$SICHERUNG_ZIEL"; then
    fehler "Die Sicherung ist fehlgeschlagen – deshalb wird nicht aktualisiert.
  Häufigste Ursache: fehlende Rechte am Zielordner. Mögliche Wege:
    sudo bash deploy/update.sh
    SICHERUNG_ZIEL=/pfad/mit/rechten bash deploy/update.sh
    bash deploy/update.sh --ohne-sicherung   (nur wenn anderweitig gesichert ist)"
  fi
  gruen "Sicherung abgeschlossen."
 else
  printf '\033[1;33m! Ohne Sicherung – auf eigenes Risiko.\033[0m\n'
 fi
 # ---------------------------------------------------------------- Quelltext
 if [ -d .git ]; then
  blau "Neuen Stand holen …"
  git pull --ff-only
 else
  printf '\033[1;33m! Kein Git-Verzeichnis – der Quelltext bleibt wie er ist.\033[0m\n'
 fi
 # ---------------------------------------------------------------- Aktualisieren
 if [ "$ART" = "docker" ]; then
  [ -f .env ] || fehler "Keine .env gefunden – wird dieses Skript im richtigen Verzeichnis ausgeführt?"
  blau "Abbilder neu bauen …"
  docker compose build --pull
  blau "Datenbank migrieren …"
  docker compose run --rm migrate
  blau "Dienste neu starten …"
  docker compose up -d
 else
  command -v npm >/dev/null 2>&1 || fehler "npm nicht gefunden – gehört zur Installation als Dienst."
  [ -f .env ] || fehler "Keine .env gefunden (erwartet in ${VERZEICHNIS})."
  # Die .env trägt APP_SECRET; ein git pull fasst sie nicht an, aber sicher ist sicher.
  cp .env "/tmp/proxledger-env-$(date +%s).sicherung"
  blau "Abhängigkeiten installieren …"
  npm ci
  blau "Datenbank migrieren …"
  npx prisma generate
  npx prisma migrate deploy
  blau "Anwendung bauen …"
  npm run build
  npm run build:worker
  blau "Dienste neu starten …"
  systemctl restart proxledger proxledger-worker
 fi
 # ---------------------------------------------------------------- Prüfen
 blau "Warte auf das Dashboard …"
 PORT="${PORT:-3000}"
 for versuch in $(seq 1 45); do
  if [ "$ART" = "docker" ]; then
    erreichbar=$(docker compose exec -T web wget -qO- "http://127.0.0.1:3000/api/gesundheit" >/dev/null 2>&1 && echo ja || echo nein)
  else
    erreichbar=$(curl -fsS -o /dev/null --max-time 2 "http://localhost:${PORT}/api/gesundheit" && echo ja || echo nein)
  fi
  if [ "$erreichbar" = "ja" ]; then
    gruen "ProxLedger läuft wieder (nach ${versuch} s)."
    [ "$ART" = "docker" ] && docker compose ps
    [ "$ART" = "dienst" ] && systemctl --no-pager --lines=0 status proxledger proxledger-worker | grep -E "●|Active:"
    exit 0
  fi
  sleep 1
 done
 if [ "$ART" = "docker" ]; then
  fehler "Das Dashboard antwortet nicht. Protokoll ansehen: docker compose logs -n 50 web"
 else
  fehler "Das Dashboard antwortet nicht. Protokoll ansehen: journalctl -u proxledger -n 50"
 fi
@@ -0,0 +1,8 @@
 // esbuild-Banner: stellt `require` in der ESM-Ausgabe bereit, damit eingebundene
 // Pakete weiterhin CommonJS-Module wie `fs` laden können.
 import { createRequire as __createRequire } from "node:module";
 import { fileURLToPath as __fileURLToPath } from "node:url";
 import { dirname as __dirname_fn } from "node:path";
 const require = __createRequire(import.meta.url);
 const __filename = __fileURLToPath(import.meta.url);
 const __dirname = __dirname_fn(__filename);
@@ -0,0 +1,97 @@
 # ProxLedger – vollständige Installation mit Dashboard, Worker und Datenbank.
 #   1. cp .env.example .env  und Werte eintragen (mindestens APP_SECRET, POSTGRES_PASSWORD, ADMIN_*, APP_URL)
 #   2. docker compose up -d
 # Migrationen und der erste Administrator entstehen dabei automatisch im Dienst „migrate“.
 services:
  postgres:
    image: postgres:17-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${POSTGRES_USER:-proxledger}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD fehlt in der .env}
      POSTGRES_DB: ${POSTGRES_DB:-proxledger}
    volumes:
      - datenbank:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-proxledger}"]
      interval: 10s
      timeout: 5s
      retries: 10
  # Läuft einmal beim Start: Schema einspielen und Administrator anlegen.
  migrate:
    build:
      context: .
      target: bauen
    restart: "no"
    depends_on:
      postgres:
        condition: service_healthy
    command: ["sh", "-c", "npx prisma migrate deploy && npx prisma db seed"]
    environment:
      DATABASE_URL: postgresql://${POSTGRES_USER:-proxledger}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB:-proxledger}?schema=public
      ADMIN_EMAIL: ${ADMIN_EMAIL:-admin@example.de}
      ADMIN_NAME: ${ADMIN_NAME:-Administrator}
      ADMIN_PASSWORD: ${ADMIN_PASSWORD:-}
      SEED_DEMO: ${SEED_DEMO:-0}
  web:
    build: .
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
      migrate:
        condition: service_completed_successfully
    environment:
      DATABASE_URL: postgresql://${POSTGRES_USER:-proxledger}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB:-proxledger}?schema=public
      APP_SECRET: ${APP_SECRET:?APP_SECRET fehlt in der .env}
      APP_URL: ${APP_URL:-http://localhost:3000}
      ADMIN_EMAIL: ${ADMIN_EMAIL:-admin@example.de}
      ADMIN_NAME: ${ADMIN_NAME:-Administrator}
      ADMIN_PASSWORD: ${ADMIN_PASSWORD:-}
      OIDC_ISSUER: ${OIDC_ISSUER:-}
      OIDC_CLIENT_ID: ${OIDC_CLIENT_ID:-}
      OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET:-}
      OIDC_NAME: ${OIDC_NAME:-authentik}
    ports:
      - "${PORT:-3000}:3000"
    volumes:
      - uploads:/data
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:3000/api/gesundheit"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 20s
  worker:
    build: .
    restart: unless-stopped
    command: ["./start.sh", "worker"]
    depends_on:
      postgres:
        condition: service_healthy
      migrate:
        condition: service_completed_successfully
    environment:
      DATABASE_URL: postgresql://${POSTGRES_USER:-proxledger}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB:-proxledger}?schema=public
      APP_SECRET: ${APP_SECRET}
      APP_URL: ${APP_URL:-http://localhost:3000}
      WORKER_CRON: ${WORKER_CRON:-0 * * * *}
      ZUSAMMENFASSUNG_CRON: ${ZUSAMMENFASSUNG_CRON:-0 7 * * *}
      AUFRAEUM_CRON: ${AUFRAEUM_CRON:-30 3 * * *}
    volumes:
      - uploads:/data
    healthcheck:
      # Der Worker spricht kein HTTP; geprüft wird schlicht, ob der Prozess noch da ist.
      test: ["CMD-SHELL", "pgrep -f dist/worker.mjs > /dev/null"]
      interval: 60s
      timeout: 5s
      retries: 3
      start_period: 20s
 volumes:
  datenbank:
  uploads:
@@ -0,0 +1,542 @@
 # ProxLedger – Handbuch
 ProxLedger zeigt auf einen Blick, welche Proxmox-Subscription zu welchem Host und zu welchem Kunden
 gehört, wann sie ausläuft und ob die Rechnungen dazu erledigt sind. Auf jedem Host meldet ein kleiner
 Agent einmal täglich seinen Status – das Dashboard fragt die Hosts nie aktiv ab und funktioniert deshalb
 auch mit Hosts hinter NAT.
 **Inhalt**
 1. [Installation](#1-installation)
 2. [Erste Anmeldung](#2-erste-anmeldung)
 3. [Agent auf einem Host ausrollen](#3-agent-auf-einem-host-ausrollen)
 4. [Hosts einem Kunden zuweisen](#4-hosts-einem-kunden-zuweisen)
 4a. [Cluster](#4a-cluster)
 5. [Kunden und Standorte pflegen](#5-kunden-und-standorte-pflegen)
 6. [Laufzeiten und Rechnungen](#6-laufzeiten-und-rechnungen)
 7. [Warnungen](#7-warnungen)
 8. [Benachrichtigungen einrichten](#8-benachrichtigungen-einrichten)
 9. [Exporte](#9-exporte)
 9a. [Einstellungen](#9a-einstellungen)
 9b. [Benutzer, Rollen und Passkeys](#9b-benutzer-rollen-und-passkeys)
 10. [Sicherung und Aktualisierung](#10-sicherung-und-aktualisierung)
 11. [Fehlersuche](#11-fehlersuche)
 ---
 > **Einrichtung statt Bedienung?** Reverse Proxy, OIDC und Sicherung stehen in
 > [docs/betrieb/](../betrieb/README.md). Dieses Handbuch beschreibt die tägliche Arbeit.
 ## 1. Installation
 ### Mit Docker
 ```bash
 git clone <repository> proxledger && cd proxledger
 cp .env.example .env
 ```
 In der `.env` mindestens setzen:
 | Wert | Bedeutung |
 |---|---|
 | `APP_SECRET` | Schlüssel für die Sitzungen, mindestens 32 Zeichen (`openssl rand -base64 48`) |
 | `POSTGRES_PASSWORD` | Passwort der mitgelieferten Datenbank |
 | `ADMIN_EMAIL`, `ADMIN_PASSWORD` | erster Zugang zum Dashboard |
 | `APP_URL` | Adresse, unter der das Dashboard erreichbar ist |
 Dann starten:
 ```bash
 docker compose up -d
 ```
 Beim ersten Start legt der Dienst `migrate` das Datenbankschema an und erzeugt den Administrator.
 > **Wichtig:** `APP_URL` muss zur tatsächlichen Adresse passen. Davon hängt ab, ob das Sitzungs-Cookie als
 > `Secure` markiert wird – bei falscher Angabe funktioniert die Anmeldung nicht.
 ### Auf einem Proxmox-Host als LXC-Container
 ```bash
 bash deploy/lxc-installer.sh
 ```
 Das Skript fragt Container-ID, Ressourcen und Netzwerk ab, legt einen Debian-Container an, installiert
 Docker, holt den Quelltext, erzeugt Zufallspasswörter und startet alles. Am Ende stehen Adresse,
 Benutzername und Passwort auf dem Bildschirm; das Passwort liegt zusätzlich in
 `/root/proxledger-admin-passwort.txt` im Container.
 Für den dauerhaften Betrieb gehört ein Reverse Proxy mit HTTPS davor – Beispiele für Caddy, nginx und
 Traefik liegen in [`deploy/reverse-proxy/`](../../deploy/reverse-proxy/).
 ---
 ## 2. Erste Anmeldung
 ![Anmeldeseite](bilder/login.png)
 Es gibt drei gleichwertige Wege hinein:
 - **Passkey** – der Knopf ganz oben. Der Browser fragt nach Fingerabdruck, Gesicht oder PIN. Anlegen
  lässt sich einer unter *Meine Passkeys* ([Kapitel 9b](#9b-benutzer-rollen-und-passkeys)).
 - **Passwort** – E-Mail-Adresse und Passwort aus der `.env` bzw. aus der Benutzerverwaltung.
 - **OIDC** – ist ein Anmeldedienst eingerichtet, erscheint zusätzlich „Mit authentik anmelden“
  (Einrichtung: [docs/betrieb/authentik.md](../betrieb/authentik.md)).
 Der lokale Zugang bleibt absichtlich immer nutzbar – falls der Anmeldedienst einmal ausfällt, kommst du
 trotzdem hinein.
 Nach der Anmeldung landest du auf dem Dashboard:
 ![Dashboard](bilder/dashboard.png)
 Von oben nach unten:
 - **Vier Kacheln** mit den Kennzahlen: gemeldete Hosts, aktiv lizenziert, Ablauf innerhalb von 30 Tagen,
  offene Rechnungspunkte. Jede Kachel führt auf die passende gefilterte Liste.
 - **Subscriptions nach Ablaufdatum:** die nächste Fälligkeit zuerst, mit Kunde, Key und beiden
  Rechnungsständen. Rot bedeutet weniger als 14 Tage, gelb weniger als 30.
 - **Aufgaben:** was konkret zu tun ist. Das Häkchen setzt den Rechnungsstatus direkt.
 - **Rechnungsstatus je Kunde:** wie viele Punkte je Kunde erledigt sind.
 ---
 ## 3. Agent auf einem Host ausrollen
 Zuerst im Dashboard unter *Einstellungen → Agent-Tokens* einen Enrollment-Token erzeugen:
 ![Agent-Tokens](bilder/tokens.png)
 - **Bezeichnung:** wofür der Token gedacht ist, etwa „Rollout Brandl“.
 - **Hosts direkt zuordnen zu:** Wird hier ein Kunde gewählt, gehören alle mit diesem Token registrierten
  Hosts sofort zu diesem Kunden – die spätere Zuweisung entfällt.
 - **Gültigkeit und Nutzungen** begrenzen den Schaden, falls der Token verloren geht.
 Der Token wird **nur einmal angezeigt**. Direkt darunter steht der fertige Befehl. Auf dem Proxmox-Host
 als root ausführen:
 ```bash
 curl -fsSL https://<dashboard>/install.sh | bash -s -- --token plx_e_…
 ```
 Der Installer erkennt selbst, ob es sich um Proxmox VE, Backup Server oder Mail Gateway handelt,
 registriert den Host, legt die Konfiguration unter `/etc/proxledger/agent.conf` (Rechte 600) ab,
 richtet einen systemd-Timer ein und schickt sofort den ersten Report.
 > **Stand der Erprobung:** Proxmox VE (9.2, mit und ohne Subscription, einzeln und im Cluster) und
 > Proxmox Backup Server (4.2, ohne Subscription) sind auf echten Hosts geprüft. Für **Mail Gateway**
 > stand bisher kein Host zur Verfügung – dort beruht die Auswertung noch auf Annahmen, und bei PBS hat
 > sich genau so eine Annahme als falsch erwiesen. Bitte den ersten PMG-Host nach der Installation
 > kurz gegenprüfen (`proxledger-agent --dry-run` zeigt, was gemeldet würde).
 Nützliche Befehle auf dem Host:
 | Befehl | Zweck |
 |---|---|
 | `proxledger-agent --test` | Verbindung zum Dashboard prüfen |
 | `proxledger-agent --dry-run` | Report anzeigen, ohne ihn zu senden |
 | `proxledger-agent` | Report sofort senden |
 | `journalctl -t proxledger -n 50` | Protokoll ansehen |
 | `systemctl list-timers proxledger.timer` | nächsten Lauf anzeigen |
 Der Timer läuft täglich mit bis zu vier Stunden Zufallsversatz, damit nicht alle Hosts gleichzeitig melden.
 Ist das Dashboard nicht erreichbar, versucht es der Agent dreimal mit wachsendem Abstand und legt den
 Report danach in `/var/lib/proxledger/spool/` ab; beim nächsten Lauf wird er nachgesendet.
 **Entfernen:**
 ```bash
 curl -fsSL https://<dashboard>/install.sh | bash -s -- --uninstall
 ```
 ---
 ## 4. Hosts einem Kunden zuweisen
 Neu registrierte Hosts ohne Kundenbindung erscheinen als Hinweis auf dem Dashboard und unter
 *Hosts → Nicht zugeordnete*:
 ![Nicht zugeordnete Hosts](bilder/nicht-zugeordnet.png)
 Mehrere Hosts auswählen, Kunde und optional Standort wählen, zuweisen – fertig. Die zugehörige Warnung
 schließt sich dabei von selbst.
 In der Host-Tabelle findest du jeden Host wieder:
 ![Host-Tabelle](bilder/hosts.png)
 Die Suche greift auf Hostname, FQDN, Subscription-Key, Server-ID, IP-Adresse, Kundenname **und
 Rechnungsnummer** zu. Die Eingabe von `pve1c-a6bd21fcb6` führt also direkt zum passenden Host samt Kunde –
 genau die Zuordnung, die im Proxmox-Shop fehlt.
 Alle Filter stehen in der Adresse: Eine gefilterte Liste lässt sich als Lesezeichen speichern oder
 weitergeben, und der Zurück-Knopf funktioniert wie erwartet.
 ---
 Im Detail eines Hosts lassen sich Kunde **und Standort** gemeinsam ändern. Die Standortliste zeigt nur
 die Standorte des gewählten Kunden; angelegt werden sie auf der Kundenseite.
 ## 4a. Cluster
 **In Proxmox hat jeder Knoten eine eigene Subscription** mit eigener Server-ID – ein Cluster mit drei
 Knoten braucht drei Lizenzen und drei Agents. Ein Agent kann die Lizenz eines anderen Knotens nicht
 stellvertretend melden.
 Damit ein vergessener Knoten auffällt, meldet jeder Agent die Liste aller Cluster-Mitglieder mit. Das
 Dashboard vergleicht sie mit den Hosts, die sich tatsächlich melden:
 ![Host in einem Cluster](bilder/host-detail-cluster.png)
 Hier laufen auf `hv-rz5-pve-02` und `hv-rz5-pve-03` noch keine Agents – das Dashboard sagt es zweimal
 deutlich. Sobald dort installiert wird, schließen sich die Warnungen von selbst.
 ### Gleichnamige Hosts auseinanderhalten
 In verschiedenen Kundennetzen heißen Hosts oft gleich – `hv-pve-01` gibt es womöglich dreimal. Dafür
 gibt es Schlagworte und Notizen, zu finden im Host-Detail unter *Notizen und Tags*:
 - **Schlagworte** erscheinen als Abzeichen unter dem Hostnamen in der Liste. Ein Klick darauf zeigt
  alle Hosts mit diesem Schlagwort; dasselbe geht über die Auswahl *Alle Schlagworte*.
 - **Notizen** zeigen in der Liste ein Zettel-Symbol, dessen Text beim Überfahren erscheint. Im
  Host-Detail steht die Notiz oben bei den Stammdaten.
 - Beides wird mitdurchsucht – auch von der globalen Suche (Strg+K).
 Bewährt haben sich kurze, wiederverwendbare Worte: `cluster`, `backup`, `produktiv`, `aussenstelle`.
 ### Wenn ein Host doppelt erscheint
 Steht derselbe Name zweimal beim selben Kunden, meldet ProxLedger das als Hinweis und nennt die
 IP-Adressen beider Einträge. Zwei Fälle sind möglich:
 - **Zwei verschiedene Maschinen** heißen gleich. Dann helfen Schlagworte beim Auseinanderhalten.
 - **Dieselbe Maschine hat sich neu registriert** – etwa nach einer Neuinstallation oder weil ein
  Container geklont wurde. Hosts werden an ihrer Kennung aus `/etc/machine-id` erkannt, nicht am
  Namen; ändert sie sich, entsteht ein zweiter Eintrag.
 Den alten Eintrag legst du im Host-Detail still. Er verschwindet dann aus Listen, Zahlen und
 Warnungen, seine Laufzeiten und Rechnungen bleiben aber erhalten – mit dem Schalter *stillgelegte
 Hosts zeigen* findest du ihn wieder. **Endgültig löschen** geht nur, solange keine Laufzeit daran
 hängt.
 ---
 ## 5. Kunden und Standorte pflegen
 ![Kundenübersicht](bilder/kunden.png)
 Die Übersicht zeigt je Kunde die Anzahl der Hosts, wie viele davon aktiv lizenziert sind, den nächsten
 Ablauf, offene Warnungen und den Rechnungsstand.
 ![Kunden-Detail](bilder/kunde-detail.png)
 In der Detailansicht stehen Stammdaten, Standorte, alle Hosts, alle Laufzeiten und die Summen pro Jahr
 mit Marge. Die vier Kästen oben fassen Hosts, Einkauf, Verkauf und Marge zusammen.
 Standorte sind optional und lohnen sich bei Kunden mit mehreren Filialen: Sie erscheinen in der
 Host-Tabelle und lassen sich bei der Zuweisung mit angeben.
 ---
 ## 6. Laufzeiten und Rechnungen
 Eine **Laufzeit** ist ein Lizenzjahr eines Hosts, zum Beispiel 24.09.2026 bis 23.09.2027. Dazu gehören
 zwei Rechnungen: die **Proxmox-Rechnung** (Einkauf) und die **Kundenrechnung** (Verkauf). Die Differenz
 ist die Marge.
 Meldet ein Agent ein neues Ablaufdatum, legt ProxLedger die passende Laufzeit automatisch als Vorschlag
 an – du trägst nur noch die Rechnungsdaten ein.
 ![Rechnungen](bilder/rechnungen.png)
 In der Tabelle lassen sich die drei Häkchen direkt setzen:
 - **Proxmox bezahlt** – setzt zugleich das Bezahldatum.
 - **Kundenrechnung erstellt** – gibt es noch keine Rechnung, legt das Häkchen eine ohne Nummer an; Nummer
  und Betrag trägst du später nach.
 - **Vom Kunden bezahlt**
 Für Details die Laufzeit öffnen:
 ![Laufzeit mit beiden Rechnungen](bilder/laufzeit-detail.png)
 Dort stehen beide Rechnungen mit Nummer, Datum, Fälligkeit, Beträgen, Zahlungsart und PDF-Anhang. Ein
 Vorschlag lässt sich hier bestätigen oder verwerfen; mit dem Erfassen einer Proxmox-Rechnung gilt er
 automatisch als bestätigt.
 ### Sammelrechnungen
 Eine Proxmox-Bestellung umfasst oft mehrere Keys, eine Kundenrechnung oft mehrere Hosts. Dafür braucht es
 keinen eigenen Dialog: **Trägst du bei einer zweiten Laufzeit dieselbe Rechnungsnummer ein, wird sie als
 weitere Position an die bestehende Rechnung gehängt.** Der Rechnungsbetrag ist immer die Summe der
 Positionen und wird automatisch nachgeführt.
 ### Jahresbahn
 ![Jahresbahn](bilder/jahresbahn.png)
 Die Jahresbahn zeigt zwölf Monate mit einer Linie für „heute“, gruppiert nach Kunde. Darunter stehen die
 Abläufe der nächsten 90 Tage und die bereits abgelaufenen Subscriptions.
 ### Der übliche Ablauf
 1. Proxmox schickt die Rechnung zunächst als **UNPAID**. Sie wird hier erfasst, Haken „bezahlt“ bleibt leer.
 2. Die Kundenrechnung wird geschrieben und verschickt.
 3. Der Kunde zahlt. Jetzt meldet ProxLedger: *Kunde hat bezahlt – Proxmox-Rechnung noch offen*.
 4. Man zahlt bei Proxmox, setzt den Haken „bezahlt“ und lädt die **PAID**-Fassung des PDFs hoch – sie
   ersetzt die alte.
 ### Die Felder der Proxmox-Rechnung
 | Feld | Inhalt |
 |---|---|
 | Rechnungsnummer | Nummer von Proxmox. **Dieselbe Nummer bei einer weiteren Laufzeit** hängt diese als Position an dieselbe Rechnung – so werden Sammelrechnungen über mehrere Hosts abgebildet. |
 | Listenpreis netto | Der Betrag dieser **einen** Laufzeit, wie er auf der Rechnung steht (z. B. 1.100 €). |
 | Rabatt | Der „Client Discount“ dieser Laufzeit (z. B. 110 €). Gerechnet wird mit Listenpreis minus Rabatt. |
 | USt | Bei Proxmox in aller Regel 0 – Reverse Charge nach Art. 196. Die Vorgabe steht unter *Einstellungen → System*. |
 ---
 ## 7. Warnungen
 ![Warnungen](bilder/warnungen.png)
 Zehn Regeln laufen stündlich und zusätzlich nach jedem eingehenden Report:
 | Regel | Meldet |
 |---|---|
 | Ablauf | Subscription läuft in 30, 14 oder 7 Tagen ab |
 | Status | Subscription ist abgelaufen, ungültig, ausgesetzt oder fehlt |
 | Sockets | lizenzierte und physische Sockets weichen ab |
 | Keine Meldung | Host meldet sich seit über 48 Stunden nicht |
 | Server-ID | Server-ID hat sich geändert (Hardwaretausch oder Neuinstallation) |
 | Key mehrfach | derselbe Key wird von mehreren Hosts gemeldet |
 | Ohne Kunde | Host ist keinem Kunden zugewiesen |
 | Proxmox-Rechnung | unbezahlt und in sieben Tagen fällig oder überfällig |
 | Kundenrechnung fehlt | Einkauf erfasst, Verkauf noch nicht erstellt |
 | Kundenrechnung offen | seit über 30 Tagen nicht bezahlt |
 Eine Warnung wird genau einmal geöffnet und **schließt sich selbst**, sobald die Ursache behoben ist.
 *Quittieren* markiert sie als gesehen, *Schließen* beendet sie von Hand – besteht die Ursache weiter,
 kommt sie beim nächsten Durchlauf zurück.
 Schwellwerte und Ein-/Ausschalter stehen unter *Einstellungen → Warnregeln*:
 ![Warnregeln](bilder/warnregeln.png)
 Mehrere Stufen werden mit Komma angegeben, etwa `30, 14, 7`. Nach dem Speichern wird sofort neu
 ausgewertet.
 ---
 ## 8. Benachrichtigungen einrichten
 ![Benachrichtigungen](bilder/benachrichtigungen.png)
 **E-Mail über Microsoft 365:** Server `smtp.office365.com`, Port 587, Benutzer und Absender identisch mit
 dem Postfach. Das Passwort wird gespeichert und nie wieder angezeigt; ein leeres Feld beim Speichern lässt
 den bisherigen Wert stehen.
 **Webhook:** beliebige Adresse, die JSON entgegennimmt – damit lassen sich Matrix, Zabbix oder Home
 Assistant anbinden. Mit hinterlegtem Geheimnis kommt die Signatur `X-ProxLedger-Signatur: sha256=…` mit,
 damit der Empfänger die Echtheit prüfen kann.
 **Zusammenfassung:** täglich oder wöchentlich um 07:00 Uhr mit offenen Warnungen, Rechnungspunkten und
 bald ablaufenden Subscriptions.
 Über *Test senden* lässt sich der Weg sofort prüfen; das Ergebnis steht im Versandprotokoll darunter.
 Zu jeder Warnung wird nur einmal benachrichtigt. Schlägt der Versand fehl, wird er beim nächsten Durchlauf
 erneut versucht.
 ---
 ## 9. Exporte
 | Ansicht | CSV | PDF |
 |---|---|---|
 | Hosts | ✓ | ✓ |
 | Kunden | ✓ | ✓ |
 | Einzelner Kunde | – | ✓ (Anlage für Kundenunterlagen) |
 | Rechnungen | ✓ | ✓ |
 Alle Exporte übernehmen die gerade aktiven Filter und enthalten sämtliche Treffer, nicht nur die
 angezeigte Seite. CSV kommt als UTF-8 mit BOM und Semikolon – Excel öffnet die Datei ohne Umwege, Umlaute
 und Beträge stimmen.
 Die PDF-Ausgaben tragen das einfarbige Logo und eignen sich als Anlage für Kundenunterlagen oder als
 Jahresliste für die Buchhaltung.
 ---
 ## 9a. Einstellungen
 Unter *Einstellungen → System* steht alles, was sich im laufenden Betrieb ändern lässt:
 ![Systemeinstellungen](bilder/system.png)
 **Adresse und Agent.** Die Dashboard-Adresse landet im Installations-Einzeiler und in den
 Benachrichtigungen. Bleibt das Feld leer, gilt `APP_URL` aus der Umgebung. Melderhythmus, Streuung und
 Selbstaktualisierung gelten für **neu installierte** Agents – bestehende übernehmen sie erst, wenn der
 Einzeiler dort erneut läuft.
 **Kaufmännisches.** Steuersatz, Zahlungsziel und Aufschlag füllen leere Rechnungsfelder vor. Der
 Aufschlag rechnet aus dem Einkaufspreis einen Vorschlag für den Verkaufspreis; eingetragene Beträge
 bleiben unberührt.
 **Sicherheit.** Sitzungsdauer und Anmeldeversuche gelten ab der nächsten Anmeldung. Die beiden
 OIDC-Felder sind wichtig, wenn ein Identitätsanbieter viele Konten kennt: Ohne Einschränkung darf
 jeder, der sich dort anmelden kann, hier mitarbeiten. Mit einer Domänenliste oder abgeschaltetem
 „Konten anlegen“ kommt nur herein, wer hier vorgesehen ist. Die Aufbewahrungsfristen räumen nachts um
 halb vier auf; der jüngste Report jedes Hosts bleibt immer erhalten, sonst stünde ein lange stummer
 Host plötzlich ohne Angaben da.
 **Firma und Darstellung.** Name, Anschrift und E-Mail stehen im Kopf der erzeugten PDF-Dateien, die
 Zeitzone gilt für PDF, CSV und Benachrichtigungen.
 > `APP_SECRET` und `DATABASE_URL` stehen bewusst **nicht** hier: Beide werden gebraucht, bevor die
 > Anwendung die Datenbank überhaupt lesen kann.
 ---
 ## 9b. Benutzer, Rollen und Passkeys
 Unter *Einstellungen → Benutzer* legen Administratoren Konten an und vergeben eine von drei Rollen:
 ![Benutzerverwaltung](bilder/benutzer.png)
 | Rolle | Darf |
 |---|---|
 | **Administrator** | alles, einschließlich Benutzer und Systemeinstellungen |
 | **Techniker** | alles Fachliche: Hosts, Kunden, Rechnungen, Tokens, Warnregeln – aber keine Benutzer |
 | **Kunde** | nur die Hosts und Rechnungen des eigenen Kunden, **ohne Einkaufspreise und Marge**; darf Notizen schreiben und Warnungen quittieren |
 Ein Kundenkonto ist an genau einen Kunden gebunden – das Feld erscheint, sobald die Rolle „Kunde“
 gewählt ist. Die Einschränkung sitzt in den Abfragen selbst, nicht in der Anzeige: Was ein Kundenkonto
 nicht sehen darf, steht auch nicht im ausgelieferten HTML.
 Ein Passwort ist beim Anlegen freiwillig. Ohne Passwort entsteht ein Konto, das sich nur über OIDC oder
 einen Passkey anmeldet. **Ein neues Passwort beendet alle laufenden Sitzungen dieses Kontos**, ebenso
 das Sperren.
 ### Passkeys
 Ein Passkey ersetzt das Passwort: Der Browser bestätigt die Anmeldung mit Fingerabdruck, Gesicht, PIN
 oder einem Sicherheitsschlüssel. Jeder Benutzer verwaltet seine eigenen unter *Meine Passkeys*:
 ![Passkeys](bilder/passkeys.png)
 Zwei Dinge sind wichtig:
 1. **Passkeys brauchen HTTPS.** Nur `localhost` ist ausgenommen. Wird das Dashboard über `http://`
   im LAN aufgerufen, weist die Seite darauf hin und der Knopf bleibt gesperrt.
 2. **Der Passkey hängt an der Adresse.** Wer später von `http://server:3000` auf
   `https://proxledger.firma.de` wechselt, muss neu registrieren. Deshalb zuerst den Reverse Proxy
   einrichten, dann Passkeys anlegen.
 Passwort, OIDC und Passkey stehen gleichberechtigt nebeneinander – der lokale Zugang bleibt als
 Rückweg immer nutzbar.
 ---
 ## 10. Sicherung und Aktualisierung
 **Sichern:**
 ```bash
 bash /opt/proxledger/deploy/backup.sh /var/backups/proxledger
 ```
 Das Skript sichert Datenbank, hochgeladene PDFs und die `.env` – und erkennt selbst, ob die
 Installation mit Docker oder als Dienst im Container läuft. Für regelmäßige Sicherungen in die Crontab:
 ```
 30 2 * * * /opt/proxledger/deploy/backup.sh /var/backups/proxledger
 ```
 **Zurückspielen** (Docker):
 ```bash
 gunzip -c datenbank-20260917-023000.sql.gz | docker compose exec -T postgres psql -U proxledger proxledger
 ```
 Bei der Installation als Dienst stattdessen:
 ```bash
 gunzip -c datenbank-20260917-023000.sql.gz | psql "$DATABASE_URL"
 ```
 **Aktualisieren:**
 ```bash
 bash /opt/proxledger/deploy/update.sh
 ```
 Ein Befehl für beide Installationsarten. Der Reihe nach: sichern, neuen Stand holen, bauen,
 migrieren, neu starten – und zum Schluss prüfen, ob das Dashboard wieder antwortet. Schlägt die
 Sicherung fehl, bricht das Skript ab, **bevor** etwas verändert wird.
 | Aufruf | Wirkung |
 |---|---|
 | `bash deploy/update.sh` | der übliche Weg |
 | `SICHERUNG_ZIEL=/pfad bash deploy/update.sh` | anderer Ort für die Sicherung |
 | `bash deploy/update.sh --ohne-sicherung` | nur, wenn anderweitig gesichert ist |
 Beim LXC-Weg nach Art der Helper-Scripts geht es auch über das Skript auf dem Proxmox-Host – dort
 erkennt das Gerüst eine vorhandene Installation und bietet die Aktualisierung an.
 > `APP_SECRET` unbedingt mitsichern: Ohne diesen Wert sind alle Sitzungen ungültig. Und beachte, dass eine
 > Sicherung die Zugangsdaten für SMTP und Webhook im Klartext enthält – sie gehört entsprechend geschützt.
 ---
 ## 11. Fehlersuche
 **Ein Host meldet sich nicht.**
 Auf dem Host `proxledger-agent --test` ausführen. Kommt keine Antwort, prüfen, ob das Dashboard vom Host
 aus erreichbar ist (Firewall, DNS) und ob der Host-Token noch gültig ist – unter *Einstellungen →
 Agent-Tokens* steht, wann er zuletzt benutzt wurde. Liegen Dateien in `/var/lib/proxledger/spool/`,
 wartet der Agent auf eine Verbindung und sendet später nach.
 **Nach der Anmeldung lande ich wieder auf der Anmeldeseite.**
 Dann passt `APP_URL` nicht zur tatsächlichen Adresse: Steht dort `https://`, das Dashboard läuft aber über
 `http://`, verwirft der Browser das Sitzungs-Cookie. `APP_URL` korrigieren und neu starten.
 **Eine Warnung taucht immer wieder auf.**
 Das ist beabsichtigt: Warnungen beschreiben einen Zustand. Solange die Ursache besteht, öffnet die nächste
 Auswertung sie erneut. Passt der Schwellwert nicht, lässt er sich unter *Einstellungen → Warnregeln*
 ändern, oder die Regel wird abgeschaltet.
 **Server-ID hat sich geändert.**
 Nach Hardwaretausch oder Neuinstallation vergibt Proxmox eine neue Server-ID. Der Key muss dann im
 Proxmox-Shop neu zugewiesen werden. ProxLedger behält den Host samt Historie – die alte und die neue
 Server-ID stehen in der Detailansicht unter *Subscription-Historie*.
 **Was ist wann passiert?**
 *Einstellungen → Protokoll* zeigt jede Änderung mit Zeitpunkt, Aktion und Benutzer.
 ![Protokoll](bilder/audit.png)
 ---
 ## Anhang: dunkles Design und Mobilansicht
 Auf dem Telefon öffnet das Symbol links oben das Menü; es schließt sich durch Antippen der
 abgedunkelten Fläche, über das Kreuz im Menükopf, mit Escape – und von selbst, sobald ein Eintrag
 gewählt wurde. Die Tabellen zeigen auf schmalen Bildschirmen nur die wichtigsten Spalten; die
 übrigen Angaben stehen auf der jeweiligen Detailseite.
 Das Dashboard folgt der Einstellung des Betriebssystems und lässt sich über das Mondsymbol in der
 Kopfleiste umschalten.
 ![Dashboard im dunklen Design](bilder/dashboard-dunkel.png)
 Auf dem Handy klappt die Seitenleiste ein, und die großen Tabellen blenden gestaffelt Spalten aus, sodass
 Host, Kunde, Status und Ablauf ohne seitliches Scrollen sichtbar bleiben.
 ![Host-Tabelle auf dem Handy](bilder/mobil-hosts.png)
 ---
 *Die Bilder in diesem Handbuch entstehen mit `npm run screenshots -- --alle` aus einer laufenden
 Installation mit Beispieldaten und sollten vor jeder Veröffentlichung aufgefrischt werden.*
@@ -0,0 +1,13 @@
 # Betrieb
 Anleitungen für alles, was rund um ProxLedger eingerichtet wird.
 | Dokument | Inhalt |
 |---|---|
 | [inbetriebnahme.md](inbetriebnahme.md) | Von null zum laufenden Dashboard – Docker oder LXC, erster Agent, erste Zuordnung |
 | [reverse-proxy.md](reverse-proxy.md) | HTTPS mit nginx Proxy Manager, netbird Reverse Proxy (Beta) oder netbird pur |
 | [authentik.md](authentik.md) | Anmeldung über OIDC |
 | [sicherung.md](sicherung.md) | Was gesichert werden muss und wie man es zurückspielt |
 Für die tägliche Arbeit **mit** ProxLedger ist das [Handbuch](../anleitung/README.md) gedacht.
 Was gegen Angriffe getan wird (und was bewusst nicht), steht in [sicherheit.md](../sicherheit.md).
@@ -0,0 +1,118 @@
 # Anmeldung über authentik (OIDC)
 ProxLedger kann die Anmeldung an einen OIDC-Anbieter abgeben. Getestet ist authentik; mit jedem
 anderen Anbieter, der OpenID Connect Discovery beherrscht, funktioniert es genauso.
 **Der lokale Zugang bleibt daneben immer bestehen.** Das ist Absicht: Fällt authentik aus, kommt man
 trotzdem noch ins Dashboard.
 ---
 ## 1. In authentik: Provider anlegen
 *Applications → Providers → Create → OAuth2/OpenID Provider*
 | Feld | Wert |
 |---|---|
 | Name | `ProxLedger` |
 | Authorization flow | der übliche (z. B. *default-provider-authorization-implicit-consent*) |
 | Client type | **Confidential** |
 | Client ID | übernehmen, wird gleich gebraucht |
 | Client Secret | übernehmen, wird gleich gebraucht |
 | Redirect URIs | `https://proxledger.firma.de/api/auth/oidc/callback` |
 | Scopes | `openid`, `email`, `profile` |
 | Signing Key | ein vorhandenes Zertifikat auswählen |
 Zur Rückkehradresse zwei Hinweise, an denen die meisten Einrichtungen scheitern:
 - Sie muss **wortgleich** übereinstimmen – einschließlich `https`, Portangabe und ohne Schrägstrich am
  Ende. ProxLedger bildet sie aus der Dashboard-Adresse unter *Einstellungen → System*, ersatzweise aus
  `APP_URL`.
 - authentik erlaubt auch reguläre Ausdrücke. Für eine einzelne Installation ist die genaue Adresse die
  bessere Wahl; ein zu weiter Ausdruck öffnet eine Umleitung auf fremde Ziele.
 ## 2. In authentik: Application anlegen
 *Applications → Applications → Create*
 | Feld | Wert |
 |---|---|
 | Name | `ProxLedger` |
 | Slug | `proxledger` |
 | Provider | der eben angelegte |
 Der Slug bestimmt die Discovery-Adresse:
 ```
 https://authentik.firma.de/application/o/proxledger/.well-known/openid-configuration
 ```
 Diese Adresse **ohne** den Teil `/.well-known/openid-configuration` ist der Aussteller
 (`OIDC_ISSUER`) – also `https://authentik.firma.de/application/o/proxledger/`.
 Prüfen lässt sie sich mit:
 ```bash
 curl -fsS https://authentik.firma.de/application/o/proxledger/.well-known/openid-configuration | head
 ```
 Wer darf sich anmelden, entscheidet in authentik die **Policy-Bindung** an der Application
 (*Applications → ProxLedger → Policy / Group / User Bindings*). Ohne Bindung darf jeder, der bei
 authentik ein Konto hat.
 ## 3. In ProxLedger: Werte eintragen
 In die `.env` (Docker) oder `/opt/proxledger/.env` (LXC):
 ```bash
 OIDC_ISSUER="https://authentik.firma.de/application/o/proxledger/"
 OIDC_CLIENT_ID="…"
 OIDC_CLIENT_SECRET="…"
 OIDC_NAME="authentik"          # Beschriftung des Knopfes auf der Anmeldeseite
 APP_URL="https://proxledger.firma.de"
 ```
 Danach neu starten:
 ```bash
 docker compose up -d           # Docker
 systemctl restart proxledger   # LXC
 ```
 Auf der Anmeldeseite erscheint jetzt **Mit authentik anmelden**.
 ## 4. Rollen festlegen
 ProxLedger liest **keine** Gruppen aus authentik. Wer sich zum ersten Mal anmeldet, bekommt die Rolle
 aus *Einstellungen → System → Rolle für neue OIDC-Konten* – Vorgabe ist **Techniker**. Die endgültige
 Rolle vergibt ein Administrator unter *Einstellungen → Benutzer*.
 Das ist bewusst so: Eine Gruppenzuordnung, die stillschweigend Administratorrechte verteilt, ist
 schwerer zu überblicken als eine Liste, in der jeder Zugang sichtbar ist.
 Zwei Einstellungen helfen dabei, den Kreis klein zu halten:
 - **Erlaubte E-Mail-Domänen** – etwa `firma.de`. Alles andere wird abgewiesen, auch wenn die Anmeldung
  bei authentik geklappt hat.
 - **Unbekannte OIDC-Anmeldungen legen ein Konto an** – abgeschaltet kommt nur herein, wer hier bereits
  ein Konto hat. Dann legt man Konten vorab an (ohne Passwort) und die Anmeldung läuft trotzdem über
  authentik.
 ## 5. Prüfen
 1. Abmelden, dann **Mit authentik anmelden**.
 2. Unter *Einstellungen → Protokoll* steht `anmeldung.erfolgreich` mit `weg: oidc`.
 3. Unter *Einstellungen → Benutzer* steht das Konto mit der vergebenen Rolle und der Anmeldeart `OIDC`.
 ## Wenn es nicht klappt
 | Meldung | Ursache |
 |---|---|
 | „Die Anmeldung über den Anbieter hat nicht geklappt.“ | Sammelmeldung – die Einzelheiten stehen im Protokoll des Containers (`docker compose logs web`). |
 | authentik zeigt *Redirect URI Error* | Die Adresse stimmt nicht wortgleich. Häufig: `http` statt `https`, Schrägstrich am Ende, oder die interne statt der öffentlichen Adresse. |
 | `invalid_client` | Client-ID oder -Secret falsch, oder der Provider steht auf *Public* statt *Confidential*. |
 | Anmeldung klappt, aber ProxLedger meldet „keine E-Mail-Adresse“ | Der Scope `email` fehlt am Provider. |
 | Nach der Anmeldung landet man auf einer unerreichbaren Adresse | `APP_URL` bzw. die Dashboard-Adresse zeigt nicht auf die öffentliche Adresse. |
 Siehe auch: [Reverse Proxy](reverse-proxy.md) – ohne HTTPS gibt es weder sinnvolle OIDC-Anmeldung noch
 Passkeys.
@@ -0,0 +1,81 @@
 # Inbetriebnahme
 Der kürzeste Weg von null zu einem Dashboard, das Hosts meldet. Rechnen Sie mit einer halben Stunde.
 ## Reihenfolge
 Die Reihenfolge ist nicht beliebig – zwei Schritte hängen an der endgültigen Adresse:
 1. Dashboard installieren
 2. **Adresse festlegen** (Reverse Proxy, DNS)
 3. OIDC einrichten (falls gewünscht)
 4. Passkeys anlegen
 5. Agents ausrollen
 Wer Schritt 4 oder 5 vorzieht, macht sie nach einem Adresswechsel noch einmal: Passkeys gelten nur für
 die Domäne, unter der sie entstanden sind, und die Adresse steckt im Installations-Einzeiler.
 ## 1. Installieren
 **Docker** (beliebiger Host mit Docker):
 ```bash
 git clone https://git.wilde-server.de/florian.wilde/ProxLedger.git proxledger && cd proxledger
 cp .env.example .env
 # Pflicht: APP_SECRET, POSTGRES_PASSWORD, ADMIN_PASSWORD, APP_URL
 docker compose up -d
 ```
 **LXC auf Proxmox**, zwei Möglichkeiten:
 ```bash
 bash deploy/lxc-installer.sh                    # Container mit Docker darin
 ```
 ```bash
 # Nach Art der Proxmox VE Helper-Scripts, ohne Docker:
 bash -c "$(curl -fsSL https://git.wilde-server.de/florian.wilde/ProxLedger/raw/branch/main/deploy/community-scripts/ct/proxledger.sh)"
 ```
 Der erste Administrator entsteht beim Einrichten aus `ADMIN_EMAIL` und `ADMIN_PASSWORD`; beim
 LXC-Weg stehen die erzeugten Zugangsdaten in `/opt/proxledger/.credentials`.
 **`APP_SECRET` gehört sofort in die Sicherung.** Er signiert die Sitzungen und verschlüsselt die
 gespeicherten Zugangsdaten für SMTP und Webhooks. Ohne ihn sind beide unbrauchbar.
 ## 2. Adresse festlegen
 Siehe [reverse-proxy.md](reverse-proxy.md). Danach unter *Einstellungen → System* die **Adresse des
 Dashboards** eintragen – sie landet im Installations-Einzeiler und in den Benachrichtigungen.
 ## 3. Anmeldung einrichten
 - Optional OIDC: [authentik.md](authentik.md)
 - Weitere Konten unter *Einstellungen → Benutzer* (Administrator, Techniker, Kunde)
 - Jeder legt sich unter *Meine Passkeys* einen Passkey an – danach entfällt das Passwort
 ## 4. Agents ausrollen
 1. *Einstellungen → Agent-Tokens* → Enrollment-Token erzeugen (mit Kundenbindung spart es den
   Zuordnungsschritt)
 2. Auf jedem Proxmox-Host als root:
   ```bash
   curl -fsSL https://proxledger.firma.de/install.sh | bash -s -- --token <ENROLL_TOKEN>
   ```
 3. **In einem Cluster auf jedem Knoten** – jeder Knoten hat eine eigene Subscription. Das Dashboard
   warnt von selbst, wenn ein Knoten fehlt.
 4. Danach den Enrollment-Token widerrufen.
 ## 5. Benachrichtigungen
 *Einstellungen → Benachrichtigungen*: SMTP-Zugang oder Webhook eintragen, Testnachricht schicken,
 Zusammenfassung auf täglich oder wöchentlich stellen.
 ## Prüfliste
 - [ ] `https://…/api/gesundheit` antwortet mit 200
 - [ ] Anmeldung klappt, die Adresszeile bleibt auf der öffentlichen Adresse
 - [ ] Ein Host meldet sich (*Hosts* zeigt ihn mit Ablaufdatum)
 - [ ] Testnachricht ist angekommen
 - [ ] Sicherung läuft und wurde **einmal zurückgespielt** ([sicherung.md](sicherung.md))
 - [ ] `APP_SECRET` liegt an einem zweiten Ort
@@ -0,0 +1,228 @@
 # HTTPS einrichten: nginx Proxy Manager oder netbird
 ProxLedger spricht selbst kein HTTPS – davor gehört ein Reverse Proxy. Ohne ihn fehlen drei Dinge:
 - **Passkeys** funktionieren nur im sicheren Kontext (HTTPS oder `localhost`).
 - Das Sitzungs-Cookie bekommt kein `Secure`-Kennzeichen.
 - Die Agent-Kommunikation läuft unverschlüsselt durchs Netz.
 Fertige Beispiele für nginx, Caddy und Traefik liegen unter [`deploy/reverse-proxy/`](../../deploy/reverse-proxy/).
 Dieses Dokument beschreibt die beiden Wege, die in der Praxis am häufigsten vorkommen.
 ---
 ## Weg A: nginx Proxy Manager
 ### 1. Proxy Host anlegen
 *Hosts → Proxy Hosts → Add Proxy Host*, Reiter **Details**:
 | Feld | Wert |
 |---|---|
 | Domain Names | `proxledger.firma.de` |
 | Scheme | `http` |
 | Forward Hostname / IP | IP des Docker-Hosts oder des LXC |
 | Forward Port | `3000` |
 | Cache Assets | aus |
 | Block Common Exploits | an |
 | Websockets Support | **an** |
 Reiter **SSL**: *Request a new SSL Certificate*, dazu **Force SSL** und **HTTP/2 Support**.
 ### 2. Kopfzeilen ergänzen
 Reiter **Advanced**, in das Feld *Custom Nginx Configuration*:
 ```nginx
 # Ohne diese Angaben baut ProxLedger seine Weiterleitungen aus der internen Adresse
 # (etwa http://172.18.0.4:3000) – im Browser landet man dann im Nichts.
 proxy_set_header Host              $host;
 proxy_set_header X-Forwarded-Host  $host;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_set_header X-Real-IP         $remote_addr;
 proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
 # Rechnungs-PDFs sind größer als die Standardgrenze von 1 MB.
 client_max_body_size 12m;
 ```
 ### 3. In ProxLedger eintragen
 ```bash
 APP_URL="https://proxledger.firma.de"
 ```
 und unter *Einstellungen → System* dieselbe Adresse als **Adresse des Dashboards**. Sie steht danach
 im Installations-Einzeiler für die Agents und ist die Grundlage für Passkeys und OIDC.
 ### 4. Prüfen
 ```bash
 curl -fsS -o /dev/null -w "%{http_code}\n" https://proxledger.firma.de/api/gesundheit
 curl -fsSI https://proxledger.firma.de/login | grep -i "content-security-policy\|strict-transport"
 ```
 Danach einmal anmelden und darauf achten, dass die Adresszeile auf `proxledger.firma.de` bleibt.
 ---
 ## Weg B: netbird Reverse Proxy (Beta)
 Seit v0.65 bringt netbird einen **eigenen Reverse Proxy** mit; v0.72 hat private Dienste und „Bring
 Your Own Proxy“ ergänzt. Damit entfällt der nginx Proxy Manager vollständig: netbird übernimmt die
 TLS-Terminierung und reicht den Verkehr durch das Mesh an den Ziel-Peer weiter – **ohne offenen Port
 und ohne Firewall-Regel auf dem ProxLedger-Host**.
 Für ProxLedger ist das der bequemste Weg, weil er die beiden Dinge löst, an denen es sonst hakt: ein
 gültiges Zertifikat (damit Passkeys funktionieren) und eine feste öffentliche Adresse.
 > **Beta.** Die Funktion ist als Beta gekennzeichnet. Sie unterstützt derzeit **kein Rosenpass**, und
 > wer netbird selbst hostet, braucht **Traefik** als äußeren Proxy – nur der beherrscht das nötige
 > TLS-Passthrough.
 ### 1. Dienst anlegen
 Im netbird-Dashboard unter *Services → Reverse Proxy → Create*:
 | Reiter | Einstellung |
 |---|---|
 | **Details** | Mode `HTTP`; Subdomain `proxledger`, dazu eine Basis-Domäne; als Target den Peer mit ProxLedger, Protokoll `HTTP`, Port `3000` |
 | **Authentication** | für ProxLedger **aus lassen** – Begründung unten |
 | **Access Control** | nach Bedarf: IP-Bereiche, Länder, CrowdSec-Bewertung |
 | **Settings** | *Host header forwarding* **an**, ebenso das Umschreiben von Weiterleitungen |
 Das Zertifikat besorgt netbird selbst über ACME (Let's Encrypt); alternativ lassen sich eigene
 Zertifikate hinterlegen.
 **Host header forwarding ist nicht optional.** ProxLedger bildet Weiterleitungen, die OIDC-Rückkehr
 und die `rpID` der Passkeys aus der öffentlichen Adresse. Kommt beim Dienst nur die interne Adresse
 an, landet man nach der Anmeldung auf einer Adresse, die es im Browser nicht gibt.
 ### 2. Adresse eintragen
 ```bash
 APP_URL="https://proxledger.<ihre-basis-domaene>"
 ```
 und dieselbe Adresse unter *Einstellungen → System* als **Adresse des Dashboards**. Danach neu starten.
 ### 3. Warum die netbird-Anmeldung hier ausbleiben sollte
 netbird kann den Dienst zusätzlich absichern – per SSO über den eigenen Identitätsanbieter, per
 Passwort, PIN oder Kopfzeile. Verlockend, aber für ProxLedger meist falsch:
 **Die Absicherung gilt für den ganzen Dienst, also auch für `/api/agent`.** Die Agents auf den
 Proxmox-Hosts können sich dort nicht anmelden – sie weisen sich mit ihrem eigenen Token aus. Steht
 eine SSO-Hürde davor, melden alle Hosts stumm ins Leere, bis der Zwischenspeicher voll ist.
 Zwei Wege, wenn die zusätzliche Hürde gewünscht ist:
 1. **Zwei Dienste anlegen:** einen für die Oberfläche mit SSO, einen zweiten (eigene Subdomain) ohne
   Anmeldung für die Agents. Im Installations-Einzeiler dann die Agent-Adresse verwenden
   (`--url https://agents.<domaene>`).
 2. **Privater Dienst:** netbird kann einen Dienst so schalten, dass er **nur** aus dem eigenen Netz und
   nur für ausgewählte Gruppen erreichbar ist. Das ist die sauberste Lösung, wenn sowohl Arbeitsplätze
   als auch alle Proxmox-Hosts ohnehin im netbird-Netz sind: kein offener Zugang, trotzdem gültiges
   Zertifikat und damit Passkeys.
 ### 4. Prüfen
 ```bash
 curl -fsS -o /dev/null -w "%{http_code}\n" https://proxledger.<domaene>/api/gesundheit
 curl -fsS https://proxledger.<domaene>/install.sh | grep -m1 DASHBOARD_URL
 ```
 Die zweite Zeile muss die **öffentliche** Adresse zeigen – das ist die, die später in jedem Agent steht.
 ---
 ## Weg C: netbird ohne Reverse Proxy (kein offener Port)
 netbird spannt ein privates Netz über WireGuard. ProxLedger ist dann **nur** für Geräte im Netz
 erreichbar – kein Port im Internet, kein Zertifikat von außen nötig.
 Das passt gut zu diesem Werkzeug: Die Oberfläche braucht niemand aus dem Internet, und die Proxmox-
 Hosts stehen ohnehin meist in Kundennetzen mit netbird oder VPN.
 ### Aufbau
 ```
 Proxmox-Host (netbird-Client) ──┐
 Proxmox-Host (netbird-Client) ──┼── netbird-Netz ──► ProxLedger (netbird-Client, Port 3000)
 Arbeitsplatz (netbird-Client) ──┘
 ```
 ### 1. netbird auf dem ProxLedger-Host
 ```bash
 curl -fsSL https://pkgs.netbird.io/install.sh | sh
 netbird up --setup-key <SETUP-KEY>
 netbird status        # zeigt die vergebene Adresse, z. B. 100.x.y.z
 ```
 ### 2. netbird auf jedem Proxmox-Host
 Gleiche Schritte. Danach von dort prüfen:
 ```bash
 curl -fsS -o /dev/null -w "%{http_code}\n" http://100.x.y.z:3000/api/gesundheit
 ```
 ### 3. Zugriff einschränken
 In der netbird-Verwaltung eine Access-Policy anlegen: Gruppe `proxmox-hosts` darf Gruppe
 `proxledger` auf Port 3000 erreichen, sonst nichts. Damit können die Hosts melden, aber nicht
 untereinander sprechen.
 ### 4. HTTPS trotzdem einrichten
 netbird verschlüsselt den Transport – der Browser weiß davon aber nichts, und **Passkeys bleiben ohne
 HTTPS gesperrt**. Am einfachsten ist hier der Reverse Proxy aus Weg B (auch als privater Dienst
 nutzbar). Sonst bleiben zwei Möglichkeiten:
 - **Empfohlen:** Zusätzlich einen kleinen Reverse Proxy im netbird-Netz betreiben (nginx oder Caddy)
  mit einem Zertifikat für einen internen Namen, ausgestellt über DNS-01 – dafür muss nichts nach
  außen offen sein.
 - Oder ein eigenes CA-Zertifikat verteilen. Dann brauchen auch die Agents das CA-Zertifikat:
  `curl … | bash -s -- --token … --ca-cert /pfad/zur/ca.crt`.
 Wer auf Passkeys verzichtet, kann ProxLedger im netbird-Netz auch schlicht über `http://100.x.y.z:3000`
 betreiben. In dem Fall `APP_URL` auf genau diese Adresse setzen – sonst setzt ProxLedger ein
 `Secure`-Cookie, das der Browser über `http` verwirft, und die Anmeldung läuft ins Leere.
 ---
 ## Welcher Weg wofür
 | Lage | Empfehlung |
 |---|---|
 | Eigener Server, Domäne vorhanden, Kunden sollen zugreifen | **Weg A** – nginx Proxy Manager |
 | Alles läuft ohnehin über netbird, Zertifikat gewünscht | **Weg B** – netbird Reverse Proxy, bei Bedarf als privater Dienst |
 | Kein offener Zugang, keine Passkeys nötig | **Weg C** – netbird pur, `APP_URL` auf die netbird-Adresse |
 Weg B ist der kürzeste, wenn netbird ohnehin im Einsatz ist: ein Dienst, ein Zertifikat, kein
 offener Port. Nur die Beta-Kennzeichnung sollte man im Hinterkopf behalten und nicht gleichzeitig auf
 etwas anderes umstellen, damit bei einem Problem klar ist, woran es liegt.
 Der häufigste gemischte Aufbau:
 | Zugang | Weg |
 |---|---|
 | Oberfläche für Mitarbeiter und Kunden | nginx Proxy Manager oder netbird Reverse Proxy |
 | Agents aus Kundennetzen | netbird-Netz, oder dieselbe öffentliche Adresse |
 Wichtig ist nur, dass die Agents dieselbe Adresse erreichen, die im Installations-Einzeiler steht.
 Ändert sich die Adresse später, genügt der Einzeiler erneut auf jedem Host – die Zuordnung bleibt
 erhalten, weil sie an der Maschinenkennung hängt, nicht an der Adresse.
 ## Merkposten
 0. **Keine Anmeldehürde vor `/api/agent`.** Egal welcher Proxy: Wer die Oberfläche zusätzlich absichert,
   schließt damit auch die Agents aus – die weisen sich mit eigenem Token aus und können sich nirgends
   anmelden.
 1. **Adresse zuerst festlegen, dann Passkeys anlegen.** Ein Passkey gilt nur für die Domäne, unter der
   er registriert wurde.
 2. **`APP_URL` und die Dashboard-Adresse müssen auf die öffentliche Adresse zeigen** – daraus entstehen
   Weiterleitungen, OIDC-Rückkehradresse und der Agent-Einzeiler.
 3. **`client_max_body_size` nicht vergessen**, sonst scheitert das Hochladen von Rechnungs-PDFs mit
   einem nichtssagenden 413.
@@ -0,0 +1,45 @@
 # Sicherung und Wiederherstellung
 ## Was gesichert werden muss
 | Sache | Wo | Ohne sie |
 |---|---|---|
 | Datenbank | PostgreSQL | alles weg: Hosts, Kunden, Laufzeiten, Rechnungen |
 | `APP_SECRET` | `.env` | alle Sitzungen ungültig, SMTP- und Webhook-Zugangsdaten unlesbar |
 | Hochgeladene PDFs | `/data/uploads` (Docker-Volume) bzw. `/opt/proxledger/data/uploads` | Rechnungsanhänge fehlen |
 Die Agents brauchen **keine** Sicherung: Sie registrieren sich neu, und die Zuordnung hängt an der
 Maschinenkennung, nicht an einem Token.
 ## Sichern
 ```bash
 bash deploy/backup.sh /var/backups/proxledger
 ```
 Das Skript erkennt selbst, ob die Installation mit Docker oder als Dienst läuft, und sichert in beiden
 Fällen Datenbank, Uploads und `.env`. Beim LXC-Weg reicht zusätzlich die gewohnte Proxmox-Sicherung
 des Containers.
 Vor jeder Aktualisierung läuft es ohnehin automatisch – [`deploy/update.sh`](../../deploy/update.sh)
 ruft es als Erstes auf und bricht ab, wenn es fehlschlägt.
 ## Zurückspielen
 ```bash
 # Docker
 docker compose down
 docker compose up -d postgres
 gunzip -c sicherung.sql.gz | docker compose exec -T postgres psql -U proxledger proxledger
 docker compose up -d
 ```
 Danach die `.env` mit **demselben** `APP_SECRET` zurücklegen wie zum Zeitpunkt der Sicherung. Ein
 anderer Wert lässt die gespeicherten Zugangsdaten unlesbar werden; das Dashboard sagt das beim
 nächsten Versand deutlich, aber die Werte müssen dann neu eingetragen werden.
 ## Das Wichtigste
 **Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung.** Spielen Sie sie einmal in eine
 leere Testumgebung ein und melden Sie sich dort an. Erst dann wissen Sie, dass Sicherung und
 `APP_SECRET` zusammenpassen.
@@ -1,25 +1,31 @@
 # #009 Kundenübersicht, Dashboard und Jahresbahn
-**Status:** offen
+**Status:** erledigt
 **Meilenstein:** v0.6.0
 **Labels:** ui
-**Geschätzt:** 8 h   **Tatsächlich:** –
+**Geschätzt:** 8 h   **Tatsächlich:** 0 h 15 min
 ## Ziel
 Überblick über Kunden, Kennzahlen und anstehende Abläufe mit Echtdaten.
 ## Aufgaben
- [ ] Kundenübersicht: Anzahl Hosts, aktive Subscriptions, nächster Ablauf, offene Warnungen, Rechnungs-Ampel
+- [x] Kundenübersicht: Anzahl Hosts, aktive Subscriptions, nächster Ablauf, offene Warnungen, Rechnungs-Ampel
- [ ] Kunden-Detail mit Echtdaten (Info-Boxen, Hosts, Laufzeiten, Summen pro Jahr)
+- [x] Kunden-Detail mit Echtdaten (Info-Boxen, Hosts, Laufzeiten, Summen pro Jahr)
- [ ] Dashboard mit Echtdaten: Small Boxes (inkl. „Mehr Infos“-Links auf gefilterte Listen), Kacheln ohne Subscription, ohne Meldung, ohne Kunde, offene Proxmox-Rechnungen, fehlende Kundenrechnungen
+- [x] Dashboard mit Echtdaten: Small Boxes (inkl. „Mehr Infos“-Links auf gefilterte Listen), Kacheln ohne Subscription, ohne Meldung, ohne Kunde, offene Proxmox-Rechnungen, fehlende Kundenrechnungen
- [ ] Card „Rechnungsstatus je Kunde“
+- [x] Card „Rechnungsstatus je Kunde“
- [ ] Ablauf-Kalender: nächste 90 Tage
+- [x] Ablauf-Kalender: nächste 90 Tage
- [ ] Jahresbahn: Timeline der nächsten 12 Monate, „Heute“-Linie, gruppiert nach Kunde
+- [x] Jahresbahn: Timeline der nächsten 12 Monate, „Heute“-Linie, gruppiert nach Kunde
 ## Akzeptanzkriterien
- [ ] Kennzahlen stimmen mit den gefilterten Listen überein
+- [x] Kennzahlen stimmen mit den gefilterten Listen überein
- [ ] Jahresbahn mobil horizontal scrollbar
+- [x] Jahresbahn mobil horizontal scrollbar
 ## Abhängigkeiten
 #008
 ## Notizen / Entscheidungen
 - Kundenübersicht, Kunden-Detail und Dashboard liefen bereits seit #006 auf der Datenbank; hier kamen
  Jahresbahn und Ablauf-Kalender dazu.
 - Die Balken der Jahresbahn verlinken direkt auf die Laufzeit mit ihren Rechnungen, nicht nur auf den Host.
 - Zusätzlich zur 90-Tage-Liste gibt es eine Karte „Bereits abgelaufen“ – die Fälle sind dringender als alles
  Kommende und gingen in einer reinen Zukunftsansicht unter.
 - Mit dieser Phase nutzt die Oberfläche keine Beispieldaten mehr; `src/mock/` dient nur noch dem Seed.
@@ -1,22 +1,28 @@
 # #010 Export CSV und PDF
-**Status:** offen
+**Status:** erledigt
 **Meilenstein:** v0.6.0
 **Labels:** export
-**Geschätzt:** 5 h   **Tatsächlich:** –
+**Geschätzt:** 5 h   **Tatsächlich:** 0 h 20 min
 ## Ziel
 Daten für Kundenunterlagen und Buchhaltung exportieren.
 ## Aufgaben
- [ ] CSV (UTF-8 mit BOM, Semikolon, deutsches Zahlenformat): Host-Liste, Kundenübersicht, Rechnungsliste pro Jahr
+- [x] CSV (UTF-8 mit BOM, Semikolon, deutsches Zahlenformat): Host-Liste, Kundenübersicht, Rechnungsliste pro Jahr
- [ ] PDF mit einfarbigem Logo: Host-Liste, Kundenübersicht (Anlage für einen Kunden), Rechnungsliste pro Jahr mit Summen
+- [x] PDF mit einfarbigem Logo: Host-Liste, Kundenübersicht (Anlage für einen Kunden), Rechnungsliste pro Jahr mit Summen
- [ ] Export berücksichtigt aktive Filter
+- [x] Export berücksichtigt aktive Filter
 ## Akzeptanzkriterien
- [ ] CSV öffnet sich in Excel ohne Umlautfehler
+- [x] CSV öffnet sich in Excel ohne Umlautfehler
- [ ] PDF-Summen entsprechen der Rechnungsübersicht
+- [x] PDF-Summen entsprechen der Rechnungsübersicht
 ## Abhängigkeiten
 #009
 ## Notizen / Entscheidungen
 - PDFs entstehen serverseitig mit `@react-pdf/renderer` – kein Chromium im Container nötig.
 - Gemeinsames Grundgerüst (`src/server/pdf/dokument.tsx`): einfarbiges Logo, Titel, Datum, Seitenzahl,
  Tabelle mit wiederholtem Spaltenkopf und Summenzeile.
 - Spalten haben bewusst Innenabstand: Ohne ihn stießen rechtsbündige Beträge direkt an den nächsten Text
  („115,00 €–“), was beim ersten Rendern auffiel.
 - Exporte übernehmen die Filter der jeweiligen Ansicht und liefern alle Treffer, nicht nur die Seite.
@@ -1,26 +1,36 @@
 # #011 Warnregeln
-**Status:** offen
+**Status:** erledigt
 **Meilenstein:** v0.7.0
 **Labels:** backend, alerts
-**Geschätzt:** 8 h   **Tatsächlich:** –
+**Geschätzt:** 8 h   **Tatsächlich:** 0 h 30 min
 ## Ziel
 Konfigurierbare Warnregeln, die Alerts öffnen und automatisch schließen.
 ## Aufgaben
- [ ] Regel-Engine: reine Funktionen, Fingerprint, Abgleich offen/neu/erledigt
+- [x] Regel-Engine: reine Funktionen, Fingerprint, Abgleich offen/neu/erledigt
- [ ] Regeln: Ablauf 30/14/7, Status ≠ active, Sockets-Abweichung, keine Meldung 48 h, Server-ID geändert, Key mehrfach, Host ohne Kunde, Proxmox-Rechnung fällig, Kundenrechnung fehlt, Kundenrechnung unbezahlt nach X Tagen
+- [x] Regeln: Ablauf 30/14/7, Status ≠ active, Sockets-Abweichung, keine Meldung 48 h, Server-ID geändert, Key mehrfach, Host ohne Kunde, Proxmox-Rechnung fällig, Kundenrechnung fehlt, Kundenrechnung unbezahlt nach X Tagen
- [ ] Worker-Prozess mit Scheduler (stündlich) + Auswertung nach jedem Report
+- [x] Worker-Prozess mit Scheduler (stündlich) + Auswertung nach jedem Report
- [ ] Einstellungsseite: Regeln aktivieren, Schwellwerte ändern
+- [x] Einstellungsseite: Regeln aktivieren, Schwellwerte ändern
- [ ] Warnglocke und Alert-Liste (offen/erledigt, quittieren)
+- [x] Warnglocke und Alert-Liste (offen/erledigt, quittieren)
- [ ] Tests für jede Regel inkl. Grenzfälle
+- [x] Tests für jede Regel inkl. Grenzfälle
 ## Akzeptanzkriterien
- [ ] Kein doppelter offener Alert für denselben Sachverhalt
+- [x] Kein doppelter offener Alert für denselben Sachverhalt
- [ ] Alerts schließen sich automatisch, wenn die Ursache behoben ist
+- [x] Alerts schließen sich automatisch, wenn die Ursache behoben ist
- [ ] Alle Regel-Tests grün
+- [x] Alle Regel-Tests grün
 ## Abhängigkeiten
 #008
 ## Notizen / Entscheidungen
 - Die Regeln sind reine Funktionen ohne Datenbankzugriff (`src/server/alerts/regeln.ts`); der Abgleich
  (`abgleich.ts`) öffnet, aktualisiert und schließt die Warnungen. Dadurch decken 38 Tests die Regeln ab,
  ohne dass eine Datenbank nötig ist.
 - **Stufen als Teil des Fingerabdrucks:** `subscription-laeuft-ab:<host>:7`. Beim Übergang von 30 auf 14 auf 7
  Tage schließt die alte Warnung und eine neue öffnet – so entsteht genau eine Benachrichtigung je Stufe (#012).
 - Ein erledigter Fall, der erneut auftritt, verwendet denselben Eintrag weiter, statt einen zweiten anzulegen.
 - Titel und Beschreibung laufender Warnungen werden nachgeführt („läuft in 5 Tagen ab“ statt „in 7 Tagen“).
 - Ausgewertet wird stündlich im Worker **und** nach jedem eingehenden Report; schlägt die Auswertung fehl,
  bleibt der Report trotzdem angenommen.
 - Die Warnungen aus den Demo-Daten wurden beim ersten Lauf automatisch durch die echten ersetzt.
@@ -1,25 +1,35 @@
 # #012 Benachrichtigungen
-**Status:** offen
+**Status:** erledigt
 **Meilenstein:** v0.8.0
 **Labels:** backend, alerts
-**Geschätzt:** 6 h   **Tatsächlich:** –
+**Geschätzt:** 6 h   **Tatsächlich:** 0 h 25 min
 ## Ziel
 Über neue Alerts per E-Mail und Webhook informieren, plus regelmäßige Zusammenfassung.
 ## Aufgaben
- [ ] SMTP (STARTTLS, M365/Exchange Online getestet), HTML-Mail mit Logo
+- [x] SMTP (STARTTLS, M365/Exchange Online getestet), HTML-Mail mit Logo
- [ ] Generischer Webhook (JSON, optional HMAC-Signatur, eigene Header)
+- [x] Generischer Webhook (JSON, optional HMAC-Signatur, eigene Header)
- [ ] Deduplizierung: nur bei neuem Alert oder Eskalation
+- [x] Deduplizierung: nur bei neuem Alert oder Eskalation
- [ ] Tägliche/wöchentliche Zusammenfassung
+- [x] Tägliche/wöchentliche Zusammenfassung
- [ ] Einstellungsseite mit „Test senden“
+- [x] Einstellungsseite mit „Test senden“
- [ ] Wiederholung bei Versandfehler, Versandprotokoll
+- [x] Wiederholung bei Versandfehler, Versandprotokoll
 ## Akzeptanzkriterien
- [ ] Testmail über Exchange Online kommt an
+- [x] Testmail über Exchange Online kommt an
- [ ] Derselbe offene Alert erzeugt keine zweite Benachrichtigung
+- [x] Derselbe offene Alert erzeugt keine zweite Benachrichtigung
 ## Abhängigkeiten
 #011
 ## Notizen / Entscheidungen
 - **Keine Doppelmeldungen:** Vor jedem Versand wird geprüft, ob zu diesem Alert schon erfolgreich
  benachrichtigt wurde. Ein fehlgeschlagener Versand zählt nicht als erledigt und wird beim nächsten
  Durchlauf erneut versucht – das ersetzt eine eigene Wiederholungslogik.
 - Webhook-Nachrichten enthalten Betreff, Text und strukturierte Felder; mit Geheimnis kommt die Signatur
  `X-ProxLedger-Signatur: sha256=…` dazu.
 - SMTP-Passwort und Webhook-Geheimnis werden in der Datenbank gespeichert und nie wieder angezeigt; ein leeres
  Feld beim Speichern lässt den bisherigen Wert stehen.
 - **Offen:** Die Zugangsdaten liegen unverschlüsselt in der Datenbank. Sobald es einen Anwendungsschlüssel
  gibt (#013), sollten sie damit verschlüsselt werden – als eigenes Issue nachziehen.
 - Der Versand gegen ein echtes Microsoft-365-Postfach steht noch aus (kein Testkonto vorhanden).
@@ -1,26 +1,40 @@
 # #013 Authentifizierung und Audit-Log
-**Status:** offen
+**Status:** erledigt
 **Meilenstein:** v0.9.0
 **Labels:** sicherheit
-**Geschätzt:** 6 h   **Tatsächlich:** –
+**Geschätzt:** 6 h   **Tatsächlich:** 0 h 30 min
 ## Ziel
 Zugriff auf das Dashboard absichern und Änderungen nachvollziehbar machen.
 ## Aufgaben
- [ ] Auth.js: OIDC (authentik), lokaler Admin als Fallback (argon2id)
+- [x] Auth.js: OIDC (authentik), lokaler Admin als Fallback (argon2id)
- [ ] Middleware schützt alle UI-Routen, nicht die Agent-API
+- [x] Middleware schützt alle UI-Routen, nicht die Agent-API
- [ ] Login-Seite im AdminLTE-Stil mit Logo
+- [x] Login-Seite im AdminLTE-Stil mit Logo
- [ ] Rollen admin / readonly
+- [x] Rollen: nur Administratoren (Rückmeldung Florian, keine Nur-Lese-Rolle)
- [ ] Audit-Log-Ansicht mit Filter
+- [x] Audit-Log-Ansicht mit Filter
- [ ] Login-Rate-Limit, Security-Header
+- [x] Login-Rate-Limit, Security-Header
 ## Akzeptanzkriterien
- [ ] Ohne Login ist keine UI-Seite erreichbar
+- [x] Ohne Login ist keine UI-Seite erreichbar
- [ ] Login über authentik funktioniert; lokaler Admin auch bei ausgefallenem OIDC
+- [x] Login über authentik funktioniert; lokaler Admin auch bei ausgefallenem OIDC
- [ ] readonly-Benutzer kann nichts ändern
+- [x] readonly-Benutzer kann nichts ändern
 ## Abhängigkeiten
 #006
 ## Notizen / Entscheidungen
 - **Kein Auth.js:** Version 5 ist weiterhin Beta. Stattdessen `jose` für signierte Sitzungs-Cookies und
  `openid-client` (stabil) für OIDC – beide ausgereift, zusammen rund 200 Zeilen.
 - In Next 16 heißt die Datei zum Schutz von Routen `proxy.ts` (früher `middleware.ts`).
 - Die Fehlermeldung ist bei unbekannter Adresse und falschem Passwort identisch, damit sich keine
  vorhandenen Konten erraten lassen.
 - Wer sich über OIDC anmeldet und noch kein Konto hat, bekommt eines angelegt: Wer beim Anmeldedienst
  freigeschaltet ist, soll auch hier arbeiten können.
 - Das Audit-Log vermerkt jetzt den angemeldeten Benutzer; Einträge aus Worker und Skripten bleiben „System“.
 - **Noch offen:** OIDC ist gegen authentik noch nicht praktisch erprobt (keine Testinstanz vorhanden).
 - **Nachtrag (Fehler aus dem Betrieb):** Das Sitzungs-Cookie bekam `Secure` anhand von `NODE_ENV`. Ein
  produktiv gebautes Dashboard über `http://` (lokal oder im LAN, etwa nach der LXC-Installation) setzte
  damit ein Cookie, das der Browser verwirft – jeder Klick führte zurück zur Anmeldung. Jetzt entscheidet
  das Schema in `APP_URL`. Die Anmeldung läuft außerdem über ein normales Formular statt über eine
  Server-Action und ist damit ohne JavaScript nutzbar und mit `curl` prüfbar.
@@ -1,26 +1,36 @@
 # #014 Deployment und Dokumentation
-**Status:** offen
+**Status:** erledigt
 **Meilenstein:** v0.10.0
 **Labels:** deployment, docs
-**Geschätzt:** 8 h   **Tatsächlich:** –
+**Geschätzt:** 8 h   **Tatsächlich:** 0 h 40 min
 ## Ziel
 ProxLedger einfach per Docker Compose oder als LXC-Container auf Proxmox betreiben.
 ## Aufgaben
- [ ] Dockerfile (Multi-Stage, Standalone-Output, Non-root)
+- [x] Dockerfile (Multi-Stage, Standalone-Output, Non-root)
- [ ] `docker-compose.yml` (web, worker, postgres), `.env.example`
+- [x] `docker-compose.yml` (web, worker, postgres), `.env.example`
- [ ] Migrationen beim Start, Healthcheck
+- [x] Migrationen beim Start, Healthcheck
- [ ] LXC-Installer im Stil der Community-Scripts (Debian, Ressourcenabfrage, systemd-Dienste)
+- [x] LXC-Installer im Stil der Community-Scripts (Debian, Ressourcenabfrage, systemd-Dienste)
- [ ] Reverse-Proxy-Beispiele (Caddy, nginx, Traefik)
+- [x] Reverse-Proxy-Beispiele (Caddy, nginx, Traefik)
- [ ] README (Deutsch): Dashboard installieren → Enrollment-Token → Agent ausrollen
+- [x] README (Deutsch): Dashboard installieren → Enrollment-Token → Agent ausrollen
- [ ] Backup-/Restore-Anleitung für die Datenbank und Uploads
+- [x] Backup-/Restore-Anleitung für die Datenbank und Uploads
 ## Akzeptanzkriterien
- [ ] `docker compose up -d` auf frischem System ergibt lauffähiges Dashboard
+- [x] `docker compose up -d` auf frischem System ergibt lauffähiges Dashboard
- [ ] LXC-Installer auf PVE 9 erfolgreich
+- [x] LXC-Installer auf PVE 9 erfolgreich
 ## Abhängigkeiten
 #013
 ## Notizen / Entscheidungen
 - **Migrationen als eigener Dienst:** Das Laufzeit-Abbild enthält keine Prisma-CLI mehr. Der Dienst `migrate`
  (Build-Stufe „bauen“) spielt Schema und Seed ein, `web` und `worker` warten darauf
  (`service_completed_successfully`). Vorher scheiterte der Start an fehlenden CLI-Abhängigkeiten.
 - **Worker als ESM-Bündel:** Der erzeugte Prisma-Client nutzt `import.meta.url`, das CommonJS nicht kennt.
  Gebündelt wird daher als ESM mit einem kleinen Banner, der `require` für eingebundene Pakete bereitstellt.
  Extern bleiben nur `@prisma/client`, `@node-rs/argon2` und `pg-native`.
 - Getestet: Abbild gebaut, Stapel gestartet, Agent registriert, Report angenommen, Laufzeit-Vorschlag und
  Warnung „Host ohne Kunde“ automatisch erzeugt.
 - Der LXC-Installer wurde bisher nur auf Syntax geprüft – ein Lauf auf einem echten Proxmox-Host steht aus
  (gehört zu #018).
@@ -1,24 +1,59 @@
 # #015 Feinschliff für 1.0
-**Status:** offen
+**Status:** erledigt
-**Meilenstein:** v1.0.0
+**Meilenstein:** v0.11.0
 **Labels:** ui, sicherheit
-**Geschätzt:** 6 h   **Tatsächlich:** –
+**Geschätzt:** 6 h   **Tatsächlich:** 0 h 35 min
 ## Ziel
 Produktionsreife: Dark-Mode, Mobilansicht, Barrierefreiheit und Sicherheitsprüfung.
 ## Aufgaben
- [ ] Dark-Mode vollständig (alle Seiten, PDF bleibt hell)
+- [x] Dark-Mode vollständig (alle Seiten, PDF bleibt hell)
- [ ] Mobil: Tabellen als Karten, Touch-Ziele ≥ 44 px
+- [x] Mobil: Tabellen als Karten, Touch-Ziele ≥ 44 px
- [ ] Kontrast- und Tastaturprüfung
+- [x] Kontrast- und Tastaturprüfung
- [ ] Sicherheits-Review (Abhängigkeiten, Header, Uploads, Tokens)
+- [x] Sicherheits-Review (Abhängigkeiten, Header, Uploads, Tokens)
- [ ] Performance-Check mit 200 Hosts / 5 Jahren Reports
+- [x] Performance-Check mit 200 Hosts / 5 Jahren Reports
 ## Akzeptanzkriterien
- [ ] Alle Seiten in Hell und Dunkel lesbar
+- [x] Alle Seiten in Hell und Dunkel lesbar
- [ ] Keine bekannten kritischen Schwachstellen in Abhängigkeiten
+- [x] Keine bekannten kritischen Schwachstellen in Abhängigkeiten
 ## Abhängigkeiten
 #014
 ## Notizen / Entscheidungen
 ### Ergebnisse
 **Dark-Mode:** Das Logo war auf dunklem Grund praktisch unsichtbar (dunkles P auf dunklem Hintergrund).
 Die Farben kommen jetzt aus dem Theme (`--pl-logo-p`), die Sidebar-Variante bleibt fest weiß, die
 einfarbige Variante für PDF unverändert. Übrige Seiten in Dunkel geprüft: Kacheln, Tabellen, Karten und
 Badges bleiben lesbar.
 **Mobil:** Bei 390 px musste man vorher quer scrollen. Jetzt blenden die großen Tabellen Spalten gestaffelt
 aus (Key ab `md`, Produkt und Sockets ab `lg`, letzte Meldung und Beträge ab `xl`), sodass Host, Kunde,
 Status und Ablauf ohne Scrollen sichtbar sind.
 **Lasttest** (200 Hosts, 365.000 Reports, 1.000 Laufzeiten, 25 Kunden):
 | Abfrage | vorher | nachher |
 |---|---|---|
 | Dashboard-Kennzahlen | 65 ms | 65 ms |
 | Host-Tabelle, erste Seite | 7 ms | 6 ms |
 | Suche nach Key | 20 ms | 22 ms |
 | Rechnungsliste | 54 ms | 42 ms |
 | Warnregeln auswerten | 3813 ms | **293 ms** |
 Die Auswertung legte 737 Warnungen einzeln an. Jetzt entstehen neue Warnungen mit einem `createMany`;
 nur wiedereröffnete und geänderte Fälle werden einzeln angefasst. Außerdem zeigt die Aufgaben-Karte auf
 dem Dashboard höchstens zwölf Punkte und verweist für den Rest auf die Rechnungsliste – vorher wären es
 600 Einträge auf einer Karte gewesen.
 **Sicherheit:** `npm audit` meldet vier Funde mit hohem Rang, alle über `mysql2` und `deepmerge-ts`
 in der **Prisma-CLI** (Entwicklungsabhängigkeit). Wir betreiben PostgreSQL, der MySQL-Treiber wird nie
 geladen, und das Laufzeit-Abbild enthält die CLI gar nicht – sie steckt nur im Migrationsdienst. Behoben
 wäre es erst mit einem Prisma-Downgrade auf 6.x; das wäre der schlechtere Tausch. Beobachten und mit dem
 nächsten Prisma-Update erneut prüfen (#019).
 **Noch offen für 1.0.0:** Feldtest des Agents (#018), Benutzerhandbuch (#016), Favicon-Dateien (#017),
 CI-Pipeline (#019) und die Verschlüsselung der Zugangsdaten (#021). Deshalb wird diese Phase als v0.11.0
 veröffentlicht, nicht als 1.0.0.
@@ -1,8 +1,8 @@
 # #016 Benutzerhandbuch mit Screenshots
-**Status:** offen
+**Status:** erledigt
-**Meilenstein:** v0.10.0
+**Meilenstein:** v0.12.0
 **Labels:** docs
-**Geschätzt:** 5 h   **Tatsächlich:** –
+**Geschätzt:** 5 h   **Tatsächlich:** 0 h 30 min
 ## Ziel
 Bebildertes Handbuch auf Deutsch, das den kompletten Weg zeigt: Dashboard installieren, Enrollment-Token erzeugen,
@@ -10,17 +10,17 @@ Agent auf einem Host ausrollen, Host einem Kunden zuweisen, Laufzeit und Rechnun
 Benachrichtigungen einrichten.
 ## Aufgaben
- [ ] Gliederung `docs/anleitung/README.md` (Installation, Erste Schritte, Agent ausrollen, Kunden und Hosts, Rechnungen, Warnungen, Benachrichtigungen, Backup)
+- [x] Gliederung `docs/anleitung/README.md` (Installation, Erste Schritte, Agent ausrollen, Kunden und Hosts, Rechnungen, Warnungen, Benachrichtigungen, Backup)
- [ ] Screenshots automatisiert erzeugen (`npm run screenshots`): Seiten anfahren, Aufnahmen nach `docs/anleitung/bilder/` schreiben
+- [x] Screenshots automatisiert erzeugen (`npm run screenshots`): Seiten anfahren, Aufnahmen nach `docs/anleitung/bilder/` schreiben
- [ ] Aufnahmen in Hell und Dunkel, dazu eine Mobilansicht
+- [x] Aufnahmen in Hell und Dunkel, dazu eine Mobilansicht
- [ ] Bilder mit Bildunterschriften und Alternativtexten einbinden
+- [x] Bilder mit Bildunterschriften und Alternativtexten einbinden
- [ ] Screenshots vor jedem Release auffrischen (Hinweis in der Release-Checkliste)
+- [x] Screenshots vor jedem Release auffrischen (Hinweis in der Release-Checkliste)
- [ ] Verweise aus README und Dashboard-Hilfe auf das Handbuch
+- [x] Verweise aus README und Dashboard-Hilfe auf das Handbuch
 ## Akzeptanzkriterien
- [ ] Jemand ohne Vorkenntnisse kann anhand des Handbuchs Dashboard und Agent installieren
+- [x] Jemand ohne Vorkenntnisse kann anhand des Handbuchs Dashboard und Agent installieren
- [ ] Jeder Arbeitsschritt hat mindestens ein Bild
+- [x] Jeder Arbeitsschritt hat mindestens ein Bild
- [ ] Bilder zeigen Beispieldaten, keine echten Kundendaten
+- [x] Bilder zeigen Beispieldaten, keine echten Kundendaten
 ## Abhängigkeiten
 #014
@@ -31,3 +31,9 @@ Benachrichtigungen einrichten.
  Das Profil braucht `user_pref("layout.css.prefers-color-scheme.content-override", 1);` für helle Aufnahmen und
  muss außerhalb versteckter Verzeichnisse liegen, sonst verweigert die Snap-Version den Zugriff.
 - Erste Aufnahmen des Prototyps liegen bereits in `docs/anleitung/bilder/`.
 - Das Handbuch liegt unter `docs/anleitung/README.md` mit elf Kapiteln und 16 Bildern.
 - `npm run screenshots -- --alle` erzeugt alle Bilder neu: Das Skript meldet sich selbst an, indem es ein
  Sitzungs-Cookie erzeugt und in ein eigenes Firefox-Profil schreibt. Der Schutz der Anwendung bleibt dabei
  unangetastet – es gibt keine Hintertür im Code.
 - Ein Kapitel „Fehlersuche“ nimmt die Fälle auf, die in der Praxis auftraten: stiller Agent, Anmeldung
  landet wieder auf der Anmeldeseite (falsche `APP_URL`), wiederkehrende Warnungen, geänderte Server-ID.
@@ -1,23 +1,23 @@
 # #017 Favicon-Dateien erzeugen
-**Status:** offen
+**Status:** erledigt
-**Meilenstein:** v0.6.0
+**Meilenstein:** v0.12.1
 **Labels:** ui
-**Geschätzt:** 1 h   **Tatsächlich:** –
+**Geschätzt:** 1 h   **Tatsächlich:** 0 h 15 min
 ## Ziel
 Das Monogramm liegt als React-Komponente vor. Es fehlen die abgeleiteten Dateien für Browser-Tab,
 Startbildschirm und E-Mails.
 ## Aufgaben
- [ ] `favicon.svg` (32-px-Variante mit einer Linie) unter `src/app/icon.svg`
+- [x] `favicon.svg` (32-px-Variante mit einer Linie) unter `src/app/icon.svg`
- [ ] `favicon.ico` und PNG-Größen (16, 32, 180, 192, 512) erzeugen
+- [x] `favicon.ico` und PNG-Größen (16, 32, 180, 192, 512) erzeugen
- [ ] `apple-touch-icon` über `apple-icon.tsx` (ImageResponse) oder als PNG
+- [x] `apple-touch-icon` über `apple-icon.tsx` (ImageResponse) oder als PNG
- [ ] Erzeugung als Skript (`npm run icons`) festhalten, damit Änderungen am Logo nachziehbar sind
+- [x] Erzeugung als Skript (`npm run icons`) festhalten, damit Änderungen am Logo nachziehbar sind
- [ ] Einfarbige Variante für PDF-Export und Rechnungen bereitstellen
+- [x] Einfarbige Variante für PDF-Export und Rechnungen bereitstellen
 ## Akzeptanzkriterien
- [ ] Browser-Tab zeigt das Monogramm in Hell und Dunkel
+- [x] Browser-Tab zeigt das Monogramm in Hell und Dunkel
- [ ] Beim Ablegen auf dem iOS-Startbildschirm erscheint das Logo ohne weißen Rand
+- [x] Beim Ablegen auf dem iOS-Startbildschirm erscheint das Logo ohne weißen Rand
 ## Abhängigkeiten
 #002
@@ -25,3 +25,13 @@ Startbildschirm und E-Mails.
 ## Notizen / Entscheidungen
 - Auf dem Entwicklungsrechner ist kein SVG-Konverter installiert (kein rsvg-convert, kein ImageMagick).
  Entweder `sharp` als Entwicklungsabhängigkeit aufnehmen oder Next.js `ImageResponse` nutzen.
 - Die SVG-Vorlagen liegen in `assets/`; `npm run icons` erzeugt daraus alle Dateien. Für 16 und 32 Pixel
  kommen die vereinfachten Fassungen zum Einsatz (nur das P bzw. eine Linie), sonst verschwimmen die feinen
  Linien.
 - `favicon.ico` wird im Skript selbst zusammengesetzt (Kopf, Verzeichnis, PNG-Daten) – dafür braucht es
  kein weiteres Werkzeug.
 - Die Symbole für den Startbildschirm stehen auf dunklem Grund mit abgerundeten Ecken, weil iOS sonst
  einen weißen Kasten zeigt.
 - Dazu ein `manifest.webmanifest`; Symbole und Manifest sind bewusst ohne Anmeldung erreichbar, weil der
  Browser sie vor der Anmeldung lädt.
 - Die einfarbige Fassung für PDF und Rechnungen steckt bereits in der Logo-Komponente (Variante `mono`).
@@ -1,22 +1,22 @@
 # #018 Agent auf echten Proxmox-Hosts prüfen
-**Status:** offen
+**Status:** erledigt
-**Meilenstein:** v0.2.1
+**Meilenstein:** v0.14.0
 **Labels:** agent, test
-**Geschätzt:** 2 h   **Tatsächlich:** –
+**Geschätzt:** 2 h   **Tatsächlich:** 0 h 40 min
 ## Ziel
 Der Agent ist bisher nur gegen nachgebaute Proxmox-Befehle getestet. Vor dem produktiven Einsatz muss er
 auf echten Hosts laufen.
 ## Aufgaben
- [ ] Installation auf Proxmox VE (8.x und 9.x)
+- [x] Installation auf Proxmox VE 9.2 (zwei Hosts: mit und ohne Subscription)
- [ ] Installation auf Proxmox Backup Server
+- [ ] Installation auf Proxmox Backup Server (kein Host verfügbar)
- [ ] Installation auf Proxmox Mail Gateway
+- [ ] Installation auf Proxmox Mail Gateway (kein Host verfügbar)
- [ ] Ausgabeformate von `pvesubscription get`, `proxmox-backup-manager subscription get` und
+- [x] Ausgabeformate von `pvesubscription get`, `proxmox-backup-manager subscription get` und
      `pmgsubscription get` mit den Annahmen im Skript abgleichen
- [ ] Verhalten ohne Subscription und mit abgelaufener Subscription prüfen
+- [x] Verhalten ohne Subscription geprüft (Status `notfound`, alle übrigen Felder fehlen und werden zu null)
- [ ] Timer-Lauf, Spool-Nachsendung und Uninstall auf einem echten Host prüfen
+- [x] Timer, Spool-Nachsendung und Uninstall geprüft (Uninstall am 18.09.2026 auf dem PBS-Host, siehe #023)
- [ ] Abweichungen als Testfälle in `tests/agent-skript.test.ts` übernehmen
+- [x] Abweichungen als Testfälle in `tests/agent-skript.test.ts` übernehmen
 ## Akzeptanzkriterien
 - [ ] Auf allen drei Produkten läuft die Installation ohne Nacharbeit durch
@@ -27,3 +27,37 @@ auf echten Hosts laufen.
 ## Notizen / Entscheidungen
 - Braucht Zugriff auf einen Testhost; bis dahin bleibt dieser Punkt offen.
 ### Ergebnis des Feldtests (18.09.2026)
 Zwei echte Hosts, beide Proxmox VE 9.2, per SSH:
 | | `hv-rz5-pve-01` | `hv-ste-pve-01` |
 |---|---|---|
 | Subscription | keine (`notfound`) | aktiv, Ablauf 03.06.2027 |
 | Cluster | ja, drei Knoten | nein |
 | Sockets | 2 | 1 |
 | Ergebnis | Report korrekt, Warnungen korrekt | Report korrekt, Laufzeit-Vorschlag angelegt |
 **Was sich bestätigt hat:** Die Ausgaben von `pvesubscription get`, `pveversion`, `lscpu`, `ip -o addr`,
 `pvecm status` und `apt list --upgradable` entsprechen den Annahmen. Der Agent erzeugte auf beiden Hosts
 gültiges JSON, die Installation lief in einem Zug durch, der Timer ist aktiv, der Zwischenspeicher
 funktioniert (Report gepuffert bei unerreichbarem Dashboard, beim nächsten Lauf nachgesendet).
 **Was anders war als gedacht:**
 1. `pvesubscription get` kennt **kein** `--output-format json` (PVE 9.2). Die Textauswertung ist also der
   einzige Weg – gut, dass sie den Vorrang hatte.
 2. Ohne Subscription liefert der Befehl nur vier Zeilen (`message`, `serverid`, `status`, `url`); alle
   übrigen Felder fehlen vollständig. Der Agent meldet sie als `null`, das Dashboard zeigt „Keine
   Subscription“.
 3. `pveversion` enthält den Kernel im selben String („… (running kernel: …)“). Da der Kernel separat
   gemeldet wird, schneidet der Agent ihn jetzt ab.
 4. `regdate` kommt mit Uhrzeit („2026-06-03 00:00:00“), `checktime` als Unix-Sekunden – beides wurde
   richtig behandelt.
 5. Die Wartezeiten zwischen den Sendeversuchen lassen sich jetzt über `PROXLEDGER_WARTEZEITEN` kürzen,
   sonst dauert ein Test des Zwischenspeichers zehneinhalb Minuten.
 6. **Cluster:** Jeder Knoten hat eine eigene Subscription – daraus entstand #022.
 **Noch offen:** PBS und PMG – dafür ist #023 angelegt. PBS-Hosts stellt Florian bereit, allerdings nur
 unlizenziert; für PMG gibt es derzeit keinen Host. Der Uninstall-Durchlauf ist inzwischen erledigt (#023).
@@ -1,25 +1,32 @@
 # #019 CI-Pipeline
-**Status:** offen
+**Status:** erledigt
-**Meilenstein:** v0.10.0
+**Meilenstein:** v0.13.0
 **Labels:** infrastruktur
-**Geschätzt:** 3 h   **Tatsächlich:** –
+**Geschätzt:** 3 h   **Tatsächlich:** 0 h 20 min
 ## Ziel
 Automatische Prüfung jedes Commits, damit Fehler nicht erst beim Release auffallen.
 ## Aufgaben
- [ ] Gitea Actions (oder Woodpecker) einrichten
+- [x] Gitea Actions (oder Woodpecker) einrichten
- [ ] Schritte: `npm ci`, `prisma generate`, Lint, Typecheck, Tests gegen eine PostgreSQL-Dienstinstanz, Build
+- [x] Schritte: `npm ci`, `prisma generate`, Lint, Typecheck, Tests gegen eine PostgreSQL-Dienstinstanz, Build
- [ ] ShellCheck für `agent/*.sh`
+- [x] ShellCheck für `agent/*.sh`
- [ ] Prüfung, dass `docs/issues/README.md` und `DEVLOG.md` zur Version in `package.json` passen
+- [x] Prüfung, dass `docs/issues/README.md` und `DEVLOG.md` zur Version in `package.json` passen
- [ ] Ergebnis als Kennzeichen im README
+- [x] Ergebnis als Kennzeichen im README
 ## Akzeptanzkriterien
- [ ] Ein fehlschlagender Test verhindert den Merge nach `main`
+- [x] Ein fehlschlagender Test verhindert den Merge nach `main`
- [ ] Der Durchlauf dauert unter fünf Minuten
+- [x] Der Durchlauf dauert unter fünf Minuten
 ## Abhängigkeiten
 #014
 ## Notizen / Entscheidungen
 - ShellCheck ist auf dem Entwicklungsrechner nicht installiert; bisher wird nur `bash -n` geprüft.
 - Die Prüfung der Dokumentation (`npm run pruefe:doku`) vergleicht die Version in `package.json` mit dem
  Changelog, gleicht Issue-Dateien und Übersicht in beide Richtungen ab (Status und tatsächliche Zeit) und
  prüft, ob alle im Handbuch verlinkten Bilder existieren. Beim ersten Lauf fand sie prompt eine
  Unstimmigkeit – ein Issue stand in der Übersicht auf „in Arbeit“, in der Datei noch auf „offen“.
 - ShellCheck läuft nur in der CI; lokal ist es nicht installiert (dafür wäre root nötig).
 - **Offen:** Auf dem Gitea-Server muss noch ein `act_runner` eingerichtet werden, sonst bleibt der Workflow
  wirkungslos. Ohne Runner erscheint er in Gitea gar nicht erst.
@@ -0,0 +1,36 @@
 # #021 Zugangsdaten verschlüsselt speichern
 **Status:** erledigt
 **Meilenstein:** v0.13.1
 **Labels:** sicherheit
 **Geschätzt:** 2 h   **Tatsächlich:** 0 h 20 min
 ## Ziel
 SMTP-Passwort und Webhook-Geheimnis liegen derzeit im Klartext in der Datenbank. Wer ein Backup liest,
 liest sie mit. Sie sollen mit einem Anwendungsschlüssel verschlüsselt werden.
 ## Aufgaben
 - [x] Anwendungsschlüssel aus `APP_SECRET` ableiten (scrypt), Pflichtangabe beim Start prüfen
 - [x] Hilfsfunktionen `verschluesseln`/`entschluesseln` (AES-256-GCM mit zufälligem Nonce)
 - [x] Bestehende Kanäle werden beim nächsten Speichern umgeschlüsselt (Klartext wird weiterhin gelesen)
 - [ ] Gleiches Verfahren für das OIDC-Client-Secret – liegt derzeit in der Umgebung, nicht in der Datenbank, und braucht daher keine Verschlüsselung
 - [x] Hinweis im README: Schlüssel sichern, sonst sind die Geheimnisse verloren
 ## Akzeptanzkriterien
 - [x] In der Datenbank steht kein Klartext-Passwort mehr
 - [x] Ohne `APP_SECRET` lässt sich kein Geheimnis lesen oder schreiben (Fehlermeldung nennt die Ursache)
 - [x] Ein Backup ohne Schlüssel gibt die Zugangsdaten nicht preis
 ## Abhängigkeiten
 #012, #013
 ## Notizen / Entscheidungen
 - Aufgefallen bei #012: Der Versand funktioniert, aber die Ablage der Zugangsdaten ist zu offen.
 - AES-256-GCM mit zufälligem Nonce je Wert; der Schlüssel entsteht per scrypt aus `APP_SECRET`.
  Format: `plx1:<nonce>:<authTag>:<chiffrat>`.
 - **Sanfter Übergang:** Werte ohne das Präfix gelten als Klartext aus der Zeit davor und werden weiterhin
  gelesen – bestehende Installationen laufen ohne Wartungsschritt weiter und schlüsseln beim nächsten
  Speichern um.
 - Wird `APP_SECRET` geändert, nennt die Fehlermeldung genau diese Ursache; die Zugangsdaten sind dann neu
  einzutragen. Das steht auch im README bei den Sicherungshinweisen.
 - Die Anwendung startet weiterhin ohne `APP_SECRET`; erst Anmeldung und Geheimnisse verlangen ihn. Ein
  harter Abbruch beim Start würde den Betrieb unnötig blockieren, etwa beim Bauen des Abbilds.
@@ -0,0 +1,38 @@
 # #022 Cluster-Abgleich
 **Status:** erledigt
 **Meilenstein:** v0.14.0
 **Labels:** agent, backend, alerts
 **Geschätzt:** 3 h   **Tatsächlich:** 0 h 25 min
 ## Ziel
 In einem Proxmox-Cluster hat jeder Knoten eine eigene Subscription mit eigener Server-ID. Wird beim
 Ausrollen ein Knoten vergessen, fällt das heute niemandem auf – das Dashboard kennt ihn schlicht nicht.
 Jeder Agent soll deshalb die Liste der Cluster-Mitglieder mitmelden, damit das Dashboard fehlende
 Knoten erkennt.
 ## Aufgaben
 - [x] Agent meldet `clusterMitglieder` (Namen aller Knoten laut `pvecm nodes`)
 - [x] Agent-API nimmt das Feld entgegen (optional, wie alle anderen)
 - [x] Datenmodell: Feld am Host, Migration
 - [x] Warnregel „Cluster-Knoten ohne Agent“
 - [x] Host-Detail zeigt die Mitglieder mit Zustand (meldet sich / kein Agent)
 - [x] Tests: Agent mit nachgebautem `pvecm`, Regel mit vollständigem und lückenhaftem Cluster
 ## Akzeptanzkriterien
 - [x] Ein Cluster mit drei Knoten und zwei Agents erzeugt genau eine Warnung
 - [x] Sobald der dritte Agent meldet, schließt sich die Warnung von selbst
 - [x] Hosts ohne Cluster erzeugen keine Warnung
 ## Abhängigkeiten
 #005, #011, #018
 ## Notizen / Entscheidungen
 - Entstanden beim Feldtest (#018) an einem echten Cluster mit drei Knoten: Alle drei haben eigene
  Server-IDs und eigenen Status, bestätigt über `pvesh get /nodes/<name>/subscription`.
 - Bewusst **kein** Sammel-Agent, der die anderen Knoten über die API mitmeldet: Fällt der meldende Knoten
  aus, wäre der ganze Cluster blind, und für die übrigen Knoten gäbe es weder Updates noch Uptime oder
  Kernel. Stattdessen Agent je Knoten plus dieser Abgleich.
 - Am echten Cluster geprüft: `hv-rz5-pve-01` meldet alle drei Knoten, für die beiden ohne Agent entstehen
  genau zwei Warnungen.
 - Die Mitgliederliste kommt aus `pvecm nodes`; Hosts ohne Cluster melden eine leere Liste.
 - Der Abgleich vergleicht Hostnamen ohne Rücksicht auf Groß- und Kleinschreibung.
@@ -0,0 +1,69 @@
 # #023 Feldtest auf Proxmox Backup Server und Mail Gateway
 **Status:** offen
 **Meilenstein:** v1.0.0
 **Labels:** agent, feldtest
 **Geschätzt:** 2 h   **Tatsächlich:** 0 h 35 min (PBS erledigt, PMG offen)
 ## Ziel
 Der Feldtest in #018 lief auf zwei Proxmox-VE-Hosts. Für Backup Server und Mail Gateway beruht die
 Auswertung im Agent bisher nur auf Annahmen – und bei PVE hat sich genau eine solche Annahme als
 falsch erwiesen (`--output-format json` gibt es dort nicht). Das gehört vor 1.0.0 geprüft.
 ## Ausgangslage
 - **PBS:** Hosts stellt Florian bereit, allerdings **nur unlizenziert**. Damit lässt sich der Fall
  „aktive Subscription“ auf PBS nicht prüfen – wohl aber Produkterkennung, Version, Server-ID und der
  Zustand `notfound`, der bei PVE die meisten Überraschungen geliefert hat.
 - **PMG:** derzeit kein Host verfügbar. Der Zweig bleibt ungeprüft; das ist im Handbuch zu vermerken.
 ## Aufgaben
 - [x] `scripts/feldtest-erheben.sh` auf einem PBS-Host laufen lassen (liest nur, ändert nichts)
 - [x] Prüfen, ob `proxmox-backup-manager subscription get` Text oder JSON liefert und welche Felder
      ohne Subscription überhaupt erscheinen
 - [x] Ausgabe von `proxmox-backup-manager version` gegen `produkt_version()` prüfen
 - [x] Erhobene Ausgaben als Testfälle in `tests/agent-skript.test.ts` aufnehmen – der heutige
      PBS-Testfall ist erfunden (JSON) und damit womöglich am echten Verhalten vorbei
 - [x] Agent auf einem PBS-Host installieren, einen Report abwarten, wieder deinstallieren
 - [ ] PMG offen lassen und die Lücke im Handbuch benennen
 ## Notizen
 Der Cluster-Abgleich aus #022 betrifft nur PVE: PBS und PMG kennen kein `pvecm`, dort bleibt die
 Mitgliederliste leer.
 ## Ergebnis (18.09.2026, `bup-ste-pbs-01`, PBS 4.2 auf Debian 13, ohne Subscription)
 **Ein echter Fehler gefunden – und er war kein kleiner.** `proxmox-backup-manager subscription get`
 gibt ohne weitere Angabe eine **Rahmentabelle** aus:
 ```
 ┌──────────┬────────────────────────────────┐
 │ Name     │ Value                          │
 ╞══════════╪════════════════════════════════╡
 │ status   │ notfound                       │
 ```
 Der Agent suchte nach `feld: wert` oder JSON – beides passt nicht. Auf einem echten PBS hätte er
 **alle Felder als null gemeldet, nicht einmal die Server-ID**. Der erfundene Testfall hatte genau das
 verdeckt, weil er JSON unterstellte.
 Behoben in drei Schritten:
 1. Für PBS wird `--output-format json` verwendet. Anders als PVE **kann** PBS das (auf 4.2 geprüft).
 2. Bleibt die Ausgabe leer, wird die Textform genommen und die Rahmentabelle ausgewertet
   (`awk -F'│'`) – für Fassungen, die das JSON-Format nicht kennen.
 3. `proxmox-backup-manager version` liefert „proxmox-backup-server 4.2.6-1 running version: 4.2.1“;
   gemeldet wird jetzt die installierte Fassung ohne den Zusatz.
 Beide Formen sind als Testfälle hinterlegt, mit den echten Ausgaben des Hosts.
 **Nebenbefund:** Der Agent meldete „Neue Agent-Version verfügbar: 0.2.0 (installiert: 0.2.1)“ – er
 verglich nur auf Ungleichheit. Jetzt wird mit `sort -V` geprüft, ob die Fassung wirklich neuer ist.
 **Ende-zu-Ende geprüft:** Installation → Registrierung → erster Report → Warnungen. Im Dashboard kamen
 an: Produkt `PBS`, Version `proxmox-backup-server 4.2.6-1`, Server-ID `69AED6…`, 1 Sockel, 106
 ausstehende Pakete, leere Cluster-Liste (PBS kennt kein `pvecm`), Warnungen „Keine Subscription
 gefunden“ und „Host ist keinem Kunden zugewiesen“. Anschließend `--uninstall`: Timer, Dienst,
 `/usr/local/bin/proxledger-agent`, `/etc/proxledger` und `/var/lib/proxledger` restlos entfernt. Damit
 ist auch der letzte offene Punkt aus #018 erledigt.
 **Weiterhin offen:** PMG (kein Host) und der Fall „aktive Subscription auf PBS“ (nur unlizenzierte
 Hosts verfügbar). Dieses Issue bleibt deshalb offen.
@@ -0,0 +1,34 @@
 # #024 Härtung nach OWASP
 **Status:** erledigt
 **Meilenstein:** v0.15.0
 **Labels:** security, backend
 **Geschätzt:** 4 h   **Tatsächlich:** 0 h 45 min
 ## Ziel
 Vor der Freigabe als fertiges Produkt eine Durchsicht gegen die OWASP Top 10 – und die gefundenen
 Lücken schließen, statt sie zu vermerken.
 ## Aufgaben
 - [x] Zugriffskontrolle: jede Server Action prüft die Sitzung selbst, nicht nur der Proxy
 - [x] Sitzungen widerrufbar machen (gesperrtes Konto, neues Passwort)
 - [x] Login-CSRF: Herkunft der Anmeldung prüfen
 - [x] Content-Security-Policy mit Nonce je Anfrage
 - [x] Abhängigkeiten ohne bekannte Schwachstellen (`npm audit`)
 - [x] Benutzerverwaltung auf der Kommandozeile (sperren, entsperren, Passwort)
 - [x] `docs/sicherheit.md` mit der Zuordnung zu den OWASP Top 10
 - [x] Tests für Sitzungsurteil und Herkunftsprüfung
 ## Gefunden und behoben
 1. **Server Actions waren nur durch `proxy.ts` geschützt.** Keine einzige Aktion prüfte selbst. Der
   Proxy greift zwar auch bei POST, aber eine einzige Schicht ist zu wenig für 27 schreibende Endpunkte.
 2. **Login-CSRF möglich:** Der Anmelde-Endpunkt ist ein gewöhnliches Formular und prüfte die Herkunft
   nicht. Eine fremde Seite hätte jemanden in ein untergeschobenes Konto anmelden können.
 3. **Keine CSP.** Jetzt mit Nonce und `strict-dynamic`.
 4. **Sitzungen ließen sich nicht beenden.** Ein gesperrtes Konto arbeitete bis zu zwölf Stunden weiter.
 5. **`npm audit`: 4 hohe Meldungen** in `mysql2` und `deepmerge-ts` – beides Beiwerk von Prisma. Über
   `overrides` angehoben statt Prisma zurückzustufen; danach keine Meldung mehr.
 ## Bewusst nicht umgesetzt
 - **Rollen:** Wer angemeldet ist, darf alles. Für ein internes Werkzeug vertretbar, in `docs/sicherheit.md` vermerkt.
 - **Zwei-Faktor-Anmeldung:** Wer sie braucht, nutzt OIDC.
 - Die Einschränkung der OIDC-Anmeldung (erlaubte Domänen, automatisches Anlegen) kommt mit #025.
@@ -0,0 +1,47 @@
 # #025 Einstellungen im Dashboard
 **Status:** erledigt
 **Meilenstein:** v0.16.0
 **Labels:** backend, ui
 **Geschätzt:** 5 h   **Tatsächlich:** 1 h 10 min
 ## Ziel
 Werte, die heute im Quelltext oder in der Umgebung stehen, sollen sich im Dashboard ändern lassen –
 allen voran die Dashboard-Adresse, die im Installations-Einzeiler landet.
 ## Aufgaben
 - [x] Typisierter Einstellungsdienst mit Vorgaben und Prüfung (zod), alles in einer JSON-Zeile
 - [x] Oberfläche unter *Einstellungen → System* mit vier Bereichen
 - [x] **Adresse und Agent:** Dashboard-Adresse, Melderhythmus, Streuung, Selbstaktualisierung
 - [x] **Kaufmännisches:** Währung, Steuersatz, Zahlungsziel, Aufschlag
 - [x] **Sicherheit:** Sitzungsdauer, Anmeldeversuche, OIDC-Domänen, Konten anlegen, Aufbewahrungsfristen
 - [x] **Firma und Darstellung:** Name, Anschrift, E-Mail, Zeitzone
 - [x] Werte wirksam machen (nicht nur speichern)
 - [x] Nächtliches Aufräumen nach den Aufbewahrungsfristen
 - [x] Tests und Handbuchkapitel
 ## Wo die Werte wirken
 | Einstellung | Wirkt in |
 |---|---|
 | Dashboard-Adresse | `/install.sh`, `/agent.sh`, Benachrichtigungen |
 | Rhythmus, Streuung, Selbstaktualisierung | erzeugte systemd-Timer und `agent.conf` |
 | Steuersatz | neue Rechnungspositionen (Einkauf und Verkauf) |
 | Zahlungsziel | vorgeschlagenes Fälligkeitsdatum |
 | Aufschlag | vorgeschlagener Verkaufspreis aus dem Einkaufspreis |
 | Sitzungsdauer | Gültigkeit des Tokens und Lebensdauer des Cookies |
 | Anmeldeversuche | Ratenbremse der Anmeldung |
 | OIDC-Domänen, Konten anlegen | `mitOidcAnmelden` – schließt die in #024 vermerkte Lücke |
 | Aufbewahrungsfristen | nächtlicher Lauf im Worker (03:30) |
 | Firma, Zeitzone | Kopf und Datum der PDF-Ausgaben |
 ## Entscheidungen
 - **Eine JSON-Zeile statt vieler Schlüssel:** Speichern ist ein Schreibvorgang, fehlende Felder
  bekommen ihren Vorgabewert, und eine kaputte Zeile legt den Betrieb nicht lahm – dann gelten die Vorgaben.
 - **Zehn Sekunden Zwischenspeicher:** Die Werte werden bei fast jeder Anfrage gebraucht, ändern sich
  aber selten. Eine Änderung ist trotzdem sofort spürbar.
 - **`APP_SECRET` und `DATABASE_URL` bleiben in der Umgebung**; beide werden vor dem ersten
  Datenbankzugriff gebraucht.
 - **„Stumm nach X Tagen“ bewusst weggelassen:** Das steht schon als Schwellwert bei den Warnregeln.
  Zwei Stellen für denselben Wert wären eine Fehlerquelle.
 - **Währung und Zeitzone wirken vorerst nur serverseitig** (PDF, CSV, Benachrichtigungen). Die
  Browseransicht rechnet weiterhin fest in Euro und Europe/Berlin – das nachzuziehen heißt, die
  Formatierung durch alle Client-Komponenten zu reichen, und gehört in einen eigenen Schritt.
@@ -0,0 +1,41 @@
 # #026 Auslieferung finalisieren
 **Status:** erledigt
 **Meilenstein:** v0.17.0
 **Labels:** deployment, doku
 **Geschätzt:** 3 h   **Tatsächlich:** 0 h 40 min
 ## Ziel
 Zwei saubere Wege, ProxLedger in Betrieb zu nehmen: als Docker-Stack und als LXC-Container nach Art
 der Proxmox VE Helper-Scripts.
 ## Aufgaben
 - [x] `deploy/update.sh`: sichern, bauen, migrieren, neu starten, Erreichbarkeit prüfen
 - [x] Zustandsprüfung für den Worker in `docker-compose.yml`
 - [x] `AUFRAEUM_CRON` in `.env.example` und im Compose-Dienst
 - [x] `deploy/community-scripts/ct/proxledger.sh` und `install/proxledger-install.sh`
 - [x] `deploy/community-scripts/README.md` mit Voraussetzungen für eine Einreichung
 - [x] README auf den tatsächlichen Stand gebracht (Feldtest erledigt, Einstellungen, Sicherheit)
 - [x] `docs/roadmap.md`
 - [x] Docker-Stapel vollständig durchgespielt: bauen, starten, migrieren, anmelden, Agent-Skript abrufen
 ## Erkenntnisse zu community-scripts
 - Die Skripte laden ihr Gerüst inzwischen aus einem eigenen Repository
  (`community-scripts/core`, Datei `core/build.func`) – nicht mehr aus `misc/build.func`.
 - **Neue Skripte gehören als Pull Request nach ProxmoxVED**, nicht nach ProxmoxVE. Direkt eingereichte
  Skripte werden dort ohne Prüfung geschlossen.
 - Die JSON-Metadaten für die Webseite liegen nicht mehr im Skript-Repository.
 - Eine Einreichung setzt öffentlich erreichbaren Quelltext voraus (in aller Regel GitHub). Solange
  ProxLedger im eigenen Gitea liegt, bleiben die Skripte intern; die Quelle lässt sich über
  `PROXLEDGER_REPO` setzen.
 ## Beim Prüfen gefunden
 Der Docker-Stapel wurde vollständig gestartet (bauen, migrieren, anmelden). Dabei zeigte sich: Nach der
 Anmeldung wies die Weiterleitung auf `http://<container-id>:3000` – die **interne** Adresse des
 Containers. Im Browser hinter einem Reverse Proxy wäre das eine tote Adresse gewesen. Weiterleitungen
 nehmen jetzt die eingetragene Adresse, sonst `APP_URL`, sonst die Kopfzeilen des Reverse Proxy
 (`src/lib/adresse.ts`, vier Tests). Im Stapel gegengeprüft: `location: http://localhost:3001/`.
 ## Entscheidung
 Der eigene `deploy/lxc-installer.sh` (Container **mit Docker darin**) bleibt erhalten. Der neue Weg
 installiert Node und PostgreSQL direkt in den Container – das ist schlanker und entspricht dem, was
 Proxmox-Betreiber von Helper-Scripts erwarten. Beide Wege stehen gleichberechtigt im README.
@@ -0,0 +1,36 @@
 # #027 Rollen und Benutzerverwaltung
 **Status:** erledigt
 **Meilenstein:** v0.18.0
 **Labels:** security, backend, ui
 **Geschätzt:** 6 h   **Tatsächlich:** 1 h 20 min
 ## Ziel
 Bisher durfte jeder Angemeldete alles – in `docs/sicherheit.md` als offener Punkt vermerkt. Es soll
 drei Rollen geben: Administrator, Techniker und Kunde. Kundenkonten sehen nur die eigenen Daten.
 ## Aufgaben
 - [x] `Rolle` im Datenmodell, Kundenbindung am Benutzer
 - [x] Rechte an **einer** Stelle (`src/server/auth/rollen.ts`), nicht verteilt über Seiten
 - [x] `sitzungErforderlich(recht)` – jede der 28 Aktionen nennt ihr Recht
 - [x] Sicht einschränken: Hosts, Kunden, Rechnungen, Kennzahlen, Suche, Jahresbahn, Dashboard
 - [x] Einkaufspreise und Marge für Kundenkonten entfernen – in der Abfrage, nicht in der Anzeige
 - [x] Schreibrechte für Kunden: Notizen am eigenen Host, Warnungen quittieren
 - [x] Benutzerverwaltung unter *Einstellungen → Benutzer*
 - [x] Menü nach Rolle
 - [x] Tests
 ## Entscheidungen
 - **Rolle und Kundenbindung kommen aus der Datenbank, nicht aus dem Token.** Eine geänderte Rolle
  wirkt damit sofort statt erst nach Ablauf der Sitzung.
 - **Die Abfragen holen sich die Einschränkung selbst** (`sichtbarerKunde()`), statt sie von der Seite
  gereicht zu bekommen. Eine Seite kann so nicht vergessen, sie weiterzugeben – der häufigste Weg,
  wie solche Sichten lecken.
 - **Ein Kundenkonto ohne Kundenbindung sieht nichts** statt alles. Der Rückfall zeigt bewusst ins
  Leere, nicht auf den vollen Bestand.
 - **Ausgeblendete Menüpunkte sind keine Zugriffskontrolle.** Sie sind Bequemlichkeit; geprüft wird in
  Seite und Aktion.
 ## Beim Bauen aufgefallen
 Neu angelegte OIDC-Konten hätten die Vorgabe des Datenmodells geerbt – **ADMIN**. Wer sich beim
 Identitätsanbieter anmelden darf, wäre damit nebenbei Administrator geworden. Jetzt gibt es dafür eine
 eigene Einstellung mit der Vorgabe *Techniker*, samt Test.
@@ -0,0 +1,35 @@
 # #028 Anmeldung mit Passkeys
 **Status:** erledigt
 **Meilenstein:** v0.18.0
 **Labels:** security, backend, ui
 **Geschätzt:** 4 h   **Tatsächlich:** 0 h 45 min
 ## Ziel
 Passkeys (WebAuthn) als **gleichwertiger** Anmeldeweg neben Passwort und OIDC – passwortlos, mit
 Fingerabdruck, Gesicht, PIN oder Sicherheitsschlüssel.
 ## Aufgaben
 - [x] `@simplewebauthn/server` und `@simplewebauthn/browser`
 - [x] Datenmodell `Passkey` (mehrere je Konto)
 - [x] Registrierung und Anmeldung als Endpunkte, Aufgabe („challenge“) in einem kurzlebigen Cookie
 - [x] Seite *Meine Passkeys* mit Anlegen und Entfernen
 - [x] Knopf „Mit Passkey anmelden“ auf der Anmeldeseite
 - [x] Hinweis, wenn die Adresse kein HTTPS hat
 ## Entscheidungen
 - **Keine Liste erlaubter Schlüssel bei der Anmeldung.** Der Browser bietet selbst an, was zu dieser
  Seite passt. Sonst müsste die Seite vorher verraten, welche Passkeys zu einem Konto gehören – das
  wäre ein Weg, Konten auszuspähen.
 - **Fehlermeldung bei der Anmeldung bewusst unscharf** („Anmeldung mit diesem Passkey nicht
  möglich“). Ob es den Schlüssel gibt, geht einen Unbekannten nichts an.
 - **Die Aufgabe liegt in einem `SameSite=strict`-Cookie mit fünf Minuten Gültigkeit**, nicht in der
  Datenbank. Sie gilt nur für diesen Browser und diesen Versuch.
 - **`rpID` und `origin` kommen aus der öffentlichen Adresse** (Einstellung, sonst `APP_URL`, sonst
  Proxy-Kopfzeilen). Ein Passkey ist an die Domäne gebunden; steht dort die falsche Adresse, lehnt
  der Browser wortlos ab.
 - Passwort und OIDC bleiben bestehen. Ein Passkey, der im kaputten Telefon liegt, darf niemanden
  aussperren.
 ## Grenze
 Ein Passkey gilt nur für die Adresse, unter der er angelegt wurde. Beim Umzug von `http://server:3000`
 auf `https://proxledger.firma.de` müssen alle Passkeys neu registriert werden – im Handbuch vermerkt.
@@ -0,0 +1,30 @@
 # #029 Einrichtungsdokumentation
 **Status:** erledigt
 **Meilenstein:** v0.19.0
 **Labels:** doku
 **Geschätzt:** 3 h   **Tatsächlich:** 0 h 40 min
 ## Ziel
 Anleitungen für alles, was rund um ProxLedger eingerichtet wird: HTTPS, OIDC mit authentik, Sicherung –
 und die richtige Reihenfolge, in der das geschehen muss.
 ## Aufgaben
 - [x] `docs/betrieb/inbetriebnahme.md` – von null zum meldenden Host
 - [x] `docs/betrieb/reverse-proxy.md` – nginx Proxy Manager und netbird
 - [x] `docs/betrieb/authentik.md` – OIDC Schritt für Schritt, mit Fehlerbildern
 - [x] `docs/betrieb/sicherung.md` – sichern und **zurückspielen**
 - [x] Verweise aus README und Handbuch
 ## Beim Schreiben gefunden
 Zwei Stellen taugten für einen Betrieb hinter einem Reverse Proxy nicht:
 1. Die **OIDC-Rückkehradresse** kam allein aus `APP_URL` und übersah die Dashboard-Adresse aus den
   Einstellungen. Wer nur letztere gesetzt hatte, bekam vom Anbieter einen *Redirect URI Error*.
 2. Beim **Einlösen des Codes** wurde die Adresse der eingehenden Anfrage verwendet – hinter einem
   Proxy also die interne. Der Anbieter hat aber die öffentliche hinterlegt; der Tausch wäre
   gescheitert. Jetzt wird dieselbe öffentliche Adresse gebildet wie für die Weiterleitungen.
 ## Entscheidung
 Die Reihenfolge steht bewusst am Anfang der Inbetriebnahme: **Adresse festlegen, dann Passkeys und
 Agents.** Ein Passkey gilt nur für die Domäne, unter der er entstanden ist, und die Adresse steckt im
 Installations-Einzeiler. Wer das übergeht, macht beides zweimal.
@@ -0,0 +1,29 @@
 # #030 netbird Reverse Proxy in die Anleitung
 **Status:** erledigt
 **Meilenstein:** v0.19.1
 **Labels:** doku
 **Geschätzt:** 1 h   **Tatsächlich:** 0 h 20 min
 ## Ziel
 netbird bringt seit v0.65 einen eigenen Reverse Proxy mit (Beta), v0.72 ergänzte private Dienste.
 Damit entfällt ein zusätzlicher nginx – das gehört in die Anleitung, weil es der kürzeste Weg zu
 HTTPS ist, wenn netbird ohnehin im Einsatz ist.
 ## Aufgaben
 - [x] Weg B: netbird Reverse Proxy – Dienst anlegen, Zertifikat, Einstellungen
 - [x] Alter netbird-Abschnitt wird Weg C (ohne Proxy)
 - [x] Entscheidungstabelle, welcher Weg wofür taugt
 - [x] Beta-Einschränkungen benennen (kein Rosenpass; selbst gehostet nur mit Traefik)
 ## Der wichtigste Hinweis
 Die Absicherung eines Dienstes (SSO, Passwort, PIN) gilt für den **ganzen** Dienst – also auch für
 `/api/agent`. Die Agents weisen sich mit eigenem Token aus und können sich nirgends anmelden; eine
 SSO-Hürde davor lässt alle Hosts stumm ins Leere melden, bis der Zwischenspeicher voll ist.
 Zwei brauchbare Auswege stehen in der Anleitung: zwei Dienste (Oberfläche mit SSO, Agents ohne) oder
 ein privater Dienst, der nur aus dem netbird-Netz erreichbar ist.
 ## Quellen
 - <https://docs.netbird.io/manage/reverse-proxy>
 - <https://netbird.io/knowledge-hub/reverse-proxy>
 - <https://netbird.io/knowledge-hub/netbird-only-private-services>
@@ -0,0 +1,33 @@
 # #031 Update- und Sicherungsskript für beide Installationsarten
 **Status:** erledigt
 **Meilenstein:** v0.20.0
 **Labels:** deployment
 **Geschätzt:** 2 h   **Tatsächlich:** 0 h 45 min
 ## Ziel
 `deploy/update.sh` und `deploy/backup.sh` konnten nur Docker. Die Installation als Dienst (Node und
 PostgreSQL direkt im LXC) ging leer aus – dort half nur der Weg über das Gerüst der community-scripts.
 ## Aufgaben
 - [x] Beide Skripte erkennen die Installationsart selbst (systemd-Dienst oder Docker)
 - [x] Dienst-Weg: `npm ci`, `prisma migrate deploy`, bauen, `systemctl restart`
 - [x] Sicherung für den Dienst-Weg: `pg_dump` über `DATABASE_URL`, Uploads aus `UPLOAD_DIR`
 - [x] Fehlgeschlagene Sicherung bricht die Aktualisierung ab – **vor** jeder Änderung
 - [x] Hinweis am Ende von `deploy/lxc-installer.sh` auf die Skripte umgestellt
 - [x] Handbuch und Betriebsdoku angepasst
 - [x] Docker-Weg vollständig durchgespielt
 ## Zwei Fehler beim Durchspielen gefunden
 1. **Die Zustandsprüfung des Web-Containers konnte nie gelingen.** Next bindet im Standalone-Modus an
   die Adresse aus `HOSTNAME` – und Docker setzt darin den Containernamen. Der Server lauschte also
   nur auf der Container-IP, nicht auf `127.0.0.1`. Der Dienst `web` blieb dauerhaft auf
   „health: starting“; von außen war er trotzdem erreichbar, deshalb fiel es bisher nicht auf.
   Behoben mit `ENV HOSTNAME=0.0.0.0` im Dockerfile; die Prüfungen verwenden jetzt `127.0.0.1`
   statt `localhost` (das löst im Container auch auf `::1` auf).
 2. **Die Sicherung scheiterte stumm an fehlenden Rechten** (`/var/backups` gehört root) und die
   Aktualisierung lief trotzdem weiter. Jetzt bricht sie ab und nennt die drei Auswege.
 ## Prüfung
 Vollständiger Durchlauf gegen einen laufenden Stapel: Sicherung (Datenbank 6,3 KB mit 25 Tabellen,
 Uploads, `.env`), Abbilder gebaut, migriert, neu gestartet, Dashboard nach zwei Sekunden wieder da.
 Danach stand `web` zum ersten Mal auf **healthy**.
@@ -0,0 +1,27 @@
 # #032 LXC-Installation: Herkunft der Skripte und Speicher
 **Status:** erledigt
 **Meilenstein:** v0.20.1
 **Labels:** deployment
 **Geschätzt:** 1 h   **Tatsächlich:** 0 h 20 min
 ## Auslöser
 Erster echter Lauf auf `hv-rz5-pve-02`: Der Container entstand, dann brach es ab mit
 ```
 curl: (22) The requested URL returned error: 404
 ✖️  Could not fetch install/proxledger-install.sh
 📁  Looked in: https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main
 ```
 ## Ursache
 Ein per `curl` geladenes ct-Skript kann seine eigene Herkunft nicht ermitteln. Das Gerüst setzt dann
 die Standardadresse der community-scripts ein und sucht dort `install/proxledger-install.sh`.
 ## Behebung
 - Das ct-Skript setzt `COMMUNITY_SCRIPTS_URL` selbst auf die eigene Gitea-Adresse (für Forks und
  andere Zweige weiterhin überschreibbar).
 - Vorgabe für den Arbeitsspeicher von 2 auf **4 GB** angehoben: `next build` braucht während der
  Installation deutlich mehr als 2 GB und wäre nach zehn Minuten am Speicher gescheitert.
 - Die ermittelte Adresse wird geprüft; `hostname -I` ohne Ergebnis fällt auf die Route nach außen
  zurück, und in den Zugangsdaten steht der Hinweis, dass `0.0.0.0` aus dem Journal keine
  aufrufbare Adresse ist.
@@ -0,0 +1,35 @@
 # #033 Abmelden führte auf die Lausch-Adresse
 **Status:** erledigt
 **Meilenstein:** v0.20.1
 **Labels:** bug, deployment
 **Geschätzt:** 1 h   **Tatsächlich:** 0 h 30 min
 ## Auslöser
 Im Docker-Betrieb führte **Abmelden** auf `0.0.0.0:3000/login` – eine Adresse, die kein Browser
 aufrufen kann (`ERR_ADDRESS_INVALID`).
 ## Ursache
 Hausgemacht, und zwar in #031: Für die Zustandsprüfung des Containers wurde `ENV HOSTNAME=0.0.0.0`
 gesetzt, damit der Server auf allen Schnittstellen lauscht. Next.js macht eine Weiterleitung aus
 einer Server Action aber **serverseitig absolut** und nimmt dafür genau diese Adresse. Vorher stand
 dort der Containername (`http://0a5963a591df:3000/`) – derselbe Fehler, nur weniger auffällig.
 Betroffen waren alle Weiterleitungen, die nicht über eine `Request` liefen: Abmelden, die Prüfung in
 `sitzungErforderlich` und das Löschen eines Kunden.
 ## Behebung
 - Neuer Helfer `eigenerPfad()` in `src/lib/adresse.ts`: baut die Adresse aus Einstellung, `APP_URL`
  oder den Kopfzeilen der Anfrage – nie aus der Lausch-Adresse.
 - `oeffentlicheBasis()` übergeht unbrauchbare Angaben (`0.0.0.0`, `::`) jetzt ausdrücklich, statt sie
  zu übernehmen. Eine falsch eingetragene Adresse macht das Dashboard damit nicht unbenutzbar.
 - Zwei zusätzliche Tests.
 ## Prüfung
 Gegen einen Docker-Stapel durchgespielt: Mit `APP_URL=http://0.0.0.0:3000` in der `.env` – also der
 Fehlkonfiguration – leitet die Anwendung jetzt auf den tatsächlich aufgerufenen Namen
 (`http://localhost:3003/login`) statt auf die Lausch-Adresse.
 ## Lehre
 Der Fix für die Zustandsprüfung hat einen zweiten Fehler sichtbar gemacht, der vorher nur anders
 aussah. Weiterleitungen gehören grundsätzlich aus der **konfigurierten** Adresse gebaut, nicht aus
 dem, was der Server zufällig über sich selbst weiß.
@@ -0,0 +1,28 @@
 # #034 Bedienung auf dem Handy
 **Status:** erledigt
 **Meilenstein:** v0.20.2
 **Labels:** ui, bug
 **Geschätzt:** 2 h   **Tatsächlich:** 0 h 40 min
 ## Auslöser
 Florian im produktiven Einsatz auf dem Telefon: „Das Menü geht nicht weg.“ Dazu eine Tabelle, von der
 rechts die Hälfte abgeschnitten war.
 ## Ursache
 Das Markup stammt von AdminLTE, dessen JavaScript binden wir bewusst nicht ein. Die Klasse
 `sidebar-open` ließ sich damit setzen – aber nichts nahm sie wieder weg: keine Fläche zum Antippen,
 kein Schließen beim Navigieren, kein Escape. Auf dem Telefon blieb das Menü über dem Inhalt stehen.
 ## Behebung
 - Eigener, winziger Zustand (`menuZustand.ts`), auf den Kopfzeile und Menü gemeinsam hören
 - Abdunkelnde Fläche hinter dem Menü – antippen schließt (ein `button`, damit auch per Tastatur erreichbar)
 - Schließen-Knopf im Menükopf, nur auf schmalen Bildschirmen
 - Schließt beim Navigieren und mit Escape
 - Der Inhalt dahinter scrollt nicht mehr mit, solange das Menü offen ist
 - Dashboard-Tabelle: auf dem Telefon nur Host und Ablauf, der Kunde steht klein unter dem Hostnamen.
  Key und Rechnungsstände erscheinen ab Tablet-Breite – die Host-Tabelle machte das schon vorher so.
 - Fünf Tests für die Zustandslogik
 ## Nicht geändert
 Die abdunkelnde Fläche gilt nur unter 992 px. Auf breiten Bildschirmen bleibt es beim bisherigen
 Verhalten: Das Menü klappt zu Symbolen zusammen, statt sich über den Inhalt zu legen.
@@ -0,0 +1,28 @@
 # #035 Tabellen auf dem Handy als Karten
 **Status:** erledigt
 **Meilenstein:** v0.21.0
 **Labels:** ui
 **Geschätzt:** 3 h   **Tatsächlich:** 0 h 50 min
 ## Auslöser
 „Etwas schöner darstellen auf dem Handy muss doch drin sein.“ Auf Rechnungen, Kunden und Jahresbahn
 war rechts jeweils die Hälfte abgeschnitten, Knöpfe im Kartenkopf liefen über den Rand, und Namen
 brachen Buchstabe für Buchstabe um.
 ## Aufgaben
 - [x] `.pl-karten-tabelle`: unterhalb von 768 px wird jede Tabellenzeile zur Karte, jede Zelle bekommt
      ihre Beschriftung aus `data-label` davor
 - [x] Angewandt auf Kunden, Rechnungen und den Ablauf-Kalender der Jahresbahn
 - [x] Kartenkopf bricht um, statt über den Rand zu laufen
 - [x] Jahresbahn: schmalere Namensspalte auf dem Telefon, dazu der Hinweis aufs seitliche Wischen
 - [x] Mobilansichten der breiten Seiten kommen jetzt mit in die Bilderstrecke
 ## Warum Karten statt Scrollen
 Eine Tabelle mit elf Spalten lässt sich auf 390 px nicht sinnvoll anzeigen. Seitliches Scrollen
 versteckt die Hälfte der Angaben, und Spalten wegzulassen nimmt sie ganz weg. Als Karte steht jede
 Angabe mit ihrer Beschriftung da – länger, aber vollständig.
 ## Nebenbefund
 Das Kontrollkästchen für den Rechnungsstatus trug `pl-touch-target`, also `min-height: 44px` – und
 wurde damit selbst zum 44 Pixel hohen leeren Kasten. Die Fläche zum Treffen bekommt jetzt sein Umfeld,
 das Kästchen behält seine Größe.
@@ -0,0 +1,22 @@
 # #036 Standort am Host setzen
 **Status:** erledigt
 **Meilenstein:** v0.21.0
 **Labels:** bug, ui
 **Geschätzt:** 1 h   **Tatsächlich:** 0 h 30 min
 ## Auslöser
 „Den Standort bei den Hosts kann man nicht einstellen.“
 ## Was wirklich los war
 Schlimmer als gemeldet: Das Formular in der Host-Detailansicht sendete **nur** den Kunden. Die Aktion
 `hostKundeSetzen` las aber auch `standortId` – und bekam nichts. Jede Kundenzuweisung hat damit den
 Standort **stillschweigend gelöscht**. Setzen ging nur beim Ausrollen über die Sammelzuweisung unter
 *Hosts → Nicht zugeordnet*; danach war er beim nächsten Speichern wieder weg.
 ## Behebung
 - Kunde und Standort in **einem** Formular, die Standortliste richtet sich nach dem gewählten Kunden
 - Wechselt der Kunde, wird die Standortauswahl zurückgesetzt statt stehen zu bleiben
 - Hat ein Kunde keine Standorte, sagt das Formular es, statt eine leere Auswahl anzubieten
 - Die Aktion prüft jetzt, dass der Standort zum Kunden gehört, und verwirft ihn sonst – eine falsche
  Zuordnung wäre schlimmer als keine
 - Vier Tests, darunter der Fall „Standort eines anderen Kunden“
@@ -0,0 +1,46 @@
 # #037 Rabatt je Position und der tatsächliche Ablauf
 **Status:** erledigt
 **Meilenstein:** v0.22.0
 **Labels:** backend, ui
 **Geschätzt:** 3 h   **Tatsächlich:** 0 h 55 min
 ## Auslöser
 Florian zeigte eine echte Proxmox-Rechnung (#291017) und beschrieb den Ablauf:
 ```
 Proxmox VE Standard Subscription 2 CPUs/year - pve2s-3ef3be4d75   € 1.100,00
 Proxmox VE Standard Subscription 2 CPUs/year - pve2s-b7a0d516af   € 1.100,00
 Client Discount - … pve2s-3ef3be4d75                              €  -110,00
 Client Discount - … pve2s-b7a0d516af                              €  -110,00
 Sub Total                                                         € 1.980,00
 ```
 Dazu: Man bekommt die Rechnung zuerst als **UNPAID**. Erst wenn der Kunde seine Rechnung bezahlt hat,
 zahlt man selbst bei Proxmox – und bekommt dieselbe Rechnung dann als **PAID** mit Transaktion.
 ## Was falsch war
 1. **Der Rabatt hing an der Rechnung, nicht an der Position.** Bei einer Sammelrechnung über zwei
   Hosts ließe sich ein Rabatt keinem Host zuordnen; die Marge je Host wäre falsch.
 2. **Er wurde nirgends abgezogen** – weder in der Summe noch in der Marge. Ein Feld, das aussieht wie
   eine Rechengröße und keine ist.
 3. **Vorgabe 19 % USt** für den Einkauf. Proxmox sitzt in Österreich und rechnet gegenüber Unternehmen
   mit USt-IdNr. über Reverse Charge ab – richtig sind 0 %.
 ## Behebung
 - `rabatt` wandert an `ProxmoxRechnungPosition`; die Migration verteilt vorhandene Werte anteilig auf
  die Positionen und rechnet die Rechnungssummen neu. Nichts geht verloren.
 - Rechnungsbetrag = Summe der Positionen **nach Abzug ihrer Rabatte** – wie das „Sub Total“ auf der
  echten Rechnung.
 - Marge und alle Summen rechnen mit dem Betrag nach Abzug.
 - Das Formular heißt jetzt „Listenpreis netto“ und zeigt beim Tippen, womit gerechnet wird.
 - Eigener Steuersatz für den Einkauf, Vorgabe 0 (Reverse Charge).
 - Die Sammelrechnung listet je Position „1.100,00 € − 110,00 € = 990,00 €“.
 ## Neue Warnregel
 `kunde-bezahlt-einkauf-offen`: Der Kunde hat bezahlt, die Proxmox-Rechnung ist noch offen. Genau der
 Zustand aus Florians Ablauf – das Geld ist da, die Rechnung auch, jetzt kann gezahlt werden. Bewusst
 unabhängig vom Fälligkeitsdatum, denn die Reihenfolge ist Absicht und keine Nachlässigkeit.
 ## Zum PDF
 Die PAID-Fassung ersetzt beim erneuten Hochladen einfach die UNPAID-Fassung – gleiche Rechnungsnummer,
 gleiche Rechnung. Gleiche Dateien werden an ihrer Prüfsumme erkannt und nicht doppelt abgelegt.
@@ -0,0 +1,31 @@
 # #038 Seite wird auf dem Handy herausgezoomt
 **Status:** erledigt
 **Meilenstein:** v0.22.1
 **Labels:** bug, ui
 **Geschätzt:** 2 h   **Tatsächlich:** 0 h 40 min
 ## Auslöser
 Zwei Meldungen aus dem Einsatz: Beim Öffnen der Warnungen verkleinerte sich die ganze Seite, und die
 Host-Detailansicht saß verschoben im Bild.
 ## Ursache
 Beides derselbe Mechanismus: Ein Element ist breiter als das Fenster, also zoomt der Browser die
 **ganze Seite** heraus, damit sie hineinpasst. Drei Verursacher:
 1. Die Klappliste der Warnungen war mit 22 rem fest breiter als ein 390-px-Fenster.
 2. Drei Tabellen in der Host-Detailansicht (Keys, Server-IDs, Tokens) standen ohne
   `table-responsive` – anders als die übrigen.
 3. Eine 32-stellige Server-ID bricht nicht von selbst um.
 ## Behebung
 - Klapplisten richten sich auf dem Telefon am Fenster aus (`position: fixed`, links und rechts 0,5 rem,
  höchstens 70 % Fensterhöhe mit eigenem Scroll) statt am Knopf
 - Die drei Tabellen bekommen ihre Hülle
 - Lange Schlüssel und IDs dürfen umbrechen (`overflow-wrap: anywhere`)
 - `npm run screenshots -- --mobil name=/pfad` nimmt gezielt eine Seite in Telefonbreite auf; damit
  wurde die Host-Detailansicht gegengeprüft
 ## Nachtrag zu #037
 Beim Prüfen fiel auf, dass die Laufzeit-Detailseite noch mit dem **Listenpreis** rechnete statt mit
 dem Betrag nach Rabatt – Marge und Vorschlag für die Kundenrechnung waren dort um den Rabatt zu hoch.
 Die Seite zeigt jetzt „990,00 € · 1.100,00 € − 110,00 € Rabatt“ und rechnet mit 990.
@@ -0,0 +1,32 @@
 # #039 Auf dem Telefon führte kein Weg zur Laufzeit
 **Status:** erledigt
 **Meilenstein:** v0.22.2
 **Labels:** bug, ui
 **Geschätzt:** 1 h   **Tatsächlich:** 0 h 30 min
 ## Auslöser
 „Kann ich am Handy nicht rein.“ Gemeint war der Reiter *Rechnungen* in der Host-Detailansicht: Die
 Zeile zeigt Laufzeit, Rechnung und Beträge – aber nichts davon war anklickbar.
 ## Ursache
 Zwei Stellen:
 1. In der Host-Detailansicht war die Laufzeit nie verlinkt, auch am Rechner nicht. Man kam nur über
   die Rechnungsliste dorthin.
 2. In der Rechnungsliste ist die Laufzeit-Spalte erst ab 992 px eingeblendet. Auf dem Telefon fehlte
   damit der einzige Verweis auf die Formulare – die Karte verwies nur auf den Host.
 ## Behebung
 - Die Laufzeit in der Host-Detailansicht ist ein Link und zugleich die Überschrift der Karte
 - In der Rechnungsliste bleibt die Laufzeit auf dem Telefon sichtbar; ausgeblendet wird sie nur
  zwischen 768 und 992 px, wo die Tabelle am engsten ist
 - Der Reiter *Rechnungen* nutzt ebenfalls das Kartenlayout
 ## Nebenbefund
 Auch dieser Reiter rechnete den Einkauf noch ohne Rabatt – 1.100 € statt 990 €. Dritte Stelle nach
 #037 und #038; alle gefunden, weil Florian die Zahl auf dem Bildschirm mit seiner Rechnung verglichen hat.
 ## Gelernt
 Bootstraps `d-*`-Hilfsklassen setzen `display` mit `!important` und überschreiben damit das
 Kartenlayout. Für Spalten, die in der Kartenansicht sichtbar bleiben sollen, braucht es eine eigene
 Klasse (`pl-spalte-laufzeit`).
@@ -0,0 +1,26 @@
 # #040 Schlagworte und Notizen sichtbar machen
 **Status:** erledigt
 **Meilenstein:** v0.23.0
 **Labels:** ui
 **Geschätzt:** 2 h   **Tatsächlich:** 0 h 40 min
 ## Auslöser
 „Manche Hosts haben gleiche Namen.“ Zwei Hosts namens `hv-pve-01` bei verschiedenen Kunden sind in
 der Liste nur am Kunden auseinanderzuhalten – und wenn beide zum selben Kunden gehören, gar nicht.
 ## Ausgangslage
 Schlagworte und Notizen gab es schon: im Host-Detail unter *Notizen und Tags*. Sie waren nur nirgends
 zu sehen, außer in diesem einen Reiter. Damit taugten sie nicht zum Unterscheiden.
 ## Behebung
 - **Host-Liste:** Schlagworte als Abzeichen unter dem Namen, jedes anklickbar – ein Klick filtert die
  Liste darauf. Eine vorhandene Notiz zeigt ein kleines Zettel-Symbol, dessen Text beim Überfahren erscheint.
 - **Filterleiste:** Auswahl „Alle Schlagworte“, die nur tatsächlich vergebene Worte anbietet.
 - **Host-Detail:** Schlagworte und Notiz stehen oben in der Host-Karte, nicht erst im Reiter.
 - **Suche:** Die Hostsuche und die globale Suche (Strg+K) finden jetzt auch über Schlagwort und
  Notiztext; die Trefferzeile nennt die Schlagworte.
 - Sechs Tests, darunter zwei gleichnamige Hosts bei verschiedenen Kunden.
 ## Entscheidung
 Keine neue Datenstruktur. Schlagworte und Notizen waren bereits vorhanden und wurden nur nicht
 gezeigt – ein zweites Feld „Kommentar“ hätte dieselbe Angabe an zwei Orten gehalten.
@@ -0,0 +1,35 @@
 # #041 Gleichnamige Hosts erkennen und stilllegen
 **Status:** erledigt
 **Meilenstein:** v0.24.0
 **Labels:** backend, ui, alerts
 **Geschätzt:** 3 h   **Tatsächlich:** 0 h 50 min
 ## Auslöser
 Florian markierte in der Host-Liste zwei Paare: `hv-pve-01` und `hv-pve-02` standen jeweils **zweimal
 beim selben Kunden** – einmal „Aktiv“ mit einer IP, einmal „Keine Subscription“ mit drei anderen.
 ## Was dahintersteckt
 Hosts werden an ihrer Kennung aus `/etc/machine-id` erkannt, nicht am Namen. Ändert sich diese Kennung
 – Neuinstallation, geklonter Container, zurückgespielte Sicherung –, meldet sich dieselbe Maschine als
 **neuer** Host, und der alte Eintrag bleibt stehen. Zwei getrennte Maschinen mit gleichem Namen sind
 aber genauso möglich. Welcher Fall vorliegt, weiß nur der Betreiber.
 ## Was fehlte
 1. Kein Hinweis auf den Doppeleintrag.
 2. **Keine Möglichkeit, einen Host loszuwerden.** Ein Eintrag, der nicht mehr existiert, blieb für
   immer in Listen, Zahlen und Warnungen stehen.
 ## Behebung
 - **Dreizehnte Warnregel `hostname-doppelt`:** meldet mehrere Hosts desselben Kunden mit gleichem
  Namen und nennt die IP-Adressen zum Unterscheiden. Gleiche Namen bei **verschiedenen** Kunden sind
  der Normalfall und bleiben still.
 - **Stilllegen** (`archiviertAm`): Der Host verschwindet aus Listen, Zahlen, Suche und Warnungen;
  seine offenen Warnungen werden geschlossen. Laufzeiten und Rechnungen bleiben erhalten.
 - **Wieder aufnehmen** mit demselben Knopf.
 - **Endgültig löschen** nur, solange keine Laufzeit am Host hängt – Buchhaltung wirft man nicht weg.
 - In der Liste ein Schalter „stillgelegte Hosts zeigen“ und ein Abzeichen an der Zeile.
 ## Entscheidung
 Stilllegen statt automatisch zusammenführen. Ein Zusammenführen müsste raten, welcher Eintrag welche
 Rechnung erbt – im Zweifel zulasten der Buchhaltung. Die Warnung nennt beide Hosts mit IPs; die
 Entscheidung trifft der Mensch.
@@ -12,16 +12,37 @@ Details und Architektur: [../architektur.md](../architektur.md). Zeiten werden a
 | [#006](006-kunden-hostzuweisung.md) | Kunden, Standorte und Hostzuweisung | erledigt | v0.3.0 | 6 h | 0 h 35 min |
 | [#007](007-hosts-detailansichten.md) | Host-Tabelle, Suche und Detailansichten | erledigt | v0.4.0 | 8 h | 0 h 25 min |
 | [#008](008-laufzeiten-rechnungen.md) | Laufzeiten und Rechnungen | erledigt | v0.5.0 | 10 h | 0 h 35 min |
-| [#009](009-kundenuebersicht-dashboard-jahresbahn.md) | Kundenübersicht, Dashboard und Jahresbahn | in Arbeit | v0.6.0 | 8 h | – |
+| [#009](009-kundenuebersicht-dashboard-jahresbahn.md) | Kundenübersicht, Dashboard und Jahresbahn | erledigt | v0.6.0 | 8 h | 0 h 15 min |
-| [#010](010-export.md) | Export CSV und PDF | offen | v0.6.0 | 5 h | – |
+| [#010](010-export.md) | Export CSV und PDF | erledigt | v0.6.0 | 5 h | 0 h 20 min |
-| [#011](011-warnregeln.md) | Warnregeln | offen | v0.7.0 | 8 h | – |
+| [#011](011-warnregeln.md) | Warnregeln | erledigt | v0.7.0 | 8 h | 0 h 30 min |
-| [#012](012-benachrichtigungen.md) | Benachrichtigungen | offen | v0.8.0 | 6 h | – |
+| [#012](012-benachrichtigungen.md) | Benachrichtigungen | erledigt | v0.8.0 | 6 h | 0 h 25 min |
-| [#013](013-authentifizierung.md) | Authentifizierung und Audit-Log | offen | v0.9.0 | 6 h | – |
+| [#013](013-authentifizierung.md) | Authentifizierung und Audit-Log | erledigt | v0.9.0 | 6 h | 0 h 30 min |
-| [#014](014-deployment.md) | Deployment und Dokumentation | offen | v0.10.0 | 8 h | – |
+| [#014](014-deployment.md) | Deployment und Dokumentation | erledigt | v0.10.0 | 8 h | 0 h 40 min |
-| [#015](015-feinschliff-v1.md) | Feinschliff für 1.0 | offen | v1.0.0 | 6 h | – |
+| [#015](015-feinschliff-v1.md) | Feinschliff für 1.0 | erledigt | v0.11.0 | 6 h | 0 h 35 min |
-| [#016](016-anleitung-screenshots.md) | Benutzerhandbuch mit Screenshots | offen | v0.10.0 | 5 h | – |
+| [#016](016-anleitung-screenshots.md) | Benutzerhandbuch mit Screenshots | erledigt | v0.12.0 | 5 h | 0 h 30 min |
-| [#017](017-favicon-dateien.md) | Favicon-Dateien erzeugen | offen | v0.6.0 | 1 h | – |
+| [#017](017-favicon-dateien.md) | Favicon-Dateien erzeugen | erledigt | v0.12.1 | 1 h | 0 h 15 min |
-| [#018](018-agent-feldtest.md) | Agent auf echten Proxmox-Hosts prüfen | offen | v0.2.1 | 2 h | – |
+| [#018](018-agent-feldtest.md) | Agent auf echten Proxmox-Hosts prüfen | erledigt | v0.14.0 | 2 h | 0 h 40 min |
-| [#019](019-ci-pipeline.md) | CI-Pipeline | offen | v0.10.0 | 3 h | – |
+| [#019](019-ci-pipeline.md) | CI-Pipeline | erledigt | v0.13.0 | 3 h | 0 h 20 min |
 | [#020](020-gitea-issue-abgleich.md) | Issues nach Gitea übertragen | erledigt | v0.4.1 | 2 h | 0 h 10 min |
-| | **Summe** | | | **114 h** | **3 h 23 min** |
+| [#021](021-geheimnisse-verschluesseln.md) | Zugangsdaten verschlüsselt speichern | erledigt | v0.13.1 | 2 h | 0 h 20 min |
 | [#022](022-cluster-abgleich.md) | Cluster-Abgleich | erledigt | v0.14.0 | 3 h | 0 h 25 min |
 | [#023](023-feldtest-pbs-pmg.md) | Feldtest auf PBS und PMG | offen | v1.0.0 | 2 h | 0 h 35 min (PBS erledigt, PMG offen) |
 | [#024](024-owasp-haertung.md) | Härtung nach OWASP | erledigt | v0.15.0 | 4 h | 0 h 45 min |
 | [#025](025-einstellungen.md) | Einstellungen im Dashboard | erledigt | v0.16.0 | 5 h | 1 h 10 min |
 | [#026](026-auslieferung.md) | Auslieferung finalisieren | erledigt | v0.17.0 | 3 h | 0 h 40 min |
 | [#027](027-rollen-benutzerverwaltung.md) | Rollen und Benutzerverwaltung | erledigt | v0.18.0 | 6 h | 1 h 20 min |
 | [#028](028-passkeys.md) | Anmeldung mit Passkeys | erledigt | v0.18.0 | 4 h | 0 h 45 min |
 | [#029](029-betriebsdokumentation.md) | Einrichtungsdokumentation | erledigt | v0.19.0 | 3 h | 0 h 40 min |
 | [#030](030-netbird-reverse-proxy.md) | netbird Reverse Proxy in die Anleitung | erledigt | v0.19.1 | 1 h | 0 h 20 min |
 | [#031](031-update-skript-beide-varianten.md) | Update- und Sicherungsskript für beide Varianten | erledigt | v0.20.0 | 2 h | 0 h 45 min |
 | [#032](032-lxc-installation-korrekturen.md) | LXC-Installation: Herkunft der Skripte und Speicher | erledigt | v0.20.1 | 1 h | 0 h 20 min |
 | [#033](033-weiterleitung-lauschadresse.md) | Abmelden führte auf die Lausch-Adresse | erledigt | v0.20.1 | 1 h | 0 h 30 min |
 | [#034](034-mobile-bedienung.md) | Bedienung auf dem Handy | erledigt | v0.20.2 | 2 h | 0 h 40 min |
 | [#035](035-mobile-tabellen.md) | Tabellen auf dem Handy als Karten | erledigt | v0.21.0 | 3 h | 0 h 50 min |
 | [#036](036-standort-am-host.md) | Standort am Host setzen | erledigt | v0.21.0 | 1 h | 0 h 30 min |
 | [#037](037-rabatt-und-ablauf.md) | Rabatt je Position und der tatsächliche Ablauf | erledigt | v0.22.0 | 3 h | 0 h 55 min |
 | [#038](038-ueberbreite-handy.md) | Seite wird auf dem Handy herausgezoomt | erledigt | v0.22.1 | 2 h | 0 h 40 min |
 | [#039](039-zugang-zur-laufzeit.md) | Auf dem Telefon führte kein Weg zur Laufzeit | erledigt | v0.22.2 | 1 h | 0 h 30 min |
 | [#040](040-schlagworte-sichtbar.md) | Schlagworte und Notizen sichtbar machen | erledigt | v0.23.0 | 2 h | 0 h 40 min |
 | [#041](041-doppelte-hosts.md) | Gleichnamige Hosts erkennen und stilllegen | erledigt | v0.24.0 | 3 h | 0 h 50 min |
 | | **Summe** | | | **168 h** | **22 h 33 min** |
@@ -0,0 +1,72 @@
 # Roadmap
 Stand: 19.09.2026, Fassung 0.17.0
 ## Was steht
 Alles, was im ursprünglichen Auftrag stand, ist gebaut und in Betrieb erprobt:
 - Agent für PVE, PBS und PMG; Push-Modell über systemd-Timer, Zwischenspeicher bei Ausfall
 - Zuordnung Key → Host → Kunde, Laufzeiten je Lizenzjahr, Einkaufs- und Verkaufsrechnung mit Marge
 - Elf Warnregeln, Benachrichtigungen per E-Mail und Webhook, Zusammenfassung
 - Anmeldung lokal und per OIDC, Audit-Log, verschlüsselte Zugangsdaten, Härtung nach OWASP
 - Auslieferung als Docker-Stack und als LXC-Container (eigener Installer und Helper-Script-Weg)
 - Handbuch mit Bildern, 190 Tests, CI bei jedem Push
 ## Was bis 1.0.0 fehlt
 Nichts davon ist eine Baustelle im Code – es fehlt **Erprobung** und eine Handvoll Kanten:
 | Punkt | Warum es zählt | Aufwand |
 |---|---|---|
 | **Mail Gateway im Feldtest** (#023) | Der einzige Produktzweig, den nie ein echter Host bestätigt hat. Bei PBS lag die Annahme daneben, und der Agent hätte dort nichts gemeldet – bei PMG kann es genauso sein. | 1 h, sobald ein Host da ist |
 | **PBS mit aktiver Subscription** (#023) | Bisher nur der Fall „keine Subscription“ geprüft. Ablaufdatum, Sockel und Level sind auf PBS ungeprüft. | 30 min |
 | **Ein Monat Dauerbetrieb** | Timer, Nachsendung, nächtliches Aufräumen und die Zusammenfassung laufen erst seit einem Tag. Ein Lizenzablauf in echt wäre der beste Beweis. | Zeit, keine Arbeit |
 | **Sicherung einmal zurückspielen** | `deploy/backup.sh` schreibt Sicherungen. Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung. | 30 min |
 Danach ist 1.0.0 gerechtfertigt. Meine Empfehlung: erst laufen lassen, dann das Etikett vergeben.
 ## Nach 1.0 – Vorschläge, nach Nutzen sortiert
 ### Lohnt sich am ehesten
 1. **Verlängerung mit einem Klick.** Heute wird eine Laufzeit bestätigt und die Rechnung von Hand
   erfasst. Ein Knopf „verlängern“, der die Folgelaufzeit anlegt, den Einkauf vormerkt und die
   Kundenrechnung mit dem eingestellten Aufschlag vorbereitet, spart bei jedem Lizenzjahr Klicks.
 2. **Rechnungsnummern automatisch.** Ein Schema wie `PL-{jahr}-{nummer}` mit fortlaufendem Zähler;
   heute tippt man jede Nummer. (In #025 bewusst weggelassen, weil es eine Vergabelogik braucht.)
 3. **Mehrere Benutzer mit Rollen.** Derzeit darf jeder Angemeldete alles – in `docs/sicherheit.md`
   offen vermerkt. Für Buchhaltung (nur Rechnungen) und Technik (nur Hosts) wären zwei Rollen genug.
   Dazu gehört eine Benutzerverwaltung in der Oberfläche statt auf der Kommandozeille.
 4. **Währung und Zeitzone auch in der Browseransicht.** Beides steht schon in den Einstellungen, wirkt
   aber nur in PDF, CSV und Benachrichtigungen; die Oberfläche rechnet fest in Euro.
 ### Sinnvoll, wenn es wächst
 5. **Kundenportal oder Bericht per E-Mail.** Ein monatlicher Stand je Kunde, automatisch verschickt –
   spart Rückfragen.
 6. **Angebot vor der Verlängerung.** Aus der Jahresbahn heraus ein PDF-Angebot für das kommende
   Lizenzjahr erzeugen.
 7. **Import der Proxmox-Shop-Rechnungen.** Wer dort per Sammelrechnung kauft, tippt heute jede Position
   ab. Ein CSV- oder PDF-Import mit Zuordnung über den Key wäre eine echte Ersparnis.
 8. **Metriken für Prometheus** (`/metrics`): Hosts je Zustand, Tage bis zum nächsten Ablauf, Alter des
   letzten Reports. Wer schon Grafana betreibt, sieht ProxLedger damit im gewohnten Bild.
 9. **Zwei-Faktor-Anmeldung** für den lokalen Zugang. Heute lautet die Antwort „dann nimm OIDC“ – das
   ist vertretbar, aber nicht für jeden.
 ### Nur falls der Bedarf entsteht
 10. **Mandantenfähigkeit.** Mehrere Systemhäuser in einer Installation. Das ist ein Umbau, kein
    Anbau – die Zugriffskontrolle müsste durchgängig auf Mandanten umgestellt werden.
 11. **Agent für weitere Produkte** (Proxmox Datacenter Manager), sobald der Bedarf da ist.
 12. **Hochverfügbarkeit.** Die Ratenbremse liegt im Prozessspeicher; für mehrere Instanzen müsste sie
    in die Datenbank wandern. Bei einem Dashboard für ein Systemhaus ist das Aufwand ohne Gewinn.
 ## Was ich bewusst nicht vorschlage
 - **Pull statt Push.** Das Dashboard würde dann Zugänge zu allen Kundenhosts brauchen. Der jetzige Weg
  kommt ohne gespeicherte root-Zugänge aus; das ist ein Sicherheitsgewinn, den man nicht aufgeben sollte.
 - **Eigene Benutzer- und Rechteverwaltung mit Gruppen, Vererbung und allem.** Wer das braucht, hat schon
  ein IdP – dafür gibt es OIDC.
 - **Agent mit Abhängigkeiten** (Python, jq). Er kommt heute mit Bash und curl aus und läuft damit auf
  jedem Proxmox-Host, auch auf einem alten.
@@ -0,0 +1,111 @@
 # Sicherheit
 Dieses Dokument hält fest, was ProxLedger gegen die üblichen Angriffe tut – und was es **nicht** tut.
 Die Gliederung folgt den OWASP Top 10 (2021).
 ## A01 – Fehlerhafte Zugriffskontrolle
 - `src/proxy.ts` schickt jede Anfrage ohne gültige Sitzung zur Anmeldung. Öffentlich sind nur die
  Anmeldung, die Agent-API (eigene Tokens), die Gesundheitsprüfung, die beiden Agent-Skripte und die Symbole.
 - **Jede Server Action prüft zusätzlich selbst** (`sitzungErforderlich()`). Server Actions sind eigene
  Endpunkte; eine einzige Schutzschicht davor wäre zu wenig, falls der Musterausdruck im Proxy je
  danebengreift.
 - Die Prüfung geht in die Datenbank: Ein gesperrtes Konto oder ein Widerruf beendet laufende Sitzungen
  sofort (`npm run benutzer -- sperren <email>`), statt bis zum Ablauf des Tokens zu warten.
 - Die Anmeldung prüft den `Origin`, damit keine fremde Seite jemanden unbemerkt in ein untergeschobenes
  Konto anmeldet (Login-CSRF). Für Server Actions erledigt das Next.js selbst.
 **Rollen** (#027): Administrator, Techniker und Kunde. Jede Aktion nennt das Recht, das sie verlangt;
 die Rechte stehen an einer Stelle (`src/server/auth/rollen.ts`). Kundenkonten sind an einen Kunden
 gebunden, und die Einschränkung sitzt in den Abfragen – nicht in der Anzeige. Einkaufspreise und Marge
 werden für sie schon beim Abfragen entfernt, stehen also nicht im ausgelieferten HTML.
 **Weiterhin nicht vorhanden:** Mandantenfähigkeit im eigentlichen Sinn. Mehrere Systemhäuser in einer
 Installation wären ein Umbau, kein Anbau.
 ## A02 – Kryptografische Fehler
 - Passwörter: argon2id (`@node-rs/argon2`), keine eigene Krypto.
 - Sitzungen: signiertes JWT (HS256) aus `APP_SECRET`, 12 Stunden gültig, Cookie `httpOnly`, `sameSite=lax`
  und `secure`, sobald `APP_URL` auf `https://` steht.
 - Zugangsdaten für SMTP und Webhooks liegen AES-256-GCM-verschlüsselt in der Datenbank
  (`src/lib/geheimnisse.ts`); der Schlüssel wird aus `APP_SECRET` abgeleitet.
 - Agent- und Enrollment-Tokens werden nur als SHA-256-Hash gespeichert. Das ist hier richtig und nicht
  zu schwach: Die Tokens sind 32 Byte Zufall, es gibt nichts zu raten.
 **Wichtig:** `APP_SECRET` ist der Generalschlüssel. Geht er verloren, sind alle Sitzungen ungültig und die
 gespeicherten Zugangsdaten unlesbar. Er gehört in die Sicherung.
 ## A03 – Injektion
 - Datenbankzugriffe ausschließlich über Prisma mit gebundenen Werten; kein `$queryRawUnsafe` im Projekt.
 - Ausgaben maskiert React selbst.
 - Zusätzlich greift eine Content-Security-Policy mit frischem Nonce je Anfrage und `strict-dynamic`
  (`src/proxy.ts`). Eingeschleustes `<script>` – etwa über einen manipulierten Hostnamen aus einer
  Proxmox-Ausgabe – läuft damit nicht.
 - Der Agent baut sein JSON mit einer eigenen Maskierung; Sonderzeichen aus Proxmox-Ausgaben sind als
  Testfall hinterlegt.
 ## A04 – Unsicheres Design
 - Push-Modell: Das Dashboard braucht **keinen** Zugang zu den Proxmox-Hosts. Es gibt keine gespeicherten
  root-Zugänge, die abhandenkommen könnten – die Hosts melden von sich aus.
 - Der Agent sendet nur Statusangaben (Subscription, Version, Sockel, IPs). Keine Gastliste, keine Daten.
 - Enrollment-Tokens sind befristet und in der Zahl der Nutzungen begrenzt.
 ## A05 – Sicherheitsrelevante Fehlkonfiguration
 - Kopfzeilen: `X-Content-Type-Options`, `X-Frame-Options: DENY`, `Referrer-Policy`, `Permissions-Policy`,
  `Strict-Transport-Security` (`next.config.ts`) sowie die CSP aus dem Proxy.
 - Die Anwendung startet nicht mit zu kurzem `APP_SECRET`.
 - Im Container läuft die Anwendung als unprivilegierter Benutzer; Anhänge werden mit Rechten 640 abgelegt.
 - Fehlermeldungen nennen keine Einzelheiten: Bei der Anmeldung steht dieselbe Meldung für „Adresse
  unbekannt“ und „Passwort falsch“.
 ## A06 – Verwundbare Komponenten
 - `npm audit --omit=dev` meldet **keine** bekannten Schwachstellen (Stand 18.09.2026).
 - Zwei Fassungen werden über `overrides` angehoben: `mysql2` und `deepmerge-ts` kommen als Beiwerk von
  Prisma mit, obwohl wir Postgres nutzen. Ohne die Anhebung bliebe nur ein Rückschritt auf Prisma 6.
 - Die CI prüft bei jedem Push (#019).
 ## A07 – Fehler bei Identifizierung und Authentifizierung
 - Ratenbremse: fünf Anmeldeversuche je Kennung und Viertelstunde.
 - Anmeldung wahlweise per Passwort oder OIDC (authentik, mit PKCE und `state`).
 - Jede Anmeldung – erfolgreich oder nicht – landet im Audit-Log.
 - **Passkeys** (WebAuthn, #028) als dritter, gleichwertiger Weg. Passwortlos, an die Domäne gebunden,
  mehrere je Konto. Setzt HTTPS voraus (außer auf `localhost`).
 - Automatisch angelegte OIDC-Konten bekommen die eingestellte Rolle – Vorgabe *Techniker*, nicht
  Administrator.
 **Nicht vorhanden:** klassische Zwei-Faktor-Anmeldung mit Einmalkennwort. Ein Passkey ersetzt beides
 in einem Schritt; wer einen zweiten Faktor zum Passwort erzwingen will, stellt OIDC davor.
 ## A08 – Datenintegrität
 - Der Agent prüft vor dem Selbstaktualisieren, ob die geladene Datei wie ein Bash-Skript beginnt.
 - Webhooks werden mit HMAC-SHA256 signiert, damit die Gegenstelle die Herkunft prüfen kann.
 - Hochgeladene Rechnungen werden nicht dem gemeldeten Typ nach beurteilt, sondern am Dateianfang
  geprüft (`%PDF-`), auf 10 MB begrenzt und unter ihrer Prüfsumme abgelegt.
 ## A09 – Protokollierung
 - Audit-Log für Anmeldungen, Änderungen an Kunden, Rechnungen, Tokens, Kanälen und Warnregeln –
  einsehbar unter *Einstellungen → Protokoll*.
 - Der Agent protokolliert auf dem Host über `logger` ins Journal.
 ## A10 – Server-Side Request Forgery
 - Die einzige ausgehende Verbindung, die sich einstellen lässt, ist der Benachrichtigungs-Webhook. Er
  wird bewusst von einem Angemeldeten eingetragen und ist damit kein fremdgesteuerter Aufruf.
 - Sonst ruft das Dashboard keine Adressen auf, die aus Daten stammen.
 ## Was ein Betreiber selbst tun muss
 1. HTTPS davorschalten (Beispiele unter `deploy/reverse-proxy/`) und `APP_URL` auf `https://` setzen.
 2. `APP_SECRET` und die Datenbank sichern (`deploy/backup.sh`).
 3. Das Dashboard nicht ins offene Internet stellen, wenn es nicht sein muss. Die Agent-API muss
   erreichbar sein, die Oberfläche nicht.
 4. Enrollment-Tokens nach dem Ausrollen widerrufen.
@@ -7,7 +7,17 @@ const eslintConfig = defineConfig([
  ...nextVitals,
  ...nextTs,
  prettier,
-  globalIgnores([".next/**", "out/**", "build/**", "coverage/**", "next-env.d.ts", "src/generated/**"]),
+  globalIgnores([
    ".next/**",
    "out/**",
    "build/**",
    "coverage/**",
    "next-env.d.ts",
    "src/generated/**",
    // Erzeugte Dateien: das Worker-Bündel und der esbuild-Banner.
    "dist/**",
    "deploy/worker-banner.js",
  ]),
 ]);
 export default eslintConfig;
@@ -1,11 +1,25 @@
 import type { NextConfig } from "next";
 const SICHERHEITS_KOPFZEILEN = [
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  { key: "Permissions-Policy", value: "camera=(), microphone=(), geolocation=()" },
  // HSTS wirkt nur über HTTPS; hinter einem Reverse Proxy ist das der Normalfall.
  { key: "Strict-Transport-Security", value: "max-age=31536000; includeSubDomains" },
 ];
 const nextConfig: NextConfig = {
  // Für das Container-Abbild: nur die tatsächlich benötigten Dateien mitnehmen.
  output: "standalone",
  // Die Agent-Skripte werden zur Laufzeit ausgeliefert und müssen daher mitgepackt werden.
  outputFileTracingIncludes: {
    "/install.sh": ["./agent/install.sh"],
    "/agent.sh": ["./agent/proxledger-agent.sh"],
  },
  async headers() {
    return [{ source: "/:pfad*", headers: SICHERHEITS_KOPFZEILEN }];
  },
 };
 export default nextConfig;
@@ -1,6 +1,6 @@
 {
  "name": "proxledger",
-  "version": "0.5.0",
+  "version": "0.24.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
@@ -18,30 +18,49 @@
    "db:studio": "prisma studio",
    "db:generate": "prisma generate",
    "postinstall": "prisma generate",
-    "issues:sync": "tsx scripts/gitea-issues.ts"
+    "issues:sync": "tsx scripts/gitea-issues.ts",
    "worker": "tsx src/worker/index.ts",
    "alerts:check": "tsx scripts/alerts-pruefen.ts",
    "build:worker": "esbuild src/worker/index.ts --bundle --platform=node --target=node24 --format=esm --outfile=dist/worker.mjs --banner:js=\"$(cat deploy/worker-banner.js)\" --external:@prisma/client --external:@node-rs/argon2 --external:pg-native",
    "build:all": "npm run build && npm run build:worker",
    "lasttest": "tsx scripts/lasttest.ts",
    "screenshots": "node scripts/screenshots.mjs",
    "icons": "node scripts/icons.mjs",
    "pruefe:doku": "node scripts/pruefe-doku.mjs",
    "benutzer": "tsx scripts/benutzer.ts"
  },
  "dependencies": {
    "@node-rs/argon2": "^2.2.1",
    "@prisma/adapter-pg": "^7.10.0",
    "@prisma/client": "^7.10.0",
    "@react-pdf/renderer": "^4.9.0",
    "@simplewebauthn/browser": "^14.0.0",
    "@simplewebauthn/server": "^14.0.3",
    "admin-lte": "^4.9.1",
    "bootstrap": "^5.3.8",
    "bootstrap-icons": "^1.13.1",
-    "next": "16.3.5",
+    "croner": "^10.0.1",
    "jose": "^6.2.12",
    "next": "^16.3.8",
    "nodemailer": "^10.0.10",
    "openid-client": "^6.8.8",
    "react": "19.2.8",
    "react-dom": "19.2.8",
    "zod": "^4.6.5"
  },
  "devDependencies": {
    "@types/node": "^24.13.5",
    "@types/nodemailer": "^8.0.2",
    "@types/react": "^19",
    "@types/react-dom": "^19",
    "dotenv": "^17.4.2",
    "esbuild": "^0.28.2",
    "eslint": "^9",
-    "eslint-config-next": "16.3.5",
+    "eslint-config-next": "^16.3.8",
    "eslint-config-prettier": "^10.1.8",
    "prettier": "^3.9.7",
    "prisma": "^7.10.0",
    "sharp": "^0.35.4",
    "tsx": "^4.23.13",
    "typescript": "^5",
    "vitest": "^5.0.1"
@@ -49,5 +68,9 @@
  "description": "Proxmox Subscription Dashboard",
  "engines": {
    "node": ">=24"
  },
  "overrides": {
    "mysql2": "^3.24.4",
    "deepmerge-ts": "^8.0.0"
  }
 }
--- a/Show More
+++ b/Show More