Conformité

Version 1.3. Statut : stable. Ce document définit ce que signifie pour un dépôt d’être conforme à Deep Work Plan — c’est-à-dire AI-first et pilotable par agent. Les mots-clés MUST, MUST NOT, SHOULD, SHOULD NOT et MAY doivent être interprétés comme décrit dans la RFC 2119.

La conformité existe pour que la qualité « AI-first » soit une propriété objective et vérifiable plutôt qu’une impression. Un dépôt satisfait les critères ci-dessous ou non. Le sous-skill verify (/dwp-verify) les vérifie mécaniquement.

Un dépôt conforme

Un dépôt conforme DWP MUST satisfaire l’ensemble des points suivants. Chaque artefact MUST être raisonné pour le dépôt — adapté à ses langages, frameworks et commandes réels. Une ébauche générique, un espace réservé ou du contenu copié d’un autre dépôt ne satisfait pas un critère.

1. AGENTS.md à la racine. Le dépôt MUST contenir un AGENTS.md racine qui inclut (a) un index de la documentation, (b) les règles obligatoires du dépôt, et (c) un bloc Quick Commands dont les commandes sont réelles et exécutables dans ce dépôt. Des commandes d’espace réservé (par exemple, npm test dans un dépôt qui n’utilise pas npm) MUST NOT apparaître. L’index MUST NOT relier un fichier docs/ qui n’existe pas, et le fichier SHOULD rester dans un budget de 150 à 500 lignes, en déplaçant le détail vers docs/ et en le reliant plutôt qu’en croissant sans limite.
2. CLAUDE.md se résout vers AGENTS.md. Un CLAUDE.md MUST exister et se résoudre vers AGENTS.md (un lien symbolique, ou un équivalent qui garantit une source de vérité unique). Les deux MUST NOT diverger.
3. Une hiérarchie docs/. Le dépôt MUST contenir un répertoire docs/ couvrant les catégories standard (architecture, standards, tests, commandes de développement, sécurité et onboarding des agents) avec un contenu réel, spécifique au dépôt. Les modules complexes SHOULD porter leur propre README.md. Le guide de tests MUST définir une véritable chaîne d’outils de test, de lint et de typage — ou, pour un dépôt qui n’en a aucune, une configuration concrète proposée à partir de la stack pendant l’onboarding. Un guide de tests vide ou « pas de tests » ne satisfait pas ce critère : sans moyen défini de valider le comportement, un plan n’a pas de porte de validation objective.
4. Un foyer .agents/. Le dépôt MUST contenir un répertoire .agents/ avec agents/, commands/ et skills/, ainsi qu’un catalogue sous .agents/docs/ qui correspond à ce qui est sur disque. Les commandes dwp-* MUST être de légers délégateurs vers le skill installé. Un chemin .claude MUST se résoudre vers .agents.
5. Un espace de travail .dwp/ ignoré par git. Le dépôt MUST contenir un répertoire .dwp/ avec plans/, et .dwp/ MUST être ignoré par git. Un espace de travail temporaire tmp/ SHOULD exister et SHOULD être ignoré par git.
6. Le skill de la méthodologie est résolvable. Le skill Deep Work Plan MUST être installé ou référencé de sorte qu’un agent dans le dépôt puisse invoquer ses sous-skills.

Un dépôt est pleinement conforme avec zéro addon optionnel. Les addons optionnels (devcontainer, Dailybot, dependency-upgrade, design-system) MUST NOT être requis pour la conformité. Depuis le standard 2.3.0, la revue locale AI Diff Reviewer (skill vendorisée + fichier d’extension) fait partie du socle : son absence est un échec pour un dépôt déclarant la 2.3.0 ou plus récente, et un constat de version de la harness pour un dépôt legacy. Sa surface CI reste optionnelle.

Un plan bien formé

Un Deep Work Plan dans .dwp/plans/ est bien formé lorsque :

