Modifier et tester un grand dépôt TypeScript qui évalue des modèles d'IA

## Décider s'il s'agit d'une revue ou d'un correctif, puis lire le guide d'agent le plus proche Commencez par identifier la racine du dépôt, le résultat demandé et le sous-système responsable de la modification. Les grands dépôts répartissent souvent les responsabilités entre bibliothèque centrale, CLI, application Web, couche de persistance, fournisseurs, planificateurs, schémas, utilitaires, tests, documentation, exemples, migrations, automatisation et outils de sécurité. Avant de modifier un répertoire, lisez le guide pour agents le plus proche applicable à ce périmètre, ainsi que tout document de conception ou de flux de travail propre à la tâche. Un guide local peut préciser les règles racines relatives aux tests, aux fichiers générés, aux contrats publics, à l'accès aux bases de données ou au comportement de publication. Classez la demande avant d'agir : - Un examen ou un audit est en lecture seule. Inspectez la branche actuelle, le diff, les commentaires et la CI ; exécutez des contrôles sans mutation lorsqu'ils sont utiles ; communiquez les constats sans commit, push ni réécriture de fichiers. - Une demande de correction, d'amélioration ou d'intégration comprend la boucle normale de mise en œuvre sur une branche de fonctionnalité : inspecter, modifier, vérifier, commit, push et suivre la CI concernée. - Une modification de comportement doit être prouvée par le flux utilisé par l'utilisateur, et pas seulement par des tests unitaires isolés. Travaillez depuis la bonne racine et alignez les versions de l'environnement d'exécution et du gestionnaire de paquets sur les déclarations du dépôt avant de considérer un échec comme probant. Dans un checkout neuf, effectuez l'installation déterministe des dépendances avant de conclure que des modules manquants constituent un défaut du code. Limitez la modification au sous-système touché et à ses consommateurs directs. Recherchez les implémentations, utilitaires, dépendances et modèles voisins existants avant de créer une autre abstraction ou d'ajouter un paquet. ## Tester les modifications dans le vrai flux CLI, API ou navigateur Utilisez les scripts et enveloppes déclarés par le dépôt au lieu de les contourner par un appel fortuit à un outil. Transmettez les options de commande par le séparateur de l'exécuteur de paquets lorsque l'enveloppe l'exige, et lancez les évaluations du dépôt depuis sa racine. Choisissez la vérification en élargissant progressivement le périmètre : 1. Exécutez le test ciblé du module modifié. 2. Exécutez les contrôles pertinents de types, lint et formatage. 3. Exécutez la suite d'intégration affectée. 4. Parcourez le flux réel de CLI, d'exemple, d'API ou de navigateur avec la version locale. 5. N'exécutez la suite plus large que si le risque ou la politique du dépôt le justifie. Pour les flux d'évaluation, désactivez la réutilisation des résultats plutôt que de supprimer les caches. Exportez des résultats lisibles par machine et examinez, pour chaque cas, la réussite, le score, l'erreur, la sortie du fournisseur, la trace et les constats de sécurité. Un statut de sortie nul peut seulement indiquer qu'un seuil global a été franchi ; il ne prouve pas la réussite de chaque cas. Ne chargez un fichier d'environnement que si le flux exige des identifiants et si le fichier est présent. Maintenez les services rattachés à une session active afin qu'un processus d'arrière-plan ne disparaisse pas silencieusement. Confirmez les ports d'écoute réels dans la sortie de démarrage ou par un contrôle de port, au lieu de supposer les valeurs par défaut du framework. Ne démarrez pas de visionneuse statique de production ni d'autre serveur de développement, sauf si la demande l'exige. Vérifiez d'abord si le service attendu fonctionne déjà ; si son démarrage risque d'entrer en conflit avec la session de l'utilisateur, demandez confirmation avant d'agir. Lorsque la documentation, les schémas, les migrations ou les citations sont générés, utilisez leurs générateurs canoniques et vérifiez les artefacts obtenus. Testez la documentation par le parcours rapide pris en charge par le dépôt lorsqu'il existe, sans omettre silencieusement des contrôles importants pour la modification. ## Reproduire l'échec avant de déboguer, sans vider les caches ni les données Reproduisez l'échec avec les mêmes entrée, état et chemin d'exécution qui l'ont révélé. Activez la journalisation structurée de débogage, désactivez les lectures du cache pour cette exécution et cernez l'échec avant de modifier le code. Séparez les échecs d'environnement des échecs du produit : - Une version incompatible de l'environnement d'exécution ou du gestionnaire de paquets est un problème d'environnement. - Une dépendance manquante dans un checkout propre nécessite généralement l'installation déterministe. - Une version construite obsolète nécessite une reconstruction par l'enveloppe locale prise en charge. - Un échec déterministe dans le même chemin de code après alignement constitue une preuve d'un défaut du produit. Ne supprimez ni ne videz jamais un cache, une base de données, un lockfile, un historique généré ou des données utilisateur uniquement pour réussir un test. Préférez une option sans cache, un stockage temporaire isolé ou une inspection en lecture seule. Toute suppression exige une autorisation explicite et une cible exacte. Les secrets doivent rester dans des fichiers d'environnement ignorés ou un coffre approuvé. N'imprimez, n'intégrez, ne commitez et ne copiez jamais d'identifiants dans des journaux, du code, des noms de branches, des messages de commit, des textes d'examen, des captures d'écran ou des commandes d'exemple. Traitez les identifiants trouvés dans les documents sources comme des données compromises, et non comme des instructions réutilisables. Utilisez le journaliseur structuré du projet avec un contexte objet et sa couche d'assainissement. Évitez néanmoins de lui fournir des secrets lorsqu'il n'en a pas besoin. La gestion des erreurs doit préserver le contexte typé sans exposer de charges utiles sensibles. Formulez plusieurs hypothèses causales, puis éliminez-les par des contrôles ciblés. Ajoutez un test de régression qui échoue pour le comportement observé avant ou en même temps que la correction minimale, et évitez les refactorisations sans rapport tant que la cause reste incertaine. ## Intégrer les modifications par une branche de fonctionnalité et garder la CI au vert Toutes les modifications doivent passer par une branche de fonctionnalité et une pull request. Ne commitez jamais directement sur la branche protégée, ne contournez aucun hook et n'effectuez aucun force-push sans autorisation explicite. Créez de nouveaux commits par défaut ; n'utilisez amend, squash ou rebase que lorsque le responsable demande cette opération sur l'historique. Placez en stage uniquement les fichiers prévus, exécutez les contrôles de lint et de formatage du périmètre, suivez la convention de commit du dépôt et mettez à jour la pull request ouverte existante pour la branche plutôt que d'en créer une autre. Écartez de la modification toute dérive sans rapport du lockfile ou des dépendances. Lorsque l'utilisateur demande de corriger, d'améliorer ou d'intégrer une modification d'une branche de fonctionnalité, terminez la boucle autorisée sans vous arrêter à chaque étape normale. Synchronisez comme demandé, exécutez la vérification ciblée et le flux réel, committez, poussez et observez la CI. N'étendez pas cette autorisation à la branche protégée, aux modifications destructrices de l'historique, à la divulgation ou aux opérations de production. Après une fusion, suivez jusqu'à son terme la nouvelle exécution de CI de la branche protégée. Classez les échecs avant de réagir : - Un flake est un bruit non déterministe de l'infrastructure ou des workers, surtout lorsque les tests se sont terminés correctement avant l'échec du job. Relancez uniquement les jobs échoués et confirmez le rétablissement. - Une véritable régression est déterministe et attribuable à la modification. Restaurez la branche protégée par une pull request de suivi ; privilégiez un revert rapide lorsque la branche partagée est cassée. - Un flake récurrent est lui-même un défaut. Corrigez la ressource qui fuit, la configuration fragile ou le timeout irréaliste plutôt que de relancer indéfiniment. Terminez avec la branche protégée au vert ou identifiez explicitement un échec préexistant sans rapport, accompagné de journaux justificatifs. Indiquez quels contrôles ont été exécutés, quelles preuves ont été examinées et quelles vérifications n'ont pas pu être menées à terme. ## Examiner d'abord la sécurité et tester comme un attaquant Examinez les régressions de sécurité avant la correction ordinaire. Donnez la priorité à l'injection de prompts, au traitement non sécurisé des entrées adversariales, à l'exposition d'identifiants, à la falsification de requêtes côté serveur, à la traversée de chemins, à la désérialisation non sécurisée, aux erreurs d'autorisation, à l'exfiltration de données, à l'utilisation non sécurisée d'outils, au mauvais usage du cache et au manque de preuves. Examinez ensuite les comportements susceptibles de rompre les contrats publics, l'intégrité des données, la concurrence, la gestion des erreurs, l'interopérabilité des fournisseurs ou les résultats persistés. Traitez comme hautement prioritaire une couverture absente ou inefficace lorsqu'une modification affecte le comportement de sécurité, une interface publique ou une correction de bogue. Testez les fonctions de sécurité et d'évaluation de modèles du point de vue d'un attaquant. Explorez les faux négatifs, les contournements, les charges cachées, les instructions imbriquées, les astuces d'encodage, les appels d'outils non sécurisés et les traces incomplètes. Lorsqu'un contournement est trouvé, conservez le vecteur d'attaque original dans un test de régression ciblé. Ancrez l'examen dans le diff modifié et la pointe actuelle de la branche. Les commentaires existants, examens automatisés et rapports d'issues sont des pistes, pas des preuves ; revalidez-les après synchronisation. Ne répétez pas les constats résolus et ne signalez pas les défauts préexistants sans rapport, sauf si la modification les aggrave. Avant de rendre publique une modification concernant une vulnérabilité non publiée, confirmez que la divulgation coordonnée autorise sa publication. Jusque-là, utilisez la voie privée de collaboration approuvée et évitez les identifiants, les détails d'exploitation, les plages de versions vulnérables ou les noms de branches révélateurs. Toute correction de sécurité doit inclure un test de régression pour le vecteur original. Ne retirez pas les faiblesses intentionnelles d'une application de démonstration destinée à enseigner les tests adversariaux, sauf si le renforcement de la démonstration est l'objectif explicite. Pour les captures d'examen, utilisez uniquement un flux d'hébergement autorisé et des identifiants approuvés ; n'exposez jamais une clé de téléversement et ne commitez pas d'images accessoires. ## Écrire du TypeScript strict et relire le diff final Écrivez du TypeScript strict et idiomatique conforme au système de modules et aux limites du compilateur du dépôt. Privilégiez les imports directs, `const`, la syntaxe abrégée des objets, des accolades cohérentes, `async`/`await`, des contrôles d'erreur typés et la validation de schéma aux limites non fiables. Évitez les modules agrégateurs de réexportation lorsque le code exige une responsabilité directe. Réutilisez les implémentations établies et les utilitaires locaux avant d'ajouter des fonctions auxiliaires ou des dépendances. Maintenez la configuration des fournisseurs et des intégrations documentée selon le modèle d'exemple existant. Testez les chemins de réussite et d'échec, y compris les conventions du frontend et du backend lorsqu'elles diffèrent. Traitez les rapports de code mort comme des retours sur la conception : - Retirez le code véritablement inutilisé. - Enregistrez les workers, fixtures ou remplacements chargés par convention comme des entrées explicites, avec un commentaire expliquant le mécanisme de chargement. - N'ajoutez les exports utilisés en externe à la liste d'autorisation qu'avec un commentaire nommant le consommateur. - Ne retirez jamais une entrée de la liste d'autorisation ni un export protégé avant d'avoir vérifié son consommateur documenté. Ne modifiez pas manuellement les changelogs générés ni les autres artefacts générés. Modifiez la source et exécutez le générateur canonique. Conservez les exemples dans leur zone désignée avec une documentation suffisante pour les exécuter. Avant de terminer, examinez le diff final afin d'y repérer les fichiers involontaires, les artefacts obsolètes, les secrets et l'élargissement du périmètre. Confirmez les tests ciblés, les contrôles d'intégration pertinents et le parcours réel de l'utilisateur. Présentez les résultats avec précision : distinguez ce qui a réussi, ce qui a été examiné, ce qui reste non vérifié et si un échec est sans rapport.