DWP v5 : les promesses, désormais garanties

Nous publions aujourd’hui Deep Work Plan v5. Ce n’est pas une réécriture : ce sont des mois d’usage réel — dont un audit direct de 108 plans réels — qui ont mis au jour, écart après écart, où les promesses de la méthodologie et le comportement réel d’un agent pouvaient diverger. Le résumé honnête de cette version : la méthodologie promettait déjà tout cela — désormais, elle le garantit. Avant v5, un agent qui suivait la documentation à la lettre pouvait encore aboutir à des scénarios d’échec réels ; chacun d’eux, identifié grâce à cet usage et à ces retours, est désormais fermé et verrouillé par un test exécutable, et non recouvert de davantage de prose. La suite de contrats du skill est passée de 132 à 258 tests durant ce cycle, et chaque garantie ci-dessous a été validée en conditions réelles sur le tag publié — installée dans un dépôt propre et menée à travers ses propres flux avant la rédaction de cette entrée.

Un vérificateur qui ne revendique jamais un succès non vérifié. Les contrôles de conformité se dégradaient auparavant en silence : sans interpréteur capable, ils sautaient toutes les vérifications tout en imprimant un verdict conforme, et du texte en gras dans un champ pouvait être pris pour un champ manquant. Désormais, le vérificateur se termine par un verdict UNVERIFIED explicite chaque fois qu’il ne peut pas réellement vérifier. Un vérificateur ne rapporte jamais un succès qu’il n’a pas contrôlé — la confiance dans les gates est toute la proposition, et un gate capable de sauter sa propre vérification brise la chaîne.

Un seul contrat d’approbation pour les plans Lite. Trois surfaces répondaient de trois manières différentes à la question « démarrer ce plan approuve-t-il son périmètre actuel ? », et un agent pouvait se bloquer ou s’exécuter sans autorisation précisément à la frontière la plus dangereuse. v5 établit un contrat unique partout : un execute ou un resume explicite approuve le périmètre ready actuel et enregistre cette approbation avant tout travail ; une proposition en attente, seule, n’autorise rien ; une promotion interrompue est récupérée avant qu’aucun travail produit ne s’exécute.

Une orchestration multi-dépôts qui ne corrompt rien. La variable d’environnement d’un hub orchestrateur fuyait auparavant vers ses dépôts enfants — un enfant pouvait écrire l’état des plans dans les dossiers du hub lui-même. Les modèles de l’orchestrateur imprimaient aussi FAIL en se terminant avec un code de succès, et un contrôle de complétude qui cherchait une chaîne de statut pouvait lire une tâche accomplie comme un plan accompli. Désormais, la racine du hub est sauvegardée avant de naviguer vers les sous-dépôts, chaque enfant résout son propre .dwp/ de façon isolée, chaque branche d’échec se termine en erreur, la complétude est lue depuis le statut de plus haut niveau du plan, et le point d’entrée du devcontainer propage les erreurs de copie avant de supprimer quoi que ce soit.

Une seule matrice de consentement pour les modules. Quel module s’installe par défaut, lequel est seulement proposé, et quelle revue est obligatoire — les surfaces répondaient différemment. v5 déclare une matrice : l’AI Diff Reviewer est obligatoire pour la revue locale, épinglé sur une version vérifiée, la revue en CI restant un opt-in explicite qui ne s’installe jamais de lui-même ; le module design-system est une offre obligatoire quand du travail d’interface est détecté, mais ne s’installe que sur acceptation explicite ; le module dependency-upgrade arrive comme un délégateur inerte quasi par défaut avec un rollback par instantané exact ; dailybot ne rend compte que là où il y est autorisé. Un diff vide ne compte plus comme une revue achevée.

Une vraie machinerie pour les plans longs. Un audit de 108 plans réels a montré que le travail parallélisable était courant mais que la décision séquentielle n’était presque jamais déclarée, et que les portes de jalons n’existaient qu’en pratique improvisée. v5 impose que la décision d’exécution soit toujours déclarée — séquentielle avec une raison enregistrée quand le parallélisme ne se justifie pas —, ajoute des Stage Gates optionnels pour les plans de vingt tâches ou plus, et enrichit les Plan Variables avec le niveau de rigueur, la barre de preuve et les actions interdites. Tout cela se charge progressivement et ne pèse jamais sur un plan Lite.

Contexte imposé, un objectif par tâche. Les plans pouvaient dériver vers des listes de tâches sans contexte, et une tâche pouvait empaqueter trois objectifs derrière un seul gate vert. v5 exige une paire Goal et Context au niveau du plan, un Context par tâche — ce dont une nouvelle session a besoin pour démarrer cette tâche seule — sur chaque nouvel enregistrement (les enregistrements achevés restent exactement tels qu’écrits), et fait de « un objectif par tâche » la règle normative, avec une garde contre l’érosion.

