Créer un workflow de développement
Passez d’un ticket aux questions, au plan validé, puis aux tests et au code vérifié.
Cet exemple part d’un ticket demandant un export CSV et suit un workflow de développement complet. Un agent pose les questions nécessaires au responsable du ticket, puis propose un plan. Après validation, les agents écrivent des tests en échec, réalisent la modification et la font relire. Le travail accepté est enregistré sur outpost/shop-142, avec un commit pour les tests et un autre pour le code.
Le workflow suit une règle de redline, un système qui mène un ticket jusqu’à une merge request, construit sur Outpost : le code décide, les agents jugent. Les agents répondent et modifient des fichiers ; votre code valide leurs réponses, lance les tests, refuse les modifications hors des fichiers de chaque rôle et fait les commits.
Ce que montre l’exemple
Section intitulée « Ce que montre l’exemple »- Tâches interactivesL’agent interroge le responsable, un point à la fois, puis rend le plan.
- ApprobationsLe responsable approuve le plan avant toute modification de fichier.
- Boucles de vérificationÉcrire, vérifier, renvoyer le refus, dans un nombre de tours limité.
- Réponses typéesLe relecteur rend un verdict validé.
- Sessions de sandboxUne sandbox chaude garde les dépendances entre les agents et les lancements de tests.
- Exécutions durablesUn checkpoint garde les réponses, le plan et les boucles terminées d’un processus à l’autre.
Écrire le script
Section intitulée « Écrire le script »Enregistrez les fichiers présentés dans les onglets à côté du outpost.config.ts de la page Installation. Ils sont regroupés par rôle : clarifier le ticket, préparer la sandbox, écrire les tests, réaliser la modification et fournir les fonctions qu’appelle votre application. Chaque fichier a une responsabilité ; les imports les relient.
Clarifier le ticket et approuver le plan
Section intitulée « Clarifier le ticket et approuver le plan »Commencez par le ticket, le format du plan attendu et l’étape d’approbation.
Préparer et réutiliser la sandbox
Section intitulée « Préparer et réutiliser la sandbox »Ces fonctions ouvrent une sandbox au début de la réalisation et la réutilisent pour les commandes et les agents.
Écrire et vérifier les tests
Section intitulée « Écrire et vérifier les tests »La boucle de tests refuse les modifications hors des fichiers de test et exige un échec avant de créer le commit.
Réaliser et relire la modification
Section intitulée « Réaliser et relire la modification »La boucle d’implémentation vérifie les fichiers modifiés, exécute les tests et demande une revue avant de créer le commit.
Assembler le workflow et son checkpoint
Section intitulée « Assembler le workflow et son checkpoint »Assemblez les tâches et le checkpoint, puis fermez la sandbox à la fin de chaque appel.
Envoyer les réponses et les décisions
Section intitulée « Envoyer les réponses et les décisions »Votre application importe les fonctions de run.ts pour transmettre les réponses et les décisions.
Votre application affiche questions dans un formulaire et plan sur une page de relecture. Chaque appel reconstruit le même workflow et le même checkpoint : il peut s’exécuter dans n’importe quel processus de la machine qui héberge le dépôt.
Comprendre les étapes
Section intitulée « Comprendre les étapes »Chaque lien indique qui transmet quoi à qui, dans le sens de la flèche.
Les vérifications s’enchaînent dans un ordre fixe, et le premier refus devient le retour du tour suivant :
| Boucle | Vérification, dans l’ordre | Refuse quand |
|---|---|---|
tests | Zone d’écriture | Aucun test modifié, ou un fichier hors test modifié |
tests | Lancement rouge : npm test | Les tests passent déjà : ils ne prouvent rien |
code | Zone d’écriture | Un fichier de test modifié |
code | Lancement vert : npm test | Les tests échouent ; leur sortie devient le retour |
code | Agent relecteur, defineJsonResponse() | approved vaut false |
Les agents ne commitent jamais. Chaque boucle ne commite qu’une fois toutes ses vérifications acceptées : un tour refusé laisse ses changements à corriger par la tentative suivante. answer() et decide() rendent la main après les tours d’agent suivants, qui peuvent durer plusieurs minutes : depuis une requête web, confiez-les à un worker de file de jobs.
Adapter l’exemple
Section intitulée « Adapter l’exemple »| Variante | Changement |
|---|---|
| Lire le ticket | Ajoutez une première defineTask() qui récupère le ticket dans votre outil de suivi et rend { key, text } ; lisez-le avec context.value() dans les briefs à la place de la constante. |
| Un relecteur adverse | Passez un autre agent dans la requête du relecteur, par exemple Claude Code avec createClaudeHarness() : un autre modèle manque d’autres choses (Choisir un agent). |
| Vérifications plus strictes | Ajoutez une vérification de types et un lint au lancement vert, ou un second relecteur qui vérifie que les tests échouent pour la bonne raison, comme le fait redline. |
| Ouvrir une merge request | Quand progress() rend branch, poussez-la depuis l’hôte et ouvrez une pull request brouillon avec gh pr create --draft --head, ou une merge request avec glab mr create --draft. |
| Plusieurs dépôts | Une paire de boucles par dépôt, enchaînées avec after dans l’ordre des dépendances (Modifier plusieurs dépôts). |
- Un refus termine l’exécution: Un plan refusé saute la livraison et l’exécution se termine en
failed. Démarrez un nouveaurunIdavec la remarque du responsable dans le brief. - Plan mal formé:
planlève une erreur, et l’exécution échoue sans redemander à l’agent. Utilisez une tâche en boucle pour laisser l’agent corriger son propre JSON. - Tours épuisés: Une boucle dont la dernière vérification refuse échoue avec
LoopTaskExhausted; les tâches terminées restent dans le checkpoint et la branche garde les tests commités. - Même machine: Le dépôt, ses worktrees et la conversation du cadrage doivent être accessibles au processus qui répond.
- Tour interrompu: Après un plantage juste après un commit, la vérification reprise ne trouve aucun changement et consomme un tour. Inspectez la branche avant de reprendre.
- Travail conservé: Le cadrage garde son worktree sur une branche
outpost/interactive-…; nettoyez-le une fois terminé.
API : defineInteractiveAgentTask · defineApprovalTask · defineLoopTask · defineAgentTask · defineJsonResponse · createSandbox · LoopTaskExhausted.