docs: rewrite CLAUDE.md for full product spec and Postgres stack

Replaces the generic React/Vite/SQLite scaffold description with the
actual Deklarix product spec: what it does, the two-stage extract/rules
principle, the Postgres-based stack and cmd/deklarix structure, data
model, evidence chain, legal guardrails (UWG, Versicherungsaufsicht,
BRAO), QA via the golden-test suite, and the DATABASE_URL/test-system
split for scripts/test.sh.

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

CLAUDE.md

@@ -1,16 +1,86 @@
 # Deklarix
 
-> Projekt für deklarix.de und deklarix.com
+> Prüfung und Nachweis für Werbe-Content. Pre-Publish-Kennzeichnungsprüfung
+> und revisionssichere Archivierung für Creator, Agenturen, Marken und
+> Kanzleien. `deklarix.de` / `deklarix.com`
+
+---
+
+## Was das Projekt ist
+
+Drei Funktionen, mehr nicht:
+
+1. **Pre-Publish-Prüfung** — Caption, Standbild und Vertragslage rein,
+   Risikobewertung mit konkreten Korrekturvorschlägen raus.
+2. **Beweissicherung** — jeder veröffentlichte Beitrag wird mit Hash und
+   Zeitstempel archiviert: Screenshot, Caption, sichtbare Kennzeichnung,
+   verknüpfter Vertrag, Briefing.
+3. **Verantwortungsmatrix** — wer hat was vorgegeben, wer hat freigegeben,
+   wer schuldet welche Prüfung (Creator / Agentur / Marke).
+
+**Wer nutzt es, wer zahlt:** Creator nutzen es täglich, zahlen wenig
+(Reichweite/Referenz). Agenturen und Marken zahlen richtig — sie haften
+über § 8 Abs. 2 UWG mit und brauchen Freigabe-Workflow plus
+Nachweisarchiv. Kanzleien lizenzieren Deklarix als Whitelabel für ihre
+Mandanten (zahlen für Software, nicht für Mandantenzugang); das
+Kanzlei-Verzeichnis im Produkt bleibt kostenlos.
+
+**Rollen von Anfang an.** Eine Submission gehört nicht einem Nutzer,
+sondern hat Beteiligte mit Rollen (`creator`, `agentur`, `marke`,
+`kanzlei`). Alle vier existieren im Datenmodell ab dem ersten Commit.
+
+**Kein Demo-Shortcut.** Es wird direkt produktionsreif entwickelt —
+keine reduzierte Zwischenstufe mit manuell eingetragenen Daten oder ohne
+Login als Selbstzweck.
+
+---
+
+## Kernprinzip: das Modell entscheidet nicht
+
+**Das LLM extrahiert Fakten. Das Regelwerk in Go fällt das Urteil.**
+
+- **Stufe 1 — Extraktion (Claude API):** Eingabe Caption plus Bild/Video,
+  Ausgabe striktes JSON (Plattform, Gegenleistung, Kennzeichnung
+  vorhanden/Kanal/Wortlaut/Position, Produktkategorie, Verlinkungen, ...).
+  Ist die Extraktion unsicher, liefert sie `unklar` — nie eine geratene
+  Bewertung.
+- **Stufe 2 — Bewertung (Go, deterministisch):** Regelwerk als
+  versionierte YAML-Dateien (`rules/`). Jedes Finding referenziert
+  Regel-ID und Version (z. B. `WK-004 v3`). Regeln sind
+  plattformunabhängig — UWG/MStV gelten überall gleich, nur
+  Darstellungsdetails unterscheiden sich; die gehören in
+  Regelbedingungen/Extraktion, nie in separate Regelsätze pro Plattform.
+
+**Absolute Regel:** Das Modell nennt niemals selbst Normen, Urteile oder
+Randnummern. Fundstellen stehen ausschließlich in den kuratierten
+YAML-Regeln. Eine halluzinierte Fundstelle ist in diesem Markt ein
+Totalschaden.
 
 ---
 
 ## Stack
 