Un chemin de mise à niveau sûr. /dwp-upgrade est nouveau. Sa phase de vérification est en lecture seule et n’installe rien ; une mise à niveau ne démarre que sur acceptation explicite, les adaptations locales étant différenciées et exposées avant tout écrasement ; l’installation vise un tag exact et se vérifie elle-même ; l’onboarding se rejoue comme un init neuf. Une mise à niveau ne touche jamais .dwp/ — aucun plan, fichier d’état, enregistrement de gate ou preuve n’est migré, réécrit ou invalidé.

Des preuves honnêtes et mesurables. Les affirmations d’efficacité sont désormais remesurées sur trois bases — v3.0.0, v4.0.3 et l’arbre final — avec le script de mesure commité dans le dépôt. Les résultats sont rapportés en octets de système de fichiers et ne sont jamais convertis en chiffres de tokens ou de coûts que nous ne pouvons pas assumer ; toute affirmation invérifiable est mise en quarantaine comme telle dans le registre d’évaluation.

Un contrat versionné, publié. Chaque promesse ci-dessus s’appuie sur des données que d’autres outils peuvent lire, pas seulement sur de la prose : les formats plan-manifest et plan-state sont désormais versionnés comme la ligne de schéma v5 — plan-manifest/v5.json et plan-state/v5.json — de sorte qu’un plan, un vérificateur ou un outil tiers puisse contrôler la conformité par rapport à un contrat publié et lisible par machine, plutôt qu’à un paragraphe de documentation. Rien dans la ligne v5 ne change de forme par rapport à v2 : les plans existants référençant les schémas v1 ou v2 restent valides et ne sont jamais réécrits.

Deep Work Plan v5 suit le standard DWP 5.0.0. Lisez la spécification normative, consultez le dépôt du skill ou commencez l’adoption depuis /init.

Mise à jour — 2026-09-17 · skill v5.4.0

La première version ponctuelle de la lignée v5 referme le dernier chemin par lequel un plan pouvait se clore sur un travail jamais réellement vérifié, et fixe où réside la preuve du plan lui-même. Le standard DWP 5.0.0 ne bouge pas : il s’agit d’une publication de contrat d’addon et de documentation, pas d’un changement de schéma.

Une revue qui n’a jamais tourné ne se confond plus avec une revue propre. La passe de sécurité du Final Review distinguait déjà un relecteur absent — consigné comme constat — d’une invocation en échec, qui avertit une fois puis continue. Le relecteur en amont a ajouté une troisième issue : une exécution qui démarre puis se termine sans écrire le moindre constat. Faute de nom propre, elle se confondait avec « la passe s’est terminée et n’a rien trouvé », ce qui permettrait de clore un plan sur une revue qui n’a pas eu lieu. C’est désormais un état à part entière : consigné comme revue incomplète, jamais compté comme preuve que l’ensemble des modifications est propre, et jamais un motif de clôture du Final Review. Trois issues distinctes — et aucune ne signifie que le diff a été lu et jugé propre.

La preuve d’un plan appartient au plan. Le standard plaçait déjà le compte rendu d’analyse, le registre des skills, la revue de sécurité et les journaux de barrières dans le analysis_results/ du plan, sans jamais énoncer cette exclusivité comme une règle. Un outil d’audit propre au dépôt, dont le chemin de rapport pointe par défaut sur le répertoire de travail, pouvait donc écrire la preuve d’un plan à la racine du dépôt sans qu’aucun flux ne s’en aperçoive. La spécification l’exige maintenant : tout ce qu’un flux produit au sujet d’un plan va dans le dossier de ce plan, et un outil dont la sortie par défaut est le répertoire de travail doit recevoir son option de sortie explicite. Une preuve qui n’est pas là où le plan l’annonce est une preuve perdue — c’est la raison pratique de la règle, pas une préférence de rangement.

L’épinglage d’AI Diff Reviewer passe en v2.3.0. La revue locale requise installe désormais un relecteur qui sépare le runner du backend : la même revue peut donc s’exécuter contre n’importe quel point d’accès compatible sans changer ce dont DWP dépend — la garantie de neutralité en sort renforcée, pas assouplie. S’y ajoutent des installateurs vérifiés par somme de contrôle, des coûts par défaut mesurés plutôt que supposés, et des tours de suivi qui relisent le vrai diff nouveau en reportant les constats en suspens. Ce dernier point a une conséquence contractuelle qui mérite d’être dite franchement : qu’un modèle déclare lui-même un constat résolu ne le retire pas — c’est un mainteneur qui le retire.

