[P1] `dsoxlab start` : une commande d'entrée unique au lieu de six gestes à connaître

[stephrobert]

Contexte

Pour commencer un lab, l'apprenant doit aujourd'hui savoir dans quel ordre
enchaîner des commandes dont aucune ne dit qu'elle en suppose une autre. Le
premier run d'un lab vm sur une infrastructure non provisionnée échoue, et
l'apprenant doit deviner qu'il lui manquait provision.

État actuel vérifié

Le README expose la séquence attendue (README.md:74-88) :

git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training
dsoxlab list-labs
dsoxlab show <id>
dsoxlab guide <id>
dsoxlab run <id>
dsoxlab check <id>

et provision n'y figure même pas, alors que les labs vm en dépendent.

Les commandes existantes sont bien séparées par responsabilité (use, provision,
run, course, challenge, check), ce qui est juste pour un usage avancé,
mais laisse l'ordonnancement à la charge de l'utilisateur.

Ce qu'on veut

dsoxlab start [<id>] : une seule commande qui, dans l'ordre, pose le contexte,
vérifie les dépendances requises pour ce lab, provisionne si nécessaire, démarre
les services déclarés, prépare le répertoire de travail, affiche la mission, et
ouvre la session. Chaque étape annonce ce qu'elle fait et s'arrête sur un message
actionnable, jamais sur une trace.

Les commandes unitaires restent, sans changement de comportement : start les
orchestre, il ne les remplace pas.

Critères d'acceptation

• dsoxlab start <id> amène un apprenant de zéro à une session utilisable
  pour un lab shell et pour un lab vm.
• Chaque étape est annoncée et son échec nomme la commande unitaire à rejouer.
• start est idempotent : relancé sur un lab déjà prêt, il reprend la session
  sans reprovisionner.
• Aucune commande existante ne change de comportement.
• Aide CLI + i18n EN + FR + fullhelp EN/FR mis à jour simultanément.
• Tests sur les deux runtimes, dont un cas « infrastructure absente ».
• CHANGELOG EN + FR, bump de version.

Priorité et lot

P1, jalon 0.2.x. Dépend de la machine d'état du lab (issue suivante) : start a
besoin de savoir où en est le lab pour décider ce qu'il doit faire.

[stephrobert]

Position révisée : à instruire sur retours d'usage, pas par principe

Cette issue était placée haut dans l'audit initial. Un second audit, joué après la livraison de dsoxlab demo (#72), revient sur cette position, et l'argument tient.

Ce qui a changé. Le problème que start visait était l'enchaînement de gestes à connaître avant de jouer un lab. demo l'a supprimé pour un nouvel arrivant : uv tool install dsoxlab puis dsoxlab demo suffisent désormais à atteindre un premier 100/100, sans hyperviseur ni catalogue.

Le risque, lui, reste entier. Une commande qui enchaîne implicitement contexte, dépendances, provisionnement, services, préparation et session rend les échecs plus opaques. Quand dsoxlab start échoue, l'utilisateur doit deviner laquelle des six étapes a cassé. C'est précisément le travail que cette milestone vient de faire dans l'autre sens : #98, #99, #102, #105 et #106 ont consisté à nommer ce qui manque plutôt qu'à le masquer.

Et pour un outil pédagogique, la séquence est du contenu. Voir qu'une infrastructure est provisionnée, puis qu'un lab est préparé, puis qu'une session s'ouvre, fait partie de ce qu'un apprenant vient apprendre. Un start qui avale les trois lui retire une distinction qu'il devra faire lui-même le jour où il travaillera sans dsoxlab.

Ce que cette issue devient

Elle reste ouverte, mais elle attend une demande réelle plutôt qu'une intuition. Deux choses la débloqueraient :

• des retours d'utilisateurs qui butent effectivement sur l'enchaînement des commandes, une fois demo et le README passés en 0.1.45 ;
• la machine d'état de [P1] Machine d'état explicite du lab, et un status qui la rende (l'actuel devient infra status) #80, qui donnerait à start de quoi dire où il en est et ce qui a échoué, au lieu de rendre un échec global.

Si elle est écrite un jour, le critère non négociable est celui-ci : start doit annoncer chaque étape et, en cas d'échec, nommer celle qui a cassé et la commande qui la rejoue seule. Sans quoi il retire au diagnostic ce que cette milestone vient d'y mettre.