chore(release): 0.3.0

[stephrobert]

Summary

La préparation du tag v0.3.0 : version, sections de CHANGELOG, liens de comparaison, uv.lock.

Le jalon compte huit issues, et un fil commun qui vaut d'être nommé : ce qui ne peut pas être vérifié ne doit pas conclure. Il court de la politique d'URL — une valeur de catalogue est une donnée, jamais une instruction — jusqu'au job qui provisionne une vraie VM, en passant par le socle dont le marqueur ne s'écrit qu'après un succès.

Ce que la version apporte

Issue	Ce qui change
#273	une politique d'URL centrale pour les valeurs d'un catalogue non fiable, et un affichage qui ne lui obéit plus
#269	learning.portal_url : chaque catalogue déclare son portail, le moteur n'en connaît aucun
#271	dsoxlab export --lab et --out : une preuve unitaire, en fichier ou en copier-coller
#270	un lien de remise après submit, la preuve dans un fragment d'URL, et rien d'envoyé
#213	infra.bootstrap : le socle d'un catalogue, joué une fois après le provisionnement
#200	les invariants du projet écrits, chacun avec le bug qui l'a révélé
#243	un job de CI qui provisionne et détruit une vraie VM KVM
#232, #222	lab_type: validation et prerequisites

Deux corrections qui touchent directement les utilisateurs : l'appliance s'importe enfin sous VMware — l'empreinte du manifeste n'était pas celle que son lecteur calcule, 64 512 octets d'écart mesurés sur le fichier publié, et l'identifiant d'OS la ramenait à un profil 32 bits (#279) ; et une coupure réseau n'est plus rendue comme un défaut de lab (#224).

La documentation a été relue en entier avant ce tag

C'était la condition posée. La relecture a trouvé onze points bloquants, dont deux défauts de code introduits pendant ce même jalon :

• destroy laissait le marqueur du socle, si bien qu'un provision suivant le sautait et que les labs tournaient sur une machine nue — la panne même que infra.bootstrap devait supprimer ;
• DSOXLAB_PORTAL_LOCAL=0 activait la dérogation de sécurité, la valeur n'étant testée que non vide.

Les deux sont corrigés, et chacun porte son test. Le reste de l'audit — 19 inexactitudes et 9 remarques — a été appliqué, sauf les points de forme.

État des contrôles avant tag

scripts/check-release.py sur cette branche :

✔ Le tag v0.3.0 correspond à la version empaquetée
✔ Le tag v0.3.0 est libre en local
✔ CHANGELOG.md décrit la version 0.3.0
✔ CHANGELOG.fr.md décrit la version 0.3.0
✔ uv.lock est aligné sur la version
✔ La version 0.3.0 est libre sur PyPI
✔ Les 95 versions annoncées sont publiées
✔ CI verte sur ce commit

Les deux contrôles restants exigent un arbre propre et la branche main : ils passeront après ce merge, et je les rejoue avant de poser le tag.

Type of change

• Bug fix
• New feature
• Refactor
• Documentation
• Chore / tooling
• Security / supply chain

Checklist

Always

• uv run ruff check … passes
• uv run mypy src/dsoxlab passes (strict)
• uv run pytest passes — 1280 tests
• uv run pytest tests_e2e passes
• The engine stays domain-agnostic
• No hardcoded personal path or host
• Manually tested : check-release.py joué, uv lock confirmant que la seule ligne à changer était celle de la version

When behavior changes

• Les deux CHANGELOG portent la section [0.3.0] - 2026-09-30 et son lien de comparaison
• Version bumped dans pyproject.toml et uv.lock — c'est l'objet de cette PR. __version__ la lit par importlib.metadata, donc rien à synchroniser dans src/dsoxlab/__init__.py

When a command or option is added, removed or changed

• N/A.

When .github/workflows/ is touched

• N/A. Le tag déclenchera release.yml (PyPI) et appliance.yml (les images), qui existent déjà.

When the declarative contract changes

• N/A pour cette PR ; le contrat de la 0.3.0 est documenté par les lots qui l'ont fait évoluer.

Ce que le tag déclenchera

La publication PyPI, et la reconstruction de l'appliance avec l'OVA corrigée — c'est elle qui débloque les utilisateurs VMware.

🤖 Generated with Claude Code