# Separacao Entre Modelo Do Atendimento E Modelo De Geracao De Tools ## Objetivo Definir a fronteira entre o runtime de modelo usado no atendimento ao cliente e o runtime de modelo usado para gerar e validar novas tools. Esta etapa consolida uma regra importante da arquitetura: os dois perfis de modelo nao podem compartilhar configuracao nem ciclo de publicacao. ## Decisao O sistema passa a tratar esses runtimes como perfis independentes. Perfis: 1. `atendimento_runtime_profile` 2. `tool_generation_runtime_profile` A separacao formal fica em `shared/contracts/model_runtime_separation.py`. ## Regras obrigatorias ### 1. Configuracoes distintas Cada runtime possui sua propria `config_key`. Portanto: - o atendimento usa `atendimento_runtime_profile` - a geracao de tools usa `tool_generation_runtime_profile` - uma mudanca de configuracao nunca reutiliza a mesma chave para os dois contextos ### 2. Catalogos com alvo separado Os modelos homologados precisam carregar o alvo funcional correto. Portanto: - modelos homologados para atendimento entram sob `runtime_target = atendimento` - modelos homologados para geracao entram sob `runtime_target = tool_generation` - um modelo pode existir nos dois catalogos, mas a selecao continua independente ### 3. Publicacao independente Os dois runtimes possuem publicacao independente. Consequencia pratica: - publicar uma mudanca no atendimento nao publica a geracao de tools - publicar uma mudanca na geracao de tools nao muda o bot que responde ao cliente - cada perfil pode ter sua propria auditoria e versao ativa ### 4. Rollback independente Cada runtime precisa poder voltar ao estado anterior sem afetar o outro. Consequencia pratica: - rollback do atendimento nao mexe no runtime de geracao - rollback da geracao nao mexe no atendimento em producao ### 5. Sem propagacao implicita Nao e permitido que uma alteracao em um runtime seja espelhada automaticamente no outro. Isso impede: - trocar o modelo do bot e, por efeito colateral, trocar o modelo de geracao - usar defaults compartilhados para empurrar mudancas silenciosas nos dois fluxos - misturar SLO, custo e risco do atendimento com o pipeline de tools ## Responsabilidade por runtime ### Atendimento - alvo funcional: responder ao cliente final - servico consumidor: `product` - impacto direto: experiencia do atendimento e fluxo conversacional ### Geracao de tools - alvo funcional: gerar e validar novas tools - servico consumidor: `admin` - impacto direto: pipeline de governanca, geracao e validacao ## Consequencias positivas - protege o atendimento de experimentos de geracao de codigo - permite escolher modelos diferentes para custo, latencia e qualidade em cada fluxo - simplifica auditoria e rollback de configuracao - prepara as futuras telas e rotas de configuracao do sistema sem ambiguidade