Prévias do escopo de limpeza CDN para agentes de IA

Um agente de IA nunca deveria pedir aprovação para “limpar o cache da CDN”. Essa frase esconde os únicos fatos que um operador precisa conhecer antes de autorizar a ação: qual host, qual caminho, quantas tags e quanto conteúdo em cache pode deixar de ser servido.

Uma boa prévia do escopo de limpeza da CDN transforma a solicitação final em uma descrição compacta do raio de impacto. Ela também precisa colocar uma invalidação direcionada em uma classe de risco diferente de uma limpeza total. Já vi limpezas amplas transformarem uma publicação rotineira em um incidente de tráfego na origem porque a caixa de aprovação fazia um curinga parecer um caminho inofensivo. A solicitação era sintaticamente pequena. O efeito não era.

O projeto correto faz mais do que adicionar uma caixa de confirmação. Ele normaliza a solicitação do provedor, classifica seu escopo, estima o alcance com incerteza honesta e vincula a aprovação do operador a esses parâmetros exatos. Se o agente alterar um host, caminho, tag, ambiente ou modo de limpeza depois da aprovação, o gateway deve perguntar novamente.

Uma solicitação de limpeza precisa de um modelo de impacto

O escopo de limpeza da CDN é o conjunto de representações em cache que um provedor pode invalidar, não a quantidade de strings em uma solicitação de API. Um curinga pode abranger uma distribuição inteira. Uma tag pode se referir a milhares de URLs sem relação entre si. Uma URL pode ter várias variantes em cache porque o cache varia por parâmetros de consulta, cabeçalhos, cookies, tipo de dispositivo ou idioma.

