sokko-g/DESIGN_SYSTEM.md

Nebula Design System - Sokko G

Ce document est la reference visuelle du projet Sokko G. Toute nouvelle interface doit rester coherente avec le theme Nebula Command actuel et les controles du Nebula Design System.

1. Vision

Sokko G est une webapp gaming locale, pensee pour rester ouverte sur un second ecran pendant une session. L'interface doit etre sombre, lisible, dense sans etre surchargee, et suffisamment immersive pour evoquer une ambiance nebuleuse premium.

Principes directeurs :

• priorite a la lisibilite pendant de longues sessions ;
• pas de style RGB agressif ;
• violet et indigo pour la profondeur et les interactions ;
• dore pour les accents de hierarchie, les eyebrows, les focus et certaines bordures ;
• cyan conserve comme token secondaire, mais non dominant ;
• les effets lumineux doivent rester contenus.

2. Tokens

Les tokens source sont dans website/src/styles/_tokens.scss. Ne pas dupliquer les couleurs dans les composants.

Couleurs principales :

--color-bg-page: #070913;
--color-bg-deep: #050711;
--color-bg-sidebar: #0b0e1b;
--color-bg-surface: #101426;
--color-bg-surface-alt: #151a30;
--color-bg-elevated: #1a2038;
--color-bg-hover: #202745;

--color-primary: #8b5cf6;
--color-primary-hover: #9f7aea;
--color-primary-active: #7347dc;
--color-primary-soft: rgba(139, 92, 246, 0.14);
--color-primary-border: rgba(139, 92, 246, 0.45);

--color-accent-gold: #f6c453;
--color-accent-cyan: #22d3ee;
--color-accent-pink: #d946ef;
--color-accent-indigo: #6366f1;

--color-text-primary: #f5f7ff;
--color-text-secondary: #b4bdd3;
--color-text-muted: #7d879f;

--color-border: rgba(150, 165, 205, 0.14);
--color-border-hover: rgba(150, 165, 205, 0.28);

Rayons :

• --radius-sm: 6px
• --radius-md: 10px
• --radius-lg: 14px
• --radius-xl: 18px
• --radius-pill: 999px

Espacements :

• --space-1: 0.25rem
• --space-2: 0.5rem
• --space-3: 0.75rem
• --space-4: 1rem
• --space-5: 1.25rem
• --space-6: 1.5rem
• --space-8: 2rem
• --space-10: 2.5rem
• --space-12: 3rem

Animations :

• --duration-fast: 120ms
• --duration-normal: 180ms
• --ease-standard: cubic-bezier(0.2, 0.8, 0.2, 1)

3. API Publique NDS

Le Nebula Design System expose ses primitives publiques avec une classe de famille et des attributs data-*.

Règles :

• la classe décrit uniquement la famille : nds-button, nds-icon-button, nds-input, nds-range, nds-select, nds-select-trigger, nds-time, nds-textarea, nds-inline-input, nds-switch, nds-radio-button-group, nds-checkbox, nds-quantity-stepper, nds-list-row, nds-large-icon-picker-trigger, nds-event-surface, nds-scrollbox ;
• les patterns transverses utilisent aussi une classe de famille : nds-panel, nds-card, nds-card-cover, nds-card-body, nds-card-actions, nds-tool-panel, nds-toolbar, nds-section-heading, nds-page-hero, nds-badge, nds-chip, nds-empty-state, nds-inline-notice, nds-progress, nds-filter-panel, nds-reorder-indicator, nds-modal, nds-modal-backdrop, nds-modal-footer, nds-drawer-panel, nds-drawer-resize-handle, nds-popover, nds-toast-stack, nds-toast ;
• les variations passent par attributs : data-size, data-variant, data-edge, data-border, data-axis ;
• la page /design-system affiche aussi data-state comme axe de comparaison visuelle des états ;
• data-size accepte seulement les tailles prévues par la famille (xs, sm, md, lg, xxs, micro selon le contrôle) ; les checkboxes utilisent md 20 px, sm 18 px et xs 14 px ;
• data-variant couvre les intentions visuelles partagées : primary, secondary, ghost, dashed, danger et les variantes spécialisées documentées dans /design-system, dont panel-toggle pour les boutons icones accolés à un panneau, icon-picker pour les triggers de sélection compacts à icône, interactive|tool|filter|modal pour les surfaces, et neutral|gold|success|warning|danger pour les badges, notices et progress ;
• data-edge="left|middle|right|top|center|bottom|top-left|top-right|bottom-right|bottom-left" décrit la position d'un bouton dans un groupe ou contre un bord, et ajuste uniquement les coins ;
• data-border="joined" masque les bordures de jonction déduites depuis data-edge ;
• data-border="none" masque toutes les bordures sans changer la taille, le fond, le hover ou l'état actif ;
• data-axis="horizontal|vertical" reste réservé aux composants dont l'axe est métier, comme nds-scrollbox et nds-reorder-indicator ;
• les boutons icônes de réorganisation utilisent nds-icon-button avec data-variant="secondary" et une classe métier contenant drag-handle ; le curseur grab/grabbing est alors géré par le NDS ;
• les états fonctionnels restent portés par le HTML et l'application : disabled, aria-pressed="true", .active, .is-active.

Exemples :

<button class="nds-button" data-size="xs" data-variant="primary" data-edge="left" data-border="joined">Ajouter</button>
<button class="nds-icon-button" data-size="sm" data-variant="danger" aria-label="Supprimer"></button>
<button class="nds-icon-button" data-variant="panel-toggle" data-edge="right" data-border="joined" aria-pressed="true" aria-label="Pages"></button>
<select class="nds-select" data-size="sm"></select>
<button class="nds-select-trigger" data-size="sm" aria-pressed="false"></button>
<article class="nds-card" data-variant="interactive"><div class="nds-card-cover"></div><div class="nds-card-body"></div></article>
<section class="nds-panel"></section>
<span class="nds-badge" data-variant="gold">Rare</span>
<p class="nds-inline-notice" data-variant="danger">Erreur compacte</p>

Les anciennes classes de variation nds-*--* ne doivent plus etre ajoutees. Les anciennes classes globales .button, .primary, .danger, .ghost et .import-button ne sont plus des APIs visuelles publiques : utiliser nds-button / nds-icon-button avec data-variant. Dans les outils, les classes métier peuvent rester pour le layout, la grille, les largeurs, le positionnement et les états fonctionnels. Le style visuel d'un contrôle générique doit venir de website/src/styles/design-system/_controls.scss ou de l'API publique website/src/styles/design-system/_attributes.scss.

Surfaces Et Patterns

Les surfaces NDS couvrent les patterns transverses, pas les composants metier complets.

• nds-panel : panneau de lecture non repete, sans hover par defaut.
• nds-card : element repete ou ouvrable ; utiliser nds-card-cover, nds-card-body et nds-card-actions quand la structure cover/contenu/actions est necessaire.
• nds-tool-panel : surface de travail d'outil, plus discrete qu'une card, avec accent dore bas/droite.
• nds-filter-panel : filtres verticaux ou horizontaux via data-variant="vertical|horizontal-compact|horizontal-menu" ; sans attribut, le rendu vertical historique est conservé.
• nds-empty-state : etat vide court, avec action optionnelle.
• nds-inline-notice : feedback compact inline, avec data-variant="info|success|warning|danger".
• nds-progress : rail de progression (taille md/défaut : 8 px, sm : 4 px, via data-size) ; le remplissage est le premier span enfant ou .nds-progress-bar.
• nds-modal, nds-drawer-panel, nds-popover, nds-toast : surfaces d'overlay. Le comportement React reste gere par les composants existants.

Les classes metier existantes peuvent coexister avec ces classes pendant la migration. Quand une classe metier reste necessaire, elle doit porter le layout, la grille ou le positionnement, pas recreer les fonds, bordures, hovers et focus partages.

4. Fond Nebula

Le fond global est defini dans website/src/styles/_nebula.scss.

Regles :

