Valider le schéma des données des préréglages en CI #91

New issue

Open

opened 2026-07-16 17:22:53 +00:00 by Reliodas · 0 comments

Reliodas commented

2026-07-16 17:22:53 +00:00

Owner

Contexte

Le dépôt contient actuellement 564 préréglages répartis dans data/*.js, dont 392 sorts. Les smoke tests vérifient la syntaxe JavaScript et les références locales, mais pas la forme des objets consommés par chaque éditeur.

Une propriété manquante, un tableau de référence non rectangulaire, un type incorrect ou un niveau invalide peut donc rester silencieux jusqu'au chargement manuel de la carte concernée. Le ticket #50 continue d'ajouter et de corriger beaucoup de données, ce qui augmente ce risque.

L'audit ne trouve actuellement aucun nom vide ou dupliqué, mais plusieurs schémas tolèrent des champs optionnels sans contrat exécutable.

Modifications à faire

Définir un validateur léger par tableau global, sans introduire de build obligatoire ni de dépendance runtime.
Vérifier les champs obligatoires, les types, les tableaux imbriqués et les valeurs énumérées utilisées par chaque éditeur.
Vérifier les structures communes : items, blocks, traits/actions, levelGroups/features et tables headers/rows.
Signaler les doublons de noms dans un même éditeur et les entrées sans nom.
Vérifier que chaque ligne de tableau possède le même nombre de cellules que ses en-têtes.
Documenter explicitement les champs optionnels, notamment source, reactions, url et higher.
Intégrer le validateur au script smoke ou à une commande npm dédiée exécutée par Woodpecker.
Produire des erreurs indiquant le fichier, l'index ou le nom de l'entrée et le champ concerné.

Critères d'acceptation

Une donnée mal typée ou incomplète fait échouer la CI avec un message localisable.
Les huit fichiers data actuels passent le validateur après clarification de leurs champs optionnels.
Les 564 préréglages sont contrôlés sans navigateur et sans accès réseau.
Les tables non rectangulaires, noms vides et doublons sont détectés.
L'application reste statique et les pages continuent de fonctionner en file://.
La commande de validation est documentée dans README.md, CONTRIBUTING.md et AGENTS.md.

## Contexte Le dépôt contient actuellement 564 préréglages répartis dans data/*.js, dont 392 sorts. Les smoke tests vérifient la syntaxe JavaScript et les références locales, mais pas la forme des objets consommés par chaque éditeur. Une propriété manquante, un tableau de référence non rectangulaire, un type incorrect ou un niveau invalide peut donc rester silencieux jusqu'au chargement manuel de la carte concernée. Le ticket #50 continue d'ajouter et de corriger beaucoup de données, ce qui augmente ce risque. L'audit ne trouve actuellement aucun nom vide ou dupliqué, mais plusieurs schémas tolèrent des champs optionnels sans contrat exécutable. ## Modifications à faire - Définir un validateur léger par tableau global, sans introduire de build obligatoire ni de dépendance runtime. - Vérifier les champs obligatoires, les types, les tableaux imbriqués et les valeurs énumérées utilisées par chaque éditeur. - Vérifier les structures communes : items, blocks, traits/actions, levelGroups/features et tables headers/rows. - Signaler les doublons de noms dans un même éditeur et les entrées sans nom. - Vérifier que chaque ligne de tableau possède le même nombre de cellules que ses en-têtes. - Documenter explicitement les champs optionnels, notamment source, reactions, url et higher. - Intégrer le validateur au script smoke ou à une commande npm dédiée exécutée par Woodpecker. - Produire des erreurs indiquant le fichier, l'index ou le nom de l'entrée et le champ concerné. ## Critères d'acceptation - Une donnée mal typée ou incomplète fait échouer la CI avec un message localisable. - Les huit fichiers data actuels passent le validateur après clarification de leurs champs optionnels. - Les 564 préréglages sont contrôlés sans navigateur et sans accès réseau. - Les tables non rectangulaires, noms vides et doublons sont détectés. - L'application reste statique et les pages continuent de fonctionner en file://. - La commande de validation est documentée dans README.md, CONTRIBUTING.md et AGENTS.md.