-| Backend | Frontend (geplant) |
+Bewusst langweilig, ein Binary, lokal lauffähig:
-|---------|---------------------|
+
-| Go 1.26 | React 19, TypeScript 5.9 |
+| Bereich | Wahl |
-| net/http (Standard-Library-first) | Vite 8, Tailwind CSS |
+|---|---|
-| SQLite (geplant) | enterprise.css Design-System (enconf-Pattern) |
+| Sprache | Go 1.26, Standard-Library wo möglich |
+| Web | `net/http` + `html/template` + htmx, kein Frontend-Build, kein React |
+| Datenbank | PostgreSQL über `pgx`, Migrationen über `golang-migrate` |
+| PDF | serverseitig erzeugt |
+| Zeitstempel | RFC-3161 von einer öffentlichen TSA |
+| Extraktion | Claude API (nur Fakten-Extraktion, siehe oben) |
+| Design | `design/enterprise.css` (Enterprise Light Theme, enconf-Pattern, Primärfarbe `#1677ff`) |
+
+Kein Docker für die App selbst, kein React, keine Queue. Neue
+Abhängigkeiten nur nach Rückfrage.
+
+**Warum Postgres statt SQLite:** Das Produkt läuft von Anfang an für
+hunderte gleichzeitige Nutzer über mehrere Mandanten (Creator, Agentur,
+Marke, Kanzlei). Ein revisionssicheres Beweisarchiv braucht robuste
+Concurrent-Writes sowie Point-in-Time-Recovery/Replikation — das ist mit
+SQLites Single-Writer-Modell nicht sauber zu bauen. Gehostet wird
+Managed Postgres in der EU (DSGVO).
 
 **Pfad:** `/var/www/deklarix` | **Git:** `https://git.netcell-it.de/projekte/deklarix` | **Branch:** `main`
 
@@ -21,21 +91,27 @@
 ```
 /var/www/deklarix/
 ├── cmd/
-│   └── server/
+│   └── deklarix/
-│       └── main.go            # Entry Point
+│       └── main.go            # Entry Point, HTTP-Server
 ├── internal/
-│   ├── config/                # Konfiguration (env-basiert)
+│   ├── extract/                # Claude-API-Aufruf, JSON-Schema, Validierung
-│   ├── handler/               # HTTP Handler
+│   ├── rules/                  # YAML-Loader, Auswertung, Versionierung
-│   └── middleware/            # Auth, Logging, CORS
+│   ├── evidence/                # Hashing, Zeitstempel, Append-only-Log
+│   ├── dossier/                 # PDF-Erzeugung
+│   ├── store/                   # Postgres, Migrationen
+│   └── web/                     # Handler, Templates
+├── rules/                      # YAML-Regeln, versioniert im Git
+├── testdata/
+│   └── golden/                 # Golden-Tests: Beispielbeiträge + erwartetes Ergebnis
 ├── design/
-│   └── enterprise.css         # Gemeinsames Design-System (enconf-Basis)
+│   └── enterprise.css          # Design-System (enconf-Basis)
 ├── packaging/
 │   └── DEBIAN/
-│       └── control.tmpl       # .deb Package-Control-Template
+│       └── control.tmpl        # .deb Package-Control-Template
 ├── scripts/
-│   ├── build.sh               # Cross-Compile amd64 + arm64
+│   ├── build.sh                # Cross-Compile amd64 + arm64
-│   ├── test.sh                # Tests + vet + build-check
+│   ├── test.sh                 # Tests + vet + build-check
-│   └── release.sh             # Vollständiger Release-Prozess
+│   └── release.sh              # Vollständiger Release-Prozess
 ├── go.mod
 ├── go.sum
 └── CLAUDE.md
@@ -43,13 +119,39 @@
 
 ---
 
+## Datenmodell
+
+Fünf Tabellen, mehr braucht der MVP nicht:
+
+- `submission` — ein eingereichter Beitrag, Status, Zeitpunkte
+- `asset` — Bild oder Datei, Pfad, SHA-256
+- `extraction` — das JSON aus Stufe 1, Modellversion, Prompt-Version
+- `finding` — Ergebnis pro Regel: Regel-ID, Regel-Version, Schwere, Text
+- `evidence_package` — Dossier, Hash, Zeitstempel-Token, erzeugt am
+- `participant` — Beteiligter an einer Submission mit Rolle
+  (`creator`, `agentur`, `marke`, `kanzlei`) und Beitrag zur
+  Verantwortungsmatrix (wer hat vorgegeben, wer freigegeben)
+
+**Append-only.** Kein UPDATE auf `finding`, `extraction` oder
+`evidence_package`. Korrekturen sind neue Zeilen mit Verweis auf die alte.
+Ein Beweisarchiv, in dem man Zeilen ändern kann, ist kein Beweisarchiv.
+
+**Beweiskette:** SHA-256 über jedes Asset und über die kanonisierte
+JSON-Repräsentation der Metadaten, RFC-3161-Zeitstempel über diesen Hash.
+Dossier-PDF enthält Beitrag, Caption, Kennzeichnung, Findings mit
+Fundstellen, Vertrags- und Briefing-Bezug, Verantwortungsmatrix, alle
+Hashes und das Zeitstempel-Token. Vollständiger Export muss für den
+Nutzer jederzeit möglich sein — wer kündigt, bekommt sein Archiv.
+
+---
+
 ## Go Commands
 
 ```bash
 export PATH=$PATH:/usr/local/go/bin   # Immer setzen!
 
 # Entwickeln
