docs(phase-15): add validation strategy

.planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-VALIDATION.md

@@ -0,0 +1,87 @@
+---
+phase: 15
+slug: modul-berechtigungen-gruppen-user-grants
+# status lifecycle: draft (seeded by plan-phase) → validated (set by validate-phase §6)
+# audit-milestone §5.5 distinguishes NOT-VALIDATED (draft) from PARTIAL (validated + nyquist_compliant: false) (#2117)
+status: draft
+nyquist_compliant: false
+wave_0_complete: false
+created: 2026-08-04
+---
+
+# Phase 15 — Validation Strategy
+
+> Per-phase validation contract for feedback sampling during execution.
+
+---
+
+## Test Infrastructure
+
+| Property | Value |
+|----------|-------|
+| **Framework** | Vitest 3.2.6 |
+| **Config file** | `apps/api/vitest.config.ts` / `apps/web/vitest.config.ts` |
+| **Quick run command** | `pnpm --filter @tessera/api test -- <datei>` |
+| **Full suite command** | `pnpm --filter @tessera/api test` und `pnpm --filter @tessera/web test` |
+| **Estimated runtime** | ~60 seconds (API-Suite), Einzeldatei ~5 s |
+
+---
+
+## Sampling Rate
+
+- **After every task commit:** Run `pnpm --filter @tessera/api test -- <betroffene Datei>`
+- **After every plan wave:** Run `pnpm --filter @tessera/api test` und `pnpm --filter @tessera/web test`
+- **Before `/gsd-verify-work`:** Volle Suite grün PLUS manueller Migrations-Trockenlauf gegen eine mit Bestandsdaten befüllte lokale Test-DB (PERM-06 ist durch Unit-Tests nicht sinnvoll abgedeckt)
+- **Max feedback latency:** 60 seconds
+
+---
+
+## Per-Task Verification Map
+
+> Task-IDs werden vom Planner vergeben; diese Zeilen binden Requirement → Test-Typ → Kommando und werden beim Planen auf konkrete Tasks abgebildet.
+
+| Task ID | Plan | Wave | Requirement | Threat Ref | Secure Behavior | Test Type | Automated Command | File Exists | Status |
+|---------|------|------|-------------|------------|-----------------|-----------|-------------------|-------------|--------|
+| TBD | TBD | TBD | PERM-01 | IDOR bei `DELETE /groups/:id` | Jede Gruppen-Query filtert zusätzlich auf `tenantId` | unit (Service) + component (Lösch-Dialog) | `pnpm --filter @tessera/api test -- groups.service` | ❌ W0 | ⬜ pending |
+| TBD | TBD | TBD | PERM-02 | — | LDAP-Sync entfernt nur `source: LDAP`-Mitgliedschaften | unit (LdapService, gemockter Client) | `pnpm --filter @tessera/api test -- ldap.service` | ✅ (`ldap.service.spec.ts`, muss erweitert werden) | ⬜ pending |
+| TBD | TBD | TBD | PERM-03 | Cross-Tenant-Grant-Injection | `group.tenantId`/`user.tenantId` wird vor jedem Grant-Insert gegen den JWT-Mandanten geprüft | unit (Service) + component (Matrix) | `pnpm --filter @tessera/api test -- module-grants.service` | ❌ W0 | ⬜ pending |
+| TBD | TBD | TBD | PERM-04 | Guard-Bypass bei fehlendem `@UseModule()` | Sidebar, Modulseite und API nutzen dieselbe Auflösung; Durchsetzung serverseitig auf jeder Schicht | integration (Guard) + component (403-Seite) | `pnpm --filter @tessera/api test -- module-access.service` und `-- module.guard` | ❌ W0 | ⬜ pending |
+| TBD | TBD | TBD | PERM-05 | Rollen-Branch als Bypass | ADMIN/SUPER_ADMIN-Bypass gilt ausschließlich innerhalb des eigenen Mandanten | unit (Rollen-Branch) | `pnpm --filter @tessera/api test -- module-access.service` | ❌ W0 | ⬜ pending |
+| TBD | TBD | TBD | PERM-06 | — | Kein Bestandsbenutzer verliert Zugriff | Migrations-Verifikation per Zähl-Assertions gegen Test-DB | manueller/skriptgestützter Lauf (Muster: `backfill-tender-source.ts`) | ❌ W0 | ⬜ pending |
+| TBD | TBD | TBD | PERM-07 | — | Widget eines gesperrten Moduls wird serverseitig herausgefiltert | unit (`DashboardService.getWidgets`) | `pnpm --filter @tessera/api test -- dashboard.service` | ❌ W0 | ⬜ pending |
+
+*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
+
+---
+
+## Wave 0 Requirements
+
+- [ ] `apps/api/src/module-registry/module-access.service.spec.ts` — deckt PERM-04 und PERM-05
+- [ ] `apps/api/src/module-registry/module.guard.spec.ts` — für den Guard existiert bisher kein Test
+- [ ] `apps/api/src/groups/groups.service.spec.ts` — deckt PERM-01
+- [ ] `apps/api/src/groups/module-grants.service.spec.ts` — deckt PERM-03
+- [ ] `apps/api/src/dashboard/dashboard.service.spec.ts` — bisher ungetestet, deckt PERM-07
+- [ ] Erweiterung von `apps/api/src/ldap/ldap.service.spec.ts` um AD-Gruppenbindungs-Fälle — deckt PERM-02
+- [ ] Migrations-Verifikationsvorgehen für PERM-06 — Zähl-Assertions oder SQL-Checks nach dem Backfill; im Projekt existiert dafür kein automatisiertes Framework
+
+---
+
+## Manual-Only Verifications
+
+| Behavior | Requirement | Why Manual | Test Instructions |
+|----------|-------------|------------|-------------------|
+| Migration erzeugt Standardgruppe, Mitgliedschaften und Grants ohne Zugriffsverlust | PERM-06 | Raw-SQL-Backfill in `migration.sql`, läuft beim Container-Start über `prisma migrate deploy`; im Projekt gibt es kein Testframework für Migrationsdaten | Lokale Test-DB mit Bestandsdaten (mehrere Mandanten, aktive Module, Benutzer) füllen, Migration anwenden, danach je Mandant prüfen: genau eine Gruppe mit `isDefault`, Mitgliederzahl gleich Benutzerzahl, Grant-Zahl gleich Zahl der aktiven Module |
+| AD-Gruppenbindung gegen ein echtes Active Directory | PERM-02 | Verhalten bei Range Retrieval und großen Gruppen ist nur gegen ein echtes AD belastbar; Research-Confidence hier MEDIUM | Gegen `balios.ctl.local` eine Gruppe binden, Sync auslösen, Mitgliederzahl in Tessera mit der AD-Gruppe vergleichen; danach einen Benutzer im AD aus der Gruppe nehmen, erneut syncen und prüfen, dass nur seine `LDAP`-Mitgliedschaft verschwindet |
+
+---
+
+## Validation Sign-Off
+
+- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
+- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
+- [ ] Wave 0 covers all MISSING references
+- [ ] No watch-mode flags
+- [ ] Feedback latency < 60s
+- [ ] `nyquist_compliant: true` set in frontmatter
+
+**Approval:** pending