Les deux flushs (L91 via persistProcessor + L130 via ensureCurrentSiteConsistency) ne sont pas wrappés dans la même transaction. Crash entre les deux (OOM, worker killed, perte de connexion DB) laisse currentSite pointer vers un site absent de user_site → viole l'invariant L34-39.
TOCTOU : switchCurrentSite() lit $this->sites en mémoire puis flush(), sans #[ORM\Version] ni lock.
GET /api/users n'est pas site-scopé (User n'implémente pas SiteAwareInterface) et le groupe user:list expose sites, currentSite, rbacRoles, directPermissions, isAdmin. Tout porteur de core.users.view énumère l'intégralité des users de tous les tenants avec leur topologie RBAC complète.
4 relations EAGER (rbacRoles L89, directPermissions L107, sites L123, currentSite L140) toutes dans le groupe user:list. Sur GET /api/users avec pagination 30, c'est 1 + 120 requêtes par page (plus N+1 nested si role.permissions est EAGER).
GetCollection + Get sur /api/sites sont gardés par sites.view mais sans filtre sur $user->getSites(). Un délégataire de sites.view lit tous les sites de l'instance — nom, adresse, CP, ville, couleur — y compris ceux auxquels il n'a pas accès.
Après suppression, loadSites() rafraîchit la liste mais pas auth.user. Si l'admin supprime son site courant, la backend passe user.current_site_id à NULL (cascade ON DELETE SET NULL de la FK) mais auth.user.currentSite côté Pinia reste le site supprimé. Le SiteSelector du header continue d'afficher la tile morte jusqu'au prochain /api/me.
Après switchSite() succès, seul auth.user.currentSite est mis à jour — ni la sidebar (useSidebar()), ni les données des pages déjà rendues (filtrées server-side sur l'ancien site via SiteScopedQueryExtension). L'utilisateur voit un toast success sur des données obsolètes ; la prochaine mutation est cross-site.
Les groupes de sérialisation de sites exposent la collection au-delà du scope sites.* :
Le bloc if (null === currentSite && !sites->isEmpty()) s'applique sur tout PATCH /rbac, même si la requête n'a pas touché sites. Scénario : un admin supprime un site → la FK passe à NULL pour les users concernés (onDelete: SET NULL). Plus tard, un manager édite seulement un rôle sur un de ces users → cet appel bascule silencieusement currentSite sur sites->first(), changeant le contexte effectif des lectures/écritures scopées.
Import direct Core → Sites (entité + exception) : viole la règle CLAUDE.md « jamais d'import direct entre modules » (ligne 138). Piste : introduire une interface SiteInterface dans Shared/Domain/Contract/ et typer User::$currentSite / hasSite() / switchCurrentSite() contre cette interface. L'exception SiteNotAuthorizedException peut aussi être remontée dans Shared/Domain/Exception/.
Shared/Domain/Contract/ ne doit dépendre de aucun module (cf. CLAUDE.md:138 et description de Contract/ ligne 23). En typant getSite(): ?Site / setSite(Site) contre l'entité concrète du module Sites, tout module qui adopte SiteAwareInterface hérite d'une dépendance transitive vers Module\Sites — ce qui défait la raison d'être de Shared/Contract/. À remplacer par un SiteInterface (dans Shared/Domain/Contract/) que Module\Sites\Domain\Entity\Site implémente.
Si auth.logout() (ligne 17) rejette, le finally exécute bien les trois resets mais l'exception se propage ensuite hors du handler onMounted — la ligne await navigateTo('/login') ne s'exécute jamais. L'utilisateur reste bloqué sur /logout avec état vidé. Déplacer navigateTo('/login') dans le finally (après les resets), ou entourer d'un try { await auth.logout() } catch {} finally { ...; await navigateTo('/login') }.