Le schéma exporté ignore tous les alias serde : il déclare invalide ce que le moteur accepte

[LeadcodeDev]

Reliquat identifié en clôturant le round 4 de l'audit. La PR #161 a corrigé la partie background du schéma exporté (31 violations → 6) ; voici la cause des 6 restantes, et elle est plus générale que prévu.

Le constat

rustmotion schema produit le fichier que les générateurs consomment pour savoir quoi écrire. schemars n'émet pas les #[serde(alias = ...)] — seulement le nom canonique. Tout document utilisant une graphie aliasée est donc déclaré invalide par le schéma alors que le moteur l'accepte parfaitement.

Vérifié sur le schéma réellement exporté :

"enum": ["float3d"]     ← présent
"enum": ["float_3d"]    ← absent

AnimationPreset::Float3d porte #[serde(alias = "float_3d")]. La graphie canonique est donc float3d, et float_3d — celle qu'emploient les exemples du dépôt et la documentation — n'existe que comme alias, invisible au schéma.

Impact mesuré

Sur les 8 exemples du dépôt, validés contre le schéma exporté par la CLI avec jsonschema (Draft 7) :

Fichier	Chemins en erreur
1600-style.json	2
dark-premium.json	2
mega-showcase.json	2

Toutes remontent à 'float_3d' is not one of ['float3d'], propagée jusqu'à faire échouer la scène entière via le anyOf de SceneEntry.

La classe complète

Dix serde(alias = ...) dans le dépôt, tous invisibles au schéma exporté :

Fichier	Alias non exposés
schema/animation.rs:157, schema/video.rs:67	float_3d
schema/style.rs:23-46	flex-start, flex_start, flex-end, flex_end, space-between, space-around, space-evenly
css/style.rs:620-629	top_left, top_right, bottom_right, bottom_left (rétro-compat ajoutée par #161)
components/lib.rs:385	progress_bar
components/lib.rs:406	container

Les deux derniers méritent une attention particulière : CLAUDE.md documente explicitement div (alias de container) et liste progress parmi les composants. Un générateur qui suit le schéma exporté n'apprendra jamais que container et progress_bar sont acceptés — et un outil qui valide contre ce schéma rejettera des scénarios corrects.

Les alias de schema/style.rs sont particulièrement piégeux : flex-start et space-between sont l'orthographe CSS réelle. C'est celle qu'un LLM écrira spontanément, et celle que le schéma déclare invalide.

Pistes

1. Implémenter JsonSchema à la main pour les enums concernés, en émettant l'union {canonique} ∪ {alias} dans le enum. C'est ce que fix(schema): turn the deserializer's silent sinks into named errors #161 a fait pour BackgroundValue/BackgroundEntry, donc le précédent existe dans le dépôt.
2. Ou une macro/helper partagé qui dérive le schéma depuis les attributs serde, pour éviter de maintenir deux listes à la main — c'est exactement le mode de dérive que cette issue dénonce.

L'option 1 est plus sûre à court terme ; l'option 2 évite que le problème revienne au prochain alias ajouté.

Vérification

Les 8 exemples doivent valider contre la sortie de rustmotion schema. Aujourd'hui : 5 sur 8 (contre 2 sur 8 avant #161). Un test automatisé existe déjà côté rustmotion-core (crates/rustmotion-core/tests/exported_schema_examples.rs, ajouté par #161) — l'étendre au schéma complet de la CLI serait le bon filet.