Composants

Organisation

src/components/
  ui/        primitives partagées (button, input, badge, dialog, table, …)
  layout/    coquille applicative (app-shell, client-shell, navbars, …)

Les écrans d’une feature vivent dans features/<module>/components/ (voir src/features/README.md), les composants génériques et réutilisables dans src/components/.

Règles

1. Ne pas réécrire une primitive : composer avec les composants de components/ui (props className via cn de #/lib/utils).
2. Un composant de layout n’embarque pas de logique métier — il reçoit ses données par props ou hooks d’état (useAuth).
3. L’accessibilité est de base : Label lié à l’input via htmlFor/id, aria-label sur les contrôles icônes, role="alert" sur les erreurs globales de formulaire.
4. Les textes utilisateur sont en français, écrits en dur dans le composant (pas de couche de traduction).

Accents (Tailwind)

• Classes utilitaires Tailwind 4 + variables CSS définies dans styles.css (.border, bg-card, text-muted-foreground, text-destructive, …).
• Éviter les couleurs hexadécimales en dur : utiliser les tokens du thème.
• Statuts : <Badge variant="success|warning|info|danger|neutral"> (components/ui/badge.tsx) — plus de bg-[#hex] text-white.
• En-têtes de page, tableaux, modales, états vides : primitives page-header, table, dialog, empty-state dans components/ui/.
• Système complet : Design system.

À ne pas faire

• ❌ Copier/coller un composant de ui/ pour le modifier à la volée dans une feature.
• ❌ Générer un composant « fourre-tout » (props any, toutes responsabilités).
• ❌ Afficher des données sans état de chargement/erreur (patterns Query).