# Deklarix > 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: Fakten trennen von Urteil **Stufe 1 bestimmt Fakten (deterministisch, kein LLM). Das Regelwerk in Go fällt das Urteil.** - **Stufe 1 — Extraktion (`internal/extract`, regelbasiert):** Ob eine Gegenleistung vorlag, kann aus dem Text nicht zuverlässig erraten werden — ein verschwiegener bezahlter Post sieht textlich identisch aus wie ein echter organischer Post. Deshalb gibt der/die Einreichende die Gegenleistung selbst an (Formularfeld). Was sich objektiv aus der Caption bestimmen lässt, wird per Zeichenketten-Logik erkannt: ob ein Kennzeichnungswort vorkommt, welcher Wortlaut, und ob es vor der plattformspezifischen "mehr anzeigen"-Kürzung steht. Kein externer Dienst, keine API-Kosten, kein Sprachmodell — daher auch keine Interpretation kreativer/impliziter Formulierungen; was nicht über ein bekanntes Kennzeichnungswort läuft, wird nicht erkannt. - **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:** Fundstellen stehen ausschließlich in den kuratierten YAML-Regeln, nie in Freitext oder Extraktionslogik erfunden. Eine halluzinierte Fundstelle ist in diesem Markt ein Totalschaden. **Historie:** Ursprünglich war Stufe 1 als Claude-API-Aufruf geplant (Kennzeichnung *und* Gegenleistung vom Modell erraten). Das wurde bewusst verworfen — der Nutzer will keine laufende Anthropic-Abhängigkeit für Deklarix selbst (getrennt von Claude Code, mit dem an Deklarix programmiert wird). Die Idee "LLM sieht Kontext-Hinweise wie Rabattcodes/Affiliate-Links, die reines Keyword-Matching übersieht" bleibt ein späterer Ausbaupunkt, kein aktueller Blocker. --- ## Stack Bewusst langweilig, ein Binary, lokal lauffähig: | Bereich | Wahl | |---|---| | 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 | regelbasiert, `internal/extract`, keine externe Abhängigkeit | | 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` --- ## Projektstruktur ``` /var/www/deklarix/ ├── cmd/ │ └── deklarix/ │ └── main.go # Entry Point, HTTP-Server ├── internal/ │ ├── extract/ # regelbasierte Fakten-Erkennung (Keywords, Kürzungs-Position) │ ├── rules/ # YAML-Loader, Auswertung, Versionierung │ ├── evidence/ # Hashing, Zeitstempel, Append-only-Log │ ├── dossier/ # PDF-Erzeugung │ ├── socialconnect/ # OAuth-Flow Instagram/TikTok (Plattform-Verbindung) │ ├── store/ # Postgres, Migrationen │ └── web/ # Handler, Templates ├── rules/ # YAML-Regeln, versioniert im Git ├── testdata/ │ └── golden/ # Golden-Tests: Beispielbeiträge + erwartetes Ergebnis ├── design/ │ └── enterprise.css # Design-System (enconf-Basis) ├── packaging/ │ └── DEBIAN/ │ └── control.tmpl # .deb Package-Control-Template ├── scripts/ │ ├── build.sh # Cross-Compile amd64 + arm64 │ ├── test.sh # Tests + vet + build-check │ └── release.sh # Vollständiger Release-Prozess ├── go.mod ├── go.sum └── CLAUDE.md ``` --- ## Datenmodell Plus drei Tabellen für Auth/Mandantentrennung (`account`, `app_user`, `session`), mehr braucht der MVP nicht: - `account` — ein Mandant (Creator, Agentur, Marke oder Kanzlei als eigene Organisation); jede Submission gehört genau einem Account. `verified` markiert einen Kanzlei-Account als für das öffentliche, kostenlose Kanzlei-Verzeichnis (`GET /kanzleien`) freigegeben — nur vom Admin-Bereich aus setzbar, nie vom Mandanten selbst - `app_user` — ein Login innerhalb eines Accounts (E-Mail, Passwort- Hash, Rolle). Rolle ist eine von `creator`, `agentur`, `marke`, `kanzlei` **oder `admin`**. `admin` ist Betreiber-Personal (Netcell-IT), nicht an einen Mandanten-Geschäftszweck gebunden, zuständig für den Admin-Bereich (`/admin/...`: Accounts-Übersicht, Kanzlei-Verzeichnis-Freigabe, Audit-Log). Es gibt **keine** Selbstregistrierung für `admin` über `POST /register` (das Formular bietet die Rolle nicht an) — der erste Admin wird einmalig per SQL angelegt: ```sql INSERT INTO account (name) VALUES ('Deklarix Admin') RETURNING id; INSERT INTO app_user (account_id, email, password_hash, role) VALUES ('', '', '', 'admin'); ``` (bcrypt-Hash z. B. über `internal/auth.HashPassword` in einem Wegwerf-`cmd/`-Programm erzeugen, da `internal/` von außerhalb des Moduls nicht importierbar ist) - `session` — eine angemeldete Sitzung (Token, Ablaufzeit); bewusst eine echte Tabelle statt zustandsloser signierter Tokens, damit Logout eine Sitzung wirklich beendet - `audit_log` — Protokoll der Admin-Aktionen (wer hat wann welchen Account wie verändert); append-only aus demselben Grund wie `finding`/`extraction`/`evidence_package` - `submission` — ein eingereichter Beitrag, Status, Zeitpunkte - `asset` — hochgeladenes Standbild, Pfad, SHA-256; append-only aus demselben Grund wie `finding`/`extraction`/`evidence_package` — ein Beweisstück wird nicht nachträglich ausgetauscht. `purpose` = `initial` (das Beweisfoto beim Prüfen, optional) oder `insights` (siehe „Insights-Erinnerung" unten; ein Beitrag kann mehrere `insights`-Assets über die Zeit bekommen). `GetLatestAssetForSubmission` berücksichtigt nur `initial`, damit ein späterer Insights-Upload nie den beim Archivieren referenzierten Original-Screenshot verdrängt - `extraction` — das JSON aus Stufe 1, Modellversion, Prompt-Version - `finding` — Ergebnis pro Regel: Regel-ID, Regel-Version, Schwere, Titel, Korrektur, Fundstellen (zum Zeitpunkt des Findings fixiert, kein Verweis auf die aktuelle Regel-YAML — die kann sich inzwischen geändert haben) - `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) - `platform_connection` — die per OAuth hergestellte Verbindung eines Accounts zu seinem eigenen Instagram- oder TikTok-Account (siehe Abschnitt „Plattform-Verbindung (OAuth)" unten). NICHT append-only — Tokens laufen ab und werden erneuert, eine Verbindung kann getrennt und neu hergestellt werden; höchstens eine Verbindung pro Account+Plattform (`UNIQUE(account_id, platform)`) **Append-only.** Kein UPDATE auf `finding`, `extraction`, `asset`, `evidence_package` oder `audit_log`. Korrekturen sind neue Zeilen mit Verweis auf die alte. Ein Beweisarchiv (bzw. Protokoll), in dem man Zeilen ändern kann, ist keines mehr. **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. **Auth/Mandantentrennung:** `POST /register` legt einen neuen Account plus den ersten Nutzer darin an, `POST /login` meldet einen bestehenden Nutzer an — beides setzt ein `deklarix_session`-Cookie (HttpOnly, SameSite=Strict, Secure sobald über TLS erreicht). `GET /` verlangt eine gültige Sitzung (sonst Redirect zu `/login`); `POST /pruefen`, `POST /veroeffentlichen` und `GET /dossier/{id}` verlangen sie ebenfalls (sonst 401). Ein Beitrag eines fremden Accounts wird wie ein nicht existierender behandelt (404), nie mit einer expliziten 403 bestätigt — sonst würde die Antwort selbst verraten, dass die ID existiert. **Plattform-Verbindung (OAuth):** Jeder Kunde kann optional seinen eigenen Instagram- oder TikTok-Account verbinden (`GET /verbindungen`), damit die Beweissicherung einen veröffentlichten Beitrag künftig direkt per API abrufen kann, statt ihn manuell hochzuladen — reiner Authorization-Code-Flow, jeder Kunde autorisiert nur seinen eigenen Account (`internal/socialconnect`, Persistenz in `platform_connection`). Der manuelle Standbild-Upload bleibt der primäre Weg und funktioniert unabhängig davon weiter; OAuth reduziert nur Reibung, ist kein Ersatz für die Pre-Publish-Prüfung (die läuft zwingend vor Veröffentlichung, wenn auf der Plattform noch nichts existiert — dafür kann OAuth nichts abrufen). Technisch ist der Flow fertig (Connector-Interface, CSRF-Schutz per State-Cookie, Token-Speicherung), aber **ohne aktive Meta-/TikTok- Freigabe nutzlos**: Instagram (`instagram_business_basic`) und TikTok (Login Kit + Content Posting API) verlangen jeweils eine einmalige, plattformseitige Prüfung des Deklarix-Betreiberkontos (Meta Business Verification + App Review: ca. 2–4 Wochen; TikTok-Audit: ca. 1–2 Wochen), bevor sich beliebige Kunden selbst verbinden können. Bis dahin lässt sich mit bis zu 25 (Meta) bzw. 10 (TikTok) manuell eingetragenen Testern trotzdem schon mit einem echten Piloten testen. Ohne gesetzte Konfiguration (`INSTAGRAM_CLIENT_ID`/`_SECRET`, `TIKTOK_CLIENT_KEY`/`_SECRET`, `PUBLIC_BASE_URL`) zeigt `GET /verbindungen` beide Plattformen als „noch nicht konfiguriert" ohne Verbinden-Button — kein Absturz, kein stiller Fallback. **Vorsicht bei künftigen Änderungen:** Instagram-/TikTok-Endpunkte, Scopes und Token-Formate in `internal/socialconnect` wurden ohne echte Zugangsdaten gegen die Entwicklerdokumentation gebaut, nie gegen die echte API verifiziert — vor dem ersten echten Verbindungsversuch mit realen Credentials die Konstanten in `internal/socialconnect/*.go` noch einmal gegen die dann aktuelle Meta-/TikTok-Dokumentation prüfen. **Insights-Erinnerung:** Story-Insights hält Instagram nach eigener Aussage nur 24 Stunden vor — danach sind sie auch über den offiziellen Datenexport nicht mehr zu bekommen, und der ursprüngliche Standbild- Screenshot beim Prüfen (der direkt beim Veröffentlichen entsteht, bevor nennenswerte Kennzahlen existieren) kann sie naturgemäß nicht erfassen. `GET /beitraege/{id}` zeigt deshalb bei veröffentlichten `story`- Beiträgen eine Erinnerung, solange keine `insights`-Asset existiert (`internal/web/insights_reminder.go`, `computeInsightsReminder` — reine Produktentscheidung zum Erinnerungs-Timing, keine Rechtsnorm, daher bewusst nicht in `rules/*.yaml`). `POST /beitraege/{id}/insights` speichert einen zusätzlichen Screenshot als `asset` mit `purpose='insights'`, gehasht wie jedes andere Beweisstück — aber NICHT im Metadaten-Hash des ursprünglichen Dossiers enthalten (das wird beim Archivieren einmalig fixiert). Bewusst nur ein In-App- Banner in dieser ersten Ausbaustufe, kein Mail-/Push-Versand — dafür fehlt aktuell ein SMTP-Relay/Versanddienst; vor einer echten Benachrichtigung per E-Mail ist das eine offene Rückfrage (welcher Versanddienst, welche Absenderdomain/SPF/DKIM). --- ## Go Commands ```bash export PATH=$PATH:/usr/local/go/bin # Immer setzen! # Entwickeln go run ./cmd/deklarix/ # Tests ./scripts/test.sh # oder direkt: go test -race ./... go vet ./... # Build (amd64 + arm64) ./scripts/build.sh 1.0.0 # Build (nur amd64) ./scripts/build.sh 1.0.0 amd64 ``` --- ## Build & Release-Prozess ### Versioning (Semantic Versioning: MAJOR.MINOR.PATCH) - **MAJOR** — Breaking changes, API-Inkompatibilitäten - **MINOR** — Neue Features, rückwärtskompatibel - **PATCH** — Bugfixes ### Release-Schritte ```bash # 1. Alle Änderungen committen git add -p && git commit -m "feat: ..." # 2. Release-Skript (macht Tests → .deb-Build → Gitea-Upload → Tag → Push) ./scripts/release.sh 1.2.0 # Danach liegt in dist/: # deklarix_1.2.0_amd64.deb # deklarix_1.2.0_arm64.deb ``` ### Was das Release-Skript tut 1. Prüft: sauberer Git-Status (keine uncommitted changes) 2. Führt `./scripts/test.sh` aus (vet + race tests + build-check, braucht `DATABASE_URL`) 3. Baut `.deb`-Pakete für `linux/amd64` und `linux/arm64` (`scripts/build.sh`) 4. Lädt die Pakete in Giteas Debian-Paketregistrierung hoch (Kanal `testing`, Suites `bookworm` + `trixie`) — siehe „Deployment“ unten 5. Setzt Git-Tag `v` mit Annotierung 6. Pusht `main` + Tag nach `origin` ### Deployment (apt, Infrastruktur-Standard wie bei enconf) Updates laufen ausschließlich über ein apt-Paket, nie über manuelles Kopieren eines Binaries. `.deb`-Pakete landen in Giteas eingebauter Debian-Paketregistrierung unter der Gitea-Org `projekte` (gleicher Mechanismus wie beim Schwesterprojekt enconf-webpanel). Zielserver richten sich einmalig ein: ```bash sudo mkdir -p /etc/apt/keyrings sudo curl -fsSL https://git.netcell-it.de/api/packages/projekte/debian/repository.key \ -o /etc/apt/keyrings/deklarix-gitea.asc echo "deb [signed-by=/etc/apt/keyrings/deklarix-gitea.asc] https://git.netcell-it.de/api/packages/projekte/debian $(lsb_release -cs) testing" \ | sudo tee /etc/apt/sources.list.d/deklarix.list sudo apt-get update && sudo apt-get install deklarix ``` Danach: `apt upgrade` für Updates, `systemctl {start,stop,status} deklarix` für den Dienst. Konfiguration liegt in `/etc/deklarix/deklarix.env` (aus `deklarix.env.example` beim Erstinstall kopiert, `DATABASE_URL` ist dort absichtlich auskommentiert — der Dienst startet erst, wenn sie gesetzt ist; `postinst` startet ihn sonst bewusst nicht, um keine Crash-Restart-Schleife gegen einen Platzhalter-Host zu erzeugen). Aktuell gibt es nur den Kanal `testing` (kein `stable` — es gibt noch keine Kunden, für die eine Trennung nötig wäre). --- ## Testing-Pattern & Qualitätssicherung ```go // Datei: internal/web/health_test.go package web_test import ( "net/http" "net/http/httptest" "testing" ) func TestHealth(t *testing.T) { req := httptest.NewRequest(http.MethodGet, "/health", nil) w := httptest.NewRecorder() HealthHandler(w, req) if w.Code != http.StatusOK { t.Fatalf("expected 200, got %d", w.Code) } } ``` - 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. --- ## Leitplanken, die dauerhaft gelten - **Keine Rechtsdienstleistung.** Deklarix ist ein Werkzeug, keine Rechtsberatung. Keine Formulierung darf eine individuelle rechtliche Bewertung suggerieren. Auf jedem Screen mit einem Ergebnis steht ein entsprechender Hinweis. Keine Erfolgsaussichten-Aussagen. - **Keine Versicherungssprache.** Nie „Abmahnschutz“, „abgesichert“, „geschützt“, „Kostenübernahme“ — sonst erlaubnispflichtiges Versicherungsgeschäft. Immer „Prüfung“, „Hinweis“, „Dokumentation“, „Nachweis“. - **Keine erfundenen Fundstellen.** Jede Norm und jedes Urteil steht in einer Regel-YAML und wurde dort von Hand geprüft. - **Nur eigene Inhalte.** Kein Scraping fremder Accounts, keine fremden Posts als Demo-Material. Demo-Material ist synthetisch. Nutzerinhalte kommen über eigenen OAuth-Zugang oder Datenexport. - **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. --- ## Domains | Domain | Verwendung | |--------|-----------| | deklarix.de | Primär (Marketing-Site) | | app.deklarix.de | Die Anwendung selbst (dieser Go-Server) | | deklarix.com | Redirect auf deklarix.de | | get.deklarix.com | Installer-Endpoint (apt-Einrichtung, siehe Deployment) | Kein separates `app.deklarix.com` — der Root-Redirect von `.com` auf `.de` deckt Fehlnavigation ab, keine zweite Produktions-Subdomain nötig. --- ## Wichtige Hinweise ### Go PATH ```bash # Immer setzen — ist nicht im Standard-PATH des Servers export PATH=$PATH:/usr/local/go/bin ``` ### Git Push ```bash git push origin main # Remote: https://git.netcell-it.de/projekte/deklarix.git ``` ### Server-Prozess ```bash # Dienst läuft über systemd (installiert per apt, siehe Deployment oben) sudo systemctl start deklarix sudo systemctl status deklarix # Config: /etc/deklarix/deklarix.env (DATABASE_URL, PORT, RULES_DIR, # DOSSIER_DIR, ASSET_DIR, TSA_URL, PUBLIC_BASE_URL, # INSTAGRAM_CLIENT_ID/_SECRET, TIKTOK_CLIENT_KEY/_SECRET — letztere vier # optional, ohne sie zeigt /verbindungen nur "nicht konfiguriert") # Logs prüfen journalctl -u deklarix -f ``` ### Bekannte Server | Rolle | Host | Zugang | |---|---|---| | Testsystem + `app.deklarix.de` (DB-Integrationstests, apt-Verifikation, nginx-Reverse-Proxy + Let's-Encrypt-TLS auf den lokalen Dienst) | 89.163.205.4 | SSH `noroot`, sudo passwortlos | | Installer-Endpoint (`get.deklarix.com`) | 89.163.205.110 | noch nicht eingerichtet | | Marketing-Site (`deklarix.de`/`.com`) | 89.163.205.80 | noch nicht eingerichtet | --- ## 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 2. `./scripts/test.sh` — alle Tests grün 3. Bestehenden Code lesen — nicht raten ## Nach Änderungen 1. `./scripts/test.sh` → 0 Fehler 2. `./scripts/build.sh ` → erfolgreich 3. Commit mit semantischer Message: `feat:`, `fix:`, `refactor:`, `docs:` 4. Bei Release: `./scripts/release.sh ` --- ## Offene Punkte - Umfang des Regelsatzes für den ersten Pilotkunden festlegen - **TSA für die Zeitstempel:** interimsweise FreeTSA.org (frei, RFC-3161- konform, siehe `internal/evidence.DefaultTSAURL`) — funktioniert technisch, ist aber **nicht eIDAS-qualifiziert**. Vor echtem Kundeneinsatz auf einen eIDAS-qualifizierten Zeitstempeldienst (z. B. D-Trust, Bundesdruckerei) umstellen, der die gesetzliche Vermutungswirkung nach eIDAS Art. 41 hat — dafür ist ein Vertrag/Account nötig, kein anonymer HTTP-Call. - Löschkonzept versus Beweisarchiv sauber ausformulieren - Markenanmeldung Deklarix, sobald erster Kunde zahlt