Cahier des charges à partir des specs

Ce skill part d'un projet de specs (skill specs-ui, et le prototype du skill prototype-ui s'il existe) et produit le cahier des charges de l'équipe de développement. Les sources sont en Markdown, une par partie. Le build les assemble en deux formats :

• un document Markdown, pour un dépôt de code ou un outil de documentation ;
• une page HTML publiée comme artifact : sommaire qui suit la lecture, recherche par identifiant, pastilles RF / CA / NF / DT / RQ, diagrammes, thème clair et sombre, boutons « Copier le Markdown », pour le document entier ou une partie. La partie fonctionnelle et UI vient des specs par extraction (aucune réécriture), la partie technique (architecture, stack, infrastructure) est proposée puis validée avec la personne, et le découpage en lots porte des estimations en fourchettes avec leurs hypothèses.

Document et échanges en français. Code des scripts en anglais ; commentaires en français. <skill> désigne le dossier de ce skill ; les scripts se lancent depuis le dossier qui contient specs/ui/. Aucune dépendance : Node suffit.

Économiser les tokens (à lire en premier)

Les specs d'un produit pèsent souvent plus d'1 Mo de HTML ; le cahier des charges, 150 à 300 Ko de Markdown. Règles :

1. specs/requirements/REQUIREMENTS.md est la mémoire : à lire en premier en reprise, et à s'en contenter tant que possible. Elle contient l'avancement par source, les contraintes, les décisions techniques DT, les hypothèses d'estimation et ce qui reste à valider. La tenir à jour à la fin de chaque étape, sous 150 lignes.
2. Ne jamais lire le HTML des specs : extract.mjs en tire la matière en Markdown dans specs/requirements/sources/generated/ (environ 7 fois plus court). Le modèle principal lit generated/inventaire.md et specs/ui/CONTEXTE.md, puis seulement les extraits utiles des lots (par morceaux).
3. Ne jamais lire les documents assemblés (specs/requirements/requirements.md et .html, nommés par requirements.json → output), ni specs/requirements/publish/. On travaille dans specs/requirements/sources/ (une source par partie), puis build.mjs et check.mjs.
4. Un fichier par partie : modifier une partie, c'est modifier sa source, pas relire le document.
5. Déléguer au bon modèle :