Approche
Comment une leçon est fabriquée.
Un historique brut n’est que du bruit. Une question sans corrigé aussi. Une leçon, c’est du travail réel, relié en une seule histoire, débarrassé de tout ce qui est privé, et rattaché à un contrôle qui dit réussite ou échec sans intervention humaine.
Le processus
Six étapes, à chaque fois.
- 1.
Collecter
Nous rassemblons chaque système qu’un travail a traversé : spécifications, chat, fichiers de design, code, revues, exécutions de CI et déploiements. Chaque fichier reçoit une somme de contrôle à la source, pour que son historique puisse être retracé plus tard.
- 2.
Relier
Les enregistrements sont réunis en un seul épisode grâce aux noms, aux chemins de fichiers, aux références de pull requests et à la chronologie. Chaque lien porte un score de confiance et les preuves qui le fondent. Les liens fragiles sont vérifiés à la main ou écartés.
- 3.
Protéger
Les personnes deviennent des pseudonymes de rôle stables. Secrets, identifiants et données clients sont retirés en deux passes : une détection automatique de motifs, puis une relecture humaine. Les droits, la confidentialité et les conditions de licence sont examinés séparément à chaque publication. Ce que nous ne pouvons pas valider, nous ne le livrons pas.
- 4.
Reproduire
Pour les tâches, nous reconstruisons l’état défaillant et l’état corrigé directement depuis le gestionnaire de versions, et nous exécutons le build et les tests du projet lui-même. Une tâche n’est livrée que si l’état cassé échoue et que le correctif réussit, à chaque exécution.
- 5.
Noter
Les tâches de code sont notées par des tests visibles et cachés. Les tâches du Workshop sont notées sur l’état final du système, jamais sur ce que dit l’agent. Les tâches de langue combinent des champs à correspondance exacte et une grille pondérée.
- 6.
Documenter
Chaque publication est livrée avec une fiche de données : ce qu’elle contient, comment elle a été produite, ce qui a été retiré, et la provenance de chaque fichier.
Les scénarios de la Guild franchissent le même seuil. Chacun est écrit par un professionnel qui fait ce travail dans la région, à partir des documents et des règles de ce marché, de la facturation électronique saoudienne à la paie du Golfe, et noté sur l’état final des comptes, de la commande ou de la boîte de réception.
Difficulté
Trois niveaux, notés de trois façons.
| Niveau | Ce qu’il demande | Comment il est noté | Exemple |
|---|---|---|---|
| Niveau 1 | Une modification isolée, souvent dans un seul fichier. La difficulté tient au diagnostic. | Tests visibles et cachés | Un événement récurrent qui dérive au passage à l’heure d’été |
| Niveau 2 | Un bug à remonter à travers plusieurs fichiers à partir d’un rapport ou d’un build en échec. | Tests, plus un contrôle du périmètre de ce qui a changé | Un remboursement qui compte la taxe en double sur des factures à taux mixtes |
| Niveau 3 | Un workflow métier en plusieurs étapes, à travers des applications, des documents ou des langues. | Contrôles d’état sur l’environnement final | Rapprocher la facture d’un fournisseur allemand de la commande et de la réception d’un acheteur de Riyad, payer ce qui est dû, et répondre en allemand |
Voyez-en un de chaque, entièrement détaillé, sur la page des exemples.
Pourquoi l’historique compte
La même fonctionnalité, trois architectures.
Bearish OS, une plateforme d’entreprise déployée à l’international, a évolué en trois générations, d’une première pile Express et MongoDB à une plateforme NestJS et Postgres dotée d’une couche multi-agents. De nombreuses fonctionnalités existent dans les trois versions, chacune avec ses propres décisions, ses bugs et ses correctifs. Un modèle peut ainsi apprendre pourquoi les conceptions changent, et pas seulement à quoi elles ressemblent à la fin. Et comme le Workshop fait tourner ce même système, un agent peut étudier comment une fonctionnalité a été construite, réparer ce qui y a cassé, puis l’utiliser en conditions réelles.
Notre exigence
Ce que chaque publication doit satisfaire.
Jamais publié
Notre travail source n’a jamais été sur le web ouvert : les modèles ne peuvent donc pas en avoir mémorisé les réponses.
Déterministe
Chaque tâche est vérifiée sur des exécutions propres répétées avant publication. Les tâches instables sont écartées.
Évaluateurs scellés
Les tests cachés et les correctifs de référence n’atteignent jamais l’agent, ni à l’entraînement ni à l’évaluation.
Provenance documentée
Chaque fichier a une origine connue et un parcours documenté jusqu’à la livraison. Les droits et les licences sont examinés à chaque publication.