Nexus : autopilot, travail parallèle et exécutions durables

Nexus est l’orchestrateur de Core. Il a quatre rôles : Scrum Master (sprints, stories, rétrospectives), Quick Flow (un petit changement avec un minimum de cérémonie), Autopilot Controller (le pipeline de l’idée à la livraison, avec points de contrôle) et Parallel Supervisor (plusieurs agents à la fois, sans collision). En dessous, un runtime durable, bmad-plus nexus, garde sur disque des graphes de tâches et des tentatives, pour que le travail survive à une session fermée et que rien ne compte comme fait tant que des contrôles indépendants ne le disent pas. Cette page s’adresse à qui veut automatiser le travail de plus d’un agent et savoir exactement jusqu’où va l’automatisation.

Autopilot#

Dites autopilot dans la conversation de votre outil IA, puis décrivez le projet. Ce sont des instructions de conversation, pas des commandes de terminal. Nexus examine la demande et le projet avant de choisir les étapes : un petit changement va directement à l’implémentation et à la revue, alors qu’un contrat manquant ou une incertitude lourde de conséquences justifie une planification plus poussée. Pour un projet qui demande le pipeline complet, il y a trois phases.

Chaque point de contrôle suit le réglage de _bmad/config.yaml : require_approval s’arrête et attend, notify_only informe et continue, auto continue et consigne. Avec execution_mode: autopilot, le point de contrôle story passe par défaut à notify_only. Une notification externe (un message sur votre téléphone, par exemple) demande un canal configuré et votre autorisation : une installation nue n’a aucun émetteur en arrière-plan, donc aucun rappel n’est envoyé de lui-même.

La recette humaine s’y insère aussi. Avec uat.mode: advisory (par défaut, y compris quand le bloc est absent), la page est construite et proposée à chaque livraison sans jamais bloquer ; gate fait attendre au point de contrôle de livraison que bmad-plus uat gate réussisse ; off ne produit aucune recette et le rapport de livraison le dit. Un pack peut aussi déclarer un pipeline dans le registre (étapes ordonnées, chacune avec une porte) ; autopilot déroule alors ce pipeline pour le travail du pack, après son intake. Aucun pack n’en déclare en 0.23.0 : c’est une capacité du framework, pas du contenu livré.

État, reprise et échecs#

• L’état de référence vit sous .bmad-plus/nexus/runs/. Le fichier facultatif .bmad-plus/orchestrator-state.yaml n’est qu’un résumé de navigation ; il ne peut pas prouver qu’une chose est acceptée ni qu’un processus s’est arrêté.
• Il n’existe pas d’exécutable autopilot --resume. Pour reprendre, inspectez l’exécution durable visée et l’état réel de l’hôte, et réconciliez une tentative interrompue avant de réessayer.
• Échec de test : les contrôles en échec sont conservés, la réparation se fait dans la limite maxAttempts de la tâche, puis les artefacts modifiés sont revérifiés. Une déclaration de fin ne peut pas faire réussir un contrôle en échec.
• Erreur d’agent : le travail partiel et l’identité de sa tentative sont préservés, et le rapport dit ce qui reste incertain. Les tâches dépendantes attendent l’acceptation.
• Conflit en travail parallèle : on cesse d’attribuer du travail qui se chevauche, on inspecte les propriétaires, on réconcilie leurs tentatives et on garde vos modifications avant tout nouvel essai.

Le travail parallèle#

Dites parallel dans la conversation, ou laissez autopilot l’appeler quand parallel_execution vaut true et que des tâches indépendantes sont détectées. Le Parallel Supervisor décide ce qui peut tourner en même temps ; l’hôte décide s’il le peut. Le vrai parallélisme dépend de votre outil : s’il ne sait pas lancer de sous-agents, les tâches s’exécutent l’une après l’autre.

Le runtime durable#

bmad-plus nexus conserve un graphe de tâches et ses tentatives sous .bmad-plus/nexus/runs/. Tout changement ordinaire prend un verrou exclusif du projet et écrit un fichier d’état avec somme de contrôle, via un fichier temporaire vidé sur disque puis un renommage atomique. L’inspection est en lecture seule. Trois issues sont tenues séparées, et cette séparation est l’intérêt même du runtime.

Les preuves restent honnêtes dans le temps. Une tâche acceptée ne compte comme à jour que tant que ses artefacts, ses ressources protégées et chaque dépendance transitive correspondent encore à ce qui a été vérifié : modifier un fichier en amont invalide les preuves des dépendants, et un ancien enregistrement « accepté » n’affirme pas que des fichiers modifiés depuis passent encore. Une échéance est une observation, pas la preuve qu’un travail n’a jamais eu lieu ou qu’un processus s’est terminé.

