diff --git a/.planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-VALIDATION.md b/.planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-VALIDATION.md new file mode 100644 index 0000000..f1f16f8 --- /dev/null +++ b/.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 -- ` | +| **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 -- ` +- **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 `` 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