Organisations, équipes et isolation tenant

Synchronisé avec le commit 7d452a6 du starter.

Chaque compte possède une organisation

L’inscription crée une organisation personnelle et une adhésion owner. Il n’existe pas de seconde voie de ressources « utilisateur » : fichiers, tâches, commandes, abonnements, crédits, clés API et réservations utilisent org_uuid.

Better Auth fournit les adhésions et invitations. Sushi ajoute le périmètre tenant, les permissions, les limites de sièges, les soldes mutualisés et les gardes de concurrence.

Rôles

La hiérarchie est owner ⊃ admin ⊃ member.

Utilisez getOrgContext(request, optionalSlug) puis can(ctx, action, resource). N’acceptez jamais org_uuid dans le corps d’une requête.

Isolation et limites de sièges

Toutes les requêtes sur des tables tenant utilisent scopedToOrg(column, ctx.orgUuid) dans les modèles. Les tests d’architecture détectent une lecture ou insertion non limitée.

Les invitations expirent après 72 heures, sont liées à l’adresse invitée et réservent un siège tant qu’elles sont actives.

La capacité est vérifiée à l’envoi et à l’acceptation sous le même verrou advisory PostgreSQL. Le support peut définir une exception auditée, temporaire ou permanente.

Invariants

• Le dernier owner ne peut pas être retiré.
• Un utilisateur ne peut pas quitter sa seule organisation.
• Un membre ne peut pas attribuer un rôle supérieur au sien.
• Un downgrade conserve membres et données, mais bloque les nouvelles entrées.
• Les crédits et le client Stripe appartiennent à l’organisation.

L’interface est sous /{locale}/account/team, l’API sous /api/account/team/*. Le starter ne fournit pas encore de sélecteur d’organisation, routes par slug, rôles personnalisés ou quantité Stripe par siège.