• fond de page tres sombre avec nebuleuses violettes, indigo, rose et leger accent dore ;
• etoiles statiques, reparties de facon non alignee ;
• pas d'animation permanente de fond ;
• le contenu reste prioritaire sur l'ambiance.

Ne pas ajouter d'orbes decoratifs supplementaires. Si une section a besoin de profondeur, utiliser les fonds semi-transparents et les bordures existantes.

5. Typographie

Police principale :

font-family: Inter, "Segoe UI", system-ui, -apple-system, BlinkMacSystemFont, sans-serif;

Regles :

• pas de letter-spacing negatif ;
• corps de texte entre 14 et 16 px ;
• titres de cartes/modules entre 15 et 18 px ;
• titres de page avec clamp deja defini dans _home.scss ;
• paragraphs limites visuellement, pas de longs blocs sans respiration ;
• les <i> doivent etre en italique, pas utilises comme gris decoratif.

6. Heroes

Les heroes de la page d'accueil et des pages jeux utilisent le meme style via .hero et .game-hero.

Sur la page d'accueil, le hero conserve deux colonnes en fenêtre large. Jusqu'à 1024px, le groupe des deux statistiques passe sous le texte et les actions, aligné à gauche. Les deux cartes restent côte à côte tant que leur largeur le permet.

L'action principale dépend des données locales : sans toolbox, « Créer ma première toolbox » ouvre directement la création guidée ; dès qu'une toolbox existe, « Voir mes toolboxes » mène à la liste. « Voir les jeux » reste l'action secondaire.

Caracteristiques :

• fond commun nebula sombre ;
• overlay sombre pour garder le texte lisible ;
• bordure gradient subtile dore/violet clair ;
• border-radius: var(--radius-xl) ;
• box-shadow: var(--shadow-md) ;
• les pages jeux peuvent fournir une image de hero via --game-hero-image.

Les pages jeux doivent heriter du hero commun. Une image de jeu peut enrichir le hero quand elle reste lisible avec l'overlay commun ; les cards et covers restent les emplacements prioritaires pour les images inspectables.

7. Cards

Les cards representent les elements repetes : toolboxes, jeux, categories, monstres, faune.

Style courant :

• fond sombre rgba(16, 20, 38, 0.88) ;
• bordure gradient fine, majoritairement doree avec une petite presence cyan ;
• support optionnel de corner-shape: scoop quand le navigateur le supporte ;
• pas de translation au hover pour les cards principales ;
• hover en violet/violet clair avec glow contenu.

La bordure haute/basse interne d'une cover doit rester doree quand elle separe une image du contenu.

Les surfaces de cards reutilisent les mixins card-surface, card-surface-hover et card-cover-divider depuis website/src/styles/design-system/_surfaces.scss.

Eviter les cards dans des cards. Les sections de page doivent rester des layouts ou panneaux, pas des empilements de cartes decoratives.

8. Modules Toolbox

Les modules sont des panneaux de travail, pas des cards classiques.

Style courant :

• fond semi-transparent rgba(16, 20, 38, 0.42) ;
• bordure neutre tres discrete ;
• accent dore leger en bas/droite ;
• hover violet/violet clair moins intense que les cards ;
• pas de mouvement au hover ;
• contenu interne au-dessus des pseudo-bordures via z-index.
• l'en-tête suit toujours l'ordre poignée de déplacement, icône, titre, switch de scroll éventuel, ajout éventuel, Configuration, suppression, chevron ; le titre peut se réduire mais les actions ne s'étirent pas ;
• le chevron de repli reste tout à droite ; l'état replié conserve l'en-tête et peut afficher le panneau Configuration sans révéler le contenu métier ;
• l'engrenage Configuration ouvre un panneau pleine largeur sous l'en-tête, nommé par aria-controls / aria-expanded. Il regroupe conditionnellement Espace, Guide, réglages propres à l'outil et Données (import/export) ; ouvrir l'ajout ferme Configuration et réciproquement ;
• dans Configuration, Espace et Données partagent la première ligne en deux colonnes. Espace affiche directement le sélecteur compact dont le placeholder décrit l'action. Les réglages propres à l'outil et la liaison Guide occupent toute la largeur en dessous ; si Espace est absent, Données utilise toute la première ligne ;
• le panneau Configuration reste une surface intégrée à l'outil : un seul contour discret, des sous-sections sans effet de carte imbriquée, séparées uniquement par des filets légers, avec libellés et contrôles compacts ;
• en fenêtre compacte, l'en-tête se répartit sur deux lignes et les sections/champs de Configuration passent en une colonne, dans l'ordre Espace, Données puis réglages spécifiques.

Le mot visible cote utilisateur est outil, pas module. Le terme module reste acceptable uniquement dans le code.

Les outils qui gèrent une collection affichent un message vide compact et discret tant qu'aucun élément n'existe. Ce message réutilise le traitement visuel en pointillés du planificateur de tâches, sans remplacer les états vides métier plus détaillés déjà présents. Lorsqu'un outil vient d'être ajouté, la page défile doucement jusqu'à son panneau afin qu'il reste immédiatement visible, y compris s'il a été inséré hors cadre.

Outils En Deux Colonnes

Les outils avec controles a gauche et resultats a droite doivent reutiliser les classes generiques tool-split-*.

Exemples actuels :

• calculateur ;
• timer.

Regles :

• ratio de base 35 / 65 entre controles et resultats ;
• lorsque son outil mesure au plus 820 px de large, le calculateur empile la saisie au-dessus de la liste, avec Calcul/Actuel à gauche et Résultat à droite dans la carte ; sous 560 px, cette carte revient à une seule colonne ;
• panneau gauche compact, sans hauteur artificielle inutile ;
• panneau droit scrollable uniquement quand l'utilisateur active le switch dedie ;
• hauteur scrollable cible : environ 450 px ;
• boutons reset, copie, scroll et tri alignes en haut a droite du panneau de resultats ;
• edition inline des libelles plutot que boutons ou alertes navigateur ;
• styles specifiques autorises uniquement pour la logique propre a l'outil.

Champs Mixtes A Badges

Les champs texte qui remplacent une valeur brute par un badge visuel doivent utiliser le pattern MixTagsInput.

Regles :

• le champ reprend le principe du mode mix Tagify : zone contentEditable et badges contentEditable=false ;
• la valeur sauvegardee reste une string normale, le badge est une representation atomique de cette valeur ;
• un badge est atomique : le curseur peut se placer avant ou apres, et la suppression retire toute la valeur associee ;
• la copie d'une selection contenant un badge doit copier la valeur brute, pas seulement le libelle visible.
• utiliser size="small" pour les champs compacts de 36 px, plutot que de deduire la taille depuis une classe metier.

Timer

Le timer combine chronometre a etapes et comptes a rebours multiples.

Regles UI :

• tabs compactes avec icones uniquement et tooltips ;
• chronometre avec centiemes visibles en plus petit dans le timer principal ;
• les temps sauvegardes gardent une taille uniforme ;
• compte a rebours sans centiemes ;
• types visibles : Duree, Heure precise, Pattern horaire, Intervalle ;
• les libelles au-dessus des champs hh:mm:ss restent accessibles en sr-only, mais ne sont pas visibles ;
• les boutons de controle utilisent les icones play-circle, pause-circle, record-circle, stop-circle, refresh, sort-time, scrollable.
• pour Heure precise et Intervalle, le refresh inline est un toggle compact de repetition automatique ; il est bloque si la frequence est inferieure a 5 minutes.
• le formulaire Intervalle affiche deux champs hh:mm:ss compacts : duree de repetition et depart optionnel ; un depart vide signifie Maintenant.
• les invalidations du formulaire countdown s'affichent en notice inline rouge compacte, portée par useDraftForm.

Alertes timer :

• switch a 3 etats par compte a rebours : aucune alerte, alerte si la toolbox est visible, alerte globale site ;
• le garde-fou ne se base pas sur le temps restant, mais sur la frequence configuree ;
• le garde-fou bloque uniquement les comptes a rebours recurrents (Pattern horaire, Intervalle) si la repetition est inferieure a 5 minutes ;
• un Pattern horaire comme X:24:X cible hh:24:00 et se repete toutes les heures.

