28 octobre 2026. Format d’auteur séparé du contrat des sessions élève 1.0. Les deux activités d’addition utilisent désormais réellement les fichiers src/lib/questionnaires/definitions/exerciseur-addition.json et qcm-addition.json comme source de leurs métadonnées, paramètres et présentation. Aucun importateur graphique, éditeur intégré, dépôt serveur ou mécanisme de publication n’est livré ici.
Séparation des responsabilités
Le JSON décrit un exercice ; les composants partagés en assurent le rendu ; le moteur de confiance corrige/génère ; la session fige le travail réalisé. On peut changer les données sans recopier le composant Svelte. Les fichiers ne transportent ni JavaScript, fonction, URL de générateur, règle de récompense, HTML interprété ou CSS arbitraire. Un texte ressemblant à du HTML reste du texte échappé.
Le schéma structurel definitions/questionnaire.schema.json sert à l’outillage et à l’autocomplétion JSON Schema 2020-12. La frontière exécutable est validateDefinition dans definition.mjs : elle ajoute les contrôles sémantiques (références, collisions, cardinalités, taille) qui ne sont pas tous exprimables dans le schéma. Tout futur importateur/éditeur doit l’appeler, pas seulement valider la structure du JSON Schema.
Champs du document
| Champ | Contrat |
|---|---|
| kind, schemaVersion | questionnaire-definition, 1 ; version inconnue refusée |
| activityId | Identité stable ASCII alphanumérique/tirets, 1–100 caractères ; ne pas dériver du titre |
| activityVersion | Version explicite du contenu/générateur et de sa configuration |
| scoringVersion | Convention de correction et compteurs ; ne pas mélanger les conventions dans les graphiques |
| title, category | Titre ; catégorie exerciseur ou qcm |
| level, difficulty | Libellé ouvert (6e, 5e, terminale, post-bac…), entier de 1 à 5 |
| subject | {id,label} de la matière |
| themes | Liste non vide de {id,label}, identifiants uniques, thèmes évaluables |
| tags | Liste de {id,label,themeIds}, identifiants uniques, classement éditorial ; zéro tag permis |
| questionCount | 1–500 questions dans une session |
| presentation | Consigne textuelle instructions, `choiceLayout:grid |
| source | Contenu fixed, banque bank ou générateur generated |
Les valeurs d’accent choisissent des styles prévus par le site, pas des couleurs/CSS fournis par un fichier. Les labels, la difficulté, les tags et la consigne sont lus depuis le JSON des cartes ; le choix grille/colonne est transmis au composant de réponses. Les boutons et la navigation restent cohérents entre activités, gérés par le site.
Sources et modalités
Fixe : {type:"fixed",questions:[...]} ; le nombre de questions doit correspondre à questionCount. Banque : {type:"bank",questions:[...]} ; au moins questionCount entrées. Matérialisation par mélange puis sélection sans remise. Les définitions ne sont pas modifiées par le tirage.
Une question fixe contient exactement id, themeId, prompt, response, correction. Textes simples, prompt limité à 1 000 caractères pour sa copie dans les paramètres primitifs de la session actuelle ; correction 5 000 caractères. Exemple à deux choix :
{
"id": "question-1",
"themeId": "addition-relatifs",
"prompt": "(-2) + 3 = 1 : vrai ou faux ?",
"response": {
"type": "single-choice",
"choices": [{"id":"vrai","label":"Vrai"},{"id":"faux","label":"Faux"}],
"correct": ["vrai"]
},
"correction": "(-2) + 3 = 1."
}Modalités : integer avec expected entier sûr ; single-choice avec 2–20 choix distincts et un seul identifiant correct ; multiple-choice avec plusieurs identifiants corrects possibles et correction par égalité exacte d’ensembles. Les réponses sont associées aux identifiants, jamais aux positions après mélange. Un document de catégorie QCM ne peut pas contenir une réponse integer. Un exerciseur peut mêler les modalités, pour des exercices composites futurs. Une nouvelle modalité demande un validateur/correcteur et un composant de confiance avant de devenir importable.
Généré : référence à integer-addition, version 1, paramètres minimum, maximum, responseType:integer|single-choice, choiceCount:2..20. Bornes entières ordonnées entre −1 000 000 et +1 000 000 ; un thème unique. Le générateur conserve le calcul, les distracteurs et l’explication algorithmique dans le code commun, sans évaluer d’expression contenue dans le JSON. Une évolution vers d’autres contraintes pédagogiques ajoutera un générateur/version validé. Les exemples actuels restent à 10 questions entre −20 et +20 et quatre choix.
Tags, thèmes, résultats et compatibilité mobile
Les tags classent l’activité ; themeIds explicite leurs liens avec les thèmes évaluables. Un tableau vide désigne un tag purement éditorial. Toute référence inconnue est refusée. Aucun vocabulaire fermé ni génération automatique de thème depuis un libellé de tag.
Chaque question porte un seul themeId. Le résumé de session comptabilise les questions et erreurs réellement posées par thème, avec les labels figés de la définition. Les tags non évalués ne deviennent pas des thèmes de session. Les sessions gardent les compteurs explicites answered, correct, planned : le futur graphique ne doit pas supposer correct = questionCount - errorCount pour une convention étrangère. Les résumés conservent ces compteurs après éviction des détails. Pour la convention précise addition-one-answer-v1, une session completed comporte exactement un verdict final par question, sans nouvel essai : chaque question incorrecte compte une erreur, même pour un choix multiple incomplet. Ainsi, pour chaque thème réellement évalué, theme.questionCount - theme.errorCount donne les bonnes réponses du thème, y compris en multithème. Un thème à zéro question est exclu des graphiques. Cette convention ne s’étend pas aux sessions incomplètes ni aux autres scoringVersion. Un test multithème vérifie ces invariants et la conservation du résumé sans détails.
Les deux activités conservent leurs activityId, activityVersion et scoringVersion ; les clés de récompenses et le format de session ne changent pas. Questions, propositions, réponses, attendus, corrections et verdicts restent figés dans le paquet 1.0. La relecture générale ne charge pas le JSON courant et n’a pas besoin de la banque/générateur d’origine. La reprise interactive d’une version absente du catalogue demeure refusée explicitement, comme auparavant ; ne pas confondre reprise d’une activité et relecture d’un historique.
Toute modification significative d’un exercice publié exige une nouvelle activityVersion ; toute modification du décompte exige une scoringVersion explicite. prepareDefinitionImport bloque une collision activityId/activityVersion au lieu d’écraser. La future politique d’ajout/remplacement/archivage sera une décision explicite de l’importateur ; rien n’est publié automatiquement.
Validation et préparation d’import
validateDefinition(input) accepte un objet JSON ou un texte (BOM UTF-8 accepté), renvoie une copie validée, refuse les clés inconnues à chaque niveau, les structures dangereuses et les formats non pris en charge. Plafond 1 Mio UTF-8 avant analyse ; profondeurs et volumes bornés. prepareDefinitionImport(input,existing) prépare définition + résumé de contrôle, sans écriture. serializeDefinition fournit le JSON formaté après validation.
L’utilitaire local fait une validation et un aperçu lisible, sans copier le fichier dans le catalogue ni exécuter le générateur :
node scripts/validate-questionnaire.mjs src/lib/questionnaires/definitions/exerciseur-addition.json src/lib/questionnaires/definitions/qcm-addition.json
node scripts/validate-questionnaire.mjs examples/questionnaires/qcm-fixe.json examples/questionnaires/qcm-banque.jsonCode de sortie non nul pour une erreur ou un doublon dans le lot. materializeDefinition construit les questions fixes/tirées/générées. createDefinitionSession produit un paquet initial compatible, avec répartition réelle par thème. Il valide aussi la limite finale de session 1 Mio : une définition valide n’autorise pas une session trop volumineuse. Ce point doit être montré avant publication/import effectif par le futur utilitaire.
Les deux fichiers examples/questionnaires/ sont des modèles éditables de QCM binaire, choix multiple et banque. Ils sont validés et matérialisables mais ne sont pas ajoutés aux cartes. La sélection des définitions actives reste explicite dans addition.mjs ; pas de scan automatique de fichiers ni de chargement distant. Ajouter une activité arbitraire à l’interface et conserver son historique de versions font partie du futur importateur/catalogue, pas de ce lot.
Coordination et vérifications
Frontières confirmées avec le Chef de projet : ce lot ne modifie pas StudentApp, le contrat student 1.0, les graphiques ou le transfert. C reprend les anciens raccords de la branche en préservant sa version intégrée ; les autres agents développent séparément le transfert groupé cinq minutes. Pas de nouvelle liste de récompenses ; leur registre et les notifications sont conservés.
Tests nouveaux : aller-retour des quatre définitions, collisions, champs inconnus, versions/générateurs non admis, limites, tags/thèmes invalides, nombre de questions, sélection sans remise, paramètres des distracteurs de 2 à 20, snapshot indépendant du fichier, compteurs et compatibilité des anciennes activités. Les six tests métier précédents passent également. Recette navigateur réussie : catégories, clavier/autofocus, succès unique, trophées, absence de listes et historique partagé. Compilation Astro/postbuild PWA réussie ; aucun ajout de dépendance ni changement du verrou. Validation CLI des quatre fichiers réussie. Pas de publication, aucune donnée réelle migrée.