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

> Autopilot avec points de contrôle, travail parallèle supervisé, export de plan depuis un essaim, et runtime durable (create, start, launch, collect, verify, accept), adaptateur Codex et limites.

Canonical: https://bmad-plus.rochetta.fr/fr/docs/concepts/nexus-orchestration/
Language: fr
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT

Documentation BMAD+ › [Concepts](https://bmad-plus.rochetta.fr/fr/docs/concepts/) › 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.

<a id="video-nexus-parallel"></a>
Video: [Nexus et le travail en parallèle](https://bmad-plus.rochetta.fr/media/nexus-parallel-fr.mp4) — Comment Nexus repère les tâches indépendantes, donne à chacune son périmètre d’écriture, consigne les résultats réels et exécute des contrôles indépendants avant d’accepter.
[Sous-titres (WebVTT)](https://bmad-plus.rochetta.fr/media/nexus-parallel-fr.vtt)

Transcription:

> Nexus coordonne le travail des autres rôles. Il cherche les tâches indépendantes, celles qui ne touchent aucun fichier commun. Chaque tâche reçoit son propre périmètre d’écriture, et ces périmètres ne peuvent pas se chevaucher. Les agents parallèles viennent de votre outil hôte. Sans eux, les tâches s’exécutent l’une après l’autre. Nexus peut aussi lancer une commande locale planifiée ou un processus Codex CLI, sous un superviseur au premier plan. Il consigne le résultat réel, puis exécute des contrôles indépendants avant que rien ne soit accepté. Aucun planificateur ne tourne en arrière-plan, et les permissions de l’hôte continuent de s’appliquer. En autopilot, le même enchaînement va de l’idée à la livraison, avec les points de contrôle que vous configurez.

Transcription avec description visuelle:

- **0:00** À l’écran : Un espace sombre. De fins rayons ambre traversent l’écran depuis les bords, convergent vers un point et s’embrasent en une étoile brillante. La légende « Nexus » apparaît d’abord, puis est remplacée par « Tâches indépendantes ». Voix off : Nexus coordonne le travail des autres rôles. Il cherche les tâches indépendantes, celles qui ne touchent aucun fichier commun.
- **0:09** À l’écran : Deux panneaux de terminal côte à côte. À gauche, on tape la commande bmad-plus nexus create --plan nexus-plan.json. Elle affiche « Nexus run demo — durable task coordination » et une ligne pour chacune de deux tâches, « value » et « notes », qui se terminent toutes par « not started; verification=pending; acceptance=pending ». Puis bmad-plus nexus inspect demo affiche le même résumé avec la ligne « Start when dependencies have current accepted evidence. » Le panneau de droite montre nexus-plan.json : une exécution avec « id »: « demo » et « maxParallel »: 2, et deux tâches. La première, « value », a pour objectif « Write the value 7 into src/value.json. » La seconde, « notes », a pour objectif « Write the release notes into docs/notes.md. », une ligne d’acceptation (« docs/notes.md exists and is not empty. »), un « dependsOn » vide, « scope »: [« docs/notes.md »] (entouré), « artifacts », « resources », une entrée « checks » qui lance un script node, « maxAttempts »: 2 et « idempotent »: true. Tout le texte du terminal est en anglais. Voix off : Chaque tâche reçoit son propre périmètre d’écriture, et ces périmètres ne peuvent pas se chevaucher.
- **0:18** À l’écran : Un réseau de sphères de verre reliées par de fines lignes ambre est suspendu dans un ciel étoilé sombre, avec une lueur ambre. Il passe d’un semis épars à un maillage connecté. La légende indique « Le parallélisme vient de l’hôte ». Voix off : Les agents parallèles viennent de votre outil hôte. Sans eux, les tâches s’exécutent l’une après l’autre.
- **0:26** À l’écran : Un terminal. La commande bmad-plus nexus launch demo value montre la tâche en « running », avec un identifiant de tentative et un identifiant de processus. Puis bmad-plus nexus collect demo value --input attempt.json la montre « completed », toujours avec « verification=pending; acceptance=pending ». bmad-plus nexus verify demo value; echo "exit code: $?" change la ligne en « verification=passed » (entouré) et affiche « exit code: 0 ». Une longue commande, bmad-plus nexus inspect demo --json filtrée par grep, sed et awk, liste la vérification qui a tourné : « command »: « /usr/local/bin/node », « policy »: « minimal-local-v1 » (entouré), « exitCode »: 0 et « stdout »: « value.json holds 7\n ». Enfin on tape bmad-plus nexus accept demo value, et la ligne d’état se termine par « verification=passed; acceptance=accepted », avec « acceptance=accepted » entouré. Tout le texte du terminal est en anglais. Voix off : Nexus peut aussi lancer une commande locale planifiée ou un processus Codex CLI, sous un superviseur au premier plan. Il consigne le résultat réel, puis exécute des contrôles indépendants avant que rien ne soit accepté.
- **0:44** À l’écran : Un nœud de fines lignes ambre emmêlées se redresse, ligne après ligne, en une grille carrée dont le centre est un point brillant. La légende indique « Pas de planificateur en arrière-plan ». Voix off : Aucun planificateur ne tourne en arrière-plan, et les permissions de l’hôte continuent de s’appliquer.
- **0:51** À l’écran : Une brume bleue terne avec un horizon lumineux qui s’éclaire lentement. La légende, en anglais, indique « Discovery · Build · Ship ». Voix off : En autopilot, le même enchaînement va de l’idée à la livraison, avec les points de contrôle que vous configurez.

<a id="autopilot"></a>
## 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.

**Le pipeline autopilot**

| Phase | Étapes | Point de contrôle |
| --- | --- | --- |
| 1. Discovery | Étape 0 : l’intake de chaque pack concerné par la demande. Puis Atlas (Analyste) : brainstorming et recherche de domaine ; Atlas (PM) : product brief et PRD ; Sentinel (UX) : spécification UX. | `discovery` : vous relisez le PRD et la spécification UX. |
| 2. Build | Forge (Architecte) : architecture ; Nexus (Scrum Master) : epics, stories, plan de sprint ; puis pour chaque story, en parallèle si elles sont indépendantes : implémenter, tester, rédiger les étapes de recette qu’une personne peut observer. Un contrôle en échec garde ses preuves et est réparé dans la limite de tentatives de la tâche. | `architecture` : vous relisez l’architecture. `story` : une notification par story terminée. |
| 3. Ship | Revue de code complète, revue UX, documentation, recette finalisée et remise à une personne, résultats lus et chaque échec classé, rétrospective. | `delivery` : vous relisez le livrable final, avec la recette citée. |

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é.

<a id="autopilot-state"></a>
### É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.

<a id="parallel"></a>
## 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.

**Ce qui peut et ne peut pas tourner en parallèle**

| Parallélisable | Séquentiel uniquement |
| --- | --- |
| Stories sans fichier commun | Stories qui modifient les mêmes fichiers |
| Recherches indépendantes (marché et technique) | Une tâche dont l’entrée est la sortie d’une autre |
| Tests pendant que la documentation s’écrit | Décisions d’architecture avant l’implémentation |
| Modifications de modules ou paquets séparés | Revue de code après l’implémentation |

**Les six actions de supervision**

| Action | Quand | Ce qui se passe |
| --- | --- | --- |
| Launch | Tâches indépendantes détectées | Démarrer des sessions d’agents parallèles. |
| Monitor | En continu | Suivre l’avancement dans l’exécution Nexus. |
| Pause | Conflit détecté | Arrêter l’agent en conflit. |
| Restart | Une fois le conflit résolu | Réconcilier la tentative existante et ses effets, puis réessayer dans la limite enregistrée avec une nouvelle identité d’hôte. |
| Reallocate | Un agent termine plus tôt | Attribuer la tâche suivante de la file. |
| Escalate | Limite de tentatives atteinte ou réconciliation bloquée | Signaler la situation non résolue et les preuves ; poursuivre le travail indépendant autorisé. |

<a id="durable-runtime"></a>
## 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.

**Exécution, vérification, acceptation**

| Issue | Qui l’établit | Ce que cela signifie |
| --- | --- | --- |
| Exécution | Un hôte identifié rapporte `completed`, `failed`, `blocked` ou `ambiguous` ; ou un superviseur d’origine, au premier plan, collecte le résultat réel de son processus enfant. | Une observation. Ce n’est pas une vérification indépendante. |
| Vérification | Nexus exécute lui-même les commandes de contrôle du plan avec des tableaux d’arguments littéraux et sans shell, enregistre les codes de sortie et une sortie bornée, et compare des instantanés des artefacts et du périmètre d’écriture avant et après. | Le résultat réussit les contrôles indépendants, avec des reçus. |
| Acceptation | Une opération séparée et sérialisée revérifie les artefacts courants, les hashes de ressources et les preuves de dépendances. | L’espace de travail courant est accepté. Aucun commit Git, fusion, copie ni déploiement n’est fait. |

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é.

<a id="plan-format"></a>
## 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.

**nexus-plan.json**

```json
{
  "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."]
    }
  ]
}
```

**Champs d’une tâche**

| Champ | Sens |
| --- | --- |
| `id`, `objective`, `acceptance` | Identifiant, ce qu’il faut produire et les conditions qui doivent tenir. |
| `dependsOn` | Tâches qui doivent avoir des preuves acceptées à jour avant que celle-ci démarre. |
| `scope` | Fichiers ou dossiers que la tâche peut écrire. Les scopes de toutes les tâches sont exclusifs et deux à deux disjoints, même entre tâches séquentielles. |
| `artifacts` | Fichiers qui composent le résultat ; leurs hashes sont enregistrés. |
| `resources` | Chaque instruction et fichier de support fourni à l’hôte, haché par Nexus. Ils doivent se trouver hors du périmètre d’écriture de toute tâche. Nexus ne peut pas attester de ce qui n’est pas déclaré. |
| `checks` | Jusqu’à 30 par tâche : `command` (`node` ou un chemin absolu d’exécutable, dont les octets sont liés au plan), `args`, `cwd`, `timeoutMs` (10 à 300000). Les arguments fichier doivent être des ressources déclarées. |
| `maxAttempts`, `deadlineMs`, `idempotent` | Limite de tentatives (10 au plus), échéance, et si un nouvel essai est sûr sans observation spécifique. |
| `authorizations` | Texte décrivant l’autorisation existante. Un worker ne peut ni la modifier ni répondre à une demande d’approbation. |
| `execution` | Contrat facultatif pour une tâche exécutée par processus (voir plus bas). Sans lui, la tâche appartient à l’hôte. |

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.

<a id="cli-flow"></a>
## 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.

**swarm/page-fanout.json (la définition de l’essaim)**

```json
{
  "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."
}
```

**swarm/units.json (les trois unités)**

```json
{
  "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" }
  ]
}
```

**swarm/briefs/page.md (le gabarit de brief)**

```md
# 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}}
```

**host.json (l’identité du worker et de sa session)**

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

**Une tâche gérée par l’hôte, de la création à l’acceptation**

```text
$ 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.
```

Sortie capturée lors d’une exécution réelle. Source: bmad-plus 0.23.0, 2026-10-19

**rec.json (ce que l’hôte rapporte ; l’id de tentative vient de start)**

```json
{
  "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.

<a id="interruption"></a>
## Interruption, annulation et nouvel essai

**Commandes pour les cas difficiles**

| Commande | Fichier d’entrée | Ce qu’elle fait |
| --- | --- | --- |
| `nexus cancel RUN TASK` | `{ "reason": "..." }` (hôte) ; `attemptId` exact, `backend` et `reason` (processus) | Enregistre une demande. Une tentative d’hôte ne signale aucun PID ni terminal ; l’hôte n’arrête que sa propre opération. La capacité reste retenue jusqu’à la réconciliation. |
| `nexus reconcile RUN TASK` | La tentative, `outcome` (`completed`, `failed` ou `cancelled`), `ownerStopped: true`, `retrySafe`, `summary` | Clôt une tentative incertaine par une observation d’opérateur. C’est une observation, jamais la preuve indépendante que le propriétaire s’est arrêté. |
| `nexus retry RUN TASK` | Une nouvelle identité d’hôte | Démarre une nouvelle tentative après réconciliation. Elle consomme `maxAttempts` ; une nouvelle session ne remet pas la limite à zéro. Les tâches non idempotentes exigent aussi `retrySafe: true`. |
| `nexus recover-lock` | Le hash exact du verrou donné par `inspect`, `ownerStopped: true`, une `note` non vide | Retire un verrou d’écriture interrompu après que vous avez inspecté son propriétaire. Un écrivain local vivant bloque le retrait. Jamais automatique. |

<a id="process-backend"></a>
## 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.

**Une tâche avec l’adaptateur de commande générique (objet execution)**

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

**L’adaptateur Codex CLI installé**

```json
{
  "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.

<a id="limits"></a>
## Limites et ce qu’il ne fait pas

**Bornes prises en charge**

| Borne | Valeur |
| --- | --- |
| Tâches par exécution | 200 |
| Tentatives actives par exécution | 32 |
| Tentatives par tâche | 10 |
| Contrôles par tâche | 30 |
| Durée autorisée par contrôle | 10 à 300000 ms |
| Sortie capturée par contrôle | 64 Kio (la troncature est signalée) |
| Fichiers par instantané de périmètre ; taille d’un fichier instantané | 10000 ; 16 Mio |
| Fichiers d’entrée JSON | 1 Mio au plus, fichiers ordinaires |

- 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.

<a id="example-nexus-autopilot-idea"></a>
### Laisser Nexus conduire un petit projet avec points de contrôle

À utiliser au début d’un projet, avec `execution_mode` laissé à `manual` ou réglé sur `hybrid` pour garder les approbations.

**Dans votre assistant IA**

```text
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.
```

**Ce que vous devriez obtenir** La Discovery s’exécute d’abord (brief, PRD, spécification UX) et s’arrête au point de contrôle `discovery` avec quelque chose que vous pouvez lire. Après votre approbation, Forge écrit l’architecture et Nexus s’arrête de nouveau. Les stories sont ensuite implémentées et testées une par une ; avec les points de contrôle par défaut, chaque story terminée attend aussi votre approbation (`story`), sauf si vous la réglez sur `notify_only`, et la livraison finale s’arrête pour votre relecture (`delivery`). Un contrôle en échec est réparé dans la limite de tentatives plutôt que laissé passer. Le rapport final dit ce qui a été vérifié et ce qui reste ouvert.

<a id="example-nexus-parallel-split"></a>
### Découper le travail approuvé en tâches indépendantes

À utiliser une fois les stories écrites. L’hôte doit gérer les sous-agents pour un vrai parallélisme ; sinon les tâches s’exécutent en séquence.

**Dans votre assistant IA**

```text
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.
```

**Ce que vous devriez obtenir** Un `nexus-plan.json` aux périmètres disjoints et aux contrôles indépendants, une exécution Nexus listée par `nexus inspect` (chaque tâche `not started; verification=pending; acceptance=pending`), puis une ligne d’état par tâche au fil du travail. Une tâche dont le contrôle échoue affiche `verification=failed` et ne peut pas être acceptée ; un conflit met en pause la tâche en collision au lieu de l’écraser.

**Voir aussi**

- [Référence : bmad-plus nexus](https://bmad-plus.rochetta.fr/fr/docs/reference/cli-nexus/)
- [Les essaims de sous-agents](https://bmad-plus.rochetta.fr/fr/docs/concepts/swarm/)
- [Revue de code et recette humaine](https://bmad-plus.rochetta.fr/fr/docs/concepts/code-review-and-acceptance/)
- [Référence : config.yaml](https://bmad-plus.rochetta.fr/fr/docs/reference/config-yaml/)
- [Traitement des données](https://bmad-plus.rochetta.fr/fr/docs/security/data-handling/)

[Documentation BMAD+](https://bmad-plus.rochetta.fr/fr/docs/) · [Concepts](https://bmad-plus.rochetta.fr/fr/docs/concepts/)

[Code sur GitHub](https://github.com/lrochetta/BMAD-PLUS)