Calendrier

Le calendrier est un outil de planification visuelle, distinct du timer.

Regles UI :

• l'outil propose une grille hebdomadaire jours x creneaux de 30 minutes ou une grille mensuelle datée avec navigation par mois ;
• les 7 jours de la semaine doivent rester visibles sans scroll horizontal ; seul le scroll vertical sert a parcourir les heures ;
• le formulaire compact est masque par defaut ; il s'ouvre via le bouton + du module ou par clic sur une entree ;
• le bouton annuler ferme le formulaire, et desactiver le bouton + le ferme aussi quand il sert a creer une entree ;
• l'ajout manuel et la selection de cellules alimentent le meme formulaire compact quand il est ouvert ;
• les champs horaires hebdomadaires restent courts, acceptent un pas de 5 minutes, et les alertes d'echeance utilisent des checkboxes 10 min, 5 min et Au debut et pendant ;
• les evenements sont affiches comme des blocs colores dans la grille, sans boutons internes et sans dominer la palette globale ;
• quand deux evenements se chevauchent sur un meme jour, ils se partagent la largeur de la colonne ; la V1 gere visuellement jusqu'a deux evenements simultanes ;
• la suppression d'une entree se fait dans le formulaire d'edition ;
• la copie et le collage d'entree utilisent les raccourcis clavier Ctrl+C et Ctrl+V ;
• le mini-switch repetable est actif par defaut ; une entree non repetable est supprimee quand son echeance de la semaine courante est terminee ;
• les alertes reutilisent le switch a 3 etats du timer : aucune, toolbox visible, globale site ;
• le choix de couleur reprend le pattern de palette compacte du Bloc Note ;
• le choix initial s'affiche dans l'outil lui-meme ; la vue mensuelle affiche le nom du mois et des boutons mois precedent / courant / suivant ;
• en vue mensuelle, la règle mensuelle peut cibler le numero du jour ou le rang du jour de semaine via un switch 2 états compact, indépendamment du choix de répétition.
• en vue mensuelle, les dates de debut et de fin utilisent un champ compact qui ouvre un mini-calendrier avec navigation ;
• en vue mensuelle, le formulaire distingue date de debut et date de fin ; une plage d'un seul jour utilise la meme valeur pour les deux ;
• en vue mensuelle, la répétition propose Aucune, Chaque semaine, Chaque mois; Chaque semaine est indisponible pour la règle Numéro du jour ;
• en vue mensuelle, la suppression d'une entree repetee distingue suppression de l'occurrence affichee et suppression de toute la serie ;
• en vue mensuelle, un clic-glisse sur plusieurs cellules preconfigure la plage de jours du formulaire ;
• en vue mensuelle, les champs horaires ne sont pas affiches ; les evenements couvrent des journees completes ;
• en vue mensuelle, les evenements multi-jours s'affichent comme une barre horizontale et ne sont pas dupliques dans chaque cellule ;
• les vues hebdomadaire et mensuelle affichent un indicateur discret du moment actuel.
• en vue hebdomadaire, un switch standard peut masquer les longues plages horaires vides ; la tranche masquée reste indiquée dans la grille, pas dans un texte qui déborde de la colonne horaire.
• le calendrier supporte l'import/export texte via la section Données du panneau Configuration, pour les vues hebdomadaire et mensuelle.

Arbre D'objectifs

L'arbre d'objectifs représente des chaînes de craft, de farm ou de prérequis sous forme d'arborescence dépliable.

Regles UI :

• utiliser le ratio tool-split-* 35 / 65 quand l'édition est visible ;
• le panneau gauche édite uniquement le nœud sélectionné via les onglets Base, Contenu quand le type le nécessite, et Avancé ;
• le panneau gauche ne doit pas porter les boutons d'ajout racine ou sous-étape ; l'ajout racine se fait via un bouton dans le schéma, long en haut en mode vertical et haut/étroit à gauche en mode horizontal, et les sous-étapes via le bouton + des cards ;
• l'onglet Base contient le type Étape, Texte, Calculateur ou Checklist, puis le titre ; pour une étape, il expose aussi l'icône et la couleur d'icône ;
• l'onglet Contenu est réservé aux types Texte, Calculateur et Checklist ; les étapes ne doivent pas afficher cet onglet ;
• l'onglet Avancé contient le reset par nœud ; pour une étape seulement, il ajoute les sections Quantité et Progression, avec un switch où l'état actif correspond à la progression automatique par les enfants ;
• le switch de progression expose une aide courte sous le contrôle afin de différencier calcul automatique et mise à jour manuelle ;
• une étape dont tous les enfants directs ont une cible de 1 se comporte par défaut en mise à jour manuelle, sauf choix explicite du mode automatique ;
• le panneau droit reste la source visuelle principale, avec branches compactes, liaisons SVG mesurées et barres de progression ;
• le panneau droit expose un switch avec icône rotate pour alterner entre organisation horizontale et verticale ; l'orientation est persistée par outil ;
• les liaisons entre nœuds doivent être dessinées par une couche dédiée basée sur les positions réelles des cartes, pas par des pseudo-éléments CSS dépendants de largeurs fixes ;
• une card peut avoir plusieurs prérequis visibles : elle garde un parent principal pour le placement, mais des liaisons supplémentaires peuvent converger vers elle ;
• tous les enfants restent rendus comme des nœuds d'organigramme, même sans sous-enfant, afin que l'ajout ultérieur d'un enfant ne change pas brutalement la structure ;
• l'ouverture d'une branche doit replier les branches sœurs du même niveau et leurs descendants, afin de limiter la largeur déployée en mode deux colonnes ;
• quand une branche ouverte contient un objectif à plusieurs parents, les branches nécessaires aux autres parents visibles doivent rester ouvertes afin que la convergence reste compréhensible ;
• les nœuds affichent une icône principale et révèlent leur titre via Tooltip, afin de garder une lecture proche organigramme ;
• les types Texte, Calculateur et Checklist sont des mini-contenus internes au nœud : leurs lignes doivent être visibles directement dans la carte, avec une zone d'ajout compacte ;
• les cards de liste doivent laisser leur preview interne occuper la largeur disponible de la card, sans largeur fixe plus étroite que la carte ;
• ces mini-contenus ne remplacent pas les sous-objectifs : les sous-objectifs restent des enfants d'organigramme séparés ;
• les lignes Checklist suivent le comportement de l'outil checklist : cible 1 affiche une checkbox ; cible supérieure à 1 affiche une quantité avec contrôles - et + ;
• les lignes Calculateur exposent une formule et un résultat ; la variable base référence la cible calculée du parent direct ;
• les cards peuvent exposer des actions secondaires au hover/focus, notamment modification et suppression, sans les rendre visibles au repos ;
• le bouton + d'une card ajoute toujours une sous-étape ; les nœuds Texte, Calculateur et Checklist exposent un bouton long dédié sous leur preview pour ajouter une entrée interne ;
• le bouton long d'entrée interne doit avoir une tooltip explicite, car son libellé visible reste volontairement compact ;
• l'accent de couleur d'un nœud doit s'appliquer à toute la card, y compris au hover, sans bordure latérale d'une couleur différente ;
• la card sélectionnée en mode édition doit être clairement identifiable par un contour et un halo plus présents que l'état sélectionné en lecture ;
• le drag & drop des nœuds doit afficher son indicateur selon l'orientation de la liste : gauche/droite en horizontal, haut/bas en vertical ;
• les actions de nœud utilisent des boutons icônes : ajout, repli, suppression, déplacement ;
• le bouton de déplacement doit rester clairement visible sur les cards compactes, notamment les nœuds Texte et Checklist ;
• la progression d'un parent doit rester agrégée et lisible sans afficher une formule détaillée dans la carte ;
• en panneau latéral ou fenêtre compacte, l'arbre passe en une colonne sans scroll horizontal.

Combos

L'outil Combos affiche des inputs de manettes et clavier sous forme de tokens visuels compacts.

Regles UI :