-go run ./cmd/server/
+go run ./cmd/deklarix/
 
 # Tests
 ./scripts/test.sh
@@ -95,11 +197,11 @@ git add -p && git commit -m "feat: ..."
 
 ---
 
-## Testing-Pattern
+## Testing-Pattern & Qualitätssicherung
 
 ```go
-// Datei: internal/handler/health_test.go
+// Datei: internal/web/health_test.go
-package handler_test
+package web_test
 
 import (
     "net/http"
@@ -117,30 +219,57 @@ func TestHealth(t *testing.T) {
 }
 ```
 
-- Tests liegen neben dem Code: `handler/foo_test.go`
+- Tests liegen neben dem Code: `paket/foo_test.go`
 - Package: `package foo_test` (Black-Box-Test) oder `package foo` (White-Box)
 - Race-Detector immer an: `go test -race ./...`
 - Tabellenbasierte Tests für mehrere Inputs
 
+**DATABASE_URL und Testsystem.** `internal/store` hat Integrationstests
+gegen echtes Postgres (u. a. die Append-only-Garantie). Ohne
+`DATABASE_URL` überspringt `go test` diese Tests einfach — praktisch für
+schnelle lokale Iteration ohne lokales Postgres. `./scripts/test.sh`
+(und damit `release.sh`) ist strenger: es bricht ohne `DATABASE_URL` mit
+Fehler ab, statt die Append-only-Garantie still zu überspringen. Es
+zieht dafür aber **kein** eigenes Postgres hoch (kein Docker-Zwang auf
+dem lokalen Dev-Rechner) — das ist Aufgabe des dedizierten Testsystems,
+dort muss `DATABASE_URL` vorkonfiguriert sein.
+
+**Golden-Test-Suite ist das eigentliche Asset des Projekts, nicht die
+UI.** 30 bis 50 Beispielbeiträge in `testdata/golden/`, abgeleitet aus
+veröffentlichten Urteilen und Beanstandungen der Medienanstalten, jeweils
+mit erwarteten Findings. Jede Regeländerung läuft gegen die komplette
+Suite. Eine Regeländerung, die ein Golden-Ergebnis kippt, wird nicht
+gemerged, ohne dass der erwartete Wert bewusst und dokumentiert angepasst
+wird. Extraktion wird separat getestet: fixierte Eingaben, geprüfte
+JSON-Ausgabe.
+
 ---
 
-## Design-System
+## Leitplanken, die dauerhaft gelten
 
