Modifiez un monorepo TypeScript full-stack et testez ses fonctionnalités LLM selon le sens

## Lancez seulement les commandes et vérifications par paquet de la CI Avant toute exécution, repérez les commandes documentées du dépôt pour le développement, le build, le lint, le formatage, les tests, les tests d’intégration et les évaluations. Utilisez la commande propre au package de l’espace de travail concerné au lieu de lui substituer un outil lancé sur toute la racine. - Exécutez un seul test au moyen de son chemin pris en charge ou d’un filtre sur son nom. - Lancez les évaluations d’IA depuis la racine du dépôt au moyen de la commande d’évaluation dédiée du package d’IA. - Utilisez le build ou la vérification de types de l’application qui correspond à la CI ; ne lancez pas à la racine une vérification de types non prise en charge qui ferait apparaître une dette sans rapport dans le monorepo. - N’installez les dépendances avant les tests ou les builds que si l’espace de travail n’est pas déjà installé. - Ne démarrez pas de serveur de développement ni de build complet, sauf si la tâche le demande explicitement. La validation doit correspondre au package modifié et aux contrôles utilisés par la CI. ## Testez ce que fait le code, pas la façon dont il est écrit Consultez le guide de test du dépôt avant de créer ou de modifier des tests. Pour les corrections de bugs du cœur du système, appliquez si possible la démarche rouge-vert-refactorisation : reproduisez d’abord l’échec, apportez ensuite la plus petite correction, puis améliorez la structure sans modifier le comportement. Placez les tests unitaires avec les fichiers source. Placez les tests d’intégration, end-to-end et d’évaluation d’IA dans leurs arborescences de test prévues. Utilisez la véritable implémentation des logs, sauf si le test vise précisément une frontière du logger. Privilégiez les tests capables de détecter une régression comportementale importante. Évitez les assertions de faible valeur qui se contentent de répéter des détails privés de l’implémentation. Les modifications de prompts et de comportement du modèle doivent disposer d’évaluations sémantiques ou de tests de contrat structuré en plus des tests ordinaires du code. ## Installez les dépendances dans l’espace de travail qui les utilise Installez une dépendance dans l’espace de travail qui l’utilise, et non à la racine du monorepo. Lors de l’ajout d’un nouveau package d’espace de travail, mettez à jour tous les manifestes de build de conteneurs de production et locaux qui copient les métadonnées des packages avant l’installation des dépendances. Maintenez les variables d’environnement synchronisées entre le fichier d’environnement d’exemple, le module de validation à l’exécution et la configuration de build du monorepo. Préfixez les variables exposées au code du navigateur avec le préfixe de variables publiques du dépôt. Si le comportement d’un framework dépend de sa version ou reste ambigu, consultez la documentation fournie avec la dépendance installée avant de modifier le code. Ne vous fiez ni à votre mémoire ni à la documentation d’une autre version installée. ## Importez depuis le fichier qui définit chaque élément et déduisez les types des schémas Activez la vérification stricte des valeurs nulles et déduisez les types TypeScript des schémas de validation au lieu de dupliquer des interfaces. N’exportez pas un type qui n’est utilisé que dans le fichier où il est défini. - Gardez chaque import en haut du fichier ; n’ajoutez pas d’import dynamique au milieu d’un fichier. - Importez depuis la source d’origine au lieu de créer des chaînes de réexportation ou des fichiers barrel. - Importez des fonctions utilitaires individuelles plutôt qu’une bibliothèque utilitaire entière. - Utilisez l’alias configuré pour la racine du projet dans les imports internes à l’application. - Placez les fonctions auxiliaires au bas du fichier. - Ne placez qu’une seule ressource par fichier de route API. Une responsabilité directe facilite la compréhension des dépendances, du tree shaking et de l’impact des modifications. ## N’extrayez une fonction utilitaire que si elle clarifie le code Par défaut, intégrez la logique directement à son point d’utilisation et placez-la avec celui-ci. De petites expressions dupliquées sont souvent plus claires qu’un utilitaire prématuré. N’extrayez pas une fonction qui ne fait que renommer et transmettre des paramètres. Procédez à une extraction lorsqu’un utilitaire nomme un concept de domaine important, rend le flux de contrôle environnant plus lisible ou maintient un comportement sensible à la justesse cohérent entre plusieurs flux. Centralisez rapidement une logique dupliquée substantielle lorsque ses copies doivent rester synchronisées pour éviter des bugs. Évitez les expressions ternaires longues ou imbriquées. Préférez un flux de contrôle simple, un utilitaire ciblé ou une table de correspondance. Ajoutez des commentaires pour expliquer pourquoi une décision existe, et non ce que fait un code déjà explicite. Privilégiez la modification lisible la plus simple. Ne préservez la rétrocompatibilité que si l’exigence le demande ; sinon, mettez directement à jour les sites d’appel coordonnés au lieu d’ajouter un chemin de migration inutilisé. ## Écartez les données personnelles des niveaux de log larges Ne répétez pas les champs de contexte du logger qui sont déjà attachés plus haut dans la chaîne d’appels. Placez les champs permettant d’identifier une personne, comme l’expéditeur, le destinataire ou l’objet du message, uniquement dans le niveau de trace le plus restreint du dépôt. Une exception explicitement documentée peut autoriser l’identifiant propre à l’utilisateur authentifié à des niveaux plus larges, mais n’étendez pas cette exception aux données de tiers. Conservez le véritable logger dans les tests afin que les filtres de confidentialité, la propagation du contexte et le formatage restent exercés. Avant d’ajouter un log, déterminez son public, sa durée de conservation, sa sensibilité et si le contexte existant fournit déjà la valeur. ## Dérivez l’état de l’UI des données et utilisez les composants partagés Ne recopiez pas dans un état local, au moyen d’un effet, des props récupérées ou des données du serveur. Préférez des valeurs dérivées pour les vues en lecture seule et un état d’édition explicite pour les brouillons contrôlés par l’utilisateur. Utilisez la bibliothèque de composants approuvée par le dépôt avant de créer une primitive personnalisée. Affichez le contenu asynchrone au moyen du wrapper partagé de chargement et d’erreur afin de préserver la cohérence des états de chargement, d’échec et de réussite. Placez les composants de page propres à une route à côté du fichier d’entrée de cette route, sans ajouter de répertoires de composants imbriqués. Placez les composants partagés entre plusieurs pages dans le répertoire de composants partagés de l’application. ## Faites les changements de données avec les actions serveur et les schémas de validation partagés Choisissez le middleware de route selon le niveau d’accès : gestion publique des erreurs, accès d’un utilisateur authentifié ou accès limité à un compte. Exportez les types de réponse en les dérivant de la fonction de données plutôt qu’en dupliquant des interfaces de réponse. Pour les mutations Web, utilisez les actions serveur par l’intermédiaire de la couche d’actions sûres du dépôt. Réservez les routes API POST aux intégrations qui exigent un contrat HTTP externe stable, comme les clients natifs. Définissez les schémas de validation des mutations dans les modules de validation prévus et déduisez les types d’entrée de ces schémas. Utilisez le cache client établi pour les lectures et invalidez la clé concernée après une mutation. Construisez les formulaires avec la bibliothèque de formulaires et le hook d’action approuvés, puis faites passer les échecs par le formateur partagé des erreurs d’action. Utilisez les abstractions de providers pour la logique normale de l’application. Ne vérifiez un type concret de provider qu’à une véritable frontière d’intégration. Évitez les transactions de base de données dynamiques fondées sur des callbacks lorsque le dépôt les interdit. ## Testez les fonctionnalités LLM selon le sens, pas avec des listes de mots-clés Corrigez les modes de défaillance généraux du modèle, et non la formulation d’un seul cas d’évaluation. N’ajoutez pas de listes noires de mots-clés ou d’expressions aux prompts, évaluations ou tests dans le seul but de détecter la formulation actuelle du modèle ; les vérifications textuelles sont particulièrement fragiles d’une langue à l’autre. Vérifiez les résultats sémantiques au moyen d’un critère de juge ou d’un contrat structuré, par exemple pour déterminer si le modèle évite les demandes de clarification inutiles ou les affirmations d’état non étayées. Ne conditionnez jamais l’injection de contexte ni le comportement d’un outil à une correspondance improvisée avec le texte de l’utilisateur. Utilisez un état structuré, des métadonnées ou des événements explicites. Rendez chaque description d’outil autonome : objectif, signification des paramètres, conseils de sélection, prérequis et contraintes de sécurité propres à l’outil. Ne conservez dans le prompt système que les politiques transversales d’identité, de confirmation, de sécurité et de formatage ; placez les consignes propres à chaque outil dans sa description. ## Relisez le diff et indiquez quelles vérifications ont tourné Avant d’annoncer la fin du travail, examinez le diff modifié et exécutez le plus petit ensemble de contrôles alignés sur la CI qui démontre le comportement concerné. Étendez la vérification aux tests d’intégration ou d’évaluation lorsque le contrat franchit ces limites. Confirmez les points suivants : - chaque dépendance et variable d’environnement appartient au bon espace de travail ; - les tests couvrent le comportement et les nouveaux fichiers de test peuvent être découverts ; - les imports, les types dérivés des schémas, les utilitaires et les abstractions respectent les conventions du dépôt ; - les logs n’élargissent pas l’exposition des données personnelles ; - l’état de l’UI, les mutations, la validation, l’invalidation du cache et les états de chargement suivent les modèles établis ; - le comportement du LLM est testé de manière sémantique plutôt qu’au moyen de formulations fragiles ; - aucune vérification non prise en charge sur toute la racine, aucun serveur de développement et aucun build complet n’a été lancé sans autorisation. Indiquez les contrôles exécutés et les vérifications plus larges volontairement exclues du périmètre.