Verrous finaux avant 1.0

Cette page sert de point de contrôle pour la promotion vers 1.0.0-rc.1, puis vers 1.0.0. Elle ne remplace pas les scripts : elle indique quoi exécuter, où conserver les preuves et quelles décisions restent manuelles.

Matrice GitHub Actions à stabiliser

Le workflow dédié est .github/workflows/rc-stability.yml. Lancez-le depuis GitHub Actions sur le dépôt réel, pour le même commit que celui qui servira à publier la release candidate.

La matrice exécute trois passes avec bun install --frozen-lockfile :

bun install --frozen-lockfile
bun run release:doctor
bun run e2e:ci:functional
bun run release:browser:check
bun run package:ci:artifact
bun run npm:publish:dry-run -- --skip-gates

Après trois passages verts, renseignez release/rc-ci-stability.json avec les liens de runs, le SHA Git et la date. Ne mélangez pas des runs issus de commits différents.

Revue d’accessibilité à compléter

La revue automatisée reste nécessaire, mais elle ne suffit pas pour la promotion 1.0. Complétez release/manual-accessibility-review.json avec ces contrôles :

Contrôle	Attendu
keyboard-only	Navigation complète sans souris, focus visible, actions de dialogue réversibles.
zoom-200	Interface utilisable à 200 %, sans perte d’information critique.
reflow-320-css-px	Lecture et actions principales possibles à 320 CSS px.
nvda-chromium	Parcours NVDA sous Chromium, annonces cohérentes des panneaux, dialogues et champs.
custom-theme-contrast	Contraste vérifié après personnalisation du thème.
artifact-review	Tarball, manifestes et exports publics revus avant publication.

Les dérogations éventuelles vont dans release/accessibility-derogations.json. Une dérogation doit rester bornée, justifiée, assortie d’une mitigation et d’une cible de correction.

Bundle et composants à surveiller

Le rapport CI de bundle est .artifacts/bundle-budget.json. Après bun run bundle:budget:inspect, exécutez :

bun run bundle:watchlist:check

Les deux zones à surveiller avant 1.0 sont Theme Builder et IconPicker. Si un chunk se rapproche du budget, découpez d’abord les branches d’édition non nécessaires au runtime public : presets lourds, chemins de popup, listes d’icônes ou options avancées.

Application métier distincte

Avant 1.0.0, intégrez 1.0.0-rc.1 dans une application Nuxt 4 distincte du dépôt QForm Builder. Renseignez release/rc-real-app-integration.json avec :

• source du package installé, npm ou tarball vérifié ;
• page qui rend FormBuilder et FormViewer ;
• import/export d’un document versionné ;
• relecture d’un document persistant par le registre public de migrations ;
• absence d’import direct depuis app/.

Après publication de la release candidate, seules les corrections compatibles doivent entrer avant 1.0.0.

Migration des schémas et thèmes

Le contrat de migration n’est plus un bloqueur fonctionnel : il existe déjà. Toute évolution future d’un document, d’un schéma ou d’un thème persistant doit passer par le registre public de migrations. La règle détaillée est dans la référence Politique de migration des schémas.