Recherche d'abord
Ne codez pas en devinant ce qu'est l'API. Vérifiez d'abord.
Vous devez faire ceci avant toute edit ou write qui n'est pas trivial:
1. Recherche: research/findings/<sujet>.md
- Vérifiez d'abord
research/findings/. Si quelqu'un a déjà fait la recherche, réutilisez-la. - Ensuite, grep le code source. Puis une recherche web si vous avez besoin de documentation externe. Utilisez 2026 lors de vos recherches pour obtenir la documentation actuelle.
- Citez ce que vous avez trouvé. Si la documentation n'existe pas, écrivez un petit test de vérification pour valider l'hypothèse.
- Enregistrez-la dans
research/findings/<slug>.mdafin que la session suivante n'ait pas à refaire le travail.
Modèle:
# Résultats: <sujet>
Date: 2026-09-04
Sources: [url, url]
Code existant: `chemin:ligne`: ce que nous avons trouvé
## Verdict
Approche recommandée: ...
Alternatives: ...
Risques: ...
2. Plan: research/plans/<tâche>.md
# Plan: <tâche>
Recherche: research/findings/<sujet>.md
Approche: ...
Fichiers à modifier: [liste]
Tests: ...
Restaurer: ...
3. Approbation
Montrez le plan à l'utilisateur. Ne commencez pas à coder tant qu'il n'a pas donné son accord. Pour les petites modifications d'un seul fichier, l'instinct d'approbation automatique peut vous laisser passer.
4. Implémenter et vérifier
Exécutez le plan, lancez les tests, harness bench --quick, puis harness memory sync pour que la prochaine session se souvienne de ce qui a fonctionné.
Notes
- Si les résultats existent déjà, ne les refaites pas.
- Lisez les fichiers pour les faits, ne devinez pas. Si ce que vous trouvez contredit ce que vous attendiez, dites-le et faites confiance au fichier.
- Une fois terminé, mettez à jour les résultats avec ce qui a réellement fonctionné.
À ne pas faire
editavantreadougrep- deviner les signatures d'API
- sauter le plan parce que « c'est petit » alors que vous allez toucher à 3 fichiers ou plus