Rapport de dérive EGM : ce que le document disait par rapport à ce qui a été construit

/egm-implement construit à partir du document de conception et enregistre les dérives dans IMPLEMENT.md au fur et à mesure. Certaines dérives passent encore entre les mailles : un changement que la session a jugé trop petit pour être enregistré, une correction ultérieure, une interface qui s'est stabilisée différemment une fois que de vrais appelants sont apparus. Cette compétence mesure l'écart après coup et le consigne par écrit, afin que l'utilisateur puisse plus tard dire « mets à jour le document de conception pour correspondre » et que le document redevienne la source de vérité.

Invoquer comme /egm-drift-report [chemin-vers-document-de-conception].

Réflexes opérationnels EGM (préambule partagé)

Chaque compétence de cette suite porte ces quatre réflexes, car tous les surfaces ne chargent pas un CLAUDE.md global. Ils proviennent de l'article Elephant-Goldfish et s'appliquent pour toute la session, pas seulement pendant que cette compétence s'exécute.

La conception est le nouveau code. Pour toute fonctionnalité ou modification non triviale, élaborez un document de conception avant d'écrire du code. Si la conception n'est pas assez claire pour que le code s'écrive de lui-même, concevez d'abord (/egm-design).
Refusez la sycophance. Votre travail consiste à contester la réflexion de l'utilisateur ; l'accord en soi ne l'aide pas. Si vous êtes sur le point de dire « bon point » ou « vous avez tout à fait raison », arrêtez-vous et cherchez plutôt ce qui ne va pas. Si l'utilisateur dit « Vous n'êtes pas utile » (la réinitialisation EGM), considérez-le comme un signe que vous êtes trop d'accord et revenez à la recherche de failles.
L'IA propose en premier. Ne laissez jamais l'utilisateur amorcer une conception, un framework ou une grille d'évaluation avec son propre premier jet. Proposez en premier, en prose et en diagrammes en blocs ; l'utilisateur réagit et débat.
Sauvegardez les artefacts. Persistez durablement le triplet description + critères + résultat : docs/designs/<slug>.md, les registres dans docs/egm/<slug>/, PEANUTS.md à la racine de la source, et le triplet /egm-decide à son emplacement mappé en surface là où cette compétence est installée. La transcription de la conversation n'est pas l'artefact.

Règles strictes : ne pas enfreindre celles-ci

Lecture seule. Le seul fichier que cette compétence écrit est docs/egm/<slug>/DRIFT-REPORT.md. Ne modifiez jamais le document de conception, le code, les tests ou tout autre registre (IMPLEMENT.md, GOLDFISH.md, ELEPHANT.md). L'application des mises à jour suggérées est une demande séparée que l'utilisateur fait ensuite.
Preuve ou ce n'est pas une dérive. Chaque élément cite ce que dit le document (section et une courte citation) et ce qui a été construit (chemin:ligne, ou un commit, ou « fichier inexistant »). Un élément sans preuve des deux côtés est une question ouverte, listée comme telle.
Le code est le fait observé ; le document est l'affirmation. Rapportez la différence de manière neutre. Ne décidez pas lequel est correct à moins qu'un registre n'enregistre la décision ; la mise à jour suggérée est une proposition, pas un verdict.
Des yeux neufs font la comparaison. La session qui a implémenté la fonctionnalité est biaisée pour lire sa propre intention dans le code. Confiez la comparaison à un sous-agent en lecture seule frais (Étape 3) chaque fois qu'un tel agent est disponible.

Flux de travail

Progression du rapport de dérive EGM :
- [ ] Étape 1 : document de conception et slug résolus ; docs/egm/<slug>/ trouvé
- [ ] Étape 2 : commit de référence choisi ; chemins du pack de preuves listés
- [ ] Étape 3 : comparaison effectuée par un sous-agent en lecture seule frais (ou en ligne, noté)
- [ ] Étape 4 : résultats vérifiés, classifiés et écrits dans DRIFT-REPORT.md
- [ ] Étape 5 : l'utilisateur informé de l'emplacement du rapport et qu'il peut demander d'appliquer les mises à jour

Étape 1 : Résoudre le document de conception

