Gegenbuch als Docker-Setup, lokales Buch auf eigener Maschine

Betreiber-Entscheidung: Das Gegenbuch laeuft auf einer eigenen Maschine fuer
Prod und Staging; ein externes Git-Repository entfaellt, das Buch liegt lokal.
Die Trennung, auf die es ankommt, ist damit gegeben - wer OpenCRM uebernimmt,
kommt nicht ans Buch.

Richtung bewusst so herum: Das Gegenbuch holt ueber HTTPS mit einem Token, das
nur audit:read kann. OpenCRM kennt weder Adresse noch Schluessel des
Gegenbuchs. Kein SSH-Zugang zum CRM noetig.

tools/audit-notary/ enthaelt jetzt Dockerfile, entrypoint.sh,
docker-compose.yml und .env.example. Zwei Dienste (prod, staging) mit
getrennten Verzeichnissen und Schluesseln, gesteuert ueber COMPOSE_PROFILES -
dasselbe Muster wie beim Caddy-Profil im Hauptstack. Der Signaturschluessel
wird beim ersten Start auf der Gegenbuch-Maschine erzeugt.

Lokaler Betrieb ist jetzt ein vollwertiger Modus statt eines Testschalters. Die
Erfolgsmeldung benennt bei jedem Lauf, was abgedeckt ist und was nicht - statt
der frueheren pauschalen Formulierung "kein Manipulationsschutz", die im
Einsatz auf eigener Maschine schlicht falsch war.

Verifiziert mit echtem Docker-Build gegen eine CRM-Attrappe: Genesis ohne
Bestaetigung -> Code 4; mit Bestaetigung Normalbetrieb exit 0; Eintrag
veraendert -> Alarm exit 2; Eintraege geloescht -> Alarm exit 2; Siegel
verschwunden -> Alarm.

Behoben beim Bauen: useradd -u 1000 || true verschluckte, dass UID 1000 im
Node-Image vergeben ist - der Container startete gar nicht.

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

tools/audit-notary/README.md

@@ -18,7 +18,77 @@ der erste – es sieht nach doppeltem Boden aus und ist keiner. Das CRM braucht
 für dieses Verfahren **gar nichts** zu wissen: Es liefert nur einen lesbaren
 Kontrollwert, der keine Geheimnisse enthält.
 
-## Einrichten
+## Einrichten mit Docker (empfohlen)
+
+Auf dem **Gegenbuch-Rechner** – nicht auf dem CRM-Server:
+
+```bash
+git clone <dieses Repository> opencrm
+cd opencrm/tools/audit-notary
+cp .env.example .env
+# .env ausfüllen: CRM-Adresse und Token eintragen
+docker compose up -d
+```
+
+Beim ersten Start einmalig `PROD_GENESIS_ACK=true` setzen (und danach wieder
+leeren) – die erste Eintragung legt fest, was als Ausgangszustand gilt, und das
+soll nicht versehentlich passieren.
+
+**Zwei Bücher auf einer Maschine** sind vorgesehen: `prod` und `staging` sind
+getrennte Dienste mit getrennten Verzeichnissen und getrennten Schlüsseln.
+Welche laufen, steuert `COMPOSE_PROFILES` in der `.env`.
+
+### Wer redet mit wem
+
+```
+Gegenbuch  ──holt lesend──>  OpenCRM      (HTTPS, Token nur mit audit:read)
+OpenCRM    ─────────────────>  (kennt das Gegenbuch nicht)
+```
+
+Das ist der eigentliche Schutz. Das Gegenbuch **holt** – es lässt sich nichts
+schicken. OpenCRM kennt weder Adresse noch Schlüssel des Gegenbuchs. Wer
+OpenCRM übernimmt, kommt hier nicht heran.
+
+Das Token kann ausschließlich Prüfwerte lesen: keine Kundendaten, keine
+Änderungen. Selbst wenn es abhandenkommt, ist damit nichts anzufangen.
+
+Der Signaturschlüssel wird beim ersten Start **auf dem Gegenbuch-Rechner
+erzeugt** und verlässt ihn nie.
+
+### Was ins Backup gehört
+
+Das Datenverzeichnis (`./data/prod` bzw. `./data/staging`). Darin liegen das
+Buch, der Schlüssel und der Beobachtungsspeicher. Geht es verloren, beginnt die
+Beobachtung von vorn – und der nächste Lauf sagt das ausdrücklich, statt „alles
+gut" zu melden.
+
+### Überwachung
+
+Jeder Durchlauf schreibt seinen Stand nach `data/<instanz>/status.txt`:
+
+```
+2026-08-22T16:49:50+00:00 exit=0 in Ordnung
+```
+
+**Alles außer `exit=0` gehört angesehen.** Wer eine Überwachung hat, greift
+diese Datei ab; wer keine hat, schaut regelmäßig mit `docker compose logs`
+hinein. Ein Alarm, den niemand liest, ist keiner.
+
+### Was dieser Betrieb abdeckt – und was nicht
+
+**Abgedeckt:** Jemand verändert oder löscht nachträglich Einträge im CRM –
+auch mit direktem Datenbankzugriff. Das widerspricht dem Gegenbuch und fällt
+beim nächsten Durchlauf auf.
+
+**Nicht abgedeckt:** Jemand übernimmt den Gegenbuch-Rechner selbst. Dagegen
+hülfe nur eine zusätzliche Ablage außerhalb (z. B. ein privates Git-Repository
+auf einem dritten Server) – das ist vorbereitet, aber für die meisten
+Installationen mehr Aufwand als Nutzen. Die Erfolgsmeldung benennt diese Grenze
+bei jedem Lauf, damit sie nicht in Vergessenheit gerät.
+
+---
+
+## Einrichten ohne Docker
 
 Auf einem **anderen** Rechner als dem CRM-Server: