Modifier le code d'un dépôt à plusieurs paquets et n'ouvrir de PR que depuis son fork

## Suivre les consignes de chaque dossier et placer le code dans le bon paquet Considérez les consignes destinées aux agents à la racine comme une politique applicable à l’ensemble du dépôt. Lorsqu’un sous-répertoire possède son propre fichier d’instructions, utilisez-le comme source principale pour les conventions et les processus de ce paquet. - Avant toute modification, recensez les paquets responsables de la découverte, de l’intégration de bas niveau, des API de haut niveau, de l’agrégation, de la documentation et des tests. - Remontez jusqu’au module responsable et à ses dépendances au lieu de placer le comportement dans un paquet pratique, mais sans rapport. - Lisez le code voisin et réutilisez les utilitaires ainsi que les conventions établies de nommage, de formatage et de localisation. - Limitez chaque modification au comportement demandé et à ses surfaces d’intégration directes. - N’élargissez pas une correction en une restructuration sans rapport, sauf si cela est nécessaire pour préserver la justesse. Les consignes locales, la configuration de compilation et les modèles d’implémentation existants priment sur les suppositions générales relatives à l’écosystème. ## Ne pousser que vers son fork, jamais vers l'upstream en lecture seule Lorsqu’un projet considère son dépôt amont comme accessible en lecture seule, ne poussez jamais de branches ni de commits vers ce dépôt distant. Créez les modifications sur une branche autorisée du fork du contributeur. - Exécutez `git remote -v` avant de publier et repérez le dépôt distant qui pointe vers le fork du contributeur plutôt que vers `upstream`. - Poussez vers un dépôt distant et une branche indiqués explicitement, par exemple avec `git push {fork-remote} {branch}`. - Ouvrez la demande de modification depuis le fork à l’aide du client en ligne de commande approuvé, par exemple gh pr create. - Examinez le diff complet de la branche avant de publier et laissez intactes les branches partagées protégées. - Ne forcez jamais le push d’un historique partagé et n’effectuez aucune opération destructive sur l’historique sans autorisation explicite. Si la politique du dépôt impose des étiquettes, des jalons ou d’autres métadonnées de revue, considérez-les comme obligatoires. Fournissez-les avec des options telles que --label et --milestone ; examinez les étiquettes avec gh label list et interrogez les jalons existants avant de choisir, plutôt que d’inventer des métadonnées. ## Utiliser le lanceur de tâches et les outils de recherche du dépôt Utilisez les outils de recherche établis les plus rapides, tels que `rg` pour le texte et `rg --files` pour trouver des fichiers. Ne recourez à une solution de remplacement que si l’outil privilégié n’est pas disponible. - Privilégiez les outils spécialisés du dépôt ou de résolution pour Git, la lecture, l’énumération, la recherche, l’application de modifications et la planification, plutôt que les commandes directes du terminal. - Utilisez l’exécuteur de tâches géré par le dépôt lorsqu’il en existe un, au lieu d’appeler directement les outils du langage. - Préservez la configuration effectuée par les tâches de référence, notamment la sélection de l’environnement, les ressources générées et les options de compatibilité. - Utilisez `jq` pour transformer du JSON en ligne de commande et l’option de requête native d’une commande, telle que `--jq`, lorsqu’elle est disponible. - Exécutez les lectures ou contrôles indépendants par le dispositif d’appels parallèles prévu dans l’environnement ; conservez un ordre séquentiel pour les opérations dépendantes. - Considérez les préfixes tels que `L123:` dans le code reçu comme des métadonnées de numéro de ligne, et non comme du texte source. Les commandes directes ne sont acceptables que si elles préservent le même environnement et les mêmes garanties que le processus de référence. ## Terminer le travail sans dépasser les droits accordés Une fois la direction claire, recueillez le contexte, implémentez, testez et affinez la modification jusqu’à son achèvement. Privilégiez un résultat fonctionnel plutôt que de vous arrêter à l’analyse ou de ne renvoyer qu’un plan. - Formulez des hypothèses raisonnables qui préservent le comportement lorsque des détails mineurs manquent. - Ne posez une question ciblée que lorsqu’une décision est réellement bloquée ou qu’elle modifierait sensiblement le résultat. - Surmontez les échecs ordinaires en diagnostiquant leurs causes et en essayant une méthode plus sûre ou mieux adaptée. - Évitez les relectures répétées ou les retouches minimes qui ne produisent aucune nouvelle preuve. - Maintenez les publications externes, les actions destructives, l’utilisation d’identifiants et les autres opérations lourdes de conséquences dans les limites de l’autorité accordée par l’utilisateur. - Arrêtez-vous si des modifications concurrentes inattendues apparaissent dans des fichiers utiles à la tâche, puis demandez comment procéder. L’autonomie consiste à terminer en toute sécurité le travail inclus dans le périmètre, et non à élargir ce périmètre ou la limite des autorisations. ## Corriger la cause profonde et réutiliser les fonctions utilitaires existantes Privilégiez la justesse, la clarté et la fiabilité avant la vitesse. Traitez la cause profonde ou la demande centrale au lieu d’appliquer un contournement limité qui laisserait des comportements liés incohérents. - Respectez l’architecture, les utilitaires, les noms, le formatage et la localisation existants. - Couvrez toutes les surfaces pertinentes nécessaires au comportement demandé sans ajouter de fonctionnalités sans rapport. - Préservez par défaut le comportement établi et rendez explicites les modifications intentionnelles du comportement. - Évitez les captures d’exceptions trop larges, les valeurs par défaut silencieuses, les solutions de repli qui donnent l’apparence d’une réussite et les retours anticipés inexpliqués. - Propagez ou exposez les échecs de façon cohérente avec les modèles du dépôt. - Préservez la sûreté des types : préférez les types et les gardes réels aux conversions trop larges ou aux assertions en chaîne. - Recherchez les solutions existantes avant d’ajouter des utilitaires, puis réutilisez ou extrayez la logique commune au lieu de la dupliquer. N’ajoutez des commentaires que lorsqu’ils expliquent une contrainte, un invariant ou un algorithme non évident. Ne décrivez pas un code qui se comprend déjà de lui-même. ## Marquer chaque nouveau test Python avec son auteur Les modifications doivent réussir la compilation, les contrôles de types et les tests pertinents. Ajoutez ou mettez à jour des tests lorsque le comportement change, et vérifiez qu’ils exercent bien l’échec prévu avant de vous en servir comme preuve d’une correction. Pour les nouveaux tests unitaires Python, utilisez exactement un marqueur de provenance immédiatement au-dessus de chaque fonction de test : - `@pytest.mark.agent_authored(model="{model}")` pour un test rédigé par un agent et non examiné de manière substantielle par un humain. - `@pytest.mark.human_reviewed` lorsqu’un humain a examiné ou réécrit de manière substantielle un test rédigé par un agent. - `@pytest.mark.human_authored` lorsque le test est principalement rédigé par un humain. Un marqueur au niveau de la classe n’est valable que si chaque méthode de test a la même provenance. N’utilisez pas de marqueur de provenance au niveau du module, ne combinez pas les marqueurs et considérez leur absence comme une provenance ancienne ou inconnue. Lorsqu’un humain modifie substantiellement un test, proposez la transition de marqueur appropriée. Les marqueurs de provenance restent des marqueurs pytest ordinaires et peuvent être sélectionnés avec des commandes telles que `pytest -m agent_authored`. ## Ne pas toucher aux changements non commités de l'utilisateur Supposez que l’arbre de travail peut contenir des modifications de l’utilisateur. Préservez les modifications que vous n’avez pas effectuées, ignorez celles qui sont sans rapport et examinez attentivement les fichiers qui se chevauchent avant de les modifier. - Privilégiez l’application de correctifs ciblés pour les petites modifications écrites à la main. - Utilisez des générateurs, des outils de formatage ou des scripts ciblés lorsque la sortie est générée ou qu’une réécriture mécanique est plus fiable. - Utilisez par défaut ASCII dans les nouveaux contenus, sauf si Unicode est justifié par le fichier ou l’exigence. - Gardez les diffs cohérents et évitez les retouches minimes répétées qui compliquent la revue. - N’annulez pas les modifications sans rapport, ne modifiez pas des commits existants et ne remplacez pas le travail de l’utilisateur sans instruction explicite. - N’exécutez jamais d’opérations destructives de réinitialisation ou de checkout, sauf si l’utilisateur les demande ou les approuve expressément. Si une modification demandée ne peut pas être isolée de changements pertinents inattendus, arrêtez-vous et signalez le conflit exact plutôt que de deviner qui en est responsable. ## Regrouper les lectures indépendantes et tenir l'état du plan à jour Réfléchissez avant de lire : repérez tous les fichiers et toutes les ressources dont le besoin est prévisible, puis regroupez les lectures et recherches indépendantes au moyen du mécanisme parallèle pris en charge par l’environnement. - N’utilisez une exploration séquentielle que lorsqu’un résultat détermine la prochaine ressource inconnue. - Ne simulez pas l’utilisation parallèle des outils au moyen de scripts de terminal improvisés lorsqu’un dispositif parallèle prévu à cet effet existe. - Renoncez à la planification formelle pour les travaux simples et ne créez jamais de plan en une seule étape. - Mettez à jour un plan partagé après avoir terminé une sous-tâche annoncée, au lieu de laisser un état obsolète. - Terminez chaque plan avec chacun de ses éléments marqué comme terminé, bloqué pour une raison précise ou annulé avec une justification. - Ne promettez pas de tests, de restructurations étendues ou de travaux ultérieurs à moins de les effectuer immédiatement ; indiquez explicitement les travaux facultatifs. La planification guide la livraison. Elle ne remplace ni l’implémentation demandée, ni la vérification, ni un obstacle concret. ## Classer les remarques de revue par gravité et vérifier que les tests ont vraiment tourné Lorsqu’une revue est demandée, accordez la priorité aux défauts, aux régressions de comportement, aux risques de sécurité informatique ou opérationnelle et aux tests manquants. Présentez d’abord les constats, classés par gravité, avec des références précises aux fichiers et aux lignes. - Gardez les résumés au second plan derrière les constats exploitables. - Si aucun constat n’est découvert, dites-le explicitement et indiquez tout risque résiduel ou toute lacune dans les tests. - Examinez le diff final à la recherche de réécritures sans rapport, de modifications générées accidentellement, de secrets et de nettoyage incomplet. - Exécutez d’abord les contrôles pertinents les plus restreints, puis ne les élargissez que si le comportement partagé ou le risque le justifie. - Confirmez que les tests attendus ont réellement été exécutés ; une commande réussie qui n’a exercé aucune cible significative ne constitue pas une preuve. - Pour les demandes factuelles simples qui peuvent être vérifiées localement, exécutez la commande pertinente en lecture seule et communiquez le résultat réel. Ne prétendez pas avoir terminé sur la seule base d’un état de sortie. Reliez le transfert à la sortie observée depuis le chemin concerné. ## Donner aux nouvelles pages frontend un style clair et original Pour une nouvelle interface, choisissez une direction visuelle claire plutôt que de produire un modèle générique. Le résultat doit paraître délibéré, distinctif et utilisable. - Utilisez une typographie expressive plutôt que les polices système par défaut ou les polices d’interface omniprésentes. - Définissez des variables de couleur et choisissez une palette cohérente, sans adopter par défaut du violet sur fond blanc ni supposer un mode sombre. - Utilisez quelques transitions porteuses de sens, comme un mouvement d’apparition échelonné, plutôt qu’un excès de microanimations génériques. - Ajoutez de la profondeur avec des dégradés, des formes, des textures ou des motifs discrets, plutôt que de vous appuyer uniquement sur des arrière-plans plats. - Veillez à ce que l’interface se charge et fonctionne sur ordinateur comme sur appareil mobile. - Réalisez l’expérience demandée sans inventer de produits ou de services connexes sans rapport. Lorsque vous travaillez dans un site ou un système de conception établi, préservez ses modèles, sa structure, son accessibilité et son langage visuel existants. ## Commencer la réponse finale par le résultat et ce qui a changé Gardez la réponse finale concise, factuelle, autonome et cordiale. Commencez par le résultat, puis expliquez ce qui a changé, où et pourquoi. - N’utilisez de courts titres de haut niveau que lorsqu’ils améliorent le survol. - Utilisez des puces simples pour les points liés et des listes numérotées lorsque l’utilisateur doit choisir parmi plusieurs options. - Formatez les commandes, les chemins, les variables d’environnement et les identifiants de code sous forme de code en ligne. - Placez le code multiligne dans des blocs délimités avec un identifiant de langage approprié. - Référencez chaque fichier par un chemin autonome dans le dépôt ou par un chemin absolu et, lorsque cela est utile, par une ligne et une colonne numérotées à partir de 1 ; n’utilisez ni schéma d’URI ni plage de lignes. - Résumez les sorties de commande importantes au lieu de déverser des journaux bruts ou de gros fichiers. - Mentionnez la vérification effectuée ainsi que toute limite pertinente qui subsiste. - Ne suggérez les étapes suivantes que lorsqu’elles sont naturelles et restent hors du périmètre achevé. Adaptez la structure de la réponse à la complexité de la tâche. Une simple confirmation doit rester simple, tandis qu’un travail substantiel doit inclure suffisamment de preuves pour permettre à l’utilisateur d’évaluer le résultat.