Quand l'utiliser
Chargez cette compétence lorsque vous décidez ce qui doit appartenir à chaque commit ou PR.
Utilisez-la pour :
- Découper une fonctionnalité en unités révisables.
- Préparer des commits avant d'ouvrir une PR.
- Transformer une grosse modification en PRs chaînées ou empilées.
- Maintenir une charge cognitive raisonnable pour le relecteur.
- Appliquer des tâches SDD sans produire accidentellement une PR de plus de 400 lignes modifiées.
Règles critiques
| Règle | Exigence |
|---|---|
| Commit par unité de travail | Un commit représente un comportement livrable, une correction, une migration ou une unité de documentation. |
| Ne pas commiter par type de fichier | Évitez les commits séparés pour models, puis services, puis tests si aucun ne fonctionne seul. |
| Garder les tests avec le code | Les tests doivent être dans le même commit que le comportement qu'ils vérifient. |
| Garder la documentation avec le changement visible par l'utilisateur | La documentation doit être dans le commit de la fonctionnalité ou du flux qu'elle explique. |
| Raconter une histoire | Un relecteur doit comprendre pourquoi chaque commit existe à partir de son diff et de son message. |
| Prêt pour une future PR | Chaque commit doit pouvoir devenir une PR chaînée lorsque la modification s'agrandit. |
| Garde-fou de charge de travail SDD | Si les tâches SDD prévoient une modification de >400 lignes, regroupez les commits en tranches de PRs chaînées avant l'implémentation. |
| Le budget n'est pas du golf de code | Ne réduisez jamais un diff en supprimant des commentaires, lignes vides, documentation ou tests, ni en compressant du code, pour respecter le budget de relecture (400 par défaut, ou review_budget_lines de la session). Découpez par unité de travail ou signalez le dépassement. |
Checklist d'unité de travail
Avant de commiter, vérifiez :
- Le commit a un seul objectif clair.
- Le dépôt a toujours du sens après l'application de ce seul commit.
- Les tests ou la documentation pour cette unité sont inclus lorsqu'ils sont pertinents.
- Un rollback est raisonnable sans annuler un travail non lié.
- Le message de commit explique le résultat, pas la liste des fichiers.
Exemples de découpage
| Mauvais découpage | Meilleur découpage (par unité de travail) |
|---|---|
add models | feat(auth): add token validation domain model and tests |
add services | feat(auth): wire token validation into login flow |
add tests | Tests inclus avec chaque commit de comportement |
update docs | Documentation incluse avec le changement utilisateur qu'elle explique |
Relation avec les PRs
Utilisez les commits par unité de travail comme base des PRs chaînées :
- Construisez la plus petite unité de travail indépendante.
- Incluez la vérification pour cette unité.
- Commitez-la avec un message de commit conventionnel.
- Si la PR approche 400 lignes modifiées, promouvez les commits ou groupes de commits en PRs chaînées.
Relation avec SDD
Lorsque sdd-tasks produit une prévision de charge de travail de relecture :
- Risque faible : gardez les commits par unité de travail dans une seule PR.
- Risque moyen : commitez par unité de travail et surveillez le nombre de lignes modifiées avant la création de la PR.
- Risque élevé : suivez la
delivery_strategyde SDD — demandez viaask-on-risk, découpage automatique viaauto-chain, exigezsize:exceptionpour unsingle-prhors budget, ou enregistrez unsize:exceptionaccepté pourexception-ok. - Le découpage est borné : après une première passe honnête de découpage, si aucun découpage cohérent par unité de travail ne tient dans le budget, arrêtez-vous et signalez le plus petit nombre honnête avec une recommandation
size:exception. N'itérez pas pour réduire le code afin d'atteindre le nombre.
Chaque unité de travail SDD doit correspondre clairement à un commit ou une PR avec :
- un état de départ clair,
- un état final clair,
- une vérification dans la même unité,
- un rollback qui ne supprime pas un travail non lié.
Commandes
# Examiner l'histoire avant de commiter
git diff --stat
git diff --cached --stat
# Vérifier le style des commits récents
git log --oneline -5