Du ticket au merge confirmé.

Préparer un ticket exécutable

/harden-card vérifie le périmètre, les critères d’acceptation, les dépendances et les tests. Une ambiguïté bloquante demande une décision humaine avant l’exécution.

La classification et la route sont conservées dans un commentaire Linear marqué delivery-routing:v1. Le ticket doit être hardened, prêt pour un agent et sans bloqueur ouvert.

Lancer l’orchestrateur

Depuis le repository consommateur :

node .agent-workflow/bin/run-card.mjs PROJ-123

Le runner ouvre un nouveau processus Codex. /start-card réconcilie l’état réel, prépare ou reprend le worktree et délègue les phases à des contextes neufs.

node .agent-workflow/bin/run-card.mjs PROJ-123 --dry-run

Implémenter, relire, corriger

1. L’implémenteur modifie le code, exécute les validations et retourne un commit.
2. Le ou les reviewers relisent ce commit et rendent un reçu lié à son SHA.
3. Les findings confirmés passent à un reworker dans un nouveau contexte.
4. Le nouveau commit fait l’objet d’une nouvelle review : les anciennes approbations ne valent plus.

Par défaut, 2 cycles de rework sont autorisés. Des avis de review contradictoires sont soumis à l’humain.

Livrer et savoir s’arrêter

Le shipper reçoit les approbations pour le commit courant. Il vérifie les gates, la PR, la CI et le merge, puis les contrôles de déploiement demandés par le projet.

Ces états sont terminaux pour la carte. L’orchestration ne choisit pas automatiquement une autre tâche.

Parcourir un backlog

La boucle externe démarre un processus neuf pour chaque carte éligible. Elle s’arrête à la première carte nécessitant une intervention, ou à la limite demandée.

node .agent-workflow/bin/backlog-loop.mjs --max-cards 3

Elle nécessite une équipe Linear configurée et des cartes déjà durcies. Les sorties locales se trouvent dans .delivery/, ignoré par Git.