AI Context

Intent

Ce document sert de contexte court pour une IA ou un agent qui doit modifier ce repo.

Regles prioritaires

• ne pas supposer que front et back sont deja totalement migres
• ne pas remplacer une regle metier backend par une simple contrainte UI
• ne pas utiliser la cle serveur Supabase comme substitut au token utilisateur
• ne pas elargir la visibilite d'un administrateur au-dela de profile.enterprise_id
• ne pas melanger enterprise et personal dans les listes d'entreprises administrables
• ne jamais exposer par defaut les entreprises personal, car elles servent uniquement aux comptes personnels

Verites actuelles

• l'authentification utilisateur est geree cote frontend via Supabase
• le backend valide le bearer token Supabase
• le backend charge profiles et roles
• GET /enterprises est le premier flux enterprise migre vers le backend
• fetchById() et plusieurs mutations entreprises sont encore directes vers Supabase cote frontend

Convention d'implementation

Quand un flux est migre du frontend vers le backend:

1. conserver le comportement metier existant
2. documenter le flux dans docs/domains/
3. ajouter ou adapter des tests unitaires
4. ajouter ou adapter des tests d'integration backend si le flux est protege par des guards
5. ne pas supprimer le flux frontend existant tant que le nouveau flux n'est pas verifie

Regle de contribution obligatoire

Pour toute modification non triviale, une IA ou un developpeur doit verifier si les elements suivants doivent etre ajoutes ou mis a jour:

1. tests unitaires
2. tests d'integration
3. documentation technique ou metier dans docs/
4. documentation Swagger si une API backend est concernee
5. commentaires de code sur les classes ou methodes uniquement quand l'intention n'est pas evidente

Cette verification est obligatoire, meme si tous les elements ne changent pas au final.

Attendus minimaux par type de changement

Changement metier backend

• mettre a jour les tests unitaires
• mettre a jour les tests d'integration si la route ou les guards sont concernes
• mettre a jour la documentation de domaine
• ajouter ou mettre a jour les commentaires uniquement si le code devient difficile a lire

Changement d'API backend

• mettre a jour les tests unitaires ou d'integration selon le niveau du changement
• mettre a jour la documentation Swagger
• mettre a jour docs/architecture/ ou docs/domains/ si le comportement change

Changement frontend sur un flux migre

• verifier si la documentation de domaine doit etre mise a jour
• verifier si les tests backend restent representatifs du comportement attendu

Convention de commentaires

• ne pas ajouter de commentaires triviaux
• ajouter un commentaire court sur une methode ou une classe si la regle metier, le filtrage, ou la raison de conception n'est pas evidente
• quand une contrainte existe pour eviter une regression metier, preferer un test en premier, puis un commentaire court si necessaire

Convention de documentation

Pour chaque domaine metier important, la documentation doit decrire:

• les regles de visibilite
• les roles impliques
• les flux frontend et backend
• les etats de migration
• les risques connus

Prochaines etapes probables sur enterprises

• migrer fetchById() vers le backend
• migrer les mutations create, update, remove
• clarifier la place des policies RLS par rapport aux regles backend