Atelier B — Publier une API sans hallucination
Scénario fictif : un agent produit une page SDK à partir d'une bibliothèque fictive.
- Épingler le commit et extraire les exports publics (
rustdocet extraction d'API selon compatibilité toolchain). - Déclarer le statut de chaque interface :
public-stable,public-experimental,internal. - Faire produire une proposition de guide à un LLM local isolé.
- Compiler un exemple minimal depuis
examples/et vérifier les symboles utilisés. - Relier toute affirmation à une preuve de type E1, E2 ou supérieure adaptée.
- Produire FR + EN, liens réciproques et notes de version.
Critères de réussite
Pas de symboles inventés, aucun accès cloud implicite, exemples qui compilent, classification publiée avec limites et revue humaine documentée.Essai reproductible
Depuis la racine du dépôt, sans installation ni modèle :
python3 examples/api_lab.py --symbol Queue.morph_to
# expected exit 1
python3 examples/api_lab.py
# expected exit 0
python3 scripts/test_labs.py
Observation et exercice
Le cas négatif demande Queue.morph_to, absent de l’inventaire AST ; le cas positif utilise Queue.enqueue et vérifie son résultat. Ajoute un export fictif et son exemple, puis une signature inconnue. Le support Python réduit les prérequis ; le transfert vers Rust exige une preuve séparée avec toolchain épinglée. Le LLM est optionnel : rédige le guide à partir de l’inventaire si aucun modèle autorisé n’est disponible.
Preuves et limites
Conserve commandes, sorties, codes de retour et HEAD. Le RED doit échouer sur le doublon ou symbole inconnu, jamais sur un environnement cassé. Ces supports n’exécutent aucune action système ni moteur graphique, et ne certifient aucune API externe.