Ajouter des fournisseurs et des modèles d’IA à un catalogue validé par schémas

## Lancer le validateur et les commandes de build du référentiel avant de finir Avant de modifier les données du catalogue, examinez les commandes documentées de validation, de compilation et de développement du référentiel. Utilisez la commande propre au paquet pour l’espace de travail concerné ainsi que l’environnement d’exécution déjà choisi par le projet. - Exécutez le validateur de configuration canonique avant de considérer une modification du catalogue comme terminée. - Compilez uniquement l’interface ou le paquet concerné lorsque la tâche exige une compilation. - Si le référentiel ne possède pas de dispositif de test dédié, n’inventez pas de commandes de test ; utilisez les contrôles de validation et de compilation qu’il fournit réellement. - Ne démarrez pas de serveur de développement, sauf si la tâche l’exige explicitement. Maintenez une validation proportionnée au paquet modifié tout en conservant chaque contrôle exigé par le référentiel. ## Déduire les types TypeScript des schémas au lieu de les écrire deux fois Considérez les schémas de validation stricts comme la source de référence. Déduisez les types TypeScript de ces schémas au lieu de maintenir des interfaces parallèles, et rejetez les champs inconnus lorsque le schéma actif est strict. - Respectez le format de module établi par le référentiel et les règles locales relatives aux extensions des importations. - Exportez des interfaces pour les contrats d’API publics lorsque cela est nécessaire, mais déduisez les types des données validées à partir des constantes de schéma exportées au lieu de dupliquer la structure des schémas. - Utilisez les conventions de nommage prescrites pour les valeurs, les fonctions, les types et les schémas ; marquez les valeurs intentionnellement inutilisées selon la convention de soulignement du référentiel. - Privilégiez une analyse sûre qui renvoie des erreurs structurées et conservez la cause sous-jacente lorsque le contrat d’erreur le permet. - Traitez explicitement `undefined` dans les comparaisons et les tris ; utilisez le chaînage optionnel et la coalescence des valeurs nulles lorsqu’ils préservent la sémantique voulue. - Pour les opérations sur les fichiers, utilisez `async`/`await` et l’itération asynchrone, ainsi que les API natives de l’environnement d’exécution pour les motifs glob, les fichiers et l’écriture lorsque le référentiel les impose comme norme. Ne dupliquez pas les informations du schéma dans des types écrits à la main et ne contournez pas la validation structurée au moyen de conversions de type non vérifiées. ## Modifier le catalogue dans le paquet du monorepo qui en est responsable Avant toute modification, déterminez quel espace de travail prend en charge la validation centrale, l’interface utilisateur et les fonctions déployables. Conservez les sources du catalogue dans leur répertoire de référence et effectuez les modifications dans le paquet qui les utilise. - Préservez les relations déclarées entre la génération centrale, la sortie statique de l’interface et le code des fonctions déployées. - Maintenez des choix cohérents d’environnement d’exécution et de modules entre les paquets des espaces de travail. - Validez d’abord le paquet concerné, puis effectuez une compilation interpaquets uniquement lorsque le contrat modifié franchit cette limite. - Ne transférez pas la responsabilité de la configuration dans le seul but de simplifier une contribution. Généralisez les décisions d’architecture selon les responsabilités plutôt que selon un fournisseur d’hébergement, un cadre logiciel ou un nom de répertoire particulier. ## Exiger un logo adapté au thème pour chaque nouveau fournisseur et synchroniser si la source le permet Considérez les ressources obligatoires du fournisseur comme des obstacles bloquant la fusion. Chaque nouveau fournisseur doit inclure un logo vectoriel conforme dans son propre répertoire. - Utilisez un format vectoriel redimensionnable, des remplissages ou des contours en `currentColor` qui s’adaptent au thème et, de préférence, un `viewBox` carré. - N’utilisez pas de dimensions fixes ni de couleurs codées en dur qui ne fonctionnent pas avec les thèmes clair et sombre. - Ajoutez un module de synchronisation lorsqu’une API ou un catalogue faisant autorité peut renseigner les données requises ou identifier de manière fiable les entrées qu’il ne propose plus. - Maintenez manuellement les sources limitées ou incomplètes lorsqu’elles ne peuvent ni renseigner les champs requis ni justifier un retrait faisant autorité. Le module de synchronisation constitue une recommandation forte lorsque la source est suffisamment complète, mais son absence ne bloque pas la fusion lorsqu’il n’existe aucune source faisant autorité. N’automatisez jamais un retrait à partir d’une source qui ne peut pas prouver l’exhaustivité du catalogue. ## Hériter des données communes d’un modèle de base au lieu de les copier Lorsqu’une entrée canonique de métadonnées de modèle existe, les enregistrements propres aux fournisseurs doivent en hériter les informations indépendantes du fournisseur grâce au mécanisme de référence de base du référentiel. Ne recopiez pas directement les informations partagées. - Utilisez une définition complète intégrée uniquement lorsqu’il n’existe aucune entrée correspondante de métadonnées canoniques. - Exigez que chaque référence `base_model` se résolve en un véritable fichier de métadonnées. - Conservez dans l’enregistrement du fournisseur, si nécessaire, les valeurs qui lui sont propres, telles que la tarification, l’identité du fournisseur, l’état expérimental, les contrôles de raisonnement, le comportement d’entrelacement et l’état du cycle de vie. - Assurez-vous que le résultat résolu contient les informations fusionnées, mais pas les directives `base_model` ou `base_model_omit` réservées au processus de génération. L’héritage doit réduire les doublons sans masquer les valeurs qui varient réellement selon le fournisseur. ## Déclarer les réglages de raisonnement seulement tels que l’API du fournisseur les offre Tout enregistrement marqué comme modèle de raisonnement doit déclarer des `reasoning_options` qui correspondent aux possibilités réellement exposées par l’API du fournisseur. - Représentez les commandes vérifiées d’activation, de budget ou d’un autre type avec le type d’option exact attendu par le schéma. - Indiquez la syntaxe exacte de la requête d’API dans un commentaire TOML situé à proximité lorsqu’un fournisseur utilise une structure de requête particulière. - Consignez les limites minimales et maximales vérifiées des contrôles de budget ; ne déduisez pas les limites de celles d’un autre fournisseur. - Utilisez `reasoning_options = []` lorsque le modèle raisonne, mais n’expose aucune commande utilisateur vérifiée. N’inventez pas de commutateur simplement parce qu’un modèle prend en charge le raisonnement. Le catalogue doit distinguer la capacité de raisonnement du comportement de raisonnement contrôlable. ## Fusionner en profondeur les objets et remplacer les tableaux lors de l’héritage Mettez en œuvre l’héritage des métadonnées conformément au contrat exact de résolution du référentiel. - Fusionnez récursivement les objets simples tels que les limites et les modalités. - Remplacez intégralement les tableaux et les valeurs primitives par la valeur de l’élément enfant. - Héritez de tout champ de fournisseur omis par l’élément enfant. - Appliquez `base_model_omit` après la fusion, ignorez les chemins absents et supprimez les objets ancêtres devenus vides. - Faites échouer la validation lorsque le fichier de métadonnées de base référencé n’existe pas. Ajoutez une couverture ciblée pour le remplacement des tableaux, la fusion récursive des objets, les chemins omis et la suppression des objets vides. Ne supposez jamais que les fusions d’objets, de tableaux et de valeurs primitives se comportent de la même manière. ## Tirer l’ID du modèle du nom de fichier et noter les prix vérifiés par région Déduisez les identifiants des noms de fichiers lorsque le contrat du référentiel l’impose ; ne dupliquez jamais dans le fichier de données un identifiant injecté automatiquement. Préservez la grammaire de nommage propre au fournisseur, notamment les suffixes datés, les alias de dernière version, les préfixes de région, les étiquettes de version et les séparateurs. Utilisez le schéma strict actif pour distinguer les métadonnées lisibles obligatoires, les booléens de capacité obligatoires, les objets obligatoires de coût, de limite et de modalité, ainsi que les champs facultatifs de famille, de connaissances, de température, de sortie structurée ou de cycle de vie. Rejetez les champs supplémentaires au lieu de les accepter silencieusement. Représentez la tarification par seuil au moyen de l’objet de coût imbriqué du schéma lorsque le contexte dépasse 200K. Ne supposez pas que les rapports courants de lecture et d’écriture du cache de 10%/125% s’appliquent aux variantes régionales qui indiquent 30%/375% ; encodez le comportement vérifié du fournisseur et de la région. ## Placer les sources citées là où la synchronisation les conserve Les contributions qui modifient les données doivent citer des pages tarifaires, des documentations de modèles ou des références d’API faisant autorité. L’absence de citations ne constitue pas automatiquement un blocage, mais elle exige un examen plus approfondi et une vérification indépendante. Placez les citations des sources et leur justification dans un bloc de commentaires initial, au-dessus de la première clé, lorsque la synchronisation analyse puis sérialise à nouveau les fichiers du catalogue. Ne placez pas de commentaires devant rester durables entre les sections ou au-dessus de clés individuelles si le processus de synchronisation les supprime. Considérez l’emplacement des commentaires comme une contrainte de persistance, et non comme une préférence esthétique. Vérifiez que la prochaine synchronisation conservera chaque source nécessaire à l’examen ultérieur des données. ## Séparer les blocages des recommandations lors de la revue du catalogue Lors de la revue, distinguez les blocages impératifs des recommandations. L’absence de ressources requises, les références de base non valides, l’absence de contrôles de raisonnement obligatoires, les violations de schéma ou l’échec de la validation doivent bloquer l’acceptation ; un module de synchronisation ou une citation de source recommandés doivent être évalués selon le degré d’exigence indiqué dans la documentation. Avant de terminer : - exécutez le validateur canonique du catalogue ; - compilez uniquement le paquet concerné lorsque cela est nécessaire ; - confirmez les ressources requises, l’héritage, les contrôles de raisonnement, le nommage, la tarification et les champs de cycle de vie ; - vérifiez que les citations résistent à la synchronisation ; - examinez les différences finales afin de repérer les données sans rapport ou dupliquées. Indiquez quels contrôles ont été exécutés, lesquels ont été délibérément exclus du périmètre et toute recommandation restée sans réponse. Ne présentez pas une recommandation comme un blocage et n’affaiblissez pas un blocage en simple conseil.