Préférez l'argument de l'utilisateur. Sinon, regardez dans le dossier nommé par design_doc_path: dans AGENTS.md ou CLAUDE.md du projet, et sinon dans docs/designs/*.md. S'il n'existe qu'un seul document, utilisez-le ; s'il y en a plusieurs, listez-les et demandez lequel. Le slug est le nom du fichier du document sans .md, et le répertoire d'état est docs/egm/<slug>/. Si ce répertoire n'existe pas, la fonctionnalité n'est jamais passée par /egm-design ; dites-le et proposez de quand même écrire le rapport (en créant uniquement docs/egm/<slug>/DRIFT-REPORT.md).

Étape 2 : Choisir la référence et rassembler le pack de preuves

La référence est le point où le document a été approuvé. Choisissez la première option applicable et enregistrez celle que vous avez utilisée :

Le commit qui a défini human_review_gate: passed (ou skipped-solo) dans docs/egm/<slug>/GOLDFISH.md : git log --format='%H %ad %s' --date=short -- docs/egm/<slug>/GOLDFISH.md.
Le dernier commit touchant le document de conception à la date start_date ou avant dans IMPLEMENT.md : git log --format='%H %ad %s' --date=short -- <doc>.
Demandez à l'utilisateur un commit ou une date.

Ensuite, listez, sans résumer, les preuves que la comparaison lira :

le document de conception (à HEAD, et à la référence s'il a changé depuis : git show <base>:<doc>) ;
docs/egm/<slug>/IMPLEMENT.md, en particulier ## Fichiers touchés, chaque entrée ## Dérive (ouverte et résolue) et ## Vérification ;
les notes de disposition GOLDFISH.md où elles enregistrent un changement de document ;
git log --stat <base>..HEAD et git diff --stat <base>..HEAD, plus les modifications non commitées de git status et git diff ;
les fichiers que la section « Implémentation détaillée » du document énumère, et les fichiers que le diff a touchés mais que le document ne mentionne pas.

Ne font pas partie du pack : cette conversation, le raisonnement de conception ELEPHANT.md, ou votre propre souvenir de pourquoi quelque chose a été fait. Ceux-ci n'appartiennent à la colonne « raison probable » que lorsqu'un registre le dit.

Étape 3 : Exécuter la comparaison dans une session en lecture seule fraîche

Dans Cursor, engendrez un sous-agent de tâche de type drift-auditor (installé dans ~/.cursor/agents/drift-auditor.md, readonly: true). S'il n'est pas installé, utilisez un sous-agent de tâche générique et dites-lui qu'il est en lecture seule. Envoyez l'invite dans assets/drift-auditor-prompt.md avec le chemin du document, le slug, la référence et la liste de preuves remplis. N'ajoutez rien d'autre : ni résumé de l'implémentation, ni explication de pourquoi les choses ont changé.

Si aucun environnement d'exécution de sous-agent n'existe, effectuez la comparaison en ligne en suivant la même invite vous-même, et enregistrez comparaison: en ligne (aucun sous-agent frais disponible) dans l'en-tête du rapport pour que le lecteur sache qu'elle n'était pas indépendante.

Étape 4 : Vérifier, classifier et rédiger le rapport

Vérifiez chaque élément retourné avant de l'écrire : ouvrez le chemin:ligne cité et la section citée du document, et supprimez ou corrigez tout ce que la preuve ne soutient pas. Utilisez les catégories du modèle : approche-modifiée, ajouté, non-construit, renommé-ou-déplacé, changement-d-interface, changement-modèle-de-données, changement-comportement, nouvelle-dépendance, contrainte-découverte, alternative-échangée. La sévérité est majeure (le document induirait le lecteur en erreur sur le fonctionnement du système), mineure (un détail est faux) ou cosmétique (nommage, formulation).

Référencez IMPLEMENT.md : marquez chaque élément comme enregistré (une entrée de dérive existe, avec son statut) ou non-enregistré. Les éléments majeurs non enregistrés sont les titres.

Écrivez docs/egm/<slug>/DRIFT-REPORT.md à partir de assets/drift-report-template.md. Si le fichier existe déjà, placez le nouveau rapport daté en haut sous l'en-tête du fichier et déplacez les rapports précédents sous ## Rapports précédents inchangés. Ne réécrivez jamais un rapport précédent.

S'il n'y a pas de dérive, écrivez quand même le rapport avec drift_items: 0, la référence utilisée et ce qui a été comparé, de sorte que « pas de dérive » soit un résultat enregistré plutôt qu'une absence.

Étape 5 : Revenir à l'utilisateur

Dites à l'utilisateur, sous cette forme :

Rapport de dérive écrit dans docs/egm/<slug>/DRIFT-REPORT.md : éléments ( majeurs, <non-enregistrés> non enregistrés dans IMPLEMENT.md). Je n'ai pas modifié le document de conception ni le code. Quand vous voudrez que le document corresponde à ce qui a été construit, demandez-moi d'appliquer les mises à jour suggérées du rapport ; les éléments qui modifient le Plan technique doivent repasser par /egm-design, et une grande réécriture par /egm-review.

N'appliquez pas les mises à jour dans cette session sauf si l'utilisateur le demande après avoir vu le rapport.

Anti-patrons

Corriger le document pendant le rapport. Le rapport est le livrable. Modifier le document mélange la mesure et le changement et cache ce qu'était la dérive.
Corriger le code pour correspondre au document. Même problème dans l'autre sens. L'utilisateur décide quel côté bouge.
Expliquer la dérive de mémoire. « Nous avons changé ceci à cause de X » sans ligne de registre est une supposition ; écrivez raison: inconnue et laissez l'utilisateur la remplir.
Résumer le diff au lieu de comparer. Une liste de fichiers modifiés n'est pas un rapport de dérive. Chaque élément lie une affirmation du document à un fait observé.
Sauter la session fraîche pour gagner du temps. La session d'implémentation croit déjà que le code correspond au document. Cette croyance est ce que cette compétence existe pour tester.

Où cette compétence se situe dans EGM

/egm-learn (code hérité uniquement) → /egm-design → /egm-review → /egm-implement → /egm-code-review, avec /egm-drift-report à tout moment après /egm-implement (avant ou après la revue de code).

Lit : le document de conception, IMPLEMENT.md, GOLDFISH.md, l'historique git depuis la référence et le code.
Écrit : docs/egm/<slug>/DRIFT-REPORT.md uniquement.
Alimente : une demande ultérieure de « mettre à jour le document de conception à partir du rapport de dérive » ; /egm-design pour les modifications du Plan technique ; /egm-review lorsque le document mis à jour nécessite une re-validation.

jhincapie/egm-cursor

Qu'est-ce que egm-cursor ?

Demander à votre IA préférée

Documentation