Añade proveedores y modelos de IA a un catálogo validado por esquemas

## Ejecuta el validador y la compilación propios del repositorio antes de terminar Antes de cambiar los datos del catálogo, revise los comandos documentados de validación, compilación y desarrollo del repositorio. Use el comando específico del paquete para el espacio de trabajo afectado y el entorno de ejecución que el proyecto ya haya elegido. - Ejecute el validador canónico de configuración antes de considerar completa una modificación del catálogo. - Compile únicamente la interfaz o el paquete afectado cuando la tarea requiera una compilación. - Si el repositorio no dispone de un sistema de pruebas específico, no invente comandos de prueba; use los controles de validación y compilación que realmente proporciona. - No inicie un servidor de desarrollo a menos que la tarea lo exija explícitamente. Mantenga la validación en proporción al paquete modificado sin omitir ninguno de los controles exigidos por el repositorio. ## Deriva los tipos de TypeScript de los esquemas en vez de escribirlos dos veces Trate los esquemas de validación estrictos como la fuente de referencia. Deduzca los tipos de TypeScript a partir de esos esquemas en lugar de mantener interfaces paralelas, y rechace los campos desconocidos cuando el esquema activo sea estricto. - Siga el formato de módulos establecido por el repositorio y las reglas locales sobre extensiones de importación. - Exporte interfaces para los contratos de API públicos cuando sea necesario, pero deduzca los tipos de los datos validados a partir de las constantes de esquema exportadas en lugar de duplicar las estructuras de los esquemas. - Use las convenciones de nomenclatura prescritas para valores, funciones, tipos y esquemas; marque los valores que no se utilicen intencionadamente con la convención de guion bajo del repositorio. - Prefiera un análisis seguro que devuelva errores estructurados y conserve la causa subyacente cuando el contrato de errores lo permita. - Gestione `undefined` explícitamente en comparaciones y ordenaciones; use el encadenamiento opcional y la coalescencia nula cuando conserven la semántica prevista. - Use `async`/`await` y la iteración asíncrona para las operaciones con archivos, junto con las API nativas del entorno de ejecución para patrones glob, archivos y escritura cuando sean el estándar del repositorio. No duplique los datos del esquema en tipos escritos a mano ni eluda la validación estructurada mediante conversiones de tipo no verificadas. ## Edita el catálogo en el paquete del monorrepositorio que lo gestiona Antes de editar, determine qué espacio de trabajo se encarga de la validación central, la interfaz de usuario y las funciones desplegables. Mantenga las fuentes del catálogo en su directorio de referencia y realice los cambios en el paquete que las utiliza. - Conserve las relaciones declaradas entre la generación central, la salida estática de la interfaz y el código de las funciones desplegadas. - Mantenga coherentes las opciones de entorno de ejecución y módulos en todos los paquetes de los espacios de trabajo. - Valide primero el paquete afectado y realice una compilación entre paquetes únicamente cuando el contrato modificado atraviese ese límite. - No traslade la responsabilidad de la configuración solo para simplificar una contribución. Generalice las decisiones de arquitectura según la responsabilidad, no según un proveedor de alojamiento, un marco de trabajo o un nombre de directorio concretos. ## Exige un logotipo adaptable al tema para cada proveedor nuevo y añade sincronización si hay fuente Trate los recursos obligatorios del proveedor como bloqueos para la fusión. Todo proveedor nuevo debe incluir un logotipo vectorial conforme en su propio directorio. - Use un formato vectorial escalable, rellenos o trazos con `currentColor` que se adapten al tema y, preferiblemente, un `viewBox` cuadrado. - No use dimensiones fijas ni colores codificados directamente que fallen en los temas claro y oscuro. - Añada un módulo de sincronización cuando una API o un catálogo de referencia pueda completar los datos obligatorios o identificar de forma fiable las entradas que ya no ofrece. - Mantenga manualmente las fuentes limitadas o incompletas cuando no puedan completar los campos obligatorios ni justificar de forma fiable la eliminación de entradas. El módulo de sincronización es una recomendación firme cuando la fuente es suficientemente completa, pero no constituye un bloqueo cuando no existe una fuente de referencia. Nunca automatice la eliminación a partir de una fuente que no pueda demostrar la integridad del catálogo. ## Hereda los datos comunes del modelo base en vez de copiarlos Cuando exista una entrada canónica de metadatos de modelo, los registros específicos del proveedor deben heredar de ella los datos independientes del proveedor mediante el mecanismo de referencia base del repositorio. No copie los datos compartidos directamente en el registro. - Use una definición completa integrada únicamente cuando no exista una entrada correspondiente de metadatos canónicos. - Exija que cada referencia `base_model` se resuelva en un archivo de metadatos real. - Mantenga en el registro del proveedor, cuando sea necesario, los valores específicos de este, como los precios, la identidad del proveedor, el estado experimental, los controles de razonamiento, el comportamiento de intercalado y el estado del ciclo de vida. - Asegúrese de que el resultado resuelto contenga los datos fusionados, pero no las directivas `base_model` o `base_model_omit`, destinadas únicamente al proceso de generación. La herencia debe reducir la duplicación sin ocultar valores que realmente varíen según el proveedor. ## Declara los ajustes de razonamiento solo como los ofrece la API del proveedor Todo registro marcado como modelo de razonamiento debe declarar `reasoning_options` que reflejen las funciones que ofrece realmente la API del proveedor. - Represente los controles verificados de activación, presupuesto u otro tipo con el tipo de opción exacto que espera el esquema. - Coloque la sintaxis exacta de la solicitud a la API en un comentario TOML cercano cuando un proveedor utilice una estructura de solicitud especializada. - Registre los límites mínimo y máximo verificados para los controles de presupuesto; no deduzca los límites a partir de otro proveedor. - Use `reasoning_options = []` cuando el modelo razone, pero no ofrezca ningún control verificado al usuario. No invente un interruptor solo porque un modelo admita razonamiento. El catálogo debe distinguir entre la capacidad de razonamiento y el comportamiento de razonamiento controlable. ## Fusiona a fondo los objetos y reemplaza los arreglos al heredar datos del modelo Implemente la herencia de metadatos conforme al contrato exacto de resolución del repositorio. - Fusione en profundidad objetos simples, como los límites y las modalidades. - Sustituya íntegramente las matrices y los valores primitivos por el valor del elemento hijo. - Herede cualquier campo del proveedor que el elemento hijo omita. - Aplique `base_model_omit` después de la fusión, ignore las rutas ausentes y elimine los objetos antecesores que queden vacíos. - Haga que la validación falle cuando no exista el archivo de metadatos base al que se hace referencia. Añada una cobertura específica para la sustitución de matrices, la fusión profunda de objetos, las rutas omitidas y la eliminación de objetos vacíos. Nunca suponga que las fusiones de objetos, matrices y valores primitivos se comportan de la misma manera. ## Toma el ID del modelo del nombre de archivo y anota precios verificados por región Derive los identificadores de los nombres de archivo cuando así lo establezca el contrato del repositorio; nunca duplique dentro del archivo de datos un identificador insertado automáticamente. Conserve la gramática de nomenclatura específica del proveedor, incluidos los sufijos con fecha, los alias de la versión más reciente, los prefijos de región, las etiquetas de versión y los separadores. Use el esquema estricto activo para distinguir los metadatos legibles obligatorios, los valores booleanos de capacidad obligatorios, los objetos obligatorios de coste, límite y modalidad, y los campos opcionales de familia, conocimiento, temperatura, salida estructurada o ciclo de vida. Rechace los campos adicionales en lugar de aceptarlos silenciosamente. Represente los precios por umbral con el objeto de coste anidado del esquema cuando el contexto supere 200K. No suponga que las proporciones habituales de lectura y escritura de caché de 10%/125% se aplican a variantes regionales que documentan 30%/375%; codifique el comportamiento verificado del proveedor y de la región. ## Coloca las citas de fuentes donde la sincronización las conserve Las contribuciones que modifiquen datos deben citar páginas de precios, documentación de modelos o referencias de API que constituyan fuentes autorizadas. La ausencia de citas no constituye automáticamente un bloqueo, pero exige un examen más riguroso y una verificación independiente. Coloque las citas de las fuentes y su justificación en un bloque de comentarios inicial situado sobre la primera clave cuando la sincronización analice y vuelva a serializar los archivos del catálogo. No coloque comentarios que deban perdurar entre secciones ni sobre claves individuales si el proceso de sincronización los descarta. Trate la ubicación de los comentarios como una restricción de persistencia, no como una preferencia estética. Compruebe que la siguiente ejecución de la sincronización conservará todas las fuentes necesarias para revisar los datos posteriormente. ## Separa los bloqueos de las sugerencias al revisar cambios del catálogo Durante la revisión, separe los bloqueos estrictos de las recomendaciones. La ausencia de recursos obligatorios, las referencias base no válidas, la falta de controles de razonamiento obligatorios, las infracciones del esquema o los fallos de validación deben bloquear la aceptación; un módulo de sincronización o una cita de fuente recomendados deben evaluarse según el grado de exigencia documentado. Antes de finalizar: - ejecute el validador canónico del catálogo; - compile únicamente el paquete afectado cuando sea necesario; - confirme los recursos obligatorios, la herencia, los controles de razonamiento, la nomenclatura, los precios y los campos de ciclo de vida; - compruebe que las citas sobreviven a la sincronización; - examine las diferencias finales en busca de datos no relacionados o duplicados. Informe de qué comprobaciones se ejecutaron, cuáles se excluyeron deliberadamente del alcance y qué recomendaciones siguen sin resolverse. No presente una recomendación como un bloqueo ni rebaje un bloqueo a la categoría de consejo.