Essa é a primeira distinção que as equipes costumam confundir: o tamanho da solicitação não é o tamanho do efeito. A documentação da Amazon CloudFront deixa essa diferença explícita. Um caminho de invalidação com curinga conta como um único caminho enviado mesmo que invalide milhares de arquivos. As unidades de cobrança descrevem a solicitação, não o alcance. Um cartão de aprovação que diz “1 caminho” sem informar que o caminho é /* apresenta um fato tecnicamente correto, mas inútil para a operação.

Modele a ação proposta em quatro eixos:

• Alvo: a conta, o serviço ou a distribuição da CDN, o ambiente e o nome do host.
• Seletor: URL exata, prefixo de caminho, curinga, tag de cache, surrogate key ou sinalizador de limpeza total do provedor.
• Semântica: como os seletores se combinam, quais variantes abrangem e se o provedor vai invalidar ou excluir objetos em cache.
• Consequência: o número estimado de objetos ou solicitações afetados, o comportamento esperado de recarga e se conteúdo desatualizado ainda pode ser servido.

O modelo deve ficar no gateway de execução, perto das credenciais e do adaptador do provedor. Não permita que o agente atribua sua própria classificação de risco. O agente pode propor uma limpeza, mas o código que entende a API do provedor deve calcular o significado dessa proposta.

Essa separação importa porque o vocabulário dos provedores é inconsistente. A Fastly chama sua etiqueta de agrupamento de surrogate key. Google Cloud e Akamai usam tags de cache. A Cloudflare aceita tags, nomes de host, prefixos de URL, arquivos individuais e limpeza total. A CloudFront aceita caminhos, curingas e invalidação por tags de cache. Uma ferramenta portátil para agentes pode expor uma interface organizada, mas a prévia precisa preservar as regras reais de correspondência do provedor.

Antes de exibir qualquer coisa, um componente de execução deve resolver aliases, tornar hosts canônicos, decodificar e normalizar caminhos segundo as regras do provedor, expandir opções de conveniência e identificar o ambiente efetivo. A prévia passa a descrever a solicitação que será assinada e enviada. Mostrar a entrada anterior e mais amigável do agente cria uma lacuna na qual a normalização pode ampliar o escopo sem que a pessoa perceba.

Invalidação direcionada e limpeza total são ações diferentes

A invalidação direcionada seleciona conteúdo por uma URL exata, um caminho ou prefixo delimitado, uma ou mais tags ou uma interseção de seletores compatíveis. A limpeza total descarta o estado útil de um serviço, uma zona ou uma distribuição inteira. Tratar as duas como valores no mesmo menu suspenso reduz uma diferença importante.

A classificação deve seguir o efeito, não o nome do endpoint. Todas estas solicitações merecem uma classificação de limpeza total:

• O sinalizador explícito purge_everything de um provedor.
• Um caminho de distribuição /*.
• Um curinga ou prefixo que se normaliza para a raiz.
• Uma tag conhecida por convenção local por marcar todas as respostas de um serviço.
• Uma lista de seletores cuja união abrange o conjunto de hosts configurados.

Os dois últimos casos exigem metadados locais. Talvez um provedor não saiba que release-current aparece em todos os objetos de um serviço, mas o sistema de implantação que aplica a tag pode registrar esse fato. Se o gateway não conseguir provar que um seletor é delimitado, deve marcar o alcance como desconhecido e elevar o nível de aprovação. Desconhecido é um resultado válido. Tratar o desconhecido silenciosamente como pequeno não é.

Direcionada não significa segura. Um prefixo /products/ em uma grande loja pode abranger a maior parte do tráfego, e uma tag tenant:42 pode atravessar vários hosts. A classificação significa que a solicitação expressa um limite que a prévia consegue mostrar. O operador ainda precisa de uma estimativa do que existe dentro desse limite.

A limpeza total precisa de um fluxo separado visual e mecanicamente. Exija um nome de ação explícito, como purge_all, e não um seletor vazio que o adaptador interpreta como tudo. Rejeite campos vazios de host e caminho no modo direcionado. Faça o operador aprovar o ambiente de produção e o serviço inteiro como alvos identificados. Não permita que uma aprovação geral da sessão absorva essa ação apenas porque o mesmo agente realizou antes uma limpeza inofensiva de URL.

Aqui eu discordo de uma recomendação popular: “Basta exigir confirmação para toda limpeza”. A repetição treina as pessoas a aprovar o formato de uma caixa de diálogo, e não a ler o conteúdo. Uma invalidação de arquivo único durante uma publicação e uma limpeza de toda a distribuição não devem apresentar o mesmo botão, alerta ou etapa de autenticação. A aprovação humana só ajuda quando a interface torna visível a diferença material.

Host, caminho e contagem de tags ficam acima do botão

O cartão de aprovação deve começar pelo alvo e pelo escopo efetivos, pois operadores leem sob pressão. Coloque primeiro o provedor e o ambiente de produção, depois o nome do host, o caminho normalizado, a contagem de tags, o alcance estimado e a classe da operação. Os detalhes de apoio podem ser expandidos abaixo, mas os fatos que mudam a decisão precisam ficar visíveis sem um clique.

Uma prévia independente de provedor pode usar esta estrutura:

{
  "operation": "targeted_invalidation",
  "provider": "example-cdn",
  "environment": "production",
  "hosts": ["assets.example.test"],
  "paths": ["/releases/2026-07-24/*"],
  "tag_count": 2,
  "tag_samples": ["release:842", "asset:bundle"],
  "selector_logic": "host AND path AND (tag OR tag)",
  "estimated_reach": {
    "objects": {"low": 1600, "high": 2300},
    "method": "tag-index snapshot",
    "observed_at": "2026-07-24T14:31:08Z"
  },
  "refill": "origin requests expected on subsequent misses"
}

Esses números são ilustrativos, não uma promessa de que uma CDN consiga contar todos os objetos ativos na borda. O importante é o formato da saída: um intervalo, seu método e o horário da observação. Se o estimador não tiver uma entrada defensável, retorne "objects": "unknown" e explique o motivo.

Mostre todos os hosts quando houver poucos. Para uma lista longa, mostre a contagem e os primeiros nomes em ordem, com uma forma explícita de inspecionar o restante. Nunca resuma uma lista que mistura produção e homologação como “12 hosts”. As fronteiras entre ambientes pesam mais na decisão do que a contagem.

Os caminhos precisam tanto do valor normalizado quanto da regra de correspondência. /picture* e /picture/* não são o mesmo seletor no Google Cloud CDN: o primeiro também corresponde a caminhos como /pictures/dog.jpg e /picture1.jpg, enquanto o segundo permanece dentro do diretório. A CloudFront exige um curinga no final para tratá-lo como curinga; um asterisco em qualquer outro lugar é literal. Uma prévia que mostra apenas os caracteres brutos obriga o operador a lembrar a gramática do provedor justamente no pior momento.

A contagem de tags também exige uma redação cuidadosa. “2 tags” significa dois seletores, não dois objetos em cache. Mostre as tags reais, a menos que contenham informações sensíveis sobre um locatário; nesse caso, apresente rótulos ocultados estáveis e uma visualização segura dos detalhes. Informe se as tags se combinam com OR ou AND. O Google Cloud CDN trata várias tags em uma solicitação como OR, enquanto a combinação de filtros de tag com seletores de host e caminho restringe o resultado por interseção. Essa pequena linha lógica costuma explicar a maior parte do raio de impacto.

O alcance estimado deve admitir o que a CDN não pode contar

Um alcance estimado deve responder “quanto estado de cache pode mudar?” sem fingir que um cache distribuído é um banco de dados de inventário. Objetos de borda aparecem e desaparecem por expiração, remoção, demanda regional e recarga em segundo plano. Muitas APIs de limpeza de CDN aceitam um seletor, mas não retornam uma contagem prévia.

Use a melhor evidência disponível em uma ordem fixa. Uma contagem recente do provedor é a opção mais forte quando a API oferece uma. Depois vem um índice de tags mantido pela implantação, que registra quais URLs receberam cada tag. Em seguida, use logs de solicitações ou telemetria do status do cache em uma janela declarada. Um catálogo de rotas configuradas pode fornecer um limite superior aproximado. Se nada disso existir, informe que o valor é desconhecido.

Cada estimativa deve conter quatro propriedades:

• Uma unidade, como objetos em cache, variantes de URL ou solicitações recentes com acerto no cache.
• Uma estimativa pontual ou um intervalo, nunca um número inteiro sem rótulo.
• Uma fonte e um horário de observação.
• Um rótulo de confiança derivado por código do tipo e da idade da fonte.

Não converta o volume recente de solicitações em uma contagem de objetos. “Cerca de 80.000 solicitações com acerto no cache na última hora corresponderam a este prefixo” é uma evidência útil de impacto, mas não significa que 80.000 objetos serão invalidados. Mostre as duas medidas quando estiverem disponíveis: objetos estimados descrevem o estado do cache; acertos recentes descrevem a provável pressão de recarga e a exposição dos usuários.

Para uma URL exata, o alcance ainda pode ser maior que um. A documentação da CloudFront observa que invalidar um arquivo também invalida variantes em cache baseadas em cookies ou cabeçalhos encaminhados. O comportamento dos parâmetros de consulta depende da configuração e do seletor. A prévia deve dizer “1 URL, todas as variantes de cookies e cabeçalhos” quando esse for o comportamento efetivo. Uma contagem simples de um objeto esconderia a parte importante.

Para tags, estime a união, não a soma. Se release:842 abrange 1.700 objetos e asset:bundle abrange 900, objetos sobrepostos devem ser contados uma vez. Quando o provedor aplica tags com OR, somar as duas contagens pode exagerar o alcance. Superestimar é mais seguro do que subestimar para um limite de aprovação, mas ainda prejudica a confiança. Calcule uma união real quando o índice local permitir, ou rotule o total como limite superior.

Para uma limpeza total, não perca tempo criando um número preciso. Diga “serviço de produção inteiro”, mostre a quantidade de hosts configurados e adicione o volume recente de acertos no cache como indicador de pressão na origem. A classe da ação já informa ao operador qual é a fronteira do cache. A falsa precisão faz o cartão parecer bem informado sem acrescentar nada à decisão.

A prévia deve expor as consequências da recarga

Uma limpeza muda o destino das solicitações posteriores, por isso a aprovação precisa descrever o comportamento de recarga e o seletor. O risco operacional muitas vezes não é o desaparecimento do conteúdo desatualizado. É uma onda concentrada de falhas de cache chegando a uma origem dimensionada sob a suposição de que o cache absorveria essas solicitações.

A documentação do Google Cloud recomenda invalidar apenas o necessário, pois uma invalidação ampla pode mandar de volta para instâncias ou buckets solicitações antes servidas pelos caches. Ela também diz para confirmar que o servidor de origem já retorna o conteúdo correto antes de solicitar a invalidação; caso contrário, a CDN pode armazenar novamente a resposta incorreta. Esse segundo ponto merece uma precondição no fluxo do agente: verifique o novo objeto na origem antes de propor a limpeza.

A Fastly faz outra distinção útil entre limpeza rígida e limpeza suave. A limpeza rígida torna o conteúdo em cache indisponível para consultas futuras. A limpeza suave marca o conteúdo como desatualizado, o que pode permitir seu uso enquanto o cache revalida, dependendo da configuração. A Fastly não oferece limpeza suave para uma limpeza total. Uma aprovação que diz apenas “limpar” elimina essa diferença operacional.

Portanto, a prévia deve incluir:

• Se a ação é invalidação rígida, invalidação suave ou exclusão específica do provedor.
• Se conteúdo desatualizado pode ser servido durante a atualização.
• A taxa recente de solicitações com acerto no cache no escopo selecionado, se disponível.
• A origem ou o grupo de backends que receberá as falhas.
• Se uma verificação de prontidão da origem passou e quando foi executada.

Evite promessas como “haverá 2.300 solicitações à origem”. Agrupamento de solicitações, distribuição regional, caches de navegador, camadas de proteção e preenchimentos recentes influenciam a carga real. Use tráfego recente medido e descreva-o com honestidade: “O escopo selecionado serviu 46.000 acertos de cache nos 15 minutos anteriores”. Isso informa o operador muito melhor do que uma previsão inventada.

O agente não deve executar sua própria verificação de prontidão por um shell sem restrições e resumir o resultado. O gateway deve realizar uma verificação definida contra a origem pretendida, registrar o status da resposta e a versão do conteúdo e anexar essa evidência à prévia. Caso contrário, um prompt comprometido pode afirmar que a origem está pronta na mesma conversa em que pede aprovação.

A normalização fecha a lacuna entre exibição e execução

O gateway deve aprovar uma ação canônica e executar essa mesma ação. Se a interface renderizar uma representação enquanto o adaptador do provedor envia outra, a aprovação vira teatro.

A canonicalização começa com campos tipados. Separe hosts, paths, tags, purge_all, soft, provider, service_id e environment. Não aceite um comando curl em formato livre como objeto de aprovação. O adaptador pode acabar produzindo HTTP, mas o código de política e exibição deve operar sobre dados validados.

Depois, aplique as regras do provedor antes da classificação. Converta nomes de host em minúsculas, remova o ponto DNS final, rejeite credenciais incorporadas, resolva o alias do serviço e analise caminhos sem tratar um fragmento como parte da solicitação. Preserve maiúsculas e minúsculas no caminho quando a CDN fizer essa distinção. Aplique a mesma normalização de URL ou conhecimento de reescrita usado pelo provedor. A Cloudflare alerta que limpezas por prefixo envolvendo Transform Rules precisam usar a URL de origem posterior à transformação. A CloudFront recomenda invalidar tanto a URI vista pelo usuário quanto a URI reescrita quando uma função de solicitação altera o caminho. A prévia deve mostrar os dois caminhos efetivos em vez de adicionar o segundo silenciosamente.

Uma função compacta de classificação pode impor os casos perigosos depois da normalização:

if purge_all is true:
    return PURGE_ALL
if any normalized path covers the root:
    return PURGE_ALL
if any tag is cataloged as service_wide:
    return PURGE_ALL
if selectors are empty:
    return REJECT
return TARGETED

Os adaptadores dos provedores precisam de testes criados a partir da própria gramática. Inclua caminhos raiz, separadores codificados, barras repetidas, barras finais, posicionamento de curingas, arrays vazios, hosts misturados, parâmetros de consulta e URLs reescritas. Testes de propriedades podem afirmar que a normalização nunca torna o escopo de execução maior do que o escopo exibido. Casos de regressão devem guardar a prévia normalizada junto da solicitação de saída exata.

Por fim, calcule um resumo da ação canônica e dos metadados essenciais da prévia. O registro de aprovação deve incluir o ator, o processo do agente, o nome da ferramenta, os parâmetros normalizados, o ambiente, o horário da estimativa, o resumo e a expiração. O AI Agent Security Cheat Sheet da OWASP recomenda vincular a aprovação à ação exata com ator, ferramenta, alvo, parâmetros normalizados, horário e expiração. Esse é o padrão correto. Uma decisão humana sobre um resumo não pode autorizar uma solicitação posterior com outro caminho.

A aprovação deve falhar de forma fechada se o escopo mudar

Qualquer mudança material depois da prévia deve invalidar a aprovação. Os campos materiais incluem provedor, conta, serviço, ambiente, host, caminho, lógica dos seletores, tags, modo de limpeza e a classe direcionada ou total. Alterar apenas a estimativa pode não exigir outro aviso, mas cruzar um limite de impacto configurado sempre deve exigir.

Use uma validade curta para a aprovação porque o estado do cache e o tráfego mudam. Se um agente esperar até outra implantação, o caminho pode conter objetos diferentes e a evidência de prontidão da origem pode estar desatualizada. A expiração deve forçar a geração de uma nova prévia, não apenas outro clique em dados antigos.

A especificação de ferramentas do Model Context Protocol diz que os aplicativos devem manter uma pessoa capaz de negar chamadas de ferramentas e apresentar avisos de confirmação. Isso faz sentido, mas uma confirmação genérica é fraca demais para chamadas destrutivas de infraestrutura. O aplicativo host pode conhecer o nome da ferramenta e os argumentos JSON, porém somente o adaptador de execução sabe que um alias do provedor aponta para produção ou que / com um curinga significa tudo. Coloque a prévia relevante no componente que consegue interpretar e impor esses fatos.

A aprovação também precisa ser independente do texto controlado pelo agente. O agente pode fornecer um motivo, como “remover a imagem do produto recolhido”, mas apresente-o em uma área secundária claramente rotulada como explicação do agente. Gere os fatos de escopo por código confiável e pela configuração do provedor. Não permita Markdown, sequências de escape de terminal ou HTML arbitrário em nenhum campo do cartão de aprovação.

Ações de alto impacto merecem mais atrito. Uma limpeza direcionada de URL exata pode exigir um clique. Um prefixo amplo pode exigir uma confirmação deliberada com o escopo repetido. A limpeza total deve exigir autenticação separada e não deve herdar a aprovação da sessão do agente. O Sallyport pode manter a credencial fora do agente, mostrar uma aprovação para cada uso de uma chave protegida da API da CDN e registrar a chamada HTTP resultante; o adaptador do provedor ainda precisa fornecer os campos de escopo normalizados que tornam essa aprovação útil.

As falhas devem fechar o portão. Se o estimador atingir o limite de tempo, mostre desconhecido em vez de zero. Se a normalização falhar, rejeite a solicitação em vez de repassar a entrada bruta. Se o registro de auditoria falhar, não execute. Se o resumo for diferente no momento do envio, descarte a aprovação e crie uma nova prévia.

Os registros de auditoria precisam da decisão e do resultado

Uma trilha de auditoria de limpeza deve preservar o que a pessoa viu, o que o gateway enviou e o que a CDN retornou. Registrar apenas a solicitação de ferramenta do agente não prova que normalização, aprovação e execução se referiam ao mesmo escopo.

Registre a solicitação canônica, os campos exibidos na prévia, a fonte da estimativa, o resumo da aprovação, a identidade de quem aprovou, o horário da aprovação, o horário da execução, o identificador da solicitação do provedor e a resposta do provedor. Marque se o provedor aceitou, concluiu, concluiu parcialmente ou rejeitou a operação. Se o provedor expuser um status posterior, acrescente observações de status em vez de reescrever o evento original.

Mantenha a estimativa separada do resultado. Uma estimativa de 2.000 objetos continua sendo uma estimativa mesmo que o provedor retorne sucesso. A maioria das respostas de sucesso significa que o provedor aceitou um seletor, não que encontrou exatamente essa quantidade de objetos em cache. Os auditores devem conseguir diferenciar quais afirmações vieram de inferência local e quais vieram da CDN.

A documentação da CloudFront diz que uma invalidação não pode ser cancelada depois do envio porque os pontos de borda começam a processá-la rapidamente. Isso torna o registro anterior à execução especialmente importante. Um botão de revogação pode impedir uma chamada futura do agente, mas não pode recolher uma limpeza já distribuída às bordas. A interface de auditoria não deve sugerir o contrário.

Em uma investigação, estas perguntas devem poder ser respondidas sem ler a transcrição de uma conversa:

• Qual processo assinado do agente propôs a ação?
• Qual pessoa aprovou qual resumo canônico?
• O cartão classificou a ação como direcionada ou limpeza total?
• Quais hosts, caminhos e tags apareceram no cartão?
• O que o estimador de alcance sabia naquele momento?

A justificativa conversacional do agente é contexto de apoio, não autoridade. Conversas podem ser truncadas, resumidas ou influenciadas por conteúdo não confiável. O diário de execução é o registro duradouro da ação.

Evidências contra adulteração importam quando um processo autônomo pode fazer chamadas repetidas à infraestrutura. O Sallyport registra sessões de agentes e chamadas individuais em um único log de auditoria criptografado e encadeado por hashes, permitindo que uma equipe verifique a cadeia sem ler seu conteúdo. Isso não torna uma limpeza incorreta reversível, mas oferece às equipes de resposta uma sequência defensável de proposta, aprovação e execução.

Uma falha detalhada mostra por que quatro campos importam

Considere um agente preparando a publicação de uma loja. A tarefa pede a atualização dos novos ativos de produtos depois da implantação. O agente vê /products/ em um manifesto de build e escolhe uma limpeza por prefixo porque ela é mais simples do que enumerar arquivos com hash.

A solicitação bruta contém um caminho. Uma caixa de diálogo fraca mostra “Limpar 1 caminho?” e o operador aprova. A CDN interpreta o prefixo em todos os hosts configurados, incluindo a loja pública, um host regional e um host de imagens. A rota também contém páginas de produtos, miniaturas, fragmentos de inventário e ativos de versões anteriores. Objetos populares desaparecem do cache juntos e depois são recarregados pelo mesmo grupo de origem.

Uma prévia útil muda a decisão antes da execução. Ela mostra:

1. Host: três hosts de produção, com os nomes visíveis.
2. Caminho: /products/*, descrito como prefixo recursivo em vez de um arquivo.
3. Tags: nenhuma, embora a versão atual tenha uma tag dedicada.
4. Alcance estimado: 38.000 variantes de URL e 1,2 milhão de solicitações recentes com acerto no cache, ambas rotuladas com suas fontes e janelas.

O operador rejeita a solicitação. O agente então propõe somente a tag da versão no host de ativos. O gateway resolve 1.840 objetos indexados, observa que dois valores de tag se combinam com OR e mostra que a ação exclui o HTML de produtos e as respostas de inventário. A verificação de origem confirma o identificador da versão atual. O operador aprova esse resumo mais restrito.

Os números do cenário são ilustrativos; o padrão de falha é comum porque a sintaxe de prefixo parece barata. A solução não é um prompt mais inteligente para o agente. A fronteira de execução precisa tornar seletores amplos legíveis e oferecer à pessoa uma opção mais restrita.

O mesmo padrão detecta outro erro: um agente pede para limpar a homologação, mas um alias de serviço é resolvido para produção. Se a prévia disser apenas “serviço storefront”, o operador pode não perceber. Se começar com “produção” e listar os hosts públicos, a divergência fica evidente.

Esse exemplo também explica por que a contagem de tags não substitui o alcance. Uma tag de versão pode identificar 1.840 objetos, enquanto vinte tags de URL exata podem identificar vinte objetos. Exiba a contagem de seletores e a estimativa de correspondências como fatos separados. Um descreve a solicitação. O outro descreve seu provável efeito.

Entregue a fronteira de segurança como contrato executável

As equipes devem implementar a prévia de limpeza como um contrato entre a ferramenta do agente, o adaptador do provedor, a interface de aprovação e o log de auditoria. O contrato é pequeno o suficiente para ser testado: entradas normalizadas chegam, uma prévia classificada e vinculada a um resumo sai, e a execução aceita somente uma aprovação não expirada para esse resumo.

No mínimo, exija estas invariantes:

• O modo direcionado tem pelo menos um seletor diferente da raiz e um ambiente explícito.
• O modo de limpeza total usa sua própria ação e não pode surgir de campos vazios.
• Host, caminho, contagem de tags e lógica dos seletores exibidos vêm de parâmetros canônicos.
• O alcance é um intervalo com fonte, um limite superior, uma medida de tráfego ou um desconhecido explícito.
• A execução recalcula o resumo e recusa parâmetros alterados.

Execute o adaptador contra casos registrados para cada operação de CDN compatível. Compare a solicitação de saída com o instantâneo da prévia. Adicione um serviço canário cuja origem suporte uma limpeza e teste URL exata, prefixo, união de tags, restrição de host, caminho reescrito e limpeza total. Uma simulação que apenas repete a entrada do agente não prova nada; o teste precisa exercitar a normalização e a construção da solicitação ao provedor.

Mantenha conteúdo versionado como o caminho normal de publicação. A documentação do Google Cloud recomenda tempos de expiração adequados ou URLs versionadas em vez de invalidações rotineiras, e esse conselho faz sentido. Limpezas servem para correções, recolhimentos e casos em que esperar pelo TTL é inaceitável. Um agente que limpa o cache a cada implantação transforma um controle excepcional em uma dependência oculta da capacidade da origem.

Quando uma limpeza é justificável, a prévia deve permitir uma aprovação rápida. Um operador deve ver assets.example.test, /releases/842/*, duas tags e uma estimativa entre 1.600 e 2.300 objetos sem decodificar o JSON do provedor. Para limpeza total, a mesma posição no cartão deve dizer “serviço de produção inteiro” e se recusar a amenizar a frase com uma contagem pequena de solicitações.

O teste que uso é direto: um operador conseguiria distinguir a atualização de um único ativo da limpeza de um serviço inteiro em dois segundos, usando apenas os campos confiáveis acima do botão de aprovação? Se não, o agente não está pronto para ter essa ação da CDN.