getedgehq/workplan

Compétence Plan de Travail

Les plans de travail sont des fichiers Markdown horodatés qui survivent à l'auto-compaction. Ils constituent votre cerveau externe pour les travaux multi-étapes.

Convention de Fichier

• Emplacement : Racine du projet, ignoré par git
• Nom : WORKPLAN-YYYYMMDD-slug.md (ex. WORKPLAN-20260228-auth-refactor.md)
• Un fichier par tâche/phase. Ne réutilisez pas d'anciens plans de travail. Commencez un nouveau fichier pour chaque effort distinct.

Actions

Créer (/workplan ou /workplan create)

1. Lire d'abord. Avant d'écrire le plan, lisez tous les fichiers, problèmes et contextes pertinents.

2. Assurez-vous que .gitignore inclut WORKPLAN-*.md (ajoutez-le si manquant).

3. Choisissez un mode d'envergure avant d'écrire le plan :

   • EXPANSION : "Quelle est la version 10 étoiles ?" Rêvez grand, repoussez le périmètre.
   • MAINTIEN : "Rendez cela inattaquable." Le périmètre est bon, maximisez la rigueur.
   • RÉDUCTION : "Quel est le minimum qui apporte de la valeur ?" Coupez sans pitié.

   Par défaut : nouvelle fonctionnalité = EXPANSION, correction de bug / préparation de lancement = MAINTIEN, contrainte de temps = RÉDUCTION.

4. Créez le fichier avec ce modèle :

# Plan de Travail : [Titre]

Créé : AAAA-MM-JJ HH:MM
Dernière mise à jour : AAAA-MM-JJ HH:MM
Statut : EN COURS
Mode : MAINTIEN / EXPANSION / RÉDUCTION

## Contexte

[Pourquoi ce travail existe. Le problème. La cause racine. Contraintes clés. Liens vers les issues/PR.]

## Feuille de Route

- [ ] 1. Description de l'étape
- [ ] 2. Description de l'étape
- [ ] 3. Description de l'étape

## Décisions

[Journal des décisions architecturales ou d'approche avec horodatages]
- [HH:MM] Choix de X plutôt que Y car Z

## Problèmes Découverts

[Choses trouvées en cours de route qui n'étaient pas dans le périmètre initial]
- [HH:MM] Trouvé... en travaillant sur l'étape 2

## Journal de Vérification

[Chaque élément terminé reçoit une entrée de vérification]
- [HH:MM] Étape 1 : VÉRIFIÉ - exécuté `npm test`, tous les 42 tests passent
- [HH:MM] Étape 3 : VÉRIFIÉ - testé manuellement le flux de connexion, fonctionne avec OAuth et email

Mettre à jour (/workplan update)

1. Lisez le ou les fichiers WORKPLAN-*.md actifs dans la racine du projet.
2. Mettez à jour l'horodatage "Dernière mise à jour".
3. Cochez les éléments terminés avec des horodatages de vérification.
4. Ajoutez toutes les nouvelles découvertes ou décisions.
5. Rapportez l'état actuel à l'utilisateur.

Clôturer (/workplan close)

1. Lisez le plan de travail actif.
2. Vérifiez que TOUS les éléments sont cochés avec des horodatages de vérification.
3. Exécutez la vérification finale (build, tests, vérifications manuelles).
4. Changez le statut en TERMINÉ.
5. Ajoutez un résumé final :

## Terminé

Clôturé : AAAA-MM-JJ HH:MM
Tous les N éléments implémentés et vérifiés. Le build passe. Les tests passent.

Reprendre (après compaction)

Lorsque le contexte a été compacté ou que vous ne savez plus où vous vous êtes arrêté :

1. Trouvez les plans de travail actifs : cherchez WORKPLAN-*.md dans la racine du projet.
2. Lisez le fichier du plan de travail.
3. Identifiez le premier élément non coché.
4. Continuez à partir de là.

Règles

1. VÉRIFIÉ signifie testé. Pas "Je pense que ça marche." Exécutez-le, voyez-le passer, puis marquez vérifié. Incluez ce que vous avez exécuté et le résultat.
2. Mettez à jour les horodatages à chaque changement. Votre futur vous (post-compaction) en dépend.
3. Les nouvelles découvertes vont immédiatement dans le fichier. Ne les gardez pas seulement dans le contexte.
4. Ne supprimez jamais le plan tant que l'utilisateur n'a pas confirmé que le travail est terminé.
5. Un souci par élément de la liste. Divisez les grandes étapes en petites parties vérifiables.
6. Si une étape échoue à la vérification, enregistrez l'échec, ne la cochez pas, ajoutez ce qui a mal fonctionné.