Le fichier de plan#

Un plan est un fichier JSON ; les entrées structurées passent toujours par des fichiers pour que le quoting du shell ne puisse pas réinterpréter un tableau de commande. Ce plan minimal a une tâche dont le résultat doit satisfaire un contrôle qui existe déjà (checks/check-result.cjs) et dont la source se trouve hors du périmètre d’écriture du worker.

{
  "id": "example",
  "maxParallel": 1,
  "config": { "language": "English" },
  "tasks": [
    {
      "id": "result",
      "objective": "Produce the requested result in work/result.txt.",
      "acceptance": ["The result satisfies the independent check."],
      "dependsOn": [],
      "scope": ["work"],
      "artifacts": ["work/result.txt"],
      "resources": ["checks/check-result.cjs", ".agents/skills/agent-orchestrator/SKILL.md"],
      "checks": [
        {
          "id": "result-content",
          "command": "node",
          "args": ["checks/check-result.cjs"],
          "cwd": ".",
          "timeoutMs": 30000
        }
      ],
      "maxAttempts": 2,
      "deadlineMs": 3600000,
      "idempotent": true,
      "authorizations": ["Edit work/ and run the listed local check."]
    }
  ]
}

Les chemins d’un plan sont portables, relatifs au projet et utilisent /. Les chemins absolus, la remontée d’arborescence, les flux alternatifs, les noms réservés de Windows, les liens symboliques ou jonctions, et les écritures dans .git ou dans l’arbre d’état de Nexus sont rejetés. Les contrôles s’exécutent dans un environnement restreint : seuls PATH, SYSTEMROOT, WINDIR, TEMP, TMP et TMPDIR peuvent être copiés (plus quelques variables d’identité et de chemin non secrètes sous Windows), la locale est C, le fuseau est UTC, et NODE_OPTIONS, PYTHONPATH, les hooks de chargement et les identifiants sont absents. C’est une restriction d’environnement, pas un bac à sable du système d’exploitation.

Le flux géré par l’hôte : create, start, record, verify, accept#

Le backend par défaut est l’hôte : votre assistant fait le travail avec ses propres moyens et en rend compte. Ci-dessous, une exécution réelle d’un fanout exporté depuis un essaim (trois unités de page ; seule la première est déroulée). Créez les trois fichiers de l’essaim et host.json dans un projet pour la reproduire. Le « worker » est une doublure qui écrit à la main le fichier de réponse : l’exemple montre la comptabilité, pas le travail d’un modèle.

{
  "schemaVersion": 1,
  "id": "site-pages",
  "kind": "fanout",
  "title": "One sub-agent per page of the site",
  "units": { "source": "input" },
  "brief": { "template": "briefs/page.md", "context": [] },
  "answer": {
    "required": ["id", "done", "words"],
    "fields": {
      "done": { "type": "boolean" },
      "words": { "type": "integer", "min": 0 },
      "note": { "type": "string", "max": 200 }
    }
  },
  "tally": { "rate": "done", "numbers": ["words"] },
  "disclosure": "Each page was written by a separate sub-agent from the same brief; read them together before publishing."
}

{
  "schemaVersion": 1,
  "units": [
    { "id": "about", "scope": "site/about", "title": "About us", "tone": "warm" },
    { "id": "pricing", "scope": ["site/pricing", "site/data/prices.json"], "title": "Pricing", "tone": "plain" },
    { "id": "contact", "scope": "site/contact", "title": "Contact", "tone": "short" }
  ]
}

# Page {{unit.id}}

Write the page "{{card.title}}" under `{{card.scope}}`, {{card.tone}} in tone. Touch nothing
outside that folder.

When the page is written, write a JSON object to `{{answer.path}}` with `id` ("{{unit.id}}"),
`done`, `words` (the word count) and an optional `note`.

{{disclosure}}

{ "backend": { "kind": "host", "id": "demo-worker", "sessionId": "demo-session-1" } }

