<required> CRITIQUE. Ajoute les étapes suivantes à ta liste TodoWrite :

• Lire les 'Directives'.
• Créer un plan complet qu'un ingénieur senior peut suivre. <system-reminder>Les chemins absolus dans ton plan DOIVENT tenir compte de tous les worktrees qui auraient pu être créés</system-reminder>
• Réfléchir à la rétrocompatibilité. Ajouter des notes au plan.
• Réfléchir aux cas limites. Les ajouter au plan.
• Réfléchir aux questions ou domaines nécessitant des clarifications. Les ajouter au plan.
• Souligner comment tu vas tester ton plan.
• Présenter le plan à l'utilisateur. </required>

Directives

Aperçu

Créer un plan d'implémentation complet en supposant que l'ingénieur n'a aucun contexte sur notre codebase et des goûts discutables. Documenter tout ce qu'il/elle doit savoir : quels fichiers modifier pour chaque tâche, le code, les tests, la documentation qu'il/elle pourrait devoir vérifier, comment le tester. Présenter le plan entier sous forme de tâches digestes. DRY. YAGNI. TDD.

Supposer qu'il/elle est un développeur talentueux. Cependant, supposer qu'il/elle ne connaît presque rien à notre outillage ou domaine problématique. Supposer qu'il/elle ne maîtrise pas bien la conception de tests.

Ne pas ajouter de code, mais inclure assez de détails pour que le code nécessaire soit évident.

Ne pas écrire un fichier sur disque sauf si explicitement demandé.

En-tête du document de plan

Chaque plan DOIT commencer par cet en-tête :

# Plan d'implémentation de [Nom de la fonctionnalité]

**Objectif :** [Une phrase décrivant ce que cela construit]

**Architecture :** [2-3 phrases sur l'approche]

**Stack technologique :** [Technologies/bibliothèques clés]

---

Section Tests

Chaque plan DOIT avoir une section tests. Elle doit être écrite en premier et doit documenter comment tu comptes tester le comportement.

**Plan de test**

J'ajouterai un test d'intégration qui garantit que foo se comporte comme blah. Le test d'intégration va mocker A/B/C. Le test va ensuite appeler function/cli/etc.

J'ajouterai un test unitaire qui garantit que baz se comporte comme qux...

Tu dois terminer CHAQUE section de plan de test en écrivant :

REMARQUE : j'écrirai *tous* les tests avant d'ajouter tout comportement d'implémentation.

<system-reminder>Tes tests ne doivent PAS contenir de tests de structures de données ou de types. Tes tests ne doivent PAS simplement tester des mocks. Toujours tester le comportement réel.</system-reminder>

<required> Pour chaque test, suivre cette checklist :

• S'assurer que le test ne teste que des mocks. Si c'est le cas, supprimer le test et réessayer.
• S'assurer que le test ne teste pas des détails d'implémentation. Si c'est le cas, réécrire le test pour qu'il teste le comportement aux limites.
• S'assurer que le test ne teste pas un format ou type de structure de données. Si c'est le cas, supprimer le test et réessayer.
• S'assurer que le test ne teste pas un comportement supprimé. Par exemple, si un comportement a été abandonné, ne pas écrire un test qui confirme simplement que le comportement ne fonctionne plus.
• Évaluer si le test traite l'intérieur de la limite de test comme une boîte noire. Tu ne dois rien connaître des variables internes, appels de fonction ou flux de contrôle. </required>

Pied de page du document de plan

Chaque plan DOIT se terminer par ce pied de page :

**Détails de test** [Brève description de ce que les tests ajoutent et comment ils testent spécifiquement le COMPORTEMENT et NON simplement l'implémentation]

**Détails d'implémentation** [maximum 10 puces sur les détails clés]

**Question** [questions ou préoccupations qui pourraient être pertinentes et qui nécessitent des réponses]

---