• les touches simples sont rendues en HTML/CSS, pas en fichiers SVG distincts ;
• les formes specifiques peuvent utiliser de petits SVG inline ou des formes CSS si le HTML seul devient ambigu ;
• les couleurs de boutons restent des accents localises et ne doivent pas dominer le panneau ;
• les sequences longues doivent revenir a la ligne sans agrandir la largeur de l'outil ;
• l'edition utilise une palette guidee pour les manettes et une palette avec saisie courte pour clavier/souris ;
• l'ajout par clic cree des etapes successives par defaut, sans bouton dedie de nouvelle etape ;
• le clavier utilise AZERTY par defaut et propose un switch QWERTY ;
• le mode simultane doit etre volontaire, via switch ou depot d'une touche dans une etape existante ;
• les categories sont regroupees automatiquement depuis le champ categorie du combo.

Bloc Note Riche

Le Bloc Note utilise une edition directe en contentEditable, sans mode preview separe.

Regles UI :

• pages multiples accessibles par un bouton icone pages pose en absolute sur la bordure gauche de l'outil ;
• le bouton ouvre toujours un menu deroulant de pages, y compris en page toolbox complete, avec deroulement de gauche vers la droite ;
• le renommage d'une page passe par un bouton edition qui active l'edition inline du titre ;
• toolbar compacte en haut de l'outil ;
• boutons courts pour gras, italique, souligne, barre, titre et listes ;
• le paragraphe est le style par defaut et n'a pas de bouton dedie ;
• les types de listes sont regroupes dans un dropdown compact ;
• couleurs texte et surlignage regroupees dans un dropdown unique avec icone arc-en-ciel et libelles de categories ;
• date de derniere modification affichee en pied d'outil, sans prendre le dessus sur le contenu ;
• switch de stockage des dessins en pied d'outil, avec icone sauvegarde et etat actif ;
• placeholder integre dans la surface d'edition quand la note est vide ;
• le HTML persiste doit rester nettoye via allowlist, jamais via HTML libre.

Mémos

L'outil Mémos sert aux informations courtes type post-it.

Regles UI :

• cartes compactes, non imbriquees, avec accent couleur localise ;
• edition directe du texte court ;
• zone de texte en hauteur automatique, sans resize manuel ni scrollbar interne ;
• palette de couleurs compacte reprenant les swatches du Bloc Note ;
• la creation de mémo est masquee par defaut et s'ouvre via le bouton + du header d'outil ;
• réorganisation des cartes par poignée de drag & drop compacte ;
• bande deroulante visible uniquement quand elle est active et qu'au moins un mémo ou une alerte de planificateur existe ; elle affiche tous les mémos dans l'outil, peut intégrer les tâches non effectuées proches du reset depuis un ou tous les planificateurs de la même toolbox, et reste fixée en bas des pages complètes de cette toolbox ainsi que des pages du jeu qui lui est associé ;
• la bande fixe laisse le contenu verticalement accessible et suit la largeur disponible entre la sidebar et le bord droit.

Calque De Dessin

Les annotations dessinees utilisent un canvas transparent superpose au contenu annote.

Regles UI :

• le calque est inactif par defaut pour laisser le contenu editable ;
• en mode dessin, les interactions pointer sont capturees par le canvas ;
• les controles de dessin sont regroupes dans un panneau reutilisable vertical, colle a droite de la surface annotee ;
• seuls les controles directement lies au dessin sont affiches quand le mode dessin est actif ;
• les controles restent compacts : gommer, annuler, effacer, couleur et epaisseur via dropdowns ;
• le mode temporaire privilegie le griffonnage de session et utilise sessionStorage ;
• le mode permanent suit le stockage IndexedDB de l'outil ;
• pour les surfaces scrollables, le canvas suit le contenu complet plutot que le viewport visible.
• sur les annotations d'images, les traits utilisent des coordonnees en pourcentage et restent visibles dans l'aperçu reduit ; l'edition se fait uniquement en plein ecran et le switch de sauvegarde reste disponible dans la barre de dessin.

8. Tabs Et Switchs

Dropdowns Compacts

Les menus flottants compacts d'icones, couleurs, epaisseurs ou actions rapides doivent reutiliser CompactDropdown.

Regles :

• conserver un trigger compact, idealement icone seule avec tooltip ;
• fermer au clic exterieur, a Escape, a la selection et quand le focus sort du menu ;
• garder le contenu interne libre pour supporter grilles d'icones, swatches, libelles de categories ou choix d'epaisseur ;
• reutiliser les classes visuelles existantes du contexte quand le menu appartient a un outil precis.

Tabs :

• utiliser le composant commun quand un outil doit alterner entre plusieurs modes ;
• icones seules quand les labels sont evidents ou fournis en tooltip ;
• etat actif sobre : bordure doree, fond legerement dore/violet, pas de gros glow.

Switchs :

• les switchs binaires utilisent l'icone a gauche et le rail a droite quand ils controlent un mode technique comme scrollable ;
• les switchs a plusieurs etats doivent rester compacts, avec icones et tooltips ;
• les etats desactives doivent etre clairement attenues et sans etat actif dore.

9. Panneaux De Section

Les grandes sections non repetitives, comme le dialogue d'origine et les sections de presentation, utilisent .nebula-panel.

Style courant :

• fond semi-transparent rgba(16, 20, 38, 0.42) ;
• bordure statique identique aux outils en etat normal ;
• accent dore leger en bas/droite ;
• pas de hover sur les panneaux de lecture ;
• implementation via le mixin gold-panel-frame dans website/src/styles/_mixins.scss.

10. Catalogue Documentation

La page catalogue des outils utilise un layout de documentation.

Regles :

• hero court, puis contenu principal en deux colonnes sur desktop ;
• sommaire a gauche en panneau sticky, avec categories puis liens d'outils de la categorie active ;
• une seule categorie d'usage est affichee a droite a la fois ;
• la categorie active commence par un mini-hero descriptif, sans compteur decoratif ;
• chaque fiche commence par le titre, l'icone, le badge de categorie et une description directe de l'outil ;
• l'exemple interactif reste visible en permanence et centre horizontalement ;
• les reperes de boutons propres a l'outil sont places a gauche de l'exemple, puis empiles au-dessus dans la disposition compacte jusqu'a 1024px ;
• les reperes sont groupes par categorie de controles de l'outil, avec apercu visuel du bouton et label court ;
• les descriptions de reperes sont reservees aux comportements non evidents, par exemple un bouton qui agit sur toute la ligne ou une action de drag & drop ;
• les fonctionnalites detaillees et formats d'import texte sont presentes sous l'exemple dans un panneau repliable pour ne pas alourdir la lecture avant manipulation ;
• les controles propres au catalogue, comme la reinitialisation d'une demo, ne sont pas documentes comme fonctionnalites de l'outil ;
• en fenêtre compacte jusqu'a 1024px, le sommaire devient un bloc normal place avant les fiches, sans position sticky ;
• sur l'accueil, cette même disposition masque l'illustration de la section « Origine du nom » et sa séparation verticale pour privilégier le dialogue.

11. Boutons

Selects Des Outils

Tous les <select> rendus dans le contenu d'un outil doivent utiliser le style factorise par website/src/styles/design-system/_controls.scss.

Regles :

• flèche custom violet clair, doree au hover/focus ;
• fond sombre en couches legerement violet/indigo ;
• hauteur compacte cible 36 px ;
• options sur fond #11182f ;
• les fichiers d'outil peuvent definir uniquement les contraintes de layout necessaires : largeur, grille, flex, ou typographie locale.

Primary

Les boutons primary sont plus contrastes que les boutons standards.

Style :

• fond violet/indigo sombre ;
• bordure doree ;
• hover plus lumineux avec bordure doree plus nette ;
• glow violet/dore contenu ;
• pas de brightness() global ;
• pas de translation verticale.

Boutons standards

Hover :

• fond nebula plus lumineux ;
• bordure violet clair ;
• glow violet tres discret ;
• pas d'accent dore systematique.

Boutons Toggle Temporaires

