Skip to content
← Tous les chapitres

Chapitre 02

La boucle centrale

DWP définit un petit ensemble d’opérations qui font passer un plan d’un objectif à un travail achevé et relisible : create → execute → refine → resume → status, avec verify comme vérification de conformité qui confirme le résultat. Ensemble, elles forment la boucle qu’un agent suit tout au long de la vie d’un plan. Les agents exécutent une tâche à la fois, en validant chaque étape avant de poursuivre.

Cette boucle est la forme opérationnelle du développement piloté par la spécification. Le plan est la spécification face à laquelle un agent s’exécute, chaque tâche porte des critères d’acceptation explicites, et l’étape de validation est la porte qui transforme une affirmation d’achèvement en preuve de celui-ci. Comme le plan et son journal de progression résident dans le dépôt, la boucle est reprenable d’une session et d’un agent à l’autre.

Les opérations

La compétence méthodologique délègue l’intention à neuf sous-compétences spécialisées : six opérations centrales d’exécution, deux assistants de cycle de vie et un moteur de rédaction :

  • create — Génère un nouveau plan à partir d’un objectif. L’agent analyse l’objectif, le décompose en tâches séquentielles et écrit les fichiers du plan. En mode guidé, l’agent matérialise directement un plan Lite — une proposition compacte et déjà exécutable —, que le développeur peut conserver, promouvoir en plan Full, modifier ou abandonner ; en mode trust, l’agent matérialise directement la représentation choisie (Lite ou Full) sans confirmation. L’analyse des exigences et la vérification de qualité du plan s’exécutent dans les deux modes.
  • execute — Exécute le plan tâche par tâche de manière séquentielle. L’agent met à jour le journal de progression, exécute les portes de validation et committe après chaque tâche. En mode trust, l’exécution se poursuit de manière autonome sans interruption entre les tâches.
  • refine — Modifie un plan existant (ajouter, modifier, diviser ou réordonner des tâches, ou promouvoir un plan Lite en Full). Les preuves validées sont strictement préservées et l’affaiblissement non confirmé de critères est interdit.
  • resume — Poursuit un plan interrompu. L’agent lit le journal en ajout seul et les fichiers de tâche pour reconstruire l’état, puis reprend à la première tâche inachevée sans refaire le travail déjà accompli.
  • status — Rend compte de la progression sans exécuter (strictement en lecture seule). L’agent résume les tâches achevées, en cours et en attente et ne change rien.
  • verify — Vérifie la conformité sans rien modifier (strictement en lecture seule). L’agent indique si le dépôt respecte le standard AI-first et si les tâches comportent des critères explicites et des portes de validation.
  • onboard — Analyse le dépôt cible et élabore par raisonnement — jamais par simple copier-coller — un AGENTS.md adapté, une arborescence docs/, la documentation des modules et le kit .agents/ avec symlinks.
  • upgrade — Vérifie les versions amont, sollicite l’accord du développeur avant tout téléchargement, installe les tags stables épinglés et concilie les adaptations locales sans toucher aux plans .dwp/ existants.
  • author — Crée et fait évoluer les compétences, agents ou commandes slash locaux au dépôt pour répondre aux flux récurrents réels, et maintient le catalogue .agents/docs/ synchronisé.

Le répertoire de sortie .dwp/

Tous les artefacts DWP résident sous un répertoire .dwp/ ignoré par git, à la racine du dépôt. Garder l’espace de travail hors de la gestion de versions signifie que l’état de travail d’un plan ne pollue jamais l’historique du projet. La configuration des addons au niveau du dépôt est enregistrée dans .dwp/config.json (dwp-config/v1), tandis que les plans se trouvent dans des répertoires numérotés :

.dwp/
├── config.json
└── plans/
    └── PLAN_001_<slug>/
        ├── manifest.json
        ├── contract.json
        ├── journal.ndjson
        ├── state.json
        ├── README.md
        ├── PROGRESS.md
        ├── 1.task_<slug>.md
        ├── 2.task_<slug>.md
        └── analysis_results/

L’anatomie d’une tâche en dix sections

Chaque fichier de tâche suit les dix sections normatives présentées ci-dessus, dans l’ordre défini par la compétence installée.

  1. Goal — un paragraphe énonçant ce que la tâche accomplit.
  2. Context — le contexte, les liens et la raison d’être de cette tâche.
  3. Surface touchée : ce que la tâche modifie et la classe de risque qui sélectionne sa validation.
  4. Steps — des actions ordonnées et concrètes à réaliser.
  5. Acceptance criteria — une liste de contrôle des conditions qui définissent « fait ».
  6. Validation — les commandes ou tests à exécuter pour vérifier le travail.
  7. Files — les chemins censés être créés ou modifiés.
  8. Dependencies — les autres tâches ou prérequis externes.
  9. Risks — ce qui pourrait mal tourner, et les mesures d’atténuation.
  10. Completion & Log — un marqueur de statut accompagné de notes chronologiques.

Validation, achèvement et reprise

La validation fait partie de la tâche, ce n’est pas un ajout après coup : chaque tâche nomme les commandes ou tests qui prouvent qu’elle est faite, et l’agent les exécute avant de marquer l’achèvement. Les tests sont ici de premier ordre — une tâche qui ajoute une nouvelle fonctionnalité ou modifie un comportement doit ajouter ou mettre à jour des tests automatisés pour ce comportement et exécuter la vérification complète de qualité de code du dépôt (les tests plus le lint et le typage), et non simplement confirmer que le build réussit ; les tests existants doivent rester au vert, mis à jour vers le comportement voulu plutôt qu’ignorés. La sécurité est de premier ordre de la même manière — toute tâche qui touche à l’authentification, au traitement des entrées, aux secrets, à la surface réseau ou aux dépendances porte les attentes de sécurité de ce changement dans ses critères d’acceptation et maintient chaque commit exempt de secrets, et chaque plan se clôt par le Final Review — la passe de sécurité sur l’ensemble des changements, la validation complète sur l’état final et la réconciliation des décisions de skills. L’achèvement est consigné avec un marqueur de statut explicite ([ ] non commencé, [~] en cours, [x] fait, [!] bloqué) dans la section Completion & Log. La reprise s’appuie sur ces marqueurs et sur le journal de progression — un agent peut reconstruire exactement où le plan s’est arrêté et poursuivre à partir de la première tâche inachevée sans refaire le travail terminé.

v6 et v7 : la même méthodologie, une structure plus stricte

La norme DWP actuelle est 7.0.0, mise en œuvre par la ligne de skill 7.x. Ce pack utilise v7 par défaut pour chaque nouveau plan ; une demande explicite de v6 matérialise toujours un plan v6. Les plans v1, v2, v5 et v6 existants conservent leur génération enregistrée et ne sont jamais migrés silencieusement ; le passage d’un plan v5 à v6 nécessite une demande de migration explicite.

v6 conserve la même méthodologie plan → tâches → barrières de validation → achèvement, les mêmes commandes slash et l’emplacement .dwp/plans/. La structure d’ingénierie devient plus stricte avec un contrat, un journal, des manifestes de contexte par tâche, un ordonnanceur et le refus d’une liste d’autorisations vide. v7 conserve cette couche d’enregistrement et ajoute un marqueur de tâche optionnel parallel_safe, un événement de journal delegation pour le travail borné confié à un autre agent, ainsi que le registre d’addons .dwp/config.json ; sans addon de délégation activé, chaque plan s’exécute toujours séquentiellement dans la session courante. La décision d’architecture est GO ; la non-infériorité empirique des résultats des agents n’a pas été mesurée.