Missions & Tasks
Ce que c'est
La colonne vertébrale de l'exécution. Une mission est un livrable unique que Genesis planifie, décompose en tasks et mène à terme ; une task est l'unité atomique qu'un Agent ou un Coder exécute. Les gates d'approbation humaine à l'intérieur du pipeline se matérialisent sous forme de decisions.
Surface opérateur
Les outils MCP couvrent l'ensemble du cycle de vie :
- Cycle de vie des missions —
mission_create,mission_get,mission_list,mission_decompose,mission_status,mission_pipeline_status. - Revue et approbation des tasks —
mission_tasks_list,mission_tasks_approve/mission_approve_tasks,mission_task_add. - Contrôle au niveau des tasks —
task_create,task_get,task_list,task_update,task_retry,task_reset_retry,task_cancel,task_delete. - Decisions (gates d'approbation humaine) —
decision_list,decision_get,decision_respond,decision_acknowledge,decision_bulk_acknowledge,decision_stats. - Runs & changements (couche d'acceptation) —
mission_run_start,mission_run_get,mission_run_accept,mission_run_discard,mission_revert_preview,mission_revert,mission_changement_stack. Voir Workflows §2.13 pour le modèle run/accept/revert complet.
La surface REST est constituée de MissionsController / TasksController / DecisionsController, et les missions s'affichent sur les pages mission du dashboard.
Comment ça marche
Une mission passe par Pending → Planning (décomposition) → InProgress → PendingReview → Completed / Failed, avec Paused comme état latéral reprenable et Cancelled comme sortie anticipée ; Completed, Failed et Cancelled sont terminaux. L'entité Mission enregistre son track, son kind, la liaison au project / matter, les cumuls de tokens / coûts, le modèle / provider sélectionné et les métadonnées de branche d'intégration. Le plan d'une mission peut provenir d'une décomposition LLM ou d'un Workflow publié compilé en elle — le cycle de vie ci-dessus est le même dans les deux cas ; seule la source du plan varie.
La décomposition est pilotée par LLM et résout le preset de site Missions:Decomposition — qui peut router vers un Coder conteneurisé ajoutant des tasks via mission_task_add. Les tasks (TaskDefinition + TaskEvent) sont dispatchées vers les Agents / Coders, et les étapes de gate se mettent en pause derrière des lignes Decision en attente, résolues avec decision_respond (approve / skip / fail). Les changements d'état des missions et des tasks transitent par une file d'événements (MissionEventQueue) consommée par l'agent dispatcher.
Les transitions de status illégales sont refusées, pas silencieusement ignorées. L'agrégat Mission possède la liste des transitions légales ; demander une transition qu'il n'autorise pas (p. ex. Failed → InProgress, ou tout changement hors d'un status terminal) est rejeté plutôt que transformé en succès no-op. En REST, l'endpoint de status renvoie un 409 avec le code mission.status.invalid-transition et un corps portant currentStatus, requestedStatus et legalTransitions ; l'outil MCP mission_status renvoie une erreur structurée INVALID_STATE_TRANSITION avec les trois mêmes champs — de sorte qu'un Agent ou un opérateur apprend ce qu'il peut faire au lieu de recevoir un succès pour un changement qui ne s'est jamais appliqué. La liste des transitions légales est dérivée des gardes de l'agrégat lui-même, elle ne peut donc pas diverger des règles réelles.
Completed est terminal, avec exactement une sortie sanctionnée : démarrer un nouveau run sur une mission terminée la rouvre en InProgress via une intention de réouverture explicite (ReopenForRun). Le chemin générique de mise à jour de status refuse toujours Completed → InProgress ; la réouverture pour un run est la seule façon dont une mission quitte Completed.
Les missions sont le substrat dans lequel se compilent les Workflows et que pilotent les Agents ; consultez ces guides pour les rouages internes de l'orchestration.