chore(config): add agent skills and project brain documentation

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

@@ -0,0 +1,20 @@
+# Sicherheitskonzept (RLS - Row Level Security)
+
+RLS ist auf Datenbankebene in Postgres implementiert und erzwingt Datenisolierung:
+
+- **Unternehmen (`companies`)**: Authentifizierte Benutzer dürfen nur die Unternehmen lesen.
+- **Endkunden (`end_customers`)**:
+  - `USING (partner_id = (SELECT company_id FROM public.users WHERE id = auth.uid()))`
+  - Partner sehen und modifizieren nur Endkunden, deren `partner_id` mit der `company_id` des angemeldeten Benutzers übereinstimmt.
+- **Bestellungen (`orders`)**:
+  - `USING (company_id = (SELECT company_id FROM public.users WHERE id = auth.uid()))`
+  - Partner sehen und modifizieren nur Bestellungen, die ihrer Company zugewiesen sind (sie müssen einer Company zugeordnet sein).
+  - Jede Bestellung wird bei der Erstellung automatisch der Company des Erstellers zugewiesen.
+  - 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.
+  - Admins dürfen alle Benutzer lesen. Zur Vermeidung von unendlichen RLS-Rekursionen auf der Tabelle `users` wird die Admin-Zuweisung über die Security-Definer-Funktion `public.is_admin(user_id)` geprüft, welche RLS auf Datenbank-Ebene umgeht.
+  - 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.