ADR-0017 — Orbit separe User, Workspace, Project, Memory et PlatformAdmin

Statut

Accepté · 2026-09-29

Remplace ou amende : ADR 0011 seulement sur l'hypothese produit interne / fondateur special. Les choix depot, base et moteurs restent inchanges.

Origine : ADR 0007 du dépôt applicatif Orbit, renumérotée 0017 à l’intégration dans cette série (une seule série d’ADR vit désormais ici).

Statut dans Orbit (2026-10) : en vigueur, précisée par l'ADR 0018 (portée de Memory, rôle de Studio, navigation) et l'ADR 0020 (Spaces, crédits par workspace, PlatformAdmin). Ici, « la plateforme » (et PlatformAdmin) désigne Orbit lui-même, le SaaS et son back-office, jamais l'ancienne application externe dont le code est issu.

Contexte

Le depot est ne comme studio interne. Cette origine reste visible dans des noms persistes (StudioMember, StudioGeneration, Product, BrainEntry) et dans un role FOUNDER qui cumule aujourd'hui propriete du workspace, permissions d'equipe et traitement financier special.

Le produit cible est un SaaS. Le fondateur d'Orbit utilise donc le cockpit comme n'importe quel autre client. Son droit d'administrer la plateforme est une capacite separee, jamais une propriete implicite de son premier workspace.

Les travaux recents ont deja separe les surfaces Overview, Studio et Memoire. Cette ADR fixe le domaine cible avant d'ajouter BYOK, MCP, billing et multi-workspace.

Decision

1. Cinq objets, cinq responsabilites

User est l'identite humaine. Il porte le profil et, plus tard, les credentials personnelles.

Workspace est le tenant SaaS. Il porte l'equipe, le plan, le pool de credits, les credentials partagees et les politiques.

WorkspaceMembership relie un User a un Workspace. Un User pourra appartenir a plusieurs workspaces. Les roles d'acces et les intitulés metier restent deux choses differentes.

Project est l'unite de travail. Le modele Prisma actuel s'appelle encore Product. Un Project possede sa Memoire, ses connexions, generations, assets, concepts, validations, performances et apprentissages.

PlatformAdmin donne acces au back-office Orbit. Il est orthogonal au membership et n'accorde aucun credit, generation ou privilege dans le cockpit.

2. Une Memoire par Project

Chaque Project a une Memoire isolee. Une information d'un projet ne nourrit jamais implicitement un autre projet. Le Style de marque fait partie de cette Memoire, avec l'identite, les consignes, knowledge, fonctionnalites, personas, sources, concepts et apprentissages.

Studio lit la Memoire du Project actif. Il ne possede plus de page Brand System parallele.

3. Les roles metier sont des presets, pas des enums d'autorisation

Les libelles produit peuvent etre Creative Producer, Reviewer, Growth Lead, etc. Ils correspondent a des ensembles de permissions. Ils ne doivent pas forcer une migration de schema a chaque nouveau metier.

Le stockage actuel garde temporairement les valeurs FOUNDER/CREATOR/REVIEWER/DISTRIBUTOR/VIEWER. Dans l'interface, FOUNDER est deja presente comme Propriétaire du workspace, jamais comme administrateur de la plateforme.

Le schema cible separera les roles d'acces stables (OWNER / ADMIN / MEMBER / VIEWER) des presets metier et des permissions granulaires.

4. Aucun rattachement implicite entre tenants

Un membership sans workspace ne peut jamais adopter le premier workspace de la base. Une ligne legacy reçoit un espace propre et deterministe jusqu'a la migration multi-workspace.

Une absence de workspace doit ensuite devenir un etat explicite : creer un workspace ou accepter une invitation.

5. Credentials et BYOK suivent le meme scope

La resolution cible est explicite et auditable :

1. credential personnelle du membre, si la politique l'autorise ;
2. credential du workspace ;
3. credential managed par Orbit.

Les secrets ne vivent jamais dans ProjectConnection. Cette table ne garde que des references non sensibles, conformement a l'ADR 0016.

Chaque generation doit pouvoir enregistrer le scope de credential et la source de facturation sans exposer le secret.

6. Pas de big-bang Prisma

Cette ADR ne renomme pas physiquement les tables.

Ordre de migration :

1. stabiliser le langage applicatif Project / Memory / Workspace ;
2. sortir les comportements Founder speciaux du ledger ;
3. ajouter PlatformAdmin ;
4. migrer StudioMember vers un vrai join WorkspaceMembership multi-workspace ;
5. migrer Product vers Project et BrainEntry vers MemoryEntry avec mapping Prisma / migrations explicites ;
6. renommer Generation / Asset / Reference / Audit si le gain depasse le risque de churn.

Chaque etape doit garder les ids et relations et etre deployable seule. Aucun db push destructif ; migrations Prisma commitees et migrate deploy.

Changements immediats

• Style de marque devient une vue native de Memoire.
• Les anciennes sections Brand System / Platform System sortent du Studio.
• Un membre legacy sans workspace reçoit son propre workspace au lieu du premier tenant de la base.
• Les libelles d'equipe utilisent Propriétaire, Creative Producer, Reviewer, Growth Lead et Viewer tout en gardant les enums persistés pour compatibilite.
• Le nouveau code peut utiliser les aliases Project pendant que Prisma garde temporairement Product.

Consequences

Le cockpit utilisateur ne depend plus de l'identite du fondateur d'Orbit. Le premier workspace (celui de l'organisation fondatrice) est un client du systeme comme un autre.

Le futur panneau admin est une application/surface separee par permission PlatformAdmin. Il ne doit pas apparaitre dans les settings utilisateur normaux.

Le multi-workspace et le BYOK necessitent encore des migrations dediees ; cette ADR empeche de coder ces fonctions sur les abstractions legacy.