cadjelmedal-blip/unvibe

Que fait unvibe ?

Cette compétence transforme une interface qui semble générée en une interface qui paraît conçue. Elle n'invente pas un nouveau style : elle applique un catalogue de petits détails mesurés que les interfaces professionnelles partagent et que les interfaces générées ignorent, le tout adapté aux couleurs du projet. Elle a été extraite d'un véritable travail de polissage de deux jours sur une SaaS en production (references/case-study.md) ; chaque règle existe parce que l'enfreindre a été remarqué.

Mappez vos couleurs, conservez les nombres. Les proportions (rayons, espacements, tailles, durées, poids) portent la qualité. Les couleurs sont la seule chose à adapter.

Avant de commencer

1. Lisez references/tells.md (ce qui rend une interface générée, avec le remplacement pour chaque élément).
2. Lisez les tokens de design du projet et tout document de conception. Remplissez le tableau de tokens dans references/porting.md.
3. Demandez au propriétaire quels écrans le dérangent le plus et ce qu'il aime. Conservez ce qu'il aime ; ne supprimez jamais ce qu'il comprend (« J'adore ça, c'est compréhensible — améliorez juste la mise en forme » signifie restyler, pas couper).
4. Notez la stack : React ou non, Tailwind 3/4 ou CSS pur, une bibliothèque de composants existante ou non, une bibliothèque headless (React Aria) ou non.

Le flux de travail

Phase 1 · Fondations (un seul passage, toute l'application)

Tokens (assets/css/unvibe.css section 1, mappés), éléments natifs restants dans la couleur de la marque, nombres tabulaires, mouvement réduit, courbes de mouvement. Puis les mots : supprimez les libellés en majuscules tracées, les emojis dans les titres, les glyphes ✓ dans les badges, les points d'exclamation (catalogue §0–§1). Rapide, visible, zéro risque.

Phase 2 · Contrôles (un seul passage, toute l'application)

Boutons avec relief et un seul bouton primaire par écran (§2) · champs remplis, une hauteur par ligne (§3) · menus réels au lieu de menus natifs (§4 ; auditez d'abord chaque site d'appel, references/pitfalls.md) · interrupteurs pour chaque oui/non, cartes interrupteurs pour les cas importants, cartes radio pour les choix visibles, tags (§6) · contrôles segmentés dont la pastille glisse (§5).

Phase 3 · Reconstruire les écrans les plus visibles sur des références

Choisissez les 3 à 5 écrans que les gens voient le plus et reconstruisez chacun sur le modèle professionnel le plus proche, mesuré (references/method.md) : vue d'ensemble analytique → tuiles KPI (§9) ; écran IA → fil de discussion agent (§12) ; activité → flux (§11) ; paramètres → lignes (§7) ; listes volumineuses → grille de données (§10) ; tâches longues → journal (§13) ; dates → préréglages + deux mois (§15).

Phase 4 · La passe générale

Chaque écran restant reçoit les mêmes détails : une bande d'en-tête de tableau, un style de champ, un menu, un style de badge, des encadrés sous forme de zones remplies, des listes sous forme de blocs encadrés, la même hauteur de filtre sur chaque page de liste (§8, §10, §16). L'incohérence entre écrans frères est elle-même un signe révélateur.

Phase 5 · Prouvez-le

Captures avant/après de la production par rapport à la branche avec scripts/capture.mjs et une page côte à côte avec scripts/compare.mjs. Ne conservez que les paires dont la différence est évidente au premier coup d'œil. Effectuez ensuite la passe complète de non-régression dans references/verification.md avant de pousser.

Règles d'or

1. Sélection ≠ action. Une couleur calme marque ce qui est choisi ; la couleur forte de la marque est réservée à l'action primaire unique par écran.
2. Survol ≠ sélection. Le survol est neutre ; la sélection est une teinte pâle plus une coche.
3. Trois surfaces : toile, blanc pour ce qui flotte, un remplissage plus foncé enfoncé pour les champs et les tuiles.
4. Pas de capitales tracées, pas d'emojis dans les titres, pas de glyphes de coche, pas de barres latérales colorées.
5. Chaque contrôle sur une ligne partage la même hauteur et le même remplissage.
6. Chaque oui/non est un interrupteur ; les cases à cocher sont pour les listes et les consentements.
7. Un paramètre est une ligne : ce qu'il fait à gauche, le contrôle à droite ; les lignes verrouillées disent pourquoi en gris.
8. Les nombres sont en 24/34 dans les tuiles remplies avec un puce d'icône et une pastille delta colorée selon le sens (un coût qui augmente est en rouge).
9. Une bande d'en-tête de tableau partout, en casse de phrase, dans un cadre de 16px ; les lignes sélectionnées reçoivent une barre intérieure de 3px.
10. Les réponses IA sont du texte dans un fil de discussion, avec ce qui a été lu et le temps écoulé réel ; jamais d'étapes factices.
11. L'animation suit un changement d'état, jamais un survol ; l'appui échelle à .985 ; les menus et les modales arrivent.
12. Jamais un nombre deviné, jamais un contrôle décoratif. Si les données manquent, dites « Non déterminé » ; si un champ ne fait rien, supprimez-le.
13. Faites les écrans frères dans la même passe.
14. Montrez uniquement les différences visibles, et prouvez qu'il n'y a pas de régression.

Ce que contient cette compétence

Chemin	Utilisez-le pour
references/catalogue.md	chaque détail avec ses valeurs exactes (§0 fondations → §17 jamais-list)
references/tells.md	les signes révélateurs d'interface générée et leurs remplacements
references/method.md	redesign guidé par référence : choisir, mesurer, mapper, reconstruire, prouver
references/pitfalls.md	les bugs que le polissage apporte (menus dans les modales, clés en double, noms perdus, couches CSS, tests)
references/verification.md	avant/après et la passe de non-régression
references/porting.md	mappage de tokens, Tailwind 3/4, autres frameworks, ordre de rétrofit, étapes sombres
references/case-study.md	le vrai passage dont cela vient, avec les mots du propriétaire
assets/css/unvibe.css	la feuille de style prête à l'emploi (CSS pur, classes uv-, tokens sur :root)
assets/react/*	Select, NativeSelect (remplacement de <select>), Switch/SwitchCard, SettingsRow, Accordion, NumberField, Segmented (pastille glissante), RollingNumber, ThinkingIndicator, DateRangePicker, useFlipToFit
scripts/capture.mjs	captures headless Chrome des éléments [data-shot], ou écrans d'application avec vérification console
scripts/compare.mjs	la page côte à côte avant/après
demo/index.html	chaque motif, avant et après, sur des données fictives

Utilisation des ressources

• CSS : copiez assets/css/unvibe.css dans le projet, mappez la section 1 sur les tokens du projet, importez-la après les styles de base. Utilisez les classes telles quelles ou traduisez-les dans les noms de classe du projet (conservez les valeurs).
• React : copiez les composants dont vous avez besoin ; ils dépendent de react-aria-components (et de @internationalized/date pour la plage de dates). Ils ne portent pas de classes Tailwind.
• Bibliothèque de composants existante : restylez ses parties avec les nombres du catalogue plutôt que de la remplacer.

Ce qu'il faut rendre

1. La page avant/après (uniquement les différences visibles).
2. Une courte liste de ce qui a changé, par famille, et les écrans touchés.
3. Le rapport de non-régression : ce qui a été audité, quelles interactions ont été testées dans un navigateur, état de la console, tests, construction. Dites clairement ce qui n'a pas été vérifié.