$ npx bmad-plus swarm init --definition swarm/page-fanout.json --units swarm/units.json
site-pages-20261019-vwk0: fanout of 3 units, budget 26, approval not-needed.
Units listed, no seed.
Next: bmad-plus swarm briefs site-pages-20261019-vwk0
$ npx bmad-plus swarm plan site-pages-20261019-vwk0 --out .bmad-plus/swarm/reports/site-pages-20261019-vwk0/plan.json
/work/demo/app/.bmad-plus/swarm/reports/site-pages-20261019-vwk0/plan.json: 3 tasks, 10 in parallel.
Next: bmad-plus nexus create --plan /work/demo/app/.bmad-plus/swarm/reports/site-pages-20261019-vwk0/plan.json
$ npx bmad-plus nexus create --plan .bmad-plus/swarm/reports/site-pages-20261019-vwk0/plan.json
Nexus run site-pages-20261019-vwk0 — durable task coordination
about: not started; verification=pending; acceptance=pending
pricing: not started; verification=pending; acceptance=pending
contact: not started; verification=pending; acceptance=pending
Use inspect --json for recorded evidence and reconciliation observations.
$ npx bmad-plus nexus start site-pages-20261019-vwk0 about --input host.json
about: running; verification=pending; acceptance=pending
  Attempt: a4ec0495-660b-487c-8c83-e82ada22a857; host: demo-worker/demo-session-1
$ echo '{"id":"about","done":true,"words":120}' > .bmad-plus/swarm/runs/site-pages-20261019-vwk0/answers/about.json
# Le worker de substitution écrit son fichier de réponse à la main. Écrivez ensuite rec.json (montré sous ce terminal) avec l’id de tentative affiché par start.
$ npx bmad-plus nexus record site-pages-20261019-vwk0 about --input rec.json
about: completed; verification=pending; acceptance=pending
  Attempt: a4ec0495-660b-487c-8c83-e82ada22a857; host: demo-worker/demo-session-1
$ npx bmad-plus nexus verify site-pages-20261019-vwk0 about
about: completed; verification=passed; acceptance=pending
$ npx bmad-plus nexus accept site-pages-20261019-vwk0 about
about: completed; verification=passed; acceptance=accepted
$ npx bmad-plus nexus inspect site-pages-20261019-vwk0
about: completed; verification=passed; acceptance=accepted
  Accept only after rechecking current artifacts and resources.
pricing: not started; verification=pending; acceptance=pending
  Start when dependencies have current accepted evidence.
# Chaque commande nexus affiche aussi la ligne d’en-tête, les lignes pricing et contact et l’indication finale ; seules les lignes qui changent sont gardées ici.

{
  "attemptId": "a4ec0495-660b-487c-8c83-e82ada22a857",
  "backend": { "kind": "host", "id": "demo-worker", "sessionId": "demo-session-1" },
  "outcome": "completed",
  "exitCode": 0,
  "summary": "The demo host reports the about page is written."
}

record exige l’id exact de la tentative et les mêmes backend et session. Les autres issues sont failed, blocked (la demande reste visible et garde sa capacité) et ambiguous (les acquittements ordinaires sont alors refusés ; réconciliez explicitement). verify sort avec 1 quand la vérification n’a pas réussi, et accept refuse une tâche sans vérification réussie éligible. Le code de sortie d’un worker ou une phrase disant « terminé » ne remplace jamais un reçu de contrôle.

Interruption, annulation et nouvel essai#

Le backend de processus facultatif et l’adaptateur Codex#

Une tâche peut porter un objet execution au lieu d’appartenir à l’hôte. C’est une définition fournie par l’opérateur, jamais une commande déduite du texte de la tâche. nexus launch RUN TASK reste alors au premier plan jusqu’à la fin de l’opération qu’il possède ; un terminal, un hôte de code ou un runner de CI le maintient en vie. L’enregistrement de la tâche est sauvé avant le lancement du processus : il lie un nouvel id de tentative à une nouvelle session de superviseur, à la définition exacte et aux hashes de ses entrées protégées. Le superviseur garde stdout et stderr bornés, la sortie ou le signal réels, et un reçu avec somme de contrôle. launch laisse la collecte en attente même après une sortie propre : nexus collect RUN TASK --input attempt.json (l’attemptId exact et tout l’objet backend) la clôt, et refuse un reçu étranger, répété ou tardif. Le statut 0 de launch signifie seulement que le reçu du processus dit « completed » ; cela ne veut pas dire acceptation.

{
  "execution": {
    "adapter": "command",
    "command": "node",
    "args": ["workers/task.cjs"],
    "cwd": ".",
    "input": "inputs/task.json",
    "resources": ["workers/task.cjs"],
    "blockedExitCodes": [75],
    "outputLimitBytes": 262144
  }
}

