Adicione provedores e modelos de IA a um catálogo validado por esquemas

## Rode o validador e a compilação do próprio repositório antes de concluir Antes de alterar dados de catálogo, verifique os comandos documentados de validação, compilação e desenvolvimento do repositório. Use o comando específico do pacote para o espaço de trabalho afetado e o ambiente de execução já escolhido pelo projeto. - Execute o validador canônico de configuração antes de considerar concluída uma alteração no catálogo. - Compile apenas a interface ou o pacote afetado quando a tarefa exigir compilação. - Se o repositório não tiver uma estrutura de testes dedicada, não invente comandos de teste; use os critérios de validação e compilação que ele realmente oferece. - Não inicie um servidor de desenvolvimento, a menos que a tarefa exija isso explicitamente. Mantenha a validação proporcional ao pacote alterado, preservando todos os critérios exigidos pelo repositório. ## Derive os tipos TypeScript dos esquemas em vez de escrevê-los duas vezes Trate os esquemas de validação rigorosos como a fonte da verdade. Infira os tipos TypeScript a partir desses esquemas, em vez de manter interfaces paralelas, e rejeite campos desconhecidos quando o esquema ativo for rigoroso. - Siga o formato de módulo estabelecido pelo repositório e as regras locais de extensão dos arquivos de importação. - Exporte interfaces para contratos de API públicos quando necessário, mas infira os tipos dos dados validados a partir das constantes de esquema exportadas, em vez de duplicar as estruturas dos esquemas. - Use as convenções de nomenclatura prescritas para valores, funções, tipos e esquemas; marque valores intencionalmente não utilizados com a convenção de sublinhado do repositório. - Prefira uma análise segura que retorne erros estruturados e preserve a causa subjacente quando o contrato de erro oferecer esse recurso. - Trate `undefined` explicitamente em comparações e ordenações; use encadeamento opcional e coalescência nula quando preservarem a semântica pretendida. - Use `async`/`await` e iteração assíncrona em operações com arquivos, junto das APIs nativas do ambiente de execução para padrões glob, arquivos e gravação, quando esse for o padrão do repositório. Não duplique fatos do esquema em tipos escritos manualmente nem contorne a validação estruturada com conversões de tipo não verificadas. ## Altere o catálogo no pacote do monorrepositório que o gerencia Antes de editar, identifique qual espaço de trabalho é responsável pela validação central, pela interface do usuário e pelas funções implantáveis. Mantenha as fontes do catálogo no diretório oficial e faça as alterações no pacote que as consome. - Preserve as relações declaradas entre a geração central, a saída estática da interface e o código das funções implantadas. - Mantenha consistentes as escolhas de ambiente de execução e de módulos em todos os pacotes dos espaços de trabalho. - Valide primeiro o pacote afetado e só depois execute uma compilação entre pacotes quando o contrato alterado atravessar esse limite. - Não transfira a responsabilidade pela configuração apenas para simplificar uma contribuição. Generalize as decisões de arquitetura por responsabilidade, e não por um fornecedor de hospedagem, arcabouço ou nome de diretório específico. ## Exija um logotipo adaptável ao tema para cada provedor novo e sincronize quando houver fonte Trate os recursos obrigatórios do provedor como bloqueadores da mesclagem. Todo novo provedor deve incluir um logotipo vetorial compatível em seu próprio diretório. - Use um formato vetorial escalável, preenchimentos ou traços com `currentColor` que se adaptem ao tema e, de preferência, um `viewBox` quadrado. - Não use dimensões fixas nem cores definidas diretamente no código que deixem de funcionar nos temas claro e escuro. - Adicione um módulo de sincronização quando uma API ou um catálogo oficial puder preencher os dados obrigatórios ou identificar com segurança os itens que deixou de oferecer. - Mantenha manualmente as fontes limitadas ou incompletas quando elas não puderem preencher os campos obrigatórios nem fundamentar uma remoção oficial. O módulo de sincronização é uma forte recomendação quando a fonte é suficientemente completa, mas não é um bloqueador quando não existe uma fonte oficial. Nunca automatize a remoção com base em uma fonte que não possa comprovar a integridade do catálogo. ## Herde os dados comuns do modelo base em vez de copiá-los Quando existir uma entrada canônica de metadados de modelo, os registros específicos do provedor deverão herdar dela os fatos independentes do provedor por meio do mecanismo de referência base do repositório. Não copie fatos compartilhados diretamente no registro. - Use uma definição integral embutida somente quando não existir uma entrada correspondente de metadados canônicos. - Exija que toda referência `base_model` seja resolvida para um arquivo de metadados real. - Mantenha no registro do provedor, quando necessário, valores específicos como preços, identidade do provedor, estado experimental, controles de raciocínio, comportamento de intercalação e estado do ciclo de vida. - Garanta que a saída resolvida contenha os fatos mesclados, mas não as diretivas `base_model` ou `base_model_omit`, usadas apenas durante a geração. A herança deve reduzir a duplicação sem ocultar valores que realmente variam conforme o provedor. ## Declare as opções de raciocínio só como a API do provedor realmente oferece Todo registro marcado como modelo de raciocínio deve declarar `reasoning_options` que reflitam os recursos reais da API do provedor. - Represente controles verificados de ativação, orçamento ou outros tipos com o tipo exato de opção esperado pelo esquema. - Coloque a sintaxe exata da solicitação à API em um comentário TOML próximo quando um provedor usar uma estrutura de solicitação especializada. - Registre os limites mínimo e máximo verificados para controles de orçamento; não deduza limites com base em outro provedor. - Use `reasoning_options = []` quando o modelo raciocinar, mas não oferecer nenhum controle verificado ao usuário. Não invente um interruptor apenas porque um modelo permite raciocínio. O catálogo deve diferenciar capacidade de raciocínio de comportamento de raciocínio controlável. ## Mescle objetos a fundo e substitua arrays ao herdar dados do modelo Implemente a herança de metadados de acordo com o contrato exato de resolução do repositório. - Faça uma mesclagem profunda de objetos simples, como limites e modalidades. - Substitua integralmente matrizes e valores primitivos pelo valor do elemento filho. - Herde todo campo do provedor que o elemento filho omitir. - Aplique `base_model_omit` após a mesclagem, ignore caminhos ausentes e remova objetos ancestrais que ficarem vazios. - Faça a validação falhar quando o arquivo de metadados base referenciado não existir. Adicione uma cobertura direcionada para substituição de matrizes, mesclagem profunda de objetos, caminhos omitidos e remoção de objetos vazios. Nunca pressuponha que mesclagens de objetos, matrizes e valores primitivos se comportem da mesma forma. ## Tire o ID do modelo do nome do arquivo e registre preços verificados por região Derive os identificadores dos nomes dos arquivos quando esse for o contrato do repositório; nunca duplique no arquivo de dados um identificador inserido automaticamente. Preserve a gramática de nomenclatura específica do provedor, incluindo sufixos com data, aliases da versão mais recente, prefixos de região, etiquetas de versão e separadores. Use o esquema rigoroso ativo para distinguir metadados legíveis obrigatórios, valores booleanos obrigatórios de capacidade, objetos obrigatórios de custo, limite e modalidade, além de campos opcionais de família, conhecimento, temperatura, saída estruturada ou ciclo de vida. Rejeite campos adicionais em vez de aceitá-los silenciosamente. Represente a precificação por limite com o objeto de custo aninhado do esquema quando o contexto ultrapassar 200K. Não pressuponha que as proporções comuns de leitura e gravação em cache de 10%/125% se apliquem a variantes regionais que documentam 30%/375%; codifique o comportamento verificado do provedor e da região. ## Coloque as citações de fontes onde a sincronização as mantenha Contribuições que alteram dados devem citar páginas oficiais de preços, documentação de modelos ou referências de API. A ausência de citações não constitui automaticamente um bloqueador, mas exige uma análise mais rigorosa e verificação independente. Coloque as citações das fontes e suas justificativas em um bloco inicial de comentários acima da primeira chave quando a sincronização analisar e serializar novamente os arquivos do catálogo. Não coloque comentários que precisem ser duráveis entre seções nem acima de chaves individuais se o processo de sincronização os descartar. Trate a posição dos comentários como uma restrição de persistência, não como uma preferência estética. Verifique se a próxima execução da sincronização manterá todas as fontes necessárias para revisar os dados posteriormente. ## Separe bloqueios de recomendações ao revisar mudanças no catálogo Durante a revisão, separe bloqueadores rígidos de recomendações. A ausência de recursos obrigatórios, referências base inválidas, controles de raciocínio obrigatórios ausentes, violações do esquema ou falhas de validação deve impedir a aceitação; um módulo de sincronização ou uma citação de fonte recomendados devem ser avaliados conforme a força registrada na documentação. Antes da conclusão: - execute o validador canônico do catálogo; - compile apenas o pacote afetado quando necessário; - confirme os recursos obrigatórios, a herança, os controles de raciocínio, a nomenclatura, os preços e os campos de ciclo de vida; - verifique se as citações sobrevivem à sincronização; - examine as diferenças finais em busca de dados não relacionados ou duplicados. Informe quais verificações foram executadas, quais foram intencionalmente excluídas do escopo e qualquer recomendação que permaneça sem solução. Não apresente uma recomendação como bloqueador nem enfraqueça um bloqueador transformando-o em conselho.