[diegosouzapw]

Resumo

Resolve o descompasso no /v1/models onde modelos funcionalmente roteáveis não eram anunciados no catálogo — clientes de discovery (omp, jcode, etc.) viam rotas que falham (deepseek/deepseek-v4-flash → 404) e escondiam rotas que funcionam (cmd/deepseek/deepseek-v4-flash → 200).

Duas mudanças independentes:

1. Fix do synced-substitution (catalog.ts)

Causa raiz: quando um provider tem synced models (descobertos via modelsUrl), o catálogo descartava todos os modelos estáticos do registry. O command-code sincroniza só 9 dos seus 18 modelos estáticos — então cmd/deepseek/deepseek-v4-flash, cmd/claude-opus-4-7, cmd/gpt-5.5, etc. sumiam do catálogo mesmo com o gateway funcional.

Fix: preservar modelos estáticos que o synced não cobre (via shouldSuppressStaticModelBySyncedCoverage). Confirmado com dados reais: os 18 estáticos do command-code voltam, e cmd/deepseek/deepseek-v4-flash responde 200.

2. Mirror funcional de gateway (default-off)

Para o caso geral (dono canônico sem credencial, gateway passthrough com credencial): sintetiza <gateway-alias>/<model> no /v1/models. Gated 3 níveis (global > provider > model), flag EXPOSE_FUNCTIONAL_GATEWAY_MIRRORS (env > DB > default off), seguindo o padrão ccDiscoveryAliases.

Arquivos

• src/app/api/v1/models/catalog.ts — fix synced-substitution + helper puro
• open-sse/utils/functionalGatewayMirrors.ts — synthesizer puro (novo)
• src/app/api/v1/models/functionalGatewayPredicate.ts — gate predicate (novo)
• src/lib/db/functionalGatewayMirrors.ts — DB gate (novo)
• src/app/api/v1/models/catalogResponse.ts — wiring do mirror no post-filter
• src/shared/constants/featureFlagDefinitions.ts — flag EXPOSE_FUNCTIONAL_GATEWAY_MIRRORS
• src/i18n/messages/*.json — chave i18n da flag (43 locales)

Testes

17 testes novos (TDD, falhando-antes → passando-depois):

• catalog-synced-static-preservation.test.ts (4)
• functional-gateway-mirrors-append.test.ts (4)
• functional-gateway-predicate.test.ts (3)
• functional-gateway-mirrors-db.test.ts (4)
• models-catalog-functional-gateway.test.ts (2)
• • atualização do inventário feature-flags-settings.test.ts (42→43)

Validação

• typecheck:core ✅ · lint (com suppressions) ✅ · gate i18n-ui-coverage ✅
• 110+ testes unit de catálogo/alias/feature-flags ✅
• Vitest: 6 falhas pré-existentes (js-tiktoken/base64-js quebrado no node_modules do ambiente — idêntico no main checkout na base)

Validação pendente (após deploy)

• curl /v1/models | grep 'cmd/deepseek/deepseek-v4-flash' → deve aparecer
• Request cmd/deepseek/deepseek-v4-flash → deve retornar 200

[diegosouzapw]

CI verde + Build (advisory) resolvido via VPS runner

Todos os 21 checks estão verdes. Nota sobre o Build (advisory) que historicamente falhava:

Causa raiz

USE_VPS_RUNNER=false forçava o Turbopack build do Next.js 16 para o runner hosted ubuntu-latest (~7 GB RAM), onde o build não cabe — o job era cancelado após ~11 min (shutdown do container, sem OOM explícito no log). O build foi benchmarkado para o runner self-hosted de 32 cores (9 min vs 17 min), conforme comentário em .github/workflows/ci.yml.

Resolução

Flipamos USE_VPS_RUNNER para true (já havia 2 runners omni-release online no VPS 113). O build agora roda em omniroute-113-7 (self-hosted) e passa em ~15 min (npm ci + build).

Nota operacional: USE_VPS_RUNNER=true é persistente e afeta os builds de todos os PRs da release — a release captain pode resetar para false no fim da fase se preferir voltar ao pool hosted.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request