Contexte
Suite à l'audit d'une branche front Vue 3/VueDsfr (feat/deepseek-implementation dans la démo ice-breaker), on constate que le skill recettes-client ne couvre que l'usage des composants, mais pas la partie qui conditionne réellement la conformité DSFR. Résultat : le code suit le skill à la lettre (DsfrInput avec is-invalid/hint, useToaster/AppToaster, etc.) tout en produisant un rendu DSFR non conforme.
Problèmes identifiés
1. Le skill n'évoque jamais la dépendance CSS ni la version
- Le skill recommande
pnpm create vue-dsfr mais ne dit rien sur :
- la dépendance directe
@gouvfr/dsfr (la feuille de style officielle) nécessaire pour le CSS DSFR actuel ;
- le fait de pinner/upgrader
@gouvminint/vue-dsfr vers une version récente.
- La branche s'est donc retrouvée sur
@gouvminint/vue-dsfr@3.6.0 (ancienne) avec le vieux CSS en bundle, sans @gouvfr/dsfr. Le DSFR obtenu est obsolète et non maîtrisé via npm.
- → Ajouter une section « Dépendances & setup » (par ex.
@gouvfr/dsfr@^1.x + @gouvminint/vue-dsfr moderne + import @gouvfr/dsfr/dist/dsfr.min.css dans main.ts).
2. Le skill n'enseigne pas la grille / typo / tokens DSFR
- Aucune mention des utilitaires
fr-container, fr-grid-row, fr-col-*, fr-py-*, fr-mb-*, ou des classes typo fr-h1, fr-text--*, ni des tokens (--bf-500, --red-marianne-*, etc.).
- Faute de cette recette, la branche a réinventé le layout et les couleurs en CSS maison :
.home__title/font-size: 1.25rem; font-weight: 600 au lieu de fr-h1/fr-text--lg ; #000091/#ce0500 en dur au lieu des tokens.
- → Ajouter une section « Grille, espacement, typo et tokens DSFR » avec des exemples conformes.
3. Encouragement à réutiliser getRandomId non respecté (partial)
- Le skill indique d'utiliser
getRandomId de VueDsfr, mais ce point « Gotcha » est facile à manquer (il est relégué en fin de fichier). La branche a réimplémenté son propre randomId().
- → Mettre en avant le rappel
getRandomId dans la recette useToaster elle-même plutôt qu'en simple gotcha.
Proposition
Compléter recettes-client avec :
- Une section dépendances (pin
@gouvfr/dsfr + VueDsfr récent + import CSS).
- Une section grille/typo/tokens avec exemples.
- Le rappel
getRandomId directement dans la recette à base de composable.
Pourquoi c'est important
Le point #1 et #2 sont les seuls à réellement garantir la conformité DSFR. Sans eux, un développeur qui suit le skill « à la lettre » obtient un composant VueDsfr correct mais un rendu / des dépendances DSFR faux.
Contexte
Suite à l'audit d'une branche front Vue 3/VueDsfr (
feat/deepseek-implementationdans la démo ice-breaker), on constate que le skillrecettes-clientne couvre que l'usage des composants, mais pas la partie qui conditionne réellement la conformité DSFR. Résultat : le code suit le skill à la lettre (DsfrInput avecis-invalid/hint,useToaster/AppToaster, etc.) tout en produisant un rendu DSFR non conforme.Problèmes identifiés
1. Le skill n'évoque jamais la dépendance CSS ni la version
pnpm create vue-dsfrmais ne dit rien sur :@gouvfr/dsfr(la feuille de style officielle) nécessaire pour le CSS DSFR actuel ;@gouvminint/vue-dsfrvers une version récente.@gouvminint/vue-dsfr@3.6.0(ancienne) avec le vieux CSS en bundle, sans@gouvfr/dsfr. Le DSFR obtenu est obsolète et non maîtrisé via npm.@gouvfr/dsfr@^1.x+@gouvminint/vue-dsfrmoderne + import@gouvfr/dsfr/dist/dsfr.min.cssdansmain.ts).2. Le skill n'enseigne pas la grille / typo / tokens DSFR
fr-container,fr-grid-row,fr-col-*,fr-py-*,fr-mb-*, ou des classes typofr-h1,fr-text--*, ni des tokens (--bf-500,--red-marianne-*, etc.)..home__title/font-size: 1.25rem; font-weight: 600au lieu defr-h1/fr-text--lg;#000091/#ce0500en dur au lieu des tokens.3. Encouragement à réutiliser
getRandomIdnon respecté (partial)getRandomIdde VueDsfr, mais ce point « Gotcha » est facile à manquer (il est relégué en fin de fichier). La branche a réimplémenté son proprerandomId().getRandomIddans la recetteuseToasterelle-même plutôt qu'en simple gotcha.Proposition
Compléter
recettes-clientavec :@gouvfr/dsfr+ VueDsfr récent + import CSS).getRandomIddirectement dans la recette à base de composable.Pourquoi c'est important
Le point #1 et #2 sont les seuls à réellement garantir la conformité DSFR. Sans eux, un développeur qui suit le skill « à la lettre » obtient un composant VueDsfr correct mais un rendu / des dépendances DSFR faux.