Les boutons qui ouvrent temporairement un panneau, un menu ou un mode local ne doivent pas utiliser le style switch.

Etat actif :

• bordure gradient dore/violet plus visible que le hover ;
• fond sombre avec degrade transparent/dore tres leger et touche violette en bas a droite, sans remplissage primary ;
• texte ou icone clair pour préserver la lisibilite ;
• trait interne dore discret pour distinguer l'etat actif des badges et actions primary ;
• bordure dore/dore clair statique, sans effet toast ;
• pas de glow externe fort ni animation permanente ;
• utiliser le mixin temporary-toggle-active pour garder les variantes coherentes.

Ghost

Hover minimal :

• leger fond violet transparent ;
• texte plus clair ;
• pas de glow.

Danger

Reserve aux actions destructrices.

• couleur rouge au repos ;
• hover rouge sombre, bordure rouge, texte/icones blancs ;
• confirmation en modale pour les actions irreversibles.

Boutons icones

Les icones utilisent currentColor via .ui-icon.

• taille habituelle : 20 px ;
• bouton : 40 x 40 px ;
• hover neutre : icone violet clair #c4b5fd + leger glow ;
• hover danger : icone blanche + glow rouge discret ;
• utiliser les SVG de website/public/static/icons.

11. Formulaires Et Checkbox

Inputs et textareas :

• fond sombre ;
• bordure fine ;
• focus dore via :focus-visible ;
• placeholders en --color-text-muted.

Checkbox :

• style custom global ;
• format carre strict ;
• fond non coche legerement eclaire ;
• bordure dore/violet ;
• etat coche avec gradient dore/violet et coche blanche ;
• spacing adapte dans les filtres.

Accessibilite :

• utiliser .sr-only pour conserver un label utile sans l'afficher ;
• ne pas retirer les labels accessibles au profit du visuel uniquement.

12. Navigation

Sidebar :

• fond sombre, stable ;
• icones SVG pour Accueil, Toolboxes et Jeux ;
• navigation active en violet soft ;
• le logo controller garde le gradient de l'ancien badge et une rotation au hover.
• sidebar[data-variant="compact"] réduit la navigation à 72 px jusqu'à 1024px, ainsi que lorsqu'un panneau toolbox latéral est ouvert en fenêtre large : la manette conserve sa rotation au hover, les trois entrées principales et les trois raccourcis secondaires utilisent Tooltip, puis l’encart inférieur contient uniquement les actions globales exporter/importer empilées avec leurs propres infobulles.

Le nom de marque affiche Sokko en blanc et G en dore. Au hover, Sokko anime vers le dore de droite a gauche puis revient au hover out.

13. Filtres Et Tableaux

Filtres :

• vertical conserve le panneau latéral historique avec des chips checkbox, icône puis texte ;
• horizontal-compact aligne recherche, petit groupe d’options directes, correspondance et reset au-dessus des résultats ;
• horizontal-menu remplace les groupes nombreux, ambigus ou avancés par des nds-select-trigger ouvrant des nds-popover ;
• nds-filter-menu[data-columns="2"] répartit les options aux libellés courts sur deux colonnes dans la largeur standard du popover, afin de compacter chaque option ;
• les menus multi-sélection gardent les libellés visibles et affichent le nombre de critères actifs dans leur trigger ;
• les listes des popovers de filtres prennent leur hauteur naturelle et n’ajoutent pas de défilement interne ;
• les sélecteurs de condition comme ET / OU ou ≥ / = restent dans une petite surface bordée afin de les distinguer des options du menu ;
• lorsque la condition ne concerne qu’un groupe avancé, comme les catégories Diablo IV, son sélecteur est placé dans le popover correspondant avec 12 px d’espace avant les options ;
• toute option réduite à son icône doit utiliser le composant commun Tooltip et conserver un nom accessible (aria-label) ; l’attribut HTML title ne remplace pas le tooltip ;
• les options directes avec libellé suivent la largeur naturelle de leur contenu ; lorsqu’elles passent en icône seule, elles retrouvent une largeur compacte commune ;
• la recherche des barres horizontales est plafonnée à 260px afin de ne pas étirer inutilement les filtres ;
• nds-active-filters forme une seconde section compacte dans la barre principale, séparée sur toute la largeur par un trait doré semi-transparent sans ombre ; la section haute conserve les 10 px de padding vertical de la barre, tandis que la section basse se limite à 4 px ; elle affiche un badge fermable par recherche ou critère actif, dont le bouton retire uniquement le filtre correspondant ;
• les barres sont sticky sous la topbar en fenêtre large, reviennent à la ligne et redeviennent statiques en fenêtre compacte ;
• reset avec bouton icône rubber.

Tableaux :

• pas de scroll horizontal pour les tableaux de degats MHWilds ;
• cellules compactes ;
• bordures fines ;
• lisibilite prioritaire sur la decoration.

Outil Tableau :

• scroll horizontal autorise uniquement dans la surface de grille editable ;
• entetes de lignes/colonnes compacts et stables ;
• intitulés de lignes/colonnes éditables sans modifier les références de formule ;
• cellules en inputs directs, avec focus dore et erreurs de formule discrètes ;
• sélection multiple visible par fond cyan/violet discret et destinée aux actions de plage comme la copie TSV ;
• actions de lignes/colonnes en boutons icones.

14. Toolboxes

Espaces d'outils

• La barre d'espaces se place entre le hero de la toolbox et les contrôles de disposition, dans la page complète comme dans le drawer lié à un jeu.
• Quand seul l'espace par défaut existe, son onglet est masqué et le bouton Nouvel espace reste aligné à droite. À partir de deux espaces, la liste devient un tablist horizontal scrollable et l'ajout prend la forme d'un bouton + placé immédiatement après le dernier onglet.
• L'espace actif reprend les surfaces et focus des radio-button groups. Les onglets ciblés par un outil affichent un soulignement doré ; les espaces secondaires disposent d'une poignée de réordonnancement distincte avec un retrait à gauche.
• Le réordonnancement des onglets reprend l'indicateur d'insertion doré des outils, positionné à gauche ou à droite selon la destination. Les actions de renommage et suppression restent groupées à droite et passent sous les onglets en fenêtre étroite.

Les toolboxes sont locales et stockees dans le navigateur.

La fenêtre « Ajouter un outil » peut s'étendre jusqu'à 900px et présente les outils sur 4 colonnes à 768px, puis 5 à partir de 900px. Chaque carte compacte place l'icône à gauche du nom complet, puis une courte phrase d'usage issue de site.json sur toute la largeur. Le contenu est réparti dans les cinq catégories du catalogue, chacune signalée par un titre et un séparateur discret, sans onglets de filtrage. Lorsque la hauteur disponible ne suffit pas, la modale utilise directement scrollbar-control, la scrollbar verticale du NDS. L'ajout rapide reste une grille d'icônes sans description ; ses boutons utilisent les infobulles NDS au survol et au focus.

Regles UI :

• pas de champ description ;
• image de jeu si associee a un jeu ;
• icone editable si toolbox libre ;
• action importer/exporter clairement identifiee ;
• budget IndexedDB recommande visible en bas de page/panneau, avec quota navigateur reel seulement informatif ;
• import/export global disponibles.

Les cards toolbox doivent garder une taille compacte. L'image/icone de cover est cliquable.

15. Donnees Jeux

Le contenu editorial editable doit rester dans :

