Prototype UI à partir des specs

Ce skill part d'un projet de specs (skill specs-ui) et en fait un prototype cliquable : mêmes écrans, même identité, et des parcours principaux qui fonctionnent. On navigue, on remplit les formulaires, les listes changent, les états s'enchaînent. Tout est simulé dans le navigateur. Il sert aux tests utilisateurs (scénarios guidés, données de départ maîtrisées, observations) et aux démos. Ce n'est pas l'application : les specs restent la référence.

Textes de l'interface, scénarios et échanges sont en français. Le code (scripts, attributs, variables, actions, identifiants) est en anglais ; ses commentaires peuvent être en français.

<skill> désigne le dossier de ce skill : les scripts se lancent avec node <skill>/scripts/… depuis la racine du projet, qui contient specs/ (specs/ui pour les specs, specs/prototype pour le prototype). Un projet à l'ancienne disposition (specs-ui/, prototype-ui/ à la racine) se range d'abord avec migrate-layout.mjs du skill specs-ui.

Économiser les tokens (à lire en premier)

Une page de prototype pèse 35 à 70 Ko (10 000 à 20 000 tokens) et shells.html plus de 150 Ko. Lire un fichier entier « pour voir » est la première source de gaspillage. Règles :

specs/prototype/PROTOTYPE.md est la mémoire : à lire en premier en reprise, et à s'en contenter tant que possible. Le tenir à jour à la fin de chaque étape, sous 150 lignes. specs/ui/CONTEXTE.md ne se lit qu'au cadrage (étape 1) : ensuite, data.js porte les faits du fil rouge.
Résumer avant de lire : outline.mjs specs/prototype e3 e4 résume chaque état d'une page avec ses lignes (environ douze fois plus court que le HTML), et outline.mjs specs/prototype --shells fait de même pour les coquilles. Lire ensuite seulement les lignes utiles (offset / limit). Jamais site/, jamais shells.html en entier.
Fiches de câblage enregistrées dans specs/prototype/fiches/eN.md (modèle templates/fiche.md). Elles sont écrites une fois, puis mises à jour à chaque itération. Le rédacteur reçoit le chemin de sa fiche, pas un long message.
Rédacteurs sobres : ils lisent references/redacteur.md (la consigne courte), pas alpine.md en entier. Ils lisent leur page par morceaux, font des modifications ciblées sans relire, lancent build et check une fois à la fin, n'écrivent aucun script de test et ne lisent aucune capture.
Contrôler avant de regarder : le texte de check.mjs d'abord, puis la planche du scénario (--scenarios, une image par étape), et les planches de pages seulement en cas de doute. Desktop d'abord ; la planche mobile seulement pour les écrans dont la portée mobile est complète.
Ne câbler que les parcours choisis. Une page non câblée ne coûte rien : elle montre les maquettes, et chaque état par ?state=.
Publier seulement ce qui a changé : le socle (proto.js) et les données (data.js) sont hors des pages, donc une correction du panneau ou des données envoie un seul fichier. Regrouper les retouches avant de publier.