docs: document asynchronous post-processing and postgres user role triggers in grand functions

.agents/skills/grand-functions/references/processes.md

@@ -59,7 +59,8 @@ graph TD
 ---
 
 ### F. PDF-Rechnungsgenerierung & Mail-Versand (Post-Processing)
-- **Snapshot-Exklusivität**: Die Rechnungsgenerierung erfolgt ausschließlich auf Basis der in `orders.order_data` und `orders.customer_data` eingefrorenen Snapshots.
+- **Entkopplung & Asynchronität**: Die Generierung der PDFs und der E-Mail-Versand sind vollständig aus dem synchronen Checkout-Flow entkoppelt. Der Checkout liefert dem Frontend sofort nach Speicherung in der DB eine Erfolgsmeldung zurück. Die Generierung und der Versand werden asynchron im Hintergrund (via unblockiertem Promise-Worker) ausgeführt, um SMTP-Latenzen abzufangen.
+- **Snapshot-Exklusivität**: Die PDF-Generierung erfolgt ausschließlich auf Basis der in `orders.order_data` und `orders.customer_data` eingefrorenen Snapshots.
 - **Layout-Unterscheidung**:
   - **Typ `purchase` (Kauf)**:
     - Generiert eine klassische **B2B-Angebot**.

.agents/skills/grand-functions/references/security.md

@@ -13,3 +13,7 @@ RLS ist auf Datenbankebene in Postgres implementiert und erzwingt Datenisolierun
   - Admins haben uneingeschränkten Zugriff und können Bestellungen nachträglich anderen Companies zuweisen.
 - **Lizenzen (`licenses`)**:
   - Partner sehen nur Lizenzen von Endkunden, die ihrer Company zugeordnet sind.
+
+- **Systembenutzer (`users`) & Rollen-Schutz**:
+  - Authentifizierte Nutzer dürfen nur ihr eigenes Profil lesen.
+  - Rollenschutz-Trigger (`check_user_role_escalation`): Jegliche Änderung der Spalte `role` oder Zuweisung der Rolle `'admin'` ist auf API-Ebene für normale Nutzer gesperrt. Updates/Inserts der Rolle werden ausschließlich von der `service_role` (Backend Admin-Client) akzeptiert, um Privilegien-Eskalation zu verhindern.