Unify toolbox drag and drop reorder behavior

AGENTS.md

@@ -29,9 +29,22 @@ Ne pas réintroduire de fallback massif type `DEFAULT_SITE_CONTENT` dans le code
 Chaque nouveau fichier source ou test doit commencer par un commentaire court `Rôle : ...` décrivant ce qu'il gère.
 
 - mettre cet en-tête à jour si la responsabilité du fichier change ;
-- garder l'intro concise, une ou deux lignes maximum ;
+- garder l'intro concise, une à trois lignes maximum selon la complexité du fichier ;
+- quand un fichier existant est modifié, vérifier si son en-tête mérite d'être précisé au-delà de la ligne générique initiale ;
+- enrichir l'en-tête quand le fichier porte une logique transverse, un hook partagé, un format de données ou un comportement réutilisable ;
+- ne pas allonger mécaniquement les en-têtes des fichiers simples : la précision doit aider à comprendre la responsabilité réelle du fichier ;
 - utiliser `// Rôle : ...` dans les fichiers JS, JSX, MJS et SCSS.
 
+## Hooks et comportements partagés
+
+Quand un comportement est déjà couvert par un hook ou un helper partagé, privilégier son utilisation plutôt qu'une réimplémentation locale afin de garder une expérience homogène.
+
+- pour la réorganisation par drag & drop, utiliser `useGroupedReorder` dès qu'il s'agit d'items, groupes, catégories, boundaries, parent/enfant ou listes horizontales/verticales ;
+- réserver `usePointerReorder` au moteur bas niveau ou aux cas DOM très spécifiques qui ne correspondent pas au modèle applicatif de `useGroupedReorder` ;
+- si une variation est nécessaire, vérifier d'abord si elle doit devenir une option du hook partagé ;
+- demander ou expliciter le choix uniquement quand la variation est réellement métier et pourrait alourdir le hook ;
+- éviter de dupliquer dans un outil une règle de reorder générique déjà prise en charge par le hook.
+
 ## Outils toolbox
 
 Chaque outil toolbox doit rester dans son propre fichier dans :
@@ -100,4 +113,6 @@ git diff --stat
 npm run check
 ```
 
+Après lecture du diff pré-push, proposer un exemple de message de commit en anglais, concis et représentatif des changements réellement présents.
+
 Ne pas faire de refactor large sans bénéfice clair. Garder les corrections pré-push ciblées, vérifiables et faciles à relire.