Skip to content
← Tous les chapitres

Chapitre 03

Modèles de plan et de tâche

Un Deep Work Plan est un répertoire de fichiers Markdown. La forme de ce répertoire — et de chaque fichier qu’il contient — est ce qui rend un plan relisible à la fois par les humains et par les agents.

Structure d’un plan

Un plan est un répertoire sous .dwp/plans/ nommé PLAN_001_<slug>/. Il contient :

  • manifest.json — l’identité du plan et le pointeur vers son contrat actif, écrit en premier lors de la matérialisation.
  • contract.json — contrat de spécification et périmètre du plan.
  • journal.ndjson — journal d’événements en ajout seul.
  • state.json — un instantané projeté depuis le journal, jamais modifié manuellement.
  • README.md — vue d’ensemble du plan : objectif, tableau des tâches et statut.
  • PROGRESS.md — journal d’exécution chronologique lisible par l’humain.
  • <n>.task_<slug>.md — fichier de spécification en dix sections par tâche.
  • analysis_results/ — répertoire pour les artefacts d’analyse, rapports et logs de portes.

Le pack 7.x actuel crée les plans v7 par défaut, dont le slug comporte 2 à 5 mots, comme pour v6. Le flux v5 conservé utilise 2 à 4 mots (son schéma figé comptant l’ID numérique comme un mot). Les nouveaux plans reçoivent des ID numériques croissants sur au moins trois chiffres (par exemple PLAN_001_add_payment_webhooks/). Les répertoires non numérotés existants PLAN_<slug>/ restent lisibles et ne sont jamais renommés ; aucun plan existant n’est migré implicitement. En présence de plans numérotés, latest désigne celui dont l’ID numérique est le plus élevé.

Structure d’un fichier de tâche

Chaque fichier de tâche est nommé <n>.task_<slug>.md et suit les dix sections normatives définies par la compétence installée (voir La boucle centrale pour les détails anatomiques). Chaque tâche se réancre à l’objectif du plan avant d’agir, ce qui empêche un agent de dériver sur un long horizon de plusieurs heures.

Le Final Review

Tout plan doit se terminer par exactement une tâche obligatoire : le Final Review. Il clôt le plan en cinq étapes strictement ordonnées — les contrôles de sécurité et portes de validation ne sont en aucun cas relâchés :

  1. Passe de sécurité — auditer tout ce que le plan a changé à la recherche de secrets, risques d’injection et nouvelle surface d’attaque, garder docs/SECURITY.md à jour et exécuter la revue locale obligatoire AI Diff Reviewer sur l’ensemble de la portée du plan (un examinateur manquant est consigné comme un résultat local reviewer not installed, jamais ignoré silencieusement). Une découverte critique bloque l’achèvement.
  2. Validation de l’état final — les suites complètes de tests, linting et vérification de types du dépôt s’exécutent et réussissent sur l’état final. Tout correctif intervenu lors de la revue invalide les résultats affectés et déclenche une réexécution.
  3. Réconciliation des compétences — vérifier que chaque tâche a consigné sa disposition locale de compétences, et rapprocher les opportunités de rédaction dans analysis_results/SKILLS_CANDIDATES.md.
  4. Réconciliation documentaire — rapprocher la surface touchée de chaque tâche modifiant le comportement avec la documentation (docs/TESTING_GUIDE.md, architecture, AGENTS.md) qui consigne cette fonctionnalité.
  5. Achèvement — les registres du plan concordent (liste des tâches, journal de progression et, pour les plans v6 et v7, l’instantané et le reçu dérivés du journal) ; présenter les livrables, preuves et limites, et proposer l’Executive Report une seule fois.

Conventions README et PROGRESS

Le README.md du plan doit contenir un titre (# Deep Work Plan: <name>), un énoncé d’objectif en prose, une section facultative sur le matériau source, un tableau des tâches (numéro, nom de la tâche, case de statut) et une ligne de statut du plan sous la forme <n>/<total> tasks complete.

PROGRESS.md est un journal d’exécution en ajout seul. Chaque entrée consigne un horodatage ISO 8601, le numéro et le nom de la tâche, ce qui a été fait, et tout écart ou raison de saut. Comme il ne fait que grandir, c’est un historique fiable de la façon dont le plan s’est réellement déroulé.

Titres et renvois

Tous les titres utilisent la casse de phrase, et les documents évitent le langage marketing et les points d’exclamation. Ces conventions gardent les plans cohérents d’un agent à l’autre et dans le temps.