1. Chaque tâche MUST déclarer un périmètre explicite, des critères d’acceptation et au moins une porte de validation (une commande ou une vérification qui réussit ou échoue objectivement).
2. Chaque tâche qui ajoute une nouvelle fonctionnalité centrale ou modifie le comportement du produit MUST inclure une couverture de tests automatisés pour ce comportement dans ses critères d’acceptation, et MUST exécuter les tests du dépôt conjointement avec ses vérifications de lint et de typage dans sa porte de validation — et non le build seul. Les tests existants MUST rester au vert ; un changement de comportement MUST mettre à jour un test qu’il casse plutôt que de le supprimer ou de l’ignorer. Les tâches purement documentaires, de configuration ou de recherche sont exemptées de la création de tests mais exécutent tout de même la porte du dépôt.
3. Chaque tâche qui touche à l’authentification, au traitement des entrées, aux secrets ou à la configuration, à la surface réseau ou aux dépendances MUST porter les attentes de sécurité de ce changement dans ses critères d’acceptation, et chaque commit MUST être exempt de tout matériau secret.
4. Le plan MUST persister la progression pour que le travail survive à l’interruption et puisse être repris par un autre agent. Une tâche MUST NOT être consignée completed tant que l’un de ses enregistrements de porte de validation affiche encore une exécution en échec non résolue, et le journal d’achèvement d’une tâche MUST NOT contredire son statut consigné (par exemple, une tâche completed dont le journal affiche encore « Status: pending » est un défaut, pas une réussite).
5. Le plan MUST se clore par sa revue finale enregistrée. Un plan rédigé sous cette version MUST se terminer par exactement un Final Review obligatoire — la passe de sécurité, la validation de l’état final et la réconciliation des skills. Un plan rédigé sous une version antérieure se termine par les trois tâches finales obligatoires (Security Review, Skills & Agents Discovery, Executive Report) et reste conforme. Une découverte de sécurité critique bloque l’achèvement jusqu’à ce qu’elle soit corrigée ou explicitement acceptée. L’achèvement lui-même est une transaction vérifiée et récupérable plutôt qu’un simple basculement de statut : la tâche terminale se clôt via une étape de publication sous garde qui valide les artefacts du plan achevé avant d’écrire l’état et laisse un reçu FINALIZATION.json vérifiable par machine ; une publication interrompue est récupérée à partir de la preuve, jamais silencieusement redéclarée achevée. Tout pointeur de preuve cité par un enregistrement de porte MUST se résoudre à l’intérieur du dossier propre du plan — un pointeur pendant ou qui s’échappe est un constat, pas une preuve passante.
6. Les tâches SHOULD se réancrer à l’objectif du plan avant de s’exécuter, afin de prévenir la dérive sur un long horizon.

Vérifier la conformité

La conformité SHOULD être vérifiée mécaniquement plutôt que par inspection. L’exécution de /dwp-verify produit un rapport de réussite/échec face aux critères ci-dessus : la présence et le contenu réel d’AGENTS.md, la résolution de CLAUDE.md, les catégories de docs/, la correspondance catalogue-versus-disque de .agents/, le statut gitignore de .dwp/ et tmp/, et — pour un plan — que chaque tâche porte des critères d’acceptation et une porte de validation, avec une couverture de tests pour les tâches qui modifient le comportement et la revue finale enregistrée présente. Pour un plan, elle vérifie aussi que le markdown du plan et son état lisible par machine concordent (un README et un state.json désynchronisés constituent un constat, jamais une réussite silencieuse), que les tâches achevées portent des preuves de porte et de journal non contradictoires, et — lorsqu’un plan achevé l’atteint — qu’un reçu de publication étaye l’achèvement qu’il revendique. Le vérificateur est conscient de la version : il MUST accepter comme conforme un plan legacy (trois tâches finales obligatoires, aucune Surface touchée) et MUST rejeter un plan qui déclare cette version et est objectivement invalide au regard d’elle. Il signale également une ligne de provenance DWP standard: manquante ou périmée comme un constat qui nomme la mise à niveau ciblée de la harness. La couche mécanique est honnête sur ses limites : sans interpréteur capable (Python 3.9+), elle se termine par un code de sortie non nul et un verdict UNVERIFIED explicite, au lieu de sauter ses vérifications — un vérificateur ne rapporte jamais un résultat qu’il n’a pas vérifié.

Un dépôt SHOULD être revérifié après l’onboarding et après chaque plan achevé, afin que la conformité soit maintenue plutôt qu’affirmée une seule fois.