Préflight de la release candidate

La source 0.1.33 conserve le registre de preuves introduit en 0.1.21 avant la promotion vers 1.0.0-rc.1. L’objectif est d’éviter qu’une version soit qualifiée de candidate sur la seule base d’un build local partiel.

Frontières contrôlées

Le préflight couvre quatre catégories indépendantes :

1. le lockfile Bun correspond exactement aux dépendances directes de package.json ;
2. les douze baselines Playwright référencées par les tests sont présentes et hachées ;
3. le tarball npm, son manifeste et son SHA-256 correspondent à la version source ;
4. la revue humaine d’accessibilité et d’artefacts est terminée.

Le plan canonique est conservé dans :

release/rc-plan.json

La revue manuelle est enregistrée dans :

release/manual-accessibility-review.json

Ces deux fichiers appartiennent à l’archive de développement et sont exclus du package npm.

Le guide illustré possède un manifeste distinct :

docs/public/guide/screenshots/manifest.json

Avant la promotion RC, les douze captures FR/EN doivent provenir de Playwright :

bun run docs:guide:ci
bun run docs:screenshots:strict

Vérifier le lockfile

bun run lockfile:check

Ce contrôle compare les groupes dependencies et devDependencies de package.json avec le workspace racine de bun.lock, puis vérifie qu’une résolution existe pour chaque dépendance directe.

Après toute modification des dépendances :

bun install
bun run lockfile:check
bun install --frozen-lockfile

Ne pas corriger manuellement les résolutions du lockfile. Le diff doit provenir de Bun et être relu avant commit.

Préparer la revue manuelle

Dans release/manual-accessibility-review.json, renseigner un rôle générique plutôt qu’un nom personnel, par exemple qa-accessibility-reviewer. La revue porte au minimum sur :

• navigation clavier seule ;
• zoom navigateur à 200 % ;
• reflow à 320 pixels CSS ;
• NVDA avec Chromium ;
• contraste de thèmes personnalisés ;
• inspection du tarball, du manifeste et des rapports de bundle.

Chaque contrôle doit être passed ou exceptionnellement not-applicable avec une justification dans notes. L’issue globale doit être passed et reviewedSourceVersion doit correspondre à package.json.

Générer le registre de preuves

Après la gate qualité, les tests navigateur et la création du package :

bun run pack:artifact
bun run release:evidence:create

Le fichier suivant est généré :

.artifacts/release-candidate-evidence.json

Il contient les empreintes SHA-256 de package.json, bun.lock, du manifeste d’API publique, du plan RC et de la revue manuelle, ainsi que les hashes des captures et du tarball npm. Les métadonnées GitHub Actions sont ajoutées lorsqu’elles sont disponibles.

La génération n’affirme pas que la release est prête. Elle produit status: "blocked" tant qu’un prérequis manque et liste chaque blocage.

Vérification stricte

bun run release:evidence:verify

La commande échoue si les sources, les captures ou le package ont changé après génération, si le lockfile est incomplet, si la revue humaine est en attente ou si l’artefact npm ne correspond plus à son manifeste.

La gate complète est :

bun run release:candidate:check

Elle ne doit être exécutée qu’après inspection des baselines et finalisation de la revue manuelle. Une réussite signifie que la source 0.1.33 est prête à être promue vers 1.0.0-rc.1; la modification de version et la publication restent des actions explicites séparées.

Verrous finaux avant 1.0.0-rc.1

La préparation de 1.0.0-rc.1 passe maintenant par quatre preuves complémentaires : matrice GitHub Actions stable sur trois passages, revue accessibilité manuelle, revue bundle Theme Builder/IconPicker et intégration dans une application métier distincte. La page Verrous finaux 1.0 détaille les fichiers à renseigner et les commandes à exécuter.

Le contrat de migration des schémas et thèmes persistés n’est plus un bloqueur fonctionnel. Toute évolution future doit passer par le registre public de migrations.