Aller au contenu

Orchestrateur

L’orchestrateur est la logique de planification qui lit le sprint, analyse les dépendances, et décide quelles tâches lancer. Ce n’est pas un agent spécial — c’est un ensemble de règles.

Les tâches sans dépendances démarrent immédiatement. Les tâches avec dépendances attendent que leurs prérequis soient terminés.

Ça fonctionne comme un Makefile ou un pipeline CI : un graphe acyclique dirigé (DAG) de tâches.

Chaque tâche suit 4 phases :

L’agent charge le contexte : manifest, memory, rules, board et l’issue.

L’agent applique le skill assigné (principal + auxiliaires) pour produire son output.

L’agent vérifie son propre travail : tests passent, pas de violations de sécurité, code conforme aux rules, self-review faite.

Mettre à jour le frontmatter de l’issue, déplacer le fichier, mettre à jour BOARD.md, écrire dans la memory si un apprentissage a eu lieu.

L’orchestrateur ne fonctionne pas en vagues rigides. Dès qu’une tâche a toutes ses dépendances terminées, elle démarre :

ISS-0001 (pas de dépendance) → démarre immédiatement
ISS-0001 terminée → ISS-0002 débloquée → démarre
ISS-0002 terminée → ISS-0003 ET ISS-0004 débloquées → démarrent en parallèle
ISS-0004 terminée → ISS-0005 débloquée → démarre (sans attendre ISS-0003)
TransitionGateQui valide
in-progress → reviewTests passent, self-review faite, CI verteAgent
review → doneCode review approuvéeHumain
Fin de sprintTous les critères qualité remplisHumain
  1. Ne jamais lancer une tâche dont les dépendances ne sont pas terminées
  2. Lancer dès que prêt — pas de vagues artificielles
  3. Un skill principal par tâche, avec des skills auxiliaires optionnels
  4. L’humain valide les quality gates
  5. En cas de doute, demander — un agent bloqué demande plutôt que de deviner
  6. Le frontmatter YAML est la source de vérité
  7. La sécurité est un skill auxiliaire par défaut pour les tâches non-documentation