Les principes de travail voyagent désormais avec le harnais. La v5.5.0, le même jour, fait en sorte que l’intégration apprenne aux agents d’un dépôt comment travailler, et pas seulement ce que le dépôt contient : dix comportements compacts — assumer le résultat, chercher avant de demander, trancher seul les questions de routine, escalader quand le jugement ou l’autorisation manque réellement, et vérifier avant de se déclarer terminé, entre autres — écrits en ligne dans AGENTS.md, là où les trouvera un agent qui ne lit que le point d’entrée. Ce sont des valeurs par défaut dans une demande, jamais une autorité nouvelle : elles ne peuvent primer sur les permissions de l’hôte, un périmètre plus étroit, les barrières d’un plan ou les règles d’approbation du dépôt. Une mise à niveau les réconcilie par le sens plutôt que par mot-clé, si bien que des règles équivalentes déjà présentes sont conservées au lieu d’être réécrites.

L’épinglage d’AI Diff Reviewer passe en v2.3.1. La skill v5.5.1 installe le relecteur dont le check, le corps de la revue et le commentaire de suivi s’accordent. Un corps qui dit Recommendation: approve n’est pas une preuve que le check a réussi — lisez le bloc Check status du marqueur de suivi. En mode advisory, une correction corroborée peut retirer un constat dont le fil est déjà replié, de sorte qu’une PR bloquée peut passer au vert après une vraie correction.

Lisez la spécification pour le texte normatif, la référence de l’addon pour ce que fait désormais le relecteur, ou la publication v5.5.1 pour la source.

Mise à jour — 2026-09-25 · skill v5.5.3 + relecteur v3.1.1

L’addon AI Diff Reviewer documente et installe désormais la ligne v3 du relecteur, publiée le 2026-09-24 (v3.0.0 → v3.1.1, pin mobile @v3). La skill v5.5.2 a réécrit les documents normatifs de l’addon, le hook d’onboarding et le modèle d’intégration autour de ce que le relecteur v3 fait réellement, et la v5.5.3 a livré le volet CI. Les changements les plus structurants, vérifiés contre le relecteur publié à l’étiquette v3.1.1 :

Un critical ne filtre que lorsqu’il est vérifié. Depuis la v3, chaque constat critique qu’un modèle affirme — plus un échantillon de 30 % des avertissements — reçoit une seconde vérification brève ancrée dans le code par un appel de modèle séparé (≈ 3 k tokens, 10 s et 0,009 $ par constat vérifié). Un critical est publié — et bloque le Final Review — uniquement lorsque ce vérificateur le confirme ; les affirmations réfutées restent visibles comme avertissements annotés et sont listées dans la sortie structurée, jamais en ligne. Une revue qui épuise son plafond de tours (incomplete) ou son horloge (timeout) est rouge sous stricte bloquante : « aucun constat » signifie désormais toujours que le relecteur a regardé et n’a rien trouvé.

Le budget suit le niveau de risque. Le budget de revue dérive du niveau de risque déterministe du changement — 8/20/30/40 tours de low à critical — et un push sans changement de code exécute une ronde de vérificateur seul à −93 % de coût. budget-profile: fixed restaure les constantes d’avant la v3 pendant la transition ; les rondes incrémentales réduisent les tokens d’entrée de 62 à 76 %.

Six sous-skills, dont une boucle. Le routeur gagne address-review (nouvelle en v3.1.1) : une seule invocation trouve les PR ouverts de la branche, vérifie que la revue couvre le head courant, présente les constats puis — sur un seul oui — applique, committe par petits lots de Conventional Commits, pousse et réarme le relecteur selon la façon dont le dépôt le déclenche. apply-review reste en lecture seule ; la sortie structurée (review-output/3.0) est la voie machine de toute automatisation. La ligne @v2 reste gelée sur release/v2 avec six mois de maintenance de sécurité et de catalogue — la v3 est la recommandation, jamais une migration forcée.

Le relecteur relit désormais ses propres maisons. Le dépôt de la skill et ce site exécutent tous deux une revue CI déclenchée par étiquette — une seule patte grok via DailybotHQ/ai-diff-reviewer@v3, déclenchée une fois par application de l’étiquette ready (retirez et re-ajoutez l’étiquette pour la relancer), avec un saut honnête quand le secret du fournisseur est absent. Ce site vendorise aussi le relecteur v3.1.1, si bien que le Final Review local et la documentation enseignent désormais le même contrat.

Lisez la spécification, la référence de l’addon pour la liste complète des capacités v3, la release v5.5.3 pour la source, ou la release v3.1.1 du relecteur pour ce qui a changé en amont.