-Das Frontend folgt dem **Enterprise Light Theme** aus enconf (`design/enterprise.css`).
+- **Keine Rechtsdienstleistung.** Deklarix ist ein Werkzeug, keine
-
+  Rechtsberatung. Keine Formulierung darf eine individuelle rechtliche
-- **Primärfarbe:** `#1677ff` (Blau)
+  Bewertung suggerieren. Auf jedem Screen mit einem Ergebnis steht ein
-- **Sidebar:** Dunkel (`#0B1426` → `#101D33`) mit weißen Icons
+  entsprechender Hinweis. Keine Erfolgsaussichten-Aussagen.
-- **Body:** `#F8FAFC` Hintergrund, `#334155` Text
+- **Keine Versicherungssprache.** Nie „Abmahnschutz“, „abgesichert“,
-- **Font:** Inter (von `/fonts/inter.css` oder Google Fonts)
+  „geschützt“, „Kostenübernahme“ — sonst erlaubnispflichtiges
-- **Radius:** 6px / 8px / 10px
+  Versicherungsgeschäft. Immer „Prüfung“, „Hinweis“, „Dokumentation“,
-
+  „Nachweis“.
-Für neue Frontend-Projekte unter `/var/www/deklarix`:
+- **Keine erfundenen Fundstellen.** Jede Norm und jedes Urteil steht in
-```bash
+  einer Regel-YAML und wurde dort von Hand geprüft.
-# Frontend-Scaffold (wenn benötigt)
+- **Nur eigene Inhalte.** Kein Scraping fremder Accounts, keine fremden
-npm create vite@latest frontend -- --template react-ts
+  Posts als Demo-Material. Demo-Material ist synthetisch. Nutzerinhalte
-cd frontend && npm install
+  kommen über eigenen OAuth-Zugang oder Datenexport.
-# enterprise.css aus design/ einbinden
+- **DSGVO und Hosting in der EU.** Löschkonzept von Anfang an mitdenken,
-```
+  aber Beweisarchiv und Löschpflicht sauber gegeneinander abgrenzen
+  (offener Punkt, siehe unten).
+- **Berufsrecht der Anwälte (§ 49b Abs. 3 S. 1 BRAO).** Kein Routing
+  (kein Button, der einen Fall an eine Kanzlei übergibt — Nutzer wählt
+  selbst aus dem Verzeichnis), kein ergebnisabhängiger Preis, keine
+  Sachvorteile an gelistete Kanzleien, Verzeichnis bleibt kostenlos
+  (BGH IX ZR 89/23: entgeltliche Mandatsvermittlung ist nichtig). Vor dem
+  ersten Kanzlei-Vertrag: formlose Auskunft der zuständigen
+  Rechtsanwaltskammer einholen.
 
 ---
 
@@ -170,7 +299,7 @@ git push origin main
 ### Server-Prozess
 ```bash
 # Start (manuell)
-PORT=8080 ./dist/deklarix_latest_amd64 &
+PORT=8080 DATABASE_URL=postgres://... ANTHROPIC_API_KEY=... ./dist/deklarix_latest_amd64 &
 
 # Logs prüfen
 journalctl -u deklarix -f
@@ -178,6 +307,20 @@ journalctl -u deklarix -f
 
 ---
 
+## Arbeitsweise für Claude Code
+
+- Kleine Commits, ein Thema pro Commit
+- Erst Test oder Golden-Fall, dann Implementierung
+- Keine neue Abhängigkeit ohne Rückfrage
+- Keine Umbenennung von Regel-IDs; Regeln werden versioniert, nicht
+  ersetzt
+- Fehler nicht verschlucken, keine stillen Fallbacks bei der Extraktion
+- Bei Unsicherheit über eine Rechtsfrage: nicht raten, sondern als offene
+  Frage in `rules/OPEN.md` notieren
+- Der Code-RAG dient der Orientierung im Bestand, nicht als Nachweis von
+  Korrektheit. Verifiziert wird durch Compiler, Tests und die
+  Golden-Suite.
+
 ## Vor Änderungen
 
 1. `go vet ./...` — keine Fehler
@@ -190,3 +333,12 @@ journalctl -u deklarix -f
 2. `./scripts/build.sh <version>` → erfolgreich
 3. Commit mit semantischer Message: `feat:`, `fix:`, `refactor:`, `docs:`
 4. Bei Release: `./scripts/release.sh <version>`
+
+---
+
+## Offene Punkte
+
+- Umfang des Regelsatzes für den ersten Pilotkunden festlegen
+- Welche TSA für die Zeitstempel
+- Löschkonzept versus Beweisarchiv sauber ausformulieren
+- Markenanmeldung Deklarix, sobald erster Kunde zahlt