[P2] Les catalogues dupliquent la documentation du moteur, et elle y dérive

[stephrobert]

État vérifié

Nombre de fichiers Markdown hors labs/ qui décrivent le contrat du moteur
(schema_version, runtime.targets, lab.yaml) :

Dépôt	Fichiers
linux-dsoxlab-training	14
ansible-training	12
terraform-training	4

Soit trente pages qui expliquent, chacune à sa façon, ce que dsoxlab documente
déjà. Elles ne sont mises à jour par aucune release du moteur.

Ce que ça coûte

Le contrat a bougé quatre fois en une journée (fixtures, runtime.services,
codes de sortie, contrôles doctor). Chaque évolution demande aujourd'hui une
relecture de quatre dépôts, et rien ne signale ceux qui n'ont pas suivi.

C'est le même mécanisme que l'issue #195, à une échelle plus grande : une
documentation qui ment est pire qu'absente, parce qu'elle fait écrire du faux
avec assurance.

Partage proposé

Ce qui appartient au catalogue et doit y rester :

• son parcours pédagogique, ses prérequis matériels propres ;
• son installation spécifique (provider, réseau, clé SSH) ;
• ses procédures de récupération particulières.

Ce qui appartient au moteur et doit y renvoyer par un lien :

• le contrat meta.yml / lab.yaml et schema_version ;
• les commandes génériques et leurs options ;
• les runtimes, les codes de sortie, la sortie --json ;
• l'authoring (dsoxlab new, validate-structure).

Critères d'acceptation

• Un inventaire de ce qui est dupliqué, dépôt par dépôt, avant toute
  suppression : certaines pages ont peut-être divergé pour de bonnes raisons.
• Les sections purement moteur deviennent des liens vers docs/ de dsoxlab.
• Un contrôle, même simple, signale une page de catalogue qui redécrit le
  contrat — sans quoi la duplication reviendra à la prochaine urgence.
• Les trois catalogues sont traités, pas seulement celui qui a servi de
  référence.

---

Relevé en confrontant au code une analyse externe du dépôt, le 2026-08-24.