Garder un agent de codage IA dans les limites de la demande dans un dépôt d'application en couches

## Classer les instructions et se fier au code actuel plutôt qu'à la mémoire La copie de travail actuelle fait autorité sur le comportement actuel. Une demande de l'utilisateur peut définir un changement de comportement souhaité, mais elle ne transforme pas une hypothèse historique en fait et n'accorde pas la permission d'effectuer une action externe sans rapport. ### Ordre des instructions Suivez d'abord les instructions applicables de niveau supérieur, puis le fichier d'instructions d'agent dont la portée est la plus proche, puis la demande la plus récente de l'utilisateur. À autorité égale, l'instruction explicite la plus récente l'emporte. ### Ordre des preuves Pour le comportement de la copie de travail actuelle, préférez le code source et les tests actuels, puis les workflows et scripts locaux au dépôt, puis la documentation. Pour l'état d'exécution actuel, une preuve en direct ne compte qu'une fois que le répertoire de travail, l'artefact, la branche ou une provenance équivalente la rattache à la copie de travail visée. Un processus non prouvé provenant d'une autre copie de travail ne l'emporte pas sur les faits établis par le code source. La mémoire antérieure et les rapports de sous-agents se classent en dessous des preuves inspectées, et l'inférence vient en dernier. ### Discipline de la mémoire Traitez la mémoire antérieure et les sorties de sous-agents comme des pistes potentiellement obsolètes. Vérifiez les affirmations lourdes de conséquences face à la copie de travail actuelle, et ne laissez jamais la mémoire autoriser une mutation ou une action externe. N'écrivez pas de mémoire durable au sujet du dépôt, sauf si l'utilisateur le demande explicitement. Ne faites jamais entrer de secrets ni de données utilisateur dans la mémoire. ## Choisir l'édition de l'app par son vrai réglage et ne pas remettre les fonctions retirées Certains comportements relèvent du contrat produit et non du détail d'implémentation. Ne les modifiez pas comme effet de bord d'une autre tâche. ### Sélectionner le comportement d'après le vrai signal d'exécution Une édition ou un mode doit être sélectionné par sa propriété d'exécution documentée ou par sa variable d'environnement de build. Le nom final d'un artefact ne change que le nom de l'artefact et n'est jamais un signal de mode d'exécution. Les nouvelles branches d'exécution doivent lire le vrai signal ; ne déduisez jamais le mode d'un nom d'archive, d'un nom d'application, d'un port ou d'un chemin d'artefact. ### Maintenir la frontière de l'édition livrée Ne réintroduisez pas le transfert par passerelle, les comptes cloud, les abonnements, le paiement, les licences commerciales ni un runtime bureau alternatif dans une édition qui les a supprimés. Masquer l'interface frontend n'équivaut pas à isoler le backend : les appels distants, les en-têtes, les cookies, les contrôleurs et l'enregistrement des services doivent eux aussi respecter la frontière de l'édition. ### Conserver une sémantique compatible Préservez la sémantique de l'API publique, du stockage, des sources de données, des espaces de noms, de la console, des tâches et des positions de mise en page, sauf si un changement explicite de compatibilité ou de migration est demandé. Lorsque le build bureau empaqueté prend en charge les mises à jour depuis l'intérieur de l'application, gardez alignés l'interface et l'état de mise à jour du renderer, les gestionnaires de mise à jour natifs, les métadonnées de l'updater, les charges utiles empaquetées et tout assistant d'updater à privilèges élevés dès que le format de release change. ## Utiliser l'index du code pour la structure et la recherche texte pour les chaînes littérales ### Questions structurelles Lorsqu'un index structurel du code est initialisé et que ses outils sont disponibles, commencez par une requête de contexte sur une fonctionnalité, une architecture ou un chemin de bug, puis explorez une seule fois le code source associé. Utilisez la recherche de symboles pour les noms, les requêtes d'appelants et d'appelés pour les chemins d'appel, et une requête d'impact avant de modifier un symbole partagé. Utilisez la liste des fichiers indexés pour explorer l'arborescence des sources, et la commande de statut pour la santé de l'index. ### Questions littérales Utilisez la recherche textuelle pour les chaînes littérales, les clés de configuration, les lignes de journal, les commentaires, les indicateurs générés et les lignes de commande. Ne répétez pas un résultat d'index par une seconde boucle de recherche et de lecture. ### Limites de l'index L'index peut être en retard sur les écritures récentes, et les outils de build restent l'autorité en matière d'exactitude. Si l'index est indisponible, utilisez des lectures de fichiers ciblées et la recherche textuelle, sans prétendre que des résultats indexés existent. Si le dépôt n'a pas d'index initialisé, demandez avant d'en créer un. ## Distinguer avant d'agir les demandes en lecture seule des demandes de modification - Les demandes de réponse, d'explication, de revue, de diagnostic et d'état sont en lecture seule par défaut. Utilisez une inspection non mutante et rapportez les preuves. Ne modifiez pas de fichiers, n'exécutez pas de builds à fortes mutations et n'implémentez pas de correctif sans qu'on vous le demande. - Les demandes de modification, de correction et de nettoyage autorisent des modifications locales du code source et les commandes locales pertinentes dans la portée indiquée. - Une demande de build autorise uniquement les commandes de build, les caches de dépendances et les sorties générées. Elle n'autorise pas la réparation du code source, sauf si l'utilisateur demande aussi un correctif. - Le commit, le push, le tag, le déclenchement de workflow, la publication, le déploiement, la signature et toute action touchant à la production ou aux données clients exigent une autorisation explicite pour cet effet externe précis. ## Mener une modification approuvée jusqu'au bout dans le plus petit périmètre Pour une tâche d'implémentation autorisée, livrez le résultat demandé de bout en bout dans la plus petite portée cohérente. - Confirmez le dépôt exact, la branche, l'état et les modifications déjà présentes de l'utilisateur. - Lisez l'implémentation, les tests, la configuration et le workflow les plus proches avant de modifier. Retracez le comportement inter-couches lorsqu'un changement s'étend au frontend, au backend, au stockage, aux conteneurs ou à l'empaquetage bureau. - Classez le changement selon la surface affectée et choisissez la vérification en conséquence. - Modifiez de façon étroite, en respectant la propriété existante des modules et les conventions locales. - Exécutez les contrôles pertinents, inspectez le diff final, et distinguez les vérifications que vous avez réellement exécutées de celles qui n'étaient pas disponibles. - Rapportez le résultat, le risque restant et l'état exact de ce qui n'est pas commité ou pas poussé. ## Garder le code serveur et client dans leurs propres couches et modules ### Côté serveur Gardez les contrôleurs et les adaptateurs de transport minces. Le comportement métier appartient aux services de domaine, et la persistance se place derrière les API ou fournisseurs de stockage. Préservez le sens des dépendances entre modules et les contrats documentés ; ne contournez pas les API de domaine par un nouveau couplage allant directement de la couche web au stockage. Utilisez le niveau de langage et les frameworks déjà en place dans le projet, au lieu d'introduire un framework parallèle ou une abstraction utilitaire pour un comportement dont un module est déjà propriétaire. Gardez le SQL spécifique à une base de données, les métadonnées, la complétion et le comportement de typage à l'intérieur du plugin qui en est propriétaire, et ajoutez des tests de plugin ciblés pour les changements de dialecte. ### Côté client Utilisez la stack frontend existante, les composants du projet et les helpers de service. Dérivez les conditions d'édition des helpers d'édition d'exécution actuels ou de la variable d'environnement de build documentée, au lieu de disséminer des vérifications d'environnement sans rapport. N'ajoutez pas de pont bureau en double ni de second transport de renderer ; utilisez les wrappers de pont existants. Préservez les contrats de réponse des services et les clés de stockage, car supprimer de l'interface n'autorise pas à supprimer un contrat backend qu'un autre chemin utilise encore. Gardez les chaînes visibles par l'utilisateur dans le système de localisation existant lorsque la fonctionnalité environnante est localisée. ### Surfaces à haut risque Les changements touchant au contexte de requête partagé, à l'identité, aux frontières d'isolation, au routage du stockage, aux services d'IA ou au démarrage de l'application bureau exigent une revue explicite des chemins d'appel et des régressions. ## Ne pas committer de secrets ni de fichiers générés ### Ne jamais commiter de contenu sensible ou reproductible Ne commitez jamais d'identifiants, de jetons, de matériel de signature, d'URL privées, de contenus de bases de données locales, de fichiers d'éditeur, de téléchargements d'exécution, de sorties de gestionnaire de paquets, de sorties de build frontend, de contenu d'empaquetage préparé, ni d'installateurs. ### Manipuler les secrets de façon étroite Ne lisez des secrets que lorsque l'opération explicitement autorisée l'exige. N'affichez, ne journalisez, ne collez, ne résumez et ne persistez jamais la valeur d'un secret. Ne réutilisez pas un identifiant pour un autre dépôt, un autre registre, un autre compte ou un autre environnement. ### Tenir les données réelles à l'écart N'accédez pas aux données de production, aux données utilisateur ou à une base de données locale sans rapport, et ne les modifiez pas, par commodité de build ou de diagnostic. Utilisez des fixtures ou une source de données de test locale nommée, sauf si l'utilisateur place explicitement un autre système dans la portée. ### Exposition réseau Gardez les écouteurs de l'application bureau et ceux publiés sur l'hôte en loopback, sauf si l'exposition distante est explicitement demandée et documentée avec son impact de sécurité. Ne modifiez pas le binding interne requis d'un conteneur afin de faire appliquer une politique de publication sur l'hôte. ### Versionné contre généré Sachez quelles ressources d'empaquetage sont du code source versionné et lesquelles sont des sorties reproductibles. Ne supprimez pas une ressource suivie au seul motif qu'elle partage un répertoire parent avec des fichiers générés. Mettez à jour le readme et les exemples de workflow lorsqu'une commande publique, un port, un artefact, une variable d'environnement ou une entrée de release change. ## Choisir tests et vérifications selon la partie de l'app modifiée - Logique, route, service ou état frontend : le test ciblé pertinent, la tâche de lint et le build de l'édition. - Code de domaine serveur, web, stockage ou plugin : des tests ciblés avec l'exécution des tests explicitement activée, tout motif d'inclusion de tests obsolète et tout réglage ignorant les échecs étant surchargés, et un nombre de tests non nul confirmé ; puis empaquetez le module affecté et ses dépendances. - API partagée ou contrat de persistance : ajoutez une couverture de compatibilité et inspectez les appelants ainsi que les effets de sérialisation et de stockage. - Comportement de mode d'exécution, d'identité, d'isolation, d'IA ou de réseau : inspectez à la fois le chemin d'enregistrement et le chemin d'appel, et exécutez un test de fumée de l'édition lorsque c'est faisable. - Code de pont natif : des tests de pont ciblés, une compilation ou un empaquetage complet, et une vérification correspondante côté renderer. - Scripts et ressources bureau : vérifiez la syntaxe des scripts shell touchés, validez les métadonnées de plateforme, exécutez l'étape de préparation et relisez les workflows multiplateformes. - Travail sur conteneurs : syntaxe des scripts, expansion de compose, build d'image, et un test de fumée HTTP ou sur les ressources statiques lorsque le runtime de conteneurs est disponible. - Définitions de workflow : analysez ou inspectez les entrées et commandes résolues, et distinguez l'envoi d'artefacts de la publication de release et de l'envoi vers le réseau de diffusion de contenu. - Changements portant uniquement sur la documentation : vérifiez les commandes, les liens, les chemins, les ports et les noms face au code source et aux workflows actuels. - Tout changement : un contrôle du diff pour les espaces et les marqueurs de conflit, une relecture ciblée du diff et un contrôle d'état final. ## Ne pas faire passer un build pour des tests réussis ; signaler seulement les tests lancés La réussite du build n'est pas la réussite des tests. Lorsqu'un projet saute les tests par défaut, ou comporte un motif d'inclusion de tests obsolète ou un réglage qui ignore les échecs, surchargez-les explicitement et confirmez que le résumé des tests indique un nombre de tests non nul, avec zéro échec et zéro erreur. ### Ne pas exagérer N'affirmez pas qu'un build a exécuté des tests lorsque le build a été lancé en sautant les tests. N'affirmez pas qu'un paquet natif fonctionne sur la seule base de la syntaxe shell ou d'une étape de préparation ; n'annoncez la réussite d'un installateur que pour un installateur réellement construit et exécuté sur sa plateforme cible. Si l'exécution d'un ensemble de tests plus large fait apparaître des échecs de compilation obsolètes ailleurs dans le module, signalez-les au lieu d'affaiblir la découverte des tests. ### Nommer ce qui n'a pas été exécuté Isolez les contrôles qui restent réservés à l'automatisation, réservés à une plateforme, ou non exécutés pour une autre raison. Si un outil requis est indisponible, signalez le contrôle manquant ou utilisez un repli équivalent en lecture seule ; ne fabriquez jamais de sortie d'outil et n'élargissez jamais l'environnement en silence. ## N'utiliser que les services et bases de test dont la tâche a besoin - Pour une tâche autorisée de modification ou de build, les modifications du dépôt, les sorties de build générées, les caches standards du gestionnaire de paquets et les téléchargements ordinaires de dépendances sont permis. Ne modifiez pas la configuration globale du gestionnaire de paquets et n'installez pas de paquets système, sauf si la tâche l'exige et que l'impact est explicite. - Ne démarrez un service local que si le test de fumée demandé en a besoin. Inspectez d'abord le port, liez le service au loopback, notez le processus, et n'arrêtez que le processus que vous avez démarré pour cette tâche. Ne redémarrez jamais un service sans rapport. - Les builds de conteneurs et les conteneurs de test limités à la tâche sont permis pour une demande de build de conteneur. Ne purgez pas le démon, ne supprimez pas de ressources sans rapport et ne démarrez pas de services composés en dehors de la tâche. - N'utilisez que des bases de données locales ou de test nommées pour la vérification autonome. Toute modification de schéma ou de données dans des systèmes partagés, de préproduction ou de production exige une portée explicite, un plan de rétablissement et une autorisation. - L'accès réseau en lecture seule pour la résolution des dépendances et la vérification de sources publiques est permis en cas de besoin. Les écritures authentifiées, les envois, les déclenchements de workflows, les messages et la publication restent des actions externes exigeant une autorité explicite de l'utilisateur. ## Garder les modifications de l'utilisateur et demander avant un push ou une release ### Protéger l'arbre de travail de l'utilisateur Préservez les modifications de l'utilisateur sans rapport avec la tâche, y compris celles qui se trouvent dans des fichiers que vous devez aussi modifier. Ne faites jamais de reset, de checkout, de clean ni d'écrasement sur ces modifications pour simplifier la tâche. N'utilisez pas de commandes destructrices de contrôle de version, et ne supprimez pas de données locales ni de caches générés en dehors de la portée demandée. ### Exiger une demande explicite N'indexez pas, ne commitez pas, ne poussez pas, ne taguez pas, ne déclenchez pas de workflows, ne publiez pas de releases, n'envoyez pas de paquets et ne poussez pas d'images, sauf si l'utilisateur demande explicitement cette action. Traitez le déclenchement de workflow, la publication de release, le push d'image, l'envoi vers le réseau de diffusion de contenu, le déplacement d'un tag glissant et la signature comme des mutations externes situées derrière une frontière d'approbation explicite. ### Lorsqu'un commit ou un push est demandé N'indexez que la portée sémantique visée, inspectez le diff indexé, vérifiez qu'il ne contient ni identifiants ni sorties générées, exécutez ses contrôles, et vérifiez les identifiants de commit locaux et distants. ## À la passation, dire ce qui a changé et quelles vérifications ont tourné Au moment du passage de relais, indiquez quel comportement a changé et quels fichiers en sont propriétaires ; quelles commandes ont réellement été exécutées et si elles ont réussi ; toute vérification qui reste réservée à l'automatisation, réservée à une plateforme, ou non exécutée pour une autre raison ; l'état actuel du contrôle de version, y compris les modifications sans rapport laissées intactes ; et chaque action externe tentée avec son identifiant de commit, de branche distante, d'exécution de workflow, d'image, de release ou d'artefact, y compris les tentatives partielles ou échouées. ### Rapports de revue de code Pour une revue de code, rapportez d'abord les constats par ordre de gravité, chacun avec son fichier et sa ligne, la surface d'exécution affectée, le risque comportemental, et le correctif requis ou la preuve manquante. S'il n'y a aucun constat, dites-le et listez les lacunes de test résiduelles. ## Décider quand s'arrêter pour demander et comment réessayer après un échec Continuez de façon autonome pour le travail normal de lecture, de modification, de build et de test dans la portée demandée. Arrêtez-vous et posez la question uniquement lorsque l'une de ces conditions change matériellement le résultat : - les instructions applicables se contredisent, ou le comportement souhaité reste ambigu après que le code source actuel a établi le comportement existant ; - la tâche exige de supprimer des données utilisateur, de modifier un contrat public de compatibilité, d'exposer un écouteur ou de franchir une frontière d'édition ; - les identifiants, l'identité de signature, la destination de release ou l'autorité sur la production font défaut ; - une action irréversible ou visible de l'extérieur n'a pas été explicitement demandée ; - des modifications de l'utilisateur sans rapport rendent le changement demandé impossible à isoler sans risque ; ou - la vérification requise échoue encore après un cycle de diagnostic et de réparation, et il ne reste aucun rétablissement sûr dans la portée. ### Reprises et interruptions Ne réessayez une opération transitoire et idempotente qu'au maximum deux fois. Ne répétez jamais aveuglément un push, un déclenchement de workflow, une release, un envoi, une demande de signature ou toute autre mutation externe après un résultat ambigu ; inspectez d'abord l'état du dépôt distant ou du fournisseur. Après une interruption ou un achèvement partiel, revérifiez l'état de la branche, de l'arbre de travail, du dépôt distant et des workflows avant de reprendre. ### En cas d'échec Gardez l'arbre de travail récupérable, consignez la commande et l'erreur exactes, évitez les affirmations de réussite non étayées, et transmettez l'objectif en cours, les preuves, les actions déjà tentées, les identifiants, les risques ouverts et la prochaine action sûre.