FDN-01: repository & projektgerüst

Git-Repository für bestehenden archivdms-Code initialisiert, Branch-/Commit-Konvention (feature/<ticket>-<slug>-Branches, Ticket-Prefix in Commit-Nachricht) etabliert.

.claude/agent-memory/retention-compliance/project_gobd_verfahrensdokumentation.md

@@ -0,0 +1,52 @@
+---
+name: project_gobd_verfahrensdokumentation
+description: GoBD-Verfahrensdokumentation-Export-Feature — Gliederung, was automatisch/manuell ableitbar, Konzeptstand
+metadata:
+  type: project
+---
+
+Feature-Idee (aus Paperless-Kursvergleich, siehe [[project_paperless_pilot_kurs_vergleich]]): automatisch generierte
+GoBD-Verfahrensdokumentation aus archivdms-Systemdaten, potenzielles Alleinstellungsmerkmal ggü. Paperless-ngx/ecoDMS.
+Stand 2026-07-30: Konzept fertig geklärt, KEIN Code geschrieben.
+
+**Gliederung (GoBD-Standard, BMF-Schreiben Rz.151-155 + Fachpraxis):**
+1. Allgemeine Beschreibung (Organisation, Verantwortliche) — MANUELL, nicht im System
+2. Anwenderdokumentation (Erfassungsprozesse) — teilweise automatisch (workflows/classification_templates)
+3. Technische Systemdokumentation (Hard-/Software) — MANUELL/Platzhalter
+4. Betriebsdokumentation (Backup, Notfall, Zugriffsschutz) — Zugriffsschutz automatisch (permission_groups+Grants),
+   Backup/Notfall MANUELL
+5. Verfahrensabläufe: Erfassung/Indizierung/Verarbeitung/Speicherung/Absicherung/Fristen/Vernichtung/Wiederauffinden
+   — größtenteils automatisch ableitbar
+6. Änderungshistorie der Doku selbst — MANUELL (oder: Zeitstempel "Stand: <Datum>" bei jeder Live-Generierung)
+
+**Automatisch ableitbar aus echtem Code-Stand (geprüft, nicht geraten):**
+- Fristen-Kapitel: `retention_rules` Tabelle (Migration 022) — trigger_type, retention_years/days, legal_basis,
+  dsgvo_conflict, Präzedenz doc-typ-spezifisch > tenant-Default
+- Zugriffsschutz-Kapitel: `permission_groups` + `document_type_grants`/`tag_grants`/`document_grants`
+  (Migration 008), Rollenmodell superadmin/domain_admin/user
+- Löschkonzept-Kapitel: `document_delete_requests` (Migration 007) — Vier-/Zwei-Augen-Workflow, Status
+  pending/confirmed/executed/blocked_retention, `documents.deleted_at/deleted_by`
+- Unveränderbarkeit: chmod 0440 + SHA-256 Content-Hash — technische Fließtext-Aussage, kein DB-Query nötig
+- Erfassungsprozess (teilweise): `workflows`/`workflow_actions`/`workflow_runs` (Migration 012),
+  `classification_templates` (Migration 011)
+- Nachvollziehbarkeit: `audit_log` append-only via BEFORE UPDATE/DELETE Trigger (Migration 001)
+
+**Zwingend manuell (nicht im System):** Organisationsbeschreibung, Verantwortliche/Vertretungsregeln,
+Server-/Backup-/Notfallkonzept außerhalb des DMS, Änderungshistorie der Doku selbst.
+
+**Format-Entscheidung:** Markdown als Primärformat (kein PDF-Sidecar im ersten Schritt), pro Mandant individuell
+(alle relevanten Tabellen sind tenant-skopiert), live aus aktuellem DB-Stand generiert (kein Caching), mit
+Zeitstempel-Hinweis "Stand: <Datum>, kein rechtsverbindliches Fertigdokument".
+
+**Endpoint-Vorschlag:** `GET /api/compliance/procedure-documentation`, Auth-Pattern wie
+`internal/api/retention_rule_handlers.go` (domain_admin+ für eigenen Tenant, superadmin optional mit
+`?tenant_id=` für Cross-Tenant, aber kein automatisches Vermischen mehrerer Mandanten in einem Dokument).
+
+**Warum kein Code in diesem Durchgang:** Der generierte Text kann vom Kunden gegenüber dem Finanzamt/Betriebsprüfer
+verwendet werden — Formulierungsrisiko, nicht Technikrisiko. Empfehlung: Konzept an backend-dev übergeben mit
+dieser Tabelle als Vorgabe, Platzhalter-Abschnitte klar als "TODO: durch Mandant auszufüllen" markieren,
+Rechtsgrundlagen-Texte vor Go-Live durch retention-compliance-Rolle gegenlesen lassen.
+
+**How to apply:** Bei Fortsetzung dieses Features zuerst hier nachlesen statt Gliederung neu zu recherchieren.
+Code-Stand der referenzierten Tabellen vor Umsetzung erneut gegen aktuelle Migrations-Dateien prüfen (Stand könnte
+sich geändert haben).