docs: Spezifikation Bienenpatenschaft mit automatischer Urkunde

Ersetzt den bisherigen Implementierungsauftrag nach den verbindlichen
Vorgaben vom 2026-10-16: drei Pakete, keine Besuche oder laufenden
Inhalte, Urkunde als deterministisch erzeugte PDF mit Vorschau aus
derselben Layoutberechnung, idempotente Erzeugung nach Zahlung,
Revisionen und Druckablauf im Admin.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

docs/superpowers/specs/2026-10-16-bienenpatenschaft-design.md

@@ -0,0 +1,563 @@
+# Bienenpatenschaft mit automatisch erzeugter Urkunde
+
+Datum: 2026-10-16
+Status: Entwurf zur Freigabe, Implementierung ausstehend
+
+Dieses Dokument ersetzt den bisherigen Implementierungsauftrag zur
+Bienenpatenschaft vollständig. Grundlage sind die verbindlichen Vorgaben des
+Inhabers vom 2026-10-16. Wo ältere Fassungen etwas anderes sagen, gilt dieses
+Dokument.
+
+## Problem und Ziel
+
+Wabenhain soll eine symbolische Bienenpatenschaft als Geschenkprodukt
+verkaufen. Das zentrale Produkt ist eine hochwertige, persönlich gestaltete
+Urkunde. Nach der Bestellung läuft alles automatisch: Zahlung, Erzeugung der
+Urkunde, Zustellung des Downloads. Die Handarbeit des Inhabers beschränkt sich
+bei physischen Paketen auf Drucken, Verpacken und Versenden.
+
+Erfolg heißt: Eine Testbestellung erzeugt ohne manuelle Nachbearbeitung eine
+korrekt personalisierte, optisch hochwertige und druckfähige Urkunde, und der
+Käufer bekommt den Download automatisch.
+
+## Nicht im Umfang
+
+Diese Leistungen entfallen vollständig. Sie werden weder auf der
+Verkaufsseite noch in E-Mails, Urkunden, FAQs oder Rechtstexten versprochen:
+
+- Besuche beim Imker oder am Bienenstand
+- Patentage, Veranstaltungen, Terminbuchungen
+- Videos, individuelle Bienenfotos, Saisonberichte, Newsletter zur Patenschaft
+- jede Pflicht zur laufenden Erstellung von Inhalten
+- Veranstaltungs- oder Teilnehmerverwaltung
+- automatische Verlängerung, Abo oder Erinnerungsmails zum Ablauf
+- Zusagen zu Naturschutzprojekten oder unbelegte Umweltversprechen
+- ein Vorlagen-Auswahlschritt für Kunden (es gibt genau eine Gestaltung)
+
+Die Patenschaftsseite zeigt nur die persönlichen Patenschaftsdaten und den
+Download der Urkunde. Sie braucht keine redaktionelle Pflege.
+
+## Produkt
+
+### Pakete
+
+Drei Ausgangspakete, im Adminbereich bearbeitbar (Name, Preis, Beschreibung,
+Leistungsliste, aktiv/inaktiv, Reihenfolge):
+
+| Paket | Testpreis | Leistungen | Versand |
+|---|---:|---|---|
+| Bienenfreund | 19 € | symbolische Namensgebung, individuell gestaltete PDF-Urkunde, sicherer Download | keiner |
+| Honigfreund | 39 € | digitale Leistungen, gedruckte Urkunde, 1 × 500 g Honig, Grußkarte, Geschenkverpackung | ja |
+| Wabenfreund | 59 € | digitale Leistungen, gedruckte Urkunde, 3 × 500 g Honig, Grußkarte, Geschenkverpackung | ja |
+
+- Die Preise sind Testpreise. Vor Veröffentlichung werden sie kaufmännisch
+  geprüft (siehe „Geschäftliche Konfiguration vor Veröffentlichung“).
+- Alle Pakete bekommen dieselbe Urkunde in derselben Qualität. Sie
+  unterscheiden sich nur in den physischen Leistungen.
+- Die Patenschaft läuft zwölf Monate ab dem gewählten Startdatum und endet
+  automatisch. Danach zeigt die Patenschaftsseite den Status „abgelaufen“, der
+  Download bleibt erhalten. Es folgen keine weiteren Leistungen oder Mails.
+
+### Honig im Paket
+
+Jedes physische Paket verweist im Admin auf ein Honigprodukt aus dem
+bestehenden Sortiment und auf eine Anzahl Gläser. Die Bestellung reserviert
+und bucht den Bestand dieses Produkts über die vorhandene Bestandslogik
+(einschließlich ApiCore-Abgleich). Ist das verknüpfte Produkt ausverkauft, ist
+das Paket nicht bestellbar und die Verkaufsseite sagt das. Der Inhaber wechselt
+die Sorte, indem er im Admin ein anderes Produkt verknüpft.
+
+### Grußkarte
+
+Die Grußkarte ist eine vorgedruckte, nicht personalisierte Karte im
+Wabenhain-Design. Persönliche Worte stehen in der Widmung auf der Urkunde.
+So entsteht kein Handschreiben pro Bestellung.
+
+## Personalisierung
+
+### Felder
+
+| Feld | Pflicht | Hinweis |
+|---|---|---|
+| Name der Patenbiene | ja | symbolischer Name |
+| Name der Person auf der Urkunde | ja | für wen die Urkunde ausgestellt ist |
+| Schenkende | nein | eine oder mehrere Personen, als Freitext („Anna und Ben“) |
+| Widmung | nein | wird unverändert übernommen |
+| Anlass | ja | für mich selbst, Geburtstag, Weihnachten, Dankeschön, allgemeines Geschenk |
+| Startdatum | ja | frühestens am Bestelltag, spätestens sechs Monate danach |
+
+Bei „für mich selbst“ blendet das Formular das Feld „Schenkende“ aus.
+
+### Eingabelimits
+
+Die endgültigen Limits ergeben sich aus der Layout-Testmatrix (siehe
+„Prüfung“). Startwerte, die die Testmatrix bestätigen oder verschärfen muss:
+
+- Bienenname: 2–24 Zeichen
+- Name auf der Urkunde: 2–60 Zeichen
+- Schenkende: bis 80 Zeichen
+- Widmung: bis 280 Zeichen und höchstens 5 Zeilenumbrüche
+
+Das Formular zeigt jedes Limit vor der Bestellung als Zeichenzähler an. Server
+und Client prüfen mit demselben zod-Schema.
+
+### Zeichen
+
+- Eingaben werden nach Unicode NFC normalisiert, Steuerzeichen entfernt,
+  Mehrfach-Leerzeichen zusammengefasst.
+- Zulässig ist jedes Zeichen, für das die eingebetteten Schriften eine Glyphe
+  haben. Die Prüfung läuft serverseitig über die Font-Metriken (fontkit).
+  Fehlt eine Glyphe (zum Beispiel Emoji), lehnt das Formular die Eingabe mit
+  einer klaren Meldung ab, statt ein Ersatzkästchen zu drucken.
+- Umlaute, ß, Akzente, Bindestriche und Apostrophe müssen funktionieren.
+
+## Urkundentext
+
+Der Text entsteht aus hinterlegten, sorgfältig formulierten Bausteinen. Es
+gibt keine KI-Anfrage pro Bestellung. Der Kunde sieht den endgültigen Wortlaut
+vor dem Kauf in der Vorschau.
+
+### Regeln
+
+- Eigene und verschenkte Patenschaft haben unterschiedliche Formulierungen.
+- Geburtstag, Weihnachten und Dankeschön haben je eine kurze, passende
+  Anlasszeile. „Für mich selbst“ und „allgemeines Geschenk“ haben keine.
+- Leere Felder erzeugen keine Platzhalter, keine leeren Zeilen und keine
+  verwaisten Bezeichnungen wie „Von:“ ohne Namen.
+- Keine erfundenen Eigenschaften, Beziehungen oder Ereignisse.
+- Keine Geschlechtszuordnung: keine Pronomen, keine Anreden wie „Liebe/Lieber“,
+  die aus dem Namen abgeleitet wären.
+- Keine Formulierung, die eine individuelle Betreuung oder Verfolgung einer
+  einzelnen Biene behauptet.
+- Die Widmung wird wörtlich übernommen. Erlaubt sind nur sichere Darstellung
+  (kein HTML, kein Markup) und sauberer Umbruch.
+
+### Bausteine (Entwurf, vor Abnahme sprachlich final prüfen)
+
+Überschrift: „Bienenpatenschaft“, darunter klein „Urkunde“.
+
+Anlasszeile über dem Haupttext:
+
+- Geburtstag: „Zum Geburtstag“
+- Weihnachten: „Zu Weihnachten“
+- Dankeschön: „Als Dankeschön“
+- allgemeines Geschenk und für mich selbst: keine Anlasszeile
+
+Haupttext, eigene Patenschaft:
+
+> {Name auf der Urkunde} hat einer Biene der Imkerei Wabenhain symbolisch den
+> Namen
+> **{Bienenname}**
+> gegeben und unterstützt damit die Imkerei und ihre Bienenvölker.
+
+Haupttext, verschenkte Patenschaft:
+
+> Für {Name auf der Urkunde}
+> Einer Biene der Imkerei Wabenhain wurde symbolisch der Name
+> **{Bienenname}**
+> gegeben. Die Patenschaft unterstützt die Imkerei und ihre Bienenvölker.
+
+Schenkende, nur wenn ausgefüllt: „Geschenkt von {Schenkende}“.
+
+Widmung, nur wenn ausgefüllt: als eigener, typografisch abgesetzter Block.
+
+Laufzeit: „Patenschaft vom {Startdatum} bis {Enddatum}“, Enddatum = Startdatum
+plus zwölf Monate minus ein Tag, deutsches Langformat.
+
+Kennung: „Nr. {Patenschaftsnummer}“, Format `WH-P-JJJJ-NNNNN`, fortlaufend über
+einen eigenen Zähler (wie `InvoiceCounter`).
+
+Hinweis, immer vorhanden und gut lesbar:
+
+> Die Namensgebung ist symbolisch. Sie gilt keiner einzeln begleiteten Biene,
+> sondern unterstützt die Imkerei Wabenhain und ihre Bienenvölker.
+
+Englische Texte: Die Seite ist zweisprachig (de/en). Die Urkunde erscheint in
+der beim Checkout gewählten Sprache (`Order.locale`). Beide Sprachfassungen
+durchlaufen dieselbe Testmatrix.
+
+## Gestaltung
+
+### Anspruch
+
+Die Urkunde soll wie ein rahmenwürdiges Geschenk wirken:
+
+- elegante Typografie mit klarer Hierarchie
+- großzügiger Weißraum, ausgewogene Proportionen
+- Bienenname und Name auf der Urkunde als gestalterischer Mittelpunkt
+- dezente Bienen-, Blüten- oder Wabenillustration als feine Strichgrafik
+- zurückhaltende Markenfarben, feine Rahmen oder Ornamente
+- harmonisch eingebundene Widmung
+- diskrete Patenschaftsnummer und Datumsangaben
+- keine Cliparts, keine Office-Vorlagenoptik, keine erfundenen Gütesiegel,
+  keine Unterschrift
+
+### Markengrundlage
+
+- Schriften: Cormorant Garamond für Überschrift, Namen und Widmung, Inter für
+  Kleintext (beide schon auf der Website, beide unter SIL Open Font License,
+  Einbettung in PDF erlaubt). Die TTF-Dateien kommen nach `assets/fonts/` samt
+  Lizenzdatei.
+- Farben aus `src/app/globals.css`: Forest `#24352b` für Text, Honey Dark
+  `#8a6531` für Akzente und Linien, Honey `#b88a44` nur flächig klein, Sage
+  `#788774` für Ornamente. Gold erscheint als flache Druckfarbe, nie als
+  Verlauf oder Folienimitat. Die Urkunde verspricht keine Goldfolie.
+- Logo: das hochgeladene Markenlogo (`getBrandAssets`). Für den Druck braucht
+  es eine SVG-Fassung oder ein PNG mit mindestens 300 dpi in Druckgröße. Liegt
+  keins vor, nutzt die Urkunde das gezeichnete Waben-Zeichen aus
+  `lib/brand-icon.ts` als Vektor. Das Logo wird nicht verzerrt, nicht
+  umgefärbt und nicht nachgezeichnet.
+- Papier ist weiß. Die Urkunde hat keine randlosen Farbflächen.
+
+### Drei Varianten, dann eine Entscheidung
+
+Zuerst entstehen drei Varianten mit identischen Beispieldaten:
+
+1. Klassisch-editorial: zentrierte Achse, feiner Doppelrahmen in Honey Dark,
+   kleine Biene als Strichzeichnung über der Überschrift.
+2. Wabe: asymmetrischer Aufbau, feines Hexagon-Linienraster als Eckmotiv,
+   Namen linksbündig groß.
+3. Botanisch: Lindenblüten- oder Kleezweig als Strichillustration, die den
+   Textblock an zwei Ecken einfasst.
+
+Alle drei werden als echte PDFs gerendert und nebeneinander beurteilt. Die zur
+Marke passendste Variante wird vollständig umgesetzt. Die anderen beiden
+bleiben nicht im Produktcode.
+
+Illustrationen werden selbst als Vektor gezeichnet (SVG-Pfade, im Code als
+Pfaddaten). Es gibt keine fremden Bildrechte und keine Rasterillustrationen.
+
+## Druck- und PDF-Anforderungen
+
+- Format A4 hochkant, genau eine Seite
+- Text als echter Text mit eingebetteten Schrift-Teilmengen, Illustrationen
+  und Rahmen als Vektor
+- Rasterbilder (nur das Logo, falls es kein SVG gibt) mit mindestens 300 dpi
+  in Druckgröße
+- sicherer Rand: aller Inhalt mindestens 15 mm vom Blattrand, Rahmenlinien
+  mindestens 12 mm. Übliche Büro- und Tintenstrahldrucker lassen 3–5 mm frei.
+- keine abgeschnittenen Namen, keine Überlagerungen
+- kleinste Schrift 8 pt (Kennung und Hinweis), Fließtext mindestens 11 pt
+- PDF-Metadaten: Titel „Bienenpatenschaft {Bienenname}“, Autor „Imkerei
+  Wabenhain“
+
+### Lange Inhalte
+
+Lange Inhalte löst das Layout über definierte Regeln, nicht durch
+Verkleinern der ganzen Seite:
+
+1. Layoutvarianten: ohne Widmung (mehr Luft, größere Namen), mit kurzer
+   Widmung, mit langer Widmung. Die Variante folgt aus der gemessenen Höhe.
+2. Kontrollierte Umbrüche: Namen brechen nur an Leerzeichen oder Bindestrich,
+   höchstens auf zwei Zeilen, nie mitten im Wort. Doppelnamen bleiben möglichst
+   in einer Zeile.
+3. Begrenzte Schriftstufen: jedes Feld hat eine feste Liste von Größen (zum
+   Beispiel Bienenname 54, 46, 40 pt). Passt der Inhalt auch in der kleinsten
+   Stufe nicht, ist das ein Validierungsfehler. Die Eingabelimits sind so
+   gewählt, dass dieser Fall im Betrieb nicht auftritt.
+
+## Architektur
+
+### Ein Layout, zwei Ausgaben
+
+Vorschau und finale PDF müssen identisch umbrechen. Deshalb gibt es genau eine
+Layout-Berechnung auf dem Server:
+
+```
+Personalisierung + Textbausteine + Vorlagenversion
+        │
+        ▼
+composeCertificateText()   → aufgelöste Textblöcke (reine Funktion)
+        │
+        ▼
+layoutCertificate()        → positionierte Elemente: Zeilen mit x/y,
+                             Schriftgröße, Schrift, Pfade (reine Funktion,
+                             misst mit fontkit an denselben TTF-Dateien)
+        │
+        ├──► renderCertificatePdf()      pdfkit, Text als Text
+        └──► renderCertificatePreview()  SVG mit Glyphen als Pfade,
+                                         per sharp zu WebP gerastert,
+                                         mit Wasserzeichen
+```
+
+Die Vorschau setzt Glyphen als Pfade aus denselben Schriftdateien an dieselben
+Positionen. Sie hängt damit nicht von Browser-Schriften ab, und ein
+Umbruchunterschied zwischen Vorschau und PDF ist ausgeschlossen. Ein Test
+vergleicht die Zeilen beider Ausgaben.
+
+Module unter `src/lib/certificate/`:
+
+| Modul | Aufgabe |
+|---|---|
+| `schema.ts` | zod-Schema der Personalisierung, gemeinsam für Client und Server |
+| `text.ts` | Bausteine je Sprache, Anlass, eigene/verschenkte Patenschaft |
+| `layout.ts` | Messen, Umbrechen, Schriftstufen, Layoutvarianten |
+| `templates/` | Vorlagen, je Version eine Datei, alte Versionen bleiben erhalten |
+| `render-pdf.ts` | pdfkit-Ausgabe |
+| `render-preview.ts` | SVG-Ausgabe und Rasterung mit Wasserzeichen |
+| `storage.ts` | Ablage der PDFs (eigenes Verzeichnis, siehe unten) |
+| `issue.ts` | Erzeugung nach Zahlung, idempotent, mit Wiederholung |
+
+### Vorlagenversion
+
+Jede Vorlage hat eine feste Kennung, etwa `wabe-classic@1`. Eine
+Designänderung erzeugt eine neue Version, die alte bleibt im Code. Neue
+Bestellungen nutzen die aktuelle Version. Bereits ausgestellte Urkunden
+behalten ihre Version und ihre gespeicherte PDF.
+
+### Datenmodell (Prisma, beide Provider)
+
+- `SponsorshipPackage`: Name, Beschreibung, Leistungsliste, Preis, aktiv,
+  Reihenfolge, physisch ja/nein, verknüpftes Honigprodukt, Anzahl Gläser,
+  Steueraufteilung (siehe unten)
+- `Sponsorship`: eine je gekaufter Patenschaft. Bezug auf `OrderItem`
+  (eindeutig, das ist der Idempotenzschlüssel), Patenschaftsnummer, Start- und
+  Enddatum, Status, Zugriffs-Token als Hash, aktuelle Revision
+- `SponsorshipRevision`: unveränderlicher Stand: Personalisierung (JSON),
+  aufgelöster Text, Vorlagenversion, PDF-Pfad, SHA-256 der PDF, erstellt von
+  (System oder Admin), Änderungsgrund, Zeitpunkt
+- `SponsorshipCounter`: fortlaufende Nummer je Jahr
+- Zustellfelder an `Sponsorship`: `pdfAttempts`, `nextAttemptAt`,
+  `lastError`, `mailSentAt`, `printedAt`
+
+Statuswerte der Patenschaft: `AUSSTEHEND` (bezahlt, PDF noch nicht da),
+`FEHLER` (Versuche aufgebraucht, braucht Admin), `BEREIT` (PDF da, Mail
+versendet), `GEDRUCKT` (nur physisch). Der Laufzeitstatus aktiv/abgelaufen
+wird aus den Daten berechnet, nicht gespeichert.
+
+### Warenkorb und Checkout
+
+- Die Patenschaft kommt als Position in den bestehenden Warenkorb, Menge
+  immer 1 je Personalisierung. Mehrere Patenschaften sind mehrere Positionen.
+- Die Personalisierung reist mit der Warenkorbposition. Der Checkout prüft sie
+  serverseitig erneut mit demselben Schema und denselben Layoutregeln.
+- Bevor die Position in den Warenkorb darf, bestätigt der Kunde: „Ich habe die
+  Vorschau und die Schreibweise geprüft.“
+- Beim Anlegen der Bestellung wird die Personalisierung zusammen mit der
+  Vorlagenversion als Entwurf an der `OrderItem` gespeichert. Genau dieser
+  Stand wird nach der Zahlung zur ersten Revision.
+- Reine Digitalbestellungen haben keine Versandkosten. Die Rechnungsanschrift
+  bleibt Pflicht wie heute. Ob dafür ein neuer `FulfillmentMethod`-Wert
+  `DIGITAL` nötig ist oder `VERSAND` mit 0 € genügt, entscheidet der
+  Implementierungsplan nach Lesen von Checkout, Rechnung und DHL-Logik.
+- Physische Pakete laufen über die bestehenden Versandstaffeln je Kategorie.
+  Für Patenschaftspakete wird eine eigene Staffel gepflegt.
+
+### Steuer
+
+Ein physisches Paket enthält Leistungen mit unterschiedlichen Steuersätzen
+(Urkunde und Leistung, Honig). Das Paket speichert deshalb eine Aufteilung des
+Bruttopreises: Honiganteil in Cent zum Honig-Satz, Rest zum Regelsatz. Die
+Rechnung zeigt das Paket mit beiden Steuerzeilen. Die vorhandene
+Gruppierung nach Steuersätzen in `lib/vat.ts` wird dafür genutzt. Die Methode
+der Aufteilung muss die Steuerberatung bestätigen. Ist
+Kleinunternehmerregelung aktiv, entfällt die Aufteilung wie heute.
+
+### Ablauf nach der Zahlung
+
+1. Der Stripe-Webhook markiert die Bestellung wie heute über den atomaren
+   Claim als bezahlt. Nur dieser Lauf legt die `Sponsorship`-Zeilen an
+   (`create` mit eindeutigem `orderItemId`; ein Duplikat bricht still ab).
+2. Danach versucht der Webhook die Erzeugung direkt: Text auflösen, Layout,
+   PDF rendern, ablegen, Hash und erste Revision speichern.
+3. Die Bestellbestätigung enthält den Downloadlink. Der Versand der Mail wird
+   über `updateMany … where mailSentAt = null` beansprucht, damit doppelte
+   Webhooks keine zweite Mail erzeugen. Erst nach erfolgreichem Versand wird
+   der Status `BEREIT`.
+4. Scheitert die Erzeugung, antwortet der Webhook trotzdem 200 (die Zahlung
+   ist erfolgt, wie bei der Rechnung heute). Die Patenschaft bleibt
+   `AUSSTEHEND` mit `nextAttemptAt`. Die Bestätigungsmail sagt dann: „Ihre
+   Urkunde wird gerade erstellt, der Link folgt in einer eigenen Mail.“
+5. Ein neuer CronJob `wabenhain-certificates` (alle 10 Minuten,
+   `concurrencyPolicy: Forbid`, wie die bestehenden Jobs in
+   `k8s/07-backup-cronjob.yaml`) holt offene Erzeugungen und offene Mails
+   nach. Wiederholung mit wachsendem Abstand, höchstens 8 Versuche, danach
+   `FEHLER` und Hinweis im Admin-Dashboard (bestehende Aufmerksamkeitsliste).
+
+Die finale Urkunde entsteht nie vor bestätigter Zahlung. Async-Zahlarten
+(SEPA) erzeugen sie erst bei `async_payment_succeeded`.
+
+### Ablage
+
+PDFs liegen in einem eigenen Verzeichnis `CERTIFICATE_DIR`, nicht unter
+`UPLOAD_DIR`, weil die Upload-Route alles ohne Anmeldung ausliefert. Die
+Startprüfung aus `lib/invoice-storage.ts` (Verzeichnis darf nicht im
+Upload-Verzeichnis liegen) wird übernommen. Das Verzeichnis kommt auf das
+gesicherte Volume und in den Sicherungs-CronJob.
+
+### Download und Patenschaftsseite
+
+- Der Link enthält ein zufälliges Token mit mindestens 128 Bit. Gespeichert
+  wird nur der SHA-256-Hash. Die URL enthält keine Namen und keine
+  Bestellnummer.
+- `/patenschaft/<token>` zeigt Bienenname, Name auf der Urkunde, Laufzeit,
+  Status aktiv/abgelaufen und den Download. Keine Anschrift, keine
+  Bestelldaten. `noindex`, Rate-Limit über `lib/rate-limit.ts`.
+- Angemeldete Kunden sehen ihre Patenschaften zusätzlich unter „Konto“.
+- Der Download liefert immer die gespeicherte PDF der aktuellen Revision. Es
+  wird nicht neu gerendert.
+- Der Link darf an Beschenkte weitergegeben werden. Er zeigt nur, was ohnehin
+  auf der Urkunde steht.
+
+### QR-Code
+
+Die Urkunde bekommt keinen QR-Code. Er brächte kaum Nutzen, stört die
+Gestaltung, und ein QR-Code zur Patenschaftsseite würde den Downloadlink
+jedem öffnen, der ein Foto der gerahmten Urkunde sieht.
+
+### Vorschau
+
+- Endpunkt `POST /api/patenschaft/vorschau`: nimmt die Personalisierung,
+  prüft sie, gibt ein WebP zurück. Rate-Limit je Besucher.
+- Die Vorschau trägt sichtbar „Unverbindliche Vorschau“ als Wasserzeichen und
+  hat nur Bildschirmauflösung. Sie ersetzt so nicht die gekaufte PDF.
+- Der Client fordert sie mit Verzögerung nach der letzten Eingabe an (etwa
+  400 ms) und zeigt bis dahin die letzte gültige Vorschau.
+
+## Adminbereich
+
+### Pakete
+
+Pakete bearbeiten wie Produkte: Name, Preis, Beschreibung, Leistungen, aktiv,
+Honigprodukt, Gläser, Steueraufteilung.
+
+### Patenschaften
+
+Liste mit Filtern nach Status (ausstehend, Fehler, bereit, zu drucken,
+gedruckt) und Paket. Detailansicht:
+
+- Vorschau der aktuellen Revision, Liste aller Revisionen
+- „Druck-PDF öffnen“: dieselbe gespeicherte PDF, die der Kunde bekommt
+- „Als gedruckt markieren“ (nur physisch)
+- „Erneut erzeugen“ bei Status `FEHLER` (gleiche Vorlagenversion)
+- „Mail erneut senden“
+
+### Korrektur
+
+1. Admin öffnet „Korrigieren“, ändert Felder im selben Formular wie der Kunde.
+2. Die Vorschau zeigt das Ergebnis mit derselben Layoutlogik.
+3. Speichern verlangt einen Änderungsgrund.
+4. Es entsteht eine neue `SponsorshipRevision` mit neuer PDF. Die alte bleibt
+   erhalten und ist abrufbar.
+5. `logAdminAction` schreibt den Vorgang ins Audit-Log (wer, wann, welche
+   Felder, Grund).
+6. Optional per Häkchen: Mail an den Käufer „Ihre korrigierte Urkunde“.
+
+Eine Korrektur nutzt standardmäßig die Vorlagenversion der bisherigen
+Revision. Ein Wechsel auf die aktuelle Version ist eine bewusste Auswahl im
+Formular.
+
+### Druckablauf
+
+Physische Bestellungen erscheinen nach der Zahlung in der Liste „zu drucken“.
+Der Inhaber öffnet die PDF, druckt sie auf festem Papier, markiert sie als
+gedruckt und versendet die Bestellung wie heute über DHL. Mehr Schritte gibt
+es nicht.
+
+## Verkaufsseite
+
+Route `/patenschaft`, zweisprachig, im bestehenden Design der Website.
+
+Im Mittelpunkt stehen:
+
+- einer Biene symbolisch einen eigenen Namen geben
+- ein persönlich gestaltetes Geschenk
+- die regionale Imkerei Wabenhain unterstützen
+- je nach Paket eigenen Wabenhain-Honig verschenken
+
+Aufbau:
+
+1. Kopfbereich mit großer, echter Urkundenvorschau als zentrales Element
+2. Paketwahl mit klarer Leistungsliste, Preis und Versandkosten
+3. Personalisierung in Schritten: Paket, für wen und Anlass, Namen, Widmung
+   und Startdatum, Vorschau prüfen
+4. Hinweis zur symbolischen Namensgebung, gut sichtbar und nicht im Kleingedruckten
+5. FAQ
+
+Auf dem Smartphone steht die Vorschau über dem jeweiligen Schritt. Ein Tipp
+vergrößert sie auf volle Breite. Eingabefelder haben mindestens 16 px
+Schriftgröße (kein Zoom unter iOS), Bedienelemente mindestens 44 px.
+
+FAQ-Themen: Was bedeutet symbolische Namensgebung? Wie lange läuft die
+Patenschaft? (zwölf Monate, endet automatisch, kein Abo) Wann kommt die
+Urkunde? (digital direkt nach Zahlung, gedruckt mit dem Paket) Was ist im
+Paket? Was kostet der Versand? Was, wenn ich mich vertippt habe? (Kontakt,
+Korrektur durch Wabenhain) Keine FAQ verspricht Besuche, Berichte, Fotos oder
+Umweltwirkungen.
+
+## Prüfung
+
+### Layout-Testmatrix
+
+Automatisierte Tests rendern echte PDFs und prüfen die Layoutdaten (keine
+Überlappung von Elementboxen, alles innerhalb der Sicherheitszone, Schrift nie
+unter Mindestgröße, genau eine Seite) für:
+
+- sehr kurze Namen („Li“, „Bo“)
+- maximal lange Namen in beiden Feldern
+- Doppelnamen („Marie-Luise Schmidt-Habermann“)
+- Umlaute und Sonderzeichen („Jürgen Weiß“, „Zoë“, „Ñúñez“, „O’Brien“)
+- mehrere Schenkende („Anna, Ben, Carla und Familie Özdemir“)
+- ohne Widmung
+- maximal lange Widmung, auch mit allen erlaubten Zeilenumbrüchen
+- jeden Anlass, eigene und verschenkte Patenschaft, Deutsch und Englisch
+- Vorschau und PDF ergeben dieselben Zeilen
+
+Die Matrix legt die endgültigen Eingabelimits fest. Sie stehen danach im
+Schema und im Formular.
+
+### Visuelle Kontrolle
+
+Die erzeugten PDFs werden gerastert (300 dpi) und angesehen: die ganze Seite
+und Ausschnitte bei hoher Vergrößerung (Namen, Widmung, Ornament, Kleintext).
+Layoutfehler werden vor Abschluss behoben. Ein Probedruck auf einem
+Bürodrucker gehört dazu.
+
+### Ablauftests
+
+- Webhook doppelt zugestellt: eine Patenschaft, eine Mail
+- PDF-Erzeugung schlägt fehl: Webhook 200, CronJob holt nach, Status wird `BEREIT`
+- Mailversand schlägt fehl: CronJob holt nach, keine Doppelmail
+- Fremdes oder falsches Token: 404 ohne Hinweis auf Existenz
+- Korrektur: neue Revision, alte unverändert, Audit-Eintrag vorhanden
+- Vorlagenversion erhöht: alte Urkunden liefern unverändert ihre PDF
+- E2E (Playwright): Paket wählen, personalisieren, Vorschau, Checkout mit
+  Stripe-Testkarte, Downloadseite, PDF abrufbar
+
+Die Repo-Skripte `lint`, `typecheck`, `test` und `build` laufen grün.
+
+## Abnahme
+
+Fertig ist die Funktion, wenn eine Testbestellung ohne manuelle Nacharbeit
+eine korrekt personalisierte, hochwertige und druckfähige Urkunde erzeugt.
+
+Zum Abschluss werden gezeigt:
+
+1. Verkaufsseite und Personalisierung auf Desktop und bei 390 px mobil
+2. die drei Designvarianten und die gewählte Gestaltung
+3. mehrere echte PDF-Ausgaben mit unterschiedlichen Beispieldaten
+4. der automatische Ablauf vom Kauf bis zum Download
+5. Druck- und Korrekturablauf im Adminbereich
+6. die offene geschäftliche Konfiguration (Liste unten)
+
+## Geschäftliche Konfiguration vor Veröffentlichung
+
+Diese Punkte entscheidet der Inhaber. Die Software ist ohne sie fertig,
+veröffentlicht wird erst danach.
+
+1. Preise kaufmännisch prüfen: Honig, Papier, Verpackung, Grußkarte,
+   Stripe-Gebühren, Arbeitszeit je Paket.
+2. Steueraufteilung der physischen Pakete mit der Steuerberatung abstimmen.
+3. AGB und Widerrufsbelehrung anpassen: Ausschluss des Widerrufs für nach
+   Kundenangaben angefertigte Waren (§ 312g Abs. 2 Nr. 1 BGB), Zustimmung zum
+   sofortigen Beginn bei digitalen Inhalten (§ 356 Abs. 5 BGB), Behandlung
+   des Honiganteils. Rechtlich prüfen lassen.
+4. Datenschutzerklärung ergänzen: Namen Dritter (Beschenkte, Schenkende),
+   Speicherdauer der Personalisierung und der PDFs.
+5. Versandstaffel für Patenschaftspakete im Admin anlegen.
+6. Logo als SVG oder PNG mit mindestens 300 dpi hochladen.
+7. Material bevorraten: Urkundenpapier (Empfehlung 200–250 g/m², matt,
+   naturweiß), Geschenkverpackung, vorgedruckte Grußkarten. Probedruck auf dem
+   eigenen Drucker freigeben.
+8. Bestellschluss für Weihnachten festlegen und auf der Verkaufsseite nennen.
+9. Bausteintexte sprachlich final freigeben (de und en).