• website/public/data/site.json pour les textes generaux ;
• website/public/data/games.json pour la liste des jeux ;
• website/public/data/mhwilds/*.json pour les donnees MHWilds.

Les retours a la ligne \n du JSON doivent etre rendus correctement. Le JSX ne doit pas contenir de contenu editorial long si une entree JSON existe deja.

16. Modales, Drawer Et Notifications

Modales :

• fond floute mais pas trop opaque ;
• panneau centre ;
• fermeture au clic exterieur quand l'action le permet ;
• boutons icones pour fermer/zoomer quand approprie.
• la visionneuse d'un outil Images peut recevoir la collection du bloc courant : sa galerie utilise de grandes cards commutables entre 4:3 et 1:1, avec image non recadrée et libellé toujours visible, dans un flux responsive centré et scrollable uniquement verticalement ; un bouton texte affiche le ratio actif, tandis que les boutons − et + règlent leur largeur de 180 à 420 px par paliers de 40 px ; le ratio et la largeur sont mémorisés comme préférences locales ; les gouttières entre cards restent compactes tandis que le bord de la galerie conserve un padding plus généreux ;
• la vue detaillee expose la position, un retour explicite a la galerie et des boutons precedent/suivant bloques aux extremites ; les fleches gauche/droite reprennent cette navigation ;
• une visionneuse d'image seule, notamment pour les annotations, ne doit afficher ni galerie ni navigation de collection.

Drawer toolbox :

• le bouton de topbar associe icone et texte visible : « Afficher la toolbox » quand le drawer est ferme, puis « Masquer la toolbox » lorsqu'il est ouvert ;
• à partir de 1440px, le panneau lateral est ancre a droite, ouvert a 700px et redimensionnable uniquement vers une largeur superieure ;
• à partir de 1440px, le shell reserve toujours 700px au panneau : toute largeur supplementaire recouvre la partie droite de la page sans la reduire davantage ;
• la page reste visible et interactive, sans backdrop bloquant ni fermeture au clic exterieur ;
• sous 1440px, la topbar propose une bascule « Guide / Toolbox » à la taille standard des groupes de boutons ; chaque vue occupe toute la zone de contenu et la poignée de redimensionnement est masquée ;
• le guide et la toolbox restent montés après leur première ouverture en mode compact afin de conserver filtres, saisies et positions de défilement ; la vue masquée est retirée du parcours clavier et de l'arbre d'accessibilité ;
• la sidebar mesure 72px jusqu'à 1024px, puis 248px jusqu'au passage en panneau latéral ;
• la largeur revient a 700px a chaque ouverture et n'est pas persistee ;
• les actions internes ne doivent pas fermer le drawer sauf action explicite.

La cible responsive est une fenêtre d'ordinateur de second écran, en plein écran ou en demi-écran. Les parcours sont validés à partir de 768px. Il ne faut pas concevoir de navigation, de composant ni de parcours dédié au téléphone. Sous la largeur validée, les règles servent uniquement à conserver l'accès au contenu et à empêcher un débordement horizontal global, sans garantie de confort.

Quand la zone utile d'une page toolbox passe sous 900px, les outils sont forcés sur une seule colonne et le sélecteur une/deux colonnes est masqué. La préférence de disposition reste enregistrée et redevient applicable lorsque la largeur le permet.

Notifications internes :

• pas d'alerte navigateur ;
• utiliser les toasts internes globaux ;
• position configurable gauche/droite via le switch de la page toolboxes ;
• une nouvelle alerte s'empile au-dessus des precedentes ;
• limite visible : 5 toasts ;
• a la 6e alerte, fermer la plus ancienne ;
• durée par défaut des confirmations ordinaires : 6 secondes ; une durée explicite reste prioritaire avec un minimum d'une seconde ;
• les alertes Timer, Calendrier et le rappel de sauvegarde sont persistants jusqu'à leur fermeture manuelle ;
• style plus visible que les confirmations simples : bordure conique animee, pulse leger, arrivee depuis le cote configure.

17. Controles Interactifs

Les champs, selects, boutons icones, switchs et choix compacts utilisent une base commune issue de website/src/styles/design-system/_controls.scss. Les fichiers d'outils peuvent choisir une taille ou poser une contrainte de layout, mais ne doivent pas redefinir localement les fonds, bordures, hovers ou etats primary/danger.

Inputs et textareas :

• utiliser field-control pour les champs standards ;
• la base globale cible uniquement les types texte explicites : text, search, email, url, password et textarea ;
• ne pas utiliser de selecteur global negatif comme input:not([type="checkbox"]), afin de ne pas capter les champs number, time, file ou les cellules specialisees ;
• tout nouvel <input> texte doit declarer son type explicitement ;
• utiliser time-control pour les champs input[type="time"], avec variante sm ou xs selon le contexte ;
• taille normale : 44px minimum ;
• taille compacte sm : 36px minimum ;
• taille dense xs : 32px minimum ;
• utiliser field-textarea pour les textareas redimensionnables avec scrollbar stable : md 108px, sm 88px, xs 72px minimum ;
• utiliser data-variant="ghost" sur nds-textarea pour les zones d'edition intégrées à une surface métier, comme les mémos ;
• placeholders via field-placeholder ;
• hover via field-hover, focus via field-focus ;
• disabled via field-disabled ;
• les variantes complexes comme les cellules de table et le champ timer hh:mm:ss utilisent des mixins dedies du meme fichier.

Edition inline :

• utiliser inline-field pour les inputs transparents au repos ;
• hover/focus via inline-field-hover ;
• utiliser inline-textarea pour les zones texte transparentes intégrées à une carte ;
• les outils peuvent changer la couleur texte selon le contexte, par exemple titre de section ou état terminé.

Selects :

• taille normale : 44px minimum ;
• taille compacte toolbox : 36px minimum ;
• taille dense xs : 32px minimum ;
• fleche custom unique, jamais de chevrons natifs ou empiles ;
• fond sombre Nebula force via background-color, hover/focus violet avec chevron dore ;
• focus visible global dore conserve.

Select triggers :

• utiliser select-trigger pour les boutons qui ouvrent une liste, un picker ou un calendrier avec le langage visuel d'un select ;
• tailles disponibles : md 44px, sm 36px, xs 32px ;
• le chevron est le meme asset CSS que select-control, pas une icone locale ;
• hover via select-trigger-hover, focus via field-focus et focus visible dore ;
• date-picker-trigger reste un alias de compatibilite pour les outils deja migrés.

Menus et palettes :

• utiliser floating-control-menu pour les menus flottants compacts ;
• les suggestions .nds-autocomplete-option utilisent le même fond doré au survol et en état .is-active, sans être écrasées par le hover générique des boutons ;
• utiliser compact-menu-button pour les options d'icones ou d'actions compactes ;
• utiliser color-swatch, color-swatch-rainbow et color-swatch-active pour les palettes couleur ;
• utiliser large-icon-picker-trigger pour les gros triggers de choix d'icone de toolbox ;
• les outils peuvent garder uniquement la position du menu, le nombre de colonnes et la variable de couleur métier.

Champs horaires :

• les champs input[type="time"] restent natifs ;
• utiliser time-control pour aligner le champ avec le theme Nebula ;
• la popup native du navigateur/OS n'est pas consideree comme stylable de facon fiable en CSS.

Boutons texte :

• utiliser text-button depuis website/src/styles/design-system/_controls.scss ;
• taille normale : hauteur minimale 42px ;
• taille compacte sm : hauteur minimale 34px ;
• taille dense xs : hauteur minimale 30px ;
• le bouton standard sert de variant secondaire par defaut ;
• variants disponibles : primary, secondary, ghost, dashed, danger ;
• les boutons texte peuvent utiliser data-edge pour ajuster leurs coins et data-border pour gérer les bordures jointes ou masquées ;
• etat toggler via .active ou .is-active, avec le mixin temporary-toggle-active ;
• etat desactive via control-disabled ;
• les outils peuvent uniquement ajuster la largeur, l'alignement ou l'espacement environnant.

Boutons icones :

• taille normale : 40px, icone 21px ;
• taille compacte : 34px, icone 19px ;
• taille dense xs : 30px, icone 17px ;
• taille inline xxs : 26px, icone 15px ;
• taille micro reservee aux noeuds denses : 22px, icone 12px ;
• fond compact sombre, rayon --radius-md, hover violet contenu ;
• variant primary dore/violet pour les actions principales ;
• variant ghost transparent pour les handles discrets ;
• variant danger rouge contenu pour les suppressions ;
• variant de forme button-edge(left|middle|right|top|center|bottom|top-left|top-right|bottom-right|bottom-left) pour ajuster uniquement les coins contre une bordure ou dans un groupe ;
• variant de bordure button-joined-border(...) pour masquer les bordures de jonction déduites depuis data-edge ;
• variant de bordure button-borderless pour masquer toutes les bordures ;
• variant visuel panel-toggle pour les boutons icones accolés à un panneau, comme le bouton pages ;
• etat toggler via .active ou .is-active, avec le mixin temporary-toggle-active.
• les barres d'outils compactes reutilisent la famille bouton icone ; toolbar-button reste un alias pratique pour les boutons courts du Bloc Note (B, I, U) et les boutons de dessin.

Boutons composes et toggles de bord :

• utiliser button-edge + button-joined-border pour les boutons groupés type ajout + chevron ;
• utiliser button-edge pour la forme des toggles accoles au bord d'un module, et icon-button-panel-toggle pour leur rendu visuel quand ils reprennent le pattern du bouton pages ;
• utiliser list-row-button pour les lignes selectionnables type pages du Bloc Note ;
• utiliser text-button-dashed pour les actions d'ajout contextuelles encadrees en pointilles ;
• split-button-start, split-button-end, edge-toggle et dashed-action-button restent des alias de compatibilite internes, pas des familles visuelles separees ;
• les outils peuvent garder uniquement la position absolue, la largeur contextuelle et les icones ;
• l'etat actif/hover doit rester dans le DS, sans fond/bordure locale.

Steppers de quantite :

• utiliser quantity-stepper depuis website/src/styles/design-system/_controls.scss ;
• variante normale : checklist, boutons 28px autour de la valeur editable ;
• variante compacte : arbre d'objectifs, boutons 18px ou 16px selon la densite du noeud ;
• hover des boutons via quantity-stepper-button-hover, pas via icon-button-hover ;
• les outils peuvent adapter la grille environnante, mais pas redefinir les boutons - / +, le hover ou le champ de valeur.

Switchs binaires :

• utiliser switch-control depuis website/src/styles/design-system/_controls.scss ;
• taille lg : switchs de module, hauteur 40px, rail 30 x 16px ;
• taille normale : tool-split, hauteur 34px, rail 34 x 18px ;
• taille compacte sm : contrôles denses, hauteur 28px, rail 24 x 14px ;
• taille inline xs : timer inline, hauteur 26px, rail 18 x 12px ;
• les variantes natives avec <label><input type="checkbox" />... doivent réutiliser native-switch-label, native-switch-input, switch-track et switch-thumb ;
• les outils peuvent uniquement ajuster l'alignement ou la largeur environnante.

Radio button groups :

• la primitive commune est radio-button-group / radio-button-group-option depuis website/src/styles/design-system/_controls.scss ;
• tailles disponibles : md, sm, xs ;
• cette base couvre les tabs d'outils, switches de layout, choix d'alertes et répétitions calendrier ;
• le nombre d'options, le fait d'utiliser une icone, un texte ou les deux ne constitue pas un variant visuel ;
• les toggles compacts non natifs peuvent reutiliser ces mixins meme avec des span, tant que le comportement reste celui d'un choix exclusif ou d'un choix compact ;
• l'etat actif passe par .active ou .is-active avec le style toggler temporaire ;
• les outils peuvent definir la grille ou la largeur, mais pas redefinir localement les fonds, bordures, hovers ou actifs.

Controles composes :

• utiliser compound-toggle-field pour les cas qui combinent un choix compact et un champ, comme Hold + number ;
• le bouton interne utilise compound-toggle-field-option, base sur radio-button-group-option(xs) ;
• le champ interne utilise compound-toggle-field-input, base sur field-control(xs) et number-spinner-reset ;
• ces controles ne sont pas des variants du groupe de choix, car leur structure mélange action et saisie.

Checkboxes :

• utiliser checkbox-control depuis website/src/styles/design-system/_controls.scss ;
• taille normale globale : 20px, format carre strict 1:1 ;
• taille compacte xs : 14px pour les listes denses comme les prérequis de l'arbre d'objectifs ;
• etat coche avec gradient dore/violet et coche blanche ;
• les outils peuvent ajuster uniquement l'alignement ou l'espacement environnant.

Date picker et menus compacts :

• les tabs internes d'outils utilisent les primitives radio-button-group-surface, radio-button-group-option, radio-button-group-option-hover et radio-button-group-option-active ;
• les boutons du mini calendrier mensuel utilisent date-picker-button et date-picker-button-hover ;
• les boutons de menu/picker compacts utilisent compact-menu-button et compact-menu-button-hover ;
• les boutons transparents integres aux evenements calendrier utilisent event-surface-button, event-surface-button-hover et les contrastes event-surface-contrast-default / event-surface-contrast-dark ;
• nds-event-surface[data-variant="default"] cible un texte blanc/gris blanc sur fond sombre ;
• nds-event-surface[data-variant="dark"] cible un texte noir/gris noir sur fond clair ;
• nds-event-surface[data-size="md"] vise les surfaces à partir de 44px et affiche le titre et la metadata secondaire, par exemple l'heure ;
• nds-event-surface[data-size="sm"] vise les surfaces autour de 22px et masque la metadata secondaire ;
• nds-event-surface[data-size="xs"] vise les surfaces ultra-fines autour de 10px et affiche uniquement le titre en taille réduite ;
• les titres compacts restent dans le flux pour donner une hauteur au bouton, même si la surface ne définit qu'une hauteur minimale ; en sm, bordures et padding doivent tenir avec la ligne de titre dans les 22px ;
• nds-event-surface[data-color="#8b5cf6"] expose la couleur métier de l'event ; la variable inline --nds-event-color applique cette couleur au fond et a la bordure ;
• le hover utilise une superposition sombre legere pour rester lisible sur une couleur dynamique inconnue du Sass ;
• les couleurs de fond des events restent métier et ne sont pas des variants NDS ;
• les fichiers d'outils peuvent conserver les dimensions de grille, le placement du menu et les états métier disabled.

Curseurs de niveau

• input[type="range"].nds-range expose un curseur natif réutilisable, avec min, max, step, value et disabled standards ;
• tailles : md (44 px, poignée 20 px) et sm (36 px, poignée 18 px) ;
• associer un label explicite et une valeur visible ; conserver les interactions clavier natives ;
• rail violet, poignée bordée de doré, hover et focus issus des tokens NDS ;
• la page Aniimo affiche tous les curseurs avec min="0", max="4", step="1" : 0 retire la capacité des critères, 1–4 fixe son niveau minimum indépendant ;
• les règles de filtrage restent dans le composant métier ; le catalogue /design-system montre un exemple interactif et l'état désactivé.

Cartes Aniimo et variantes

• la carte d'entrée du guide utilise games.json > images.aniimosCover : le portrait d’Emberpup, recadré sur sa tête dans la couverture commune de 120 px ; des marges internes latérales de 15 % dézooment le portrait sans modifier le cadre ; une description courte conserve le gabarit des autres guides ;

• MHW et Aniimo partagent les mixins flip-card-inner, flip-card-indicator, flip-card-indicator-hover et flip-card-face-hover de _surfaces.scss : rotation de 420 ms, surfaces et indicateurs identiques ;

• les contrôles de retournement Aniimo sont dans chaque face et tournent avec elle ; le focus clavier rejoint le contrôle de la nouvelle face ;

• afficher les portraits dans un cadre compact 3 / 4 plafonné à 250 px de hauteur, avec object-fit: cover et cadrage centré ; les fichiers source restent inchangés ;

• les deux variantes de Petit Esprit de Feu utilisent object-position: center 20% pour descendre légèrement le personnage dans son cadre ;

• la grille utilise un minimum de 220 px pour afficher cinq colonnes à 1920 px, puis réduit le nombre de colonnes selon la largeur disponible ; limiter les cartes à 280 px de largeur ; le recto fixe leur hauteur avec le portrait et un pied de 96 px, indépendamment des noms et des variantes ;

• le nom de forme revient à la ligne au recto, dans le pied fixe de 96 px ;

• le recto affiche uniquement les icônes d'éléments, centrées dans le pied de carte, avec texte alternatif et infobulle ;

• le numéro Aniimo reste un texte HTML visible en bas à gauche du portrait, afin de rester accessible à la recherche du navigateur ;

• les onglets affichent des initiales ou une abréviation de trois lettres pour les formes à un seul mot (PLA, PRA, PRI) ; le nom complet reste accessible via Tooltip, au survol et au focus ;

• placer les onglets au-dessus du contrôle de retournement, avec navigation clavier ; une grille de colonnes égales affiche les sept formes sur une ligne sans couper les libellés ;

• la forme Prismana est la dernière entrée des variantes dans le JSON ; son onglet reçoit un léger fond et un soulignement arc-en-ciel statiques, sans masquer la sélection ou le focus ;

• conserver la face affichée lorsqu'une autre variante est sélectionnée ;

• le verso répartit les éléments et le rôle sur deux colonnes séparées par un trait vertical très discret, centré dans un espacement de 20 px (10 px de chaque côté), avant les compétences ;

• les badges d'élément et de rôle restent sur une ligne dans leur colonne : icône fixe, padding compact et points de suspension sur les libellés trop longs, avec texte complet au survol ;

• espacer de 24 px les sections Éléments/Rôle, Compétences de logis et Statistiques au verso ;

• le verso ajoute les six statistiques et leur total sous les compétences : barres nds-progress[data-size="sm"], valeur numérique alignée à droite, échelle commune égale au maximum du catalogue complet (130 actuellement), indépendante des filtres ;

• le compteur met en évidence les Aniimos ou les variantes selon le mode de copie ; l’infobulle du bouton précise le contenu copié ;

• le verso occupe exactement la même surface que le recto ; garder son en-tête fixe et faire défiler les détails dans une zone NDS accessible au clavier ; masquer la face inactive aux technologies d'assistance ;

• réduire l'animation selon prefers-reduced-motion ;

• les filtres se cumulent par famille et sont évalués sur chaque variante avant regroupement ; les compétences de logis sont toujours cumulatives et leur sélecteur compact ≥ / =, aligné comme « Correspondance », utilise le niveau minimum par défaut ; les libellés complets restent accessibles ;

• l’option directe « Prismana » reprend le style et les dimensions des nds-filter-option, utilise une étoile SVG arc-en-ciel et limite les résultats à prismana_form avant regroupement ; son nom accessible reste « Prismana uniquement » ;

• la barre horizontale avancée ouvre trois menus distincts pour Rôles, Éléments et Compétences de logis ; chaque trigger conserve le nombre de critères sélectionnés ;

• rôles et éléments utilisent des chips sm avec icône et texte, réparties sur deux colonnes via data-columns="2" ; le menu des compétences sépare sans titre visible les éléments et les actions en deux colonnes accessibles, le séparateur étant porté par la colonne des éléments, plus haute ; chaque ligne conserve icône, texte, curseur et valeur ; un seuil à 0 reste visible mais ne participe pas au filtrage ;

• recherche, Prismana, rôles, éléments et niveaux actifs sont rappelés sous la barre par des badges supprimables individuellement ;

• les menus restent ouverts pendant une sélection multiple et se ferment au clic extérieur, à Escape ou quand le focus quitte le menu.

Liaison des guides aux checklists

Dans la toolbox latérale, chaque checklist compatible avec le guide ouvert expose sa liaison dans la section Guide du panneau Configuration commun. L'engrenage conserve un marqueur d'état lorsque la liste est associée et expose aria-expanded et aria-controls. Le bouton NDS « Associer à la page » / « Dissocier » expose aria-pressed ; activer une liste dissocie la précédente. Le switch « Masquer les cochés » est désactivé sur les listes non associées. Les commandes sont centrées et reviennent à la ligne en fenêtre étroite ; le nombre de correspondances figure dessous. Une liste active devenue incompatible garde ses commandes avec un message explicite. Un encart compact placé en haut à droite du header du guide expose un sélecteur dès qu'au moins une checklist compatible existe. Sans association, lui seul est affiché. Une fois une liste choisie, l'encart ajoute le switch « Masquer les cochés » et l'action « Dissocier la checklist ». Changer la valeur du sélecteur remplace immédiatement l'association sans perdre le réglage de masquage. La colonne d'actions occupe la hauteur existante du header afin que cet encart n'ajoute pas de ligne ou d'espace vertical. Cette association est conservée dans localStorage entre les sessions ; elle est retirée si la checklist, la toolbox liée ou la liaison jeu/toolbox disparaît. Le bouton texte « Utiliser les résultats », accompagné de l'icône de copie, est visible dans l'en-tête des pages de résultats filtrables. Son aria-label et son infobulle conservent le contexte précis des éléments concernés. Il ouvre une modale NDS qui rappelle que les filtres, le regroupement et le masquage déterminent les éléments exportés. La copie texte reste disponible sans toolbox liée ; l'action de création est alors désactivée et accompagnée d'une notice inline. Avec une toolbox liée, la modale affiche son nom et crée la checklist dans son espace actif. L'état terminé désature et atténue uniquement les portraits (ou les icônes de catégorie Diablo). Le recto utilise uniquement la checkbox interactive ; la coche accessible « Coché » reste sur le verso des cartes retournables. Les textes restent lisibles et les indicateurs absolus ne modifient pas la taille des cartes. Lorsqu'une carte correspond à la checklist associée, une checkbox NDS apparaît en bas à droite de la zone d'image du recto (ou de la carte pour un affixe sans image). Elle met à jour toutes les lignes exactes correspondantes, sans retourner la carte ; pour Aniimo, la forme spécifique reste prioritaire sur l'entrée générale.

18. Scrollbars

Les scrollbars utilisent scrollbar-control depuis website/src/styles/design-system/_controls.scss.

Regles :

• largeur/hauteur WebKit : 6px ;
• scrollbar-width: thin pour Firefox ;
• track transparent ;
• thumb violet/indigo avec hover dore contenu ;
• coin transparent pour les zones scrollables dans les deux axes ;
• les textareas redimensionnables ajoutent scrollbar-resizer, sans fond noir ;
• ne pas ajouter de rail noir visible ni de double bordure pres des panneaux.

19. Images Et Assets

Regles :

• les pages jeux et toolboxes associees utilisent les images de jeu en cover ;
• les images de jeu doivent etre rangees par jeu dans website/public/static/img/games/<game-id>/ ;
• utiliser card-cover.png pour les cards et hero-bg.png pour le futur fond de hero ;
• declarer ces images dans games.json via images.cardCover et images.heroBg ;
• les toolboxes libres utilisent une icone de website/public/static/img/toolbox-icons ;
• toolbox.png est l'icone par defaut ;
• les SVG utilises comme icones ou masques UI doivent etre ranges directement dans website/public/static/icons ;
• en cas de collision de nom, reutiliser l'icone existante quand elle couvre le meme usage ; sinon prefixer le fichier par son domaine plutot que creer un sous-dossier ;
• website/public/static/img reste reserve aux images bitmap, covers, illustrations, captures et visuels editoriaux ;
• les categories de jeu utilisent des images representatives, entieres et bien cadrees ;
• eviter les images trop grandes dans les cards.

20. Accessibilite

Minimum attendu :

• focus visible dore ;
• boutons reels pour les actions ;
• liens reels pour la navigation ;
• labels explicites ou aria-label pour les boutons icones ;
• contraste suffisant ;
• modales avec role="dialog" et aria-modal="true" ;
• ne pas transmettre une information uniquement par couleur.

21. A Eviter

• accents dores partout ;
• hover trop lumineux sur tous les elements ;
• mouvements verticaux sur les cards/modules principaux ;
• background inline qui remplace le theme commun ;
• descriptions de toolbox ;
• alertes navigateur pour confirmations ou creation ;
• gros blocs explicatifs visibles dans l'app ;
• scroll horizontal sur les tableaux de donnees critiques.

Les chips nds-chip[data-size="sm"] utilisent une hauteur minimale de 30 px, un padding de 4 × 8 px, une police xs et des icônes/images de 16 px. Le catalogue interactif expose cette taille à côté de la taille par défaut.