{
  "execution": {
    "adapter": "codex-exec",
    "command": "/absolute/path/to/codex",
    "input": "inputs/task.md",
    "instructions": [".agents/skills/agent-architect-dev/SKILL.md"],
    "sandbox": "workspace-write"
  }
}

• L’exécutable est résolu vers un fichier ordinaire et son SHA-256 est épinglé dans le plan. Les arguments sont des tableaux littéraux, passés sans shell, sans surcharge d’environnement et sans instantané d’identifiants.
• Les entrées texte font 256 Kio chacune au plus et le paquet entier 1 Mio. Les instructions sont placées avant l’entrée standard, avec leurs chemins relatifs.
• Une sortie à zéro est un succès générique ; un code non nul listé dans blockedExitCodes est bloqué. Cette liste est une convention de votre enveloppe, jamais une politique d’approbation.
• L’adaptateur Codex construit -a never exec --json --color never --sandbox MODE --skip-git-repo-check --ignore-user-config - ; model est facultatif et n’ajoute que --model MODEL. sandbox vaut read-only (défaut) ou workspace-write ; aucun autre drapeau, aucun contournement d’approbation et aucune chaîne shell n’est accepté. Seuls HOME, USERPROFILE, HOMEDRIVE, HOMEPATH et CODEX_HOME peuvent être hérités au-delà de l’environnement minimal, et les reçus listent des noms de variables, pas des valeurs.
• L’achèvement Codex exige une sortie à zéro, une identité thread.started et un événement turn.completed sans erreur terminale. Seuls les codes d’erreur explicites approval_required sont traduits en bloqué ; les autres erreurs du fournisseur restent des échecs.
• L’annulation est liée à l’identité renvoyée. Seul le superviseur d’origine peut signaler le processus enfant direct qu’il a créé ; rien ne tue un PID sauvegardé ni n’adopte un ancien terminal. Une échéance, une sortie excessive ou un superviseur perdu produit un résultat ambigu et garde la capacité jusqu’à la réconciliation.
• Preuve honnête : le contrat de drapeaux a été vérifié sur Codex CLI 0.153.4. Un appel autorisé le 2026-09-11 a produit un vrai fil et un événement terminal, mais l’hôte a rejeté en lecture seule la modification de fichier demandée ; Nexus a collecté le reçu, le vérificateur indépendant a échoué et l’acceptation a été refusée. Cela montre le câblage et le confinement de l’échec sur cet hôte ; l’écriture réussie de fichiers par Codex n’y a pas été établie.

Limites et ce qu’il ne fait pas#

• Pas de démon, pas de planificateur, pas de boucle sans surveillance. Chaque lancement est explicite et retient une place de capacité ; la capacité n’est pas un budget d’argent.
• Pas de bac à sable du système d’exploitation. Les workers partagent le projet et l’utilisateur du système avec Nexus et peuvent ignorer les scopes déclarés ; les sommes de contrôle détectent un changement accidentel, ce ne sont pas des signatures. Protégez le plan et le vérificateur, et utilisez un projet isolé ou une politique d’hôte quand c’est important.
• Pas de commit Git, de fusion ni de déploiement. L’acceptation veut dire « l’espace de travail courant a réussi les contrôles indépendants », rien de plus.
• Aucune affirmation sur la qualité d’un modèle. Un reçu n’est pas la preuve qu’un modèle s’est amélioré en quoi que ce soit.
• Un délai de vérification dépassé ne signale que l’enfant direct et enregistre un résultat ambigu, car l’absence de descendants ou d’effets extérieurs n’est pas prouvée. Les programmes de contrôle doivent être des commandes bornées, au premier plan.

autopilot. Le projet : une petite API qui permet à des indépendants d’envoyer des devis et de les transformer en factures. Commence par l’intake de tout pack concerné. Arrête-toi au point de contrôle du PRD et à celui de l’architecture et attends mon approbation. Garde chaque story petite, vérifie chacune par rapport à ses critères d’acceptation avant la suivante, et dis-moi à la fin ce qui reste incertain.

parallel. Prends les stories approuvées et découpe-les en tâches qui ne touchent pas les mêmes fichiers. Pour chaque tâche, donne un périmètre d’écriture exclusif, les fichiers qu’elle peut lire et un contrôle que je peux lancer. Enregistre le plan avec bmad-plus nexus create, ne lance ensemble que les tâches indépendantes et montre-moi nexus inspect après chaque vague. N’accepte pas une tâche avant que nexus verify ait réussi.