Website com autorreparação: um agente de IA que repara o que consegue verificar

O que faz o ciclo do website com autorreparação

Um website só se repara sozinho onde o agente consegue provar a correção, e construímos todo o mecanismo à volta dessa fronteira. O nosso agente de IA de autorreparação faz um varrimento semanal ao site publicado, regista cada defeito como um bug e envia cada bug para a sua própria execução num ambiente isolado. Essa execução reescreve o que pode através da API do CMS, volta a verificar a página guardada e só fecha o bug se a verificação estiver limpa. O ConvOps gere o agendamento, a fila de bugs e os dois fluxos de trabalho. É um dos ciclos com que gerimos a nossa empresa.

Um website com autorreparação é um site em que um agente encontra os defeitos visíveis para o leitor e repara os que consegue verificar, e deixa os restantes para uma pessoa. Não é um conjunto de testes com autorreparação: esses reparam seletores nos testes, enquanto este ciclo repara o conteúdo que o leitor vê.

Todos os ecrãs e números abaixo usam dados de exemplo da Shutterlane, um site fictício de análises de material fotográfico, feito por duas pessoas, em shutterlane.example.com.

Um varrimento semanal encontra defeitos, cada bug tem a sua própria execução de reparação e o registo transforma as repetições em verificações no momento da escrita.

O varrimento (legenda 1) regista as deteções (2), compara-as com o registo de prevenção (3) e despacha os bugs abertos (4). Cada bug é reparado conforme a sua via (5), é verificado (6) e depois é fechado ou fica em espera (7).

Porque o construímos: um agente de IA que corrige bugs de conteúdo do website

Um agente de QA que só reporta é um gerador de ruído. Um agente que encontra e corrige na mesma execução é juiz em causa própria. Separámos as duas coisas.

O nosso varrimento começou por só reportar. Encontrava os mesmos links partidos e as mesmas páginas desatualizadas todas as semanas, e ninguém era responsável pela correção. O gráfico mostra esse padrão com dados da Shutterlane: um bug é registado (legenda 1), recebe uma nota de recorrência todas as terças-feiras (2) e nunca é reparado (3).

Um varrimento que só reporta encontra o mesmo defeito todas as semanas e, sem um passo de reparação, a pilha de notas de recorrência só cresce.

Daqui saíram três princípios:

1. Encontrar e corrigir são trabalhos separados. O varrimento nunca escreve conteúdo, e a reparação nunca avalia o site.
2. Um defeito é uma unidade de trabalho. Cada deteção nova é o seu próprio bug, e cada execução de reparação é dona de exatamente um bug.
3. Concluído significa verificado. Um bug só fecha depois de uma nova verificação da página guardada, nunca com base na palavra do agente.

Se os seus relatórios de QA se acumulam da mesma forma, veja como o ConvOps transforma deteções em bugs que os executores recolhem um a um(abre num novo separador).

Como funciona: pool, executor, ambiente, fluxo de trabalho

O modelo é a parte menos interessante. O pool decide o que é trabalhado, o ambiente aquilo em que o agente pode tocar, o fluxo de trabalho quando está concluído. Dois fluxos de trabalho fazem o trabalho: o fluxo de varrimento, WF-qa, e o fluxo de reparação, WF-bugfix. É um grafo de passos e portões, a forma que descrevemos em O que é a engenharia de grafos (graph engineering)?, o mesmo ciclo agendado e com portões das nossas experiências de SEO com o Claude Code e a resposta à proliferação de agentes.

Um pool decide o que é trabalhado, o executor executa, o ambiente limita aquilo em que pode tocar e o fluxo de trabalho decide quando está concluído.

As deteções tornam-se bugs num pool

Um pool é uma consulta guardada no ConvOps: um filtro por tipo de tarefa, etiquetas, projeto, horizonte e estado, mais uma ordenação. Nunca contém tarefas; quando é consultado, devolve as que correspondem, por isso os bugs de qualquer projeto aparecem em todos os pools a que correspondem. pools_next devolve a primeira tarefa, desempata pelo id da tarefa e regista uma linha de recolha por chamada, por isso todas as recolhas são auditáveis.

O pool open-qa-bugs da Shutterlane é type = bug AND tags contains qa-finding AND status in [backlog, todo], do mais antigo para o mais recente (legenda 1).

Os executores recolhem o trabalho

Um executor é um processo de execução com nome, opcionalmente associado ao pool de onde recolhe (legenda 2). Há exatamente dois tipos:

O nosso ciclo corre num executor isolado do Claude Code, indicado no agendamento. O passo de despacho do varrimento executa ele próprio a consulta com o formato do pool e envia cada bug para esse executor; associar o executor a um pool passa essa mesma recolha para o ConvOps. Uma execução encravada é terminada ao fim de time_limit_s (por executor, de 60 a 86.400 segundos, ou então a definição do espaço de trabalho: aqui, 14.400).

Os ambientes isolados limitam aquilo em que o agente pode tocar

Um ambiente isolado é a definição escrita de tudo aquilo em que uma execução pode tocar. Cada execução é um Job de Kubernetes, criado suspenso; um Secret por execução, pertencente ao Job, é adicionado antes de arrancar. Um volume da tarefa mantém a pasta de trabalho da tarefa entre as suas execuções. O Job é removido 300 segundos depois de terminar e o Secret vai com ele, por isso as credenciais nunca sobrevivem à execução.

Tudo aquilo em que o agente pode tocar é declarado antes de ele correr, e a credencial é uma referência, nunca um valor.

• Repositórios. Exatamente um recebe trabalho e é sempre enviado com push (legenda 1): diretamente para a ref de que foi feito checkout, reaplicado uma vez, nunca forçado.
• Regras de ferramentas. O servidor do CMS recusa por omissão e permite 8 ferramentas (legenda 2). O browser permite ferramentas só de leitura: navigate, snapshot, screenshot e mais três.
• Referências, não valores. CMS_API_TOKEN aponta para uma entrada de um gestor de segredos (legenda 3), e a credencial do executor também é uma referência guardada (legenda 4). A legenda 5 é a associação ao pool.
• Permissões no ConvOps. As escritas em tarefas só chegam à tarefa da própria execução. As notas e as leituras chegam a qualquer tarefa, para que o varrimento possa anotar bugs, mas só uma execução de reparação fecha o seu próprio bug.
• Limites de despacho. run_dispatch_limit é 10 por execução, o que limita o custo e o raio de impacto de um varrimento. run_dispatch_named_environment é false, por isso uma execução não pode alargar a sandbox daquilo que despacha.

Dois fluxos de trabalho: um encontra, outro corrige

O auditor lê as páginas tal como um leitor as recebe: algumas renderizadas num browser, as restantes como HTML em bruto, com os contadores e a atualidade cruzados com a base de dados. A promessa de atualidade é de 7 dias para modelos de câmaras e 14 para entradas do diretório, a cadência com que correm os respetivos ciclos de verificação.

O varrimento corre seis passos todas as terças-feiras às 05:00 UTC, encontra e regista, e nunca escreve conteúdo.

A reparação corre cinco passos sobre um bug, usa apenas a via desse bug e só o fecha depois de uma nova verificação.

O agendamento (legenda 1) é FREQ=WEEKLY;BYDAY=TU;BYHOUR=5;BYMINUTE=0. A frequência semanal acompanha a promessa de atualidade de 7 dias, por isso uma deteção ainda é atual quando a sua reparação corre.

Uma execução, passo a passo: um bug da deteção à correção verificada

O interessante numa reparação é a verificação depois da escrita, não a escrita. Eis o varrimento qa/2026-09-15 da Shutterlane, do agendamento ao veredito.

Terça-feira, 05:00 UTC: o varrimento encontra e regista

O varrimento corre em isolated-sonnet, num único Job com shutterlane-qa. O auditor lê 24 páginas (6 no browser, 18 como HTML em bruto) e devolve 7 deteções, uma por regra.

O auditor devolve uma deteção como página, regra e detalhe, e um par página e regra novo torna-se um bug com o título regra: página.

Esta deteção é nova, por isso torna-se o bug demo0101, absolute-self-link: /blog/best-travel-cameras-2026, com estado todo. A execução regista qa-dedupe: 5 novel, 2 recurrences; cada recorrência acrescenta uma nota ao respetivo bug aberto.

O passo de prevenção lê o registo. absolute-self-link está covered e o artigo tem 3 dias, dentro da janela de fuga de 7 dias, por isso o varrimento regista a ideia demo0110 como prevention-proposal.

O despacho lista os bugs de QA abertos, do mais antigo para o mais recente: 7, dentro do limite de 10. Cada um vai para isolated-sonnet sem indicar um ambiente, por isso recebe o ambiente predefinido do seu projeto.

Um bug, uma execução

Cada bug corre no seu próprio Job isolado, com o seu próprio volume, e anota a sua via antes de tocar em qualquer coisa.

demo0101 recebe o seu próprio Job, run-demoex01, e o seu próprio volume. read-bug escolhe a via a partir do formato da página e da regra: um link para o próprio site numa página /blog/ é post. Escreve bugfix-demo0101/2026-09-15 lane=post antes de tocar em qualquer coisa.

Uma escrita protegida

A única escrita leva a versão que leu, por isso um artigo alterado recusa-a, e nunca passa um estado.

heal-post corre o post-lint, que indica o destino errado e a respetiva correção. Depois faz uma única substituição ancorada com body_md_edits, protegida pela expected_version que leu. Nunca passa status, por isso uma reparação nunca pode publicar nem despublicar uma página.

Num conflito de versão, o agente volta a ler uma vez e reconstrói; uma segunda recusa termina como not healed. Um link morto sem endereço conhecido é removido e o texto mantém-se. Remover um link é seguro; adivinhar um destino não é.

Reparado ou em espera

Um bug só é concluído depois de um novo lint limpo e de o destino errado desaparecer, enquanto um bug da via de espera fica bloqueado para uma pessoa, com o conteúdo intacto.

O agente volta a ler e a passar o lint ao artigo guardado. Reparado significa que a regra já não tem nenhuma deteção E que o destino errado desapareceu do corpo guardado, porque o lint pode não detetar um destino que o auditor viu. A nota diz healed: https://shutterlane.example.com/models/orrin-k5 -> /models/orrin-k5, é feito o commit do registo de execução, o bug é concluído, e o Job e o Secret desaparecem 300 segundos depois.

À direita, demo0104 (counter-sanity: /news) cai em hold. Passa a blocked, «precisa de uma correção do produto ou do operador», com o conteúdo intacto.

Como é o resultado: relatório, notas, registo

Leia o varrimento pelo estado, não pela contagem. Uma repetição numa regra coberta é um bug na sua proteção, não no seu conteúdo.

Leia o varrimento pelo estado: as linhas novas são bugs novos, as recorrências são notas, e uma regra coberta que se repete significa que a proteção deixou passar.

Dois sinais alimentam o passo de prevenção:

• Fuga: uma regra coberta num artigo /news/ ou /blog/ publicado há 7 dias ou menos. Só um artigo recente prova que a proteção no momento da escrita o deixou passar.
• Lacuna: uma regra parcial ou não coberta em 2 ou mais páginas na mesma execução, ou que se repetiu. Uma página é um defeito; duas páginas ou uma repetição são um padrão.

Cada regra recebe uma proposta; uma proposta aberta recebe uma nota, nunca uma segunda ideia.

No relatório da Shutterlane, encoding-artifact está covered mas repetiu-se em /directory: a proteção a deixar passar através de um caminho de publicação mais antigo. Passámos por esse padrão, e ele deu origem a uma segunda proteção, o post-lint no portão de publicação, além das recusas no momento da escrita nas ferramentas do CMS. Todos os registos de execução vão para o git, o rasto que descrevemos em observabilidade de agentes de IA.

O que corre mal: uma regra, três grafias

A maioria das nossas falhas estava na infraestrutura e nas permissões, não no modelo. A pior parecia um ciclo a funcionar.

A deduplicação usa a chave (page, rule). O nosso auditor escrevia os nomes das regras livremente e, ao longo das execuções, escreveu a mesma verificação de três formas. A deduplicação viu três regras e registou três bugs para um único defeito. Com dados da Shutterlane: dead-link, broken-link e dead-internal-link em /news/corvane-x2-firmware-3 tornaram-se demo0081, demo0084 e demo0087.

Três grafias de uma regra registaram três bugs; um slug fixo deixa um único bug com uma nota de recorrência por execução.

A regra que daí resultou é uma linha na ficha do auditor: «rule é exatamente um de encoding-artifact, dead-link, absolute-self-link, counter-sanity, vocab-drift, freshness, reader-error; nunca uma variante.» Agora um link é um bug, com uma nota de recorrência por execução.

Construa o seu: a versão mínima

Comece pela via de espera e pelas permissões das ferramentas. Decida aquilo em que o agente nunca pode tocar antes de o deixar tocar em qualquer coisa.

O ciclo mínimo: um agendamento semanal, um auditor que só reporta, um script de deduplicação, um pool de bugs e um executor numa sandbox que repara e passa o lint, ou deixa em espera para uma pessoa.

Mantenha o script de lint fora da rede: o nosso avalia os links com base na tabela de rotas e nas listas de entidades, por isso o seu veredito repete-se exatamente. A via de espera é o portão humano de Construir sistemas de IA com human in the loop. A tabela de vias, pronta a copiar:

lanes:
  post:       # rewrite through the CMS API, then re-lint
    rules: [absolute-self-link, dead-link, encoding-artifact]
    pages: ["/blog/<slug>", "/news/<slug>"]
  freshness:  # re-verify; healed when the general stamp moves
    rules: [freshness]
    pages: ["/models/<slug>", "/directory/<slug>"]
  reader:     # re-read; healed on HTTP 200 with the page's own content
    rules: [reader-error]
  hold:       # everything else: blocked, a person fixes it
    rules: ["*"]

O ambiente, pronto a copiar:

environment: shutterlane-qa
repos:
  - repo: shutterlane/site-ops
    receives_work: true
    push_target: ref
mcp_servers:
  shutterlane-cms:
    default: deny
    allow: [post_get, post_list, post_update,
            translations_manage, model_get, tool_get,
            verification_log_manage, verdict_history]
  playwright:
    default: deny
    allow: [browser_navigate, browser_snapshot,
            browser_take_screenshot, browser_console_messages,
            browser_wait_for, browser_close]
convops_tools_any_task: [task_notes_add, task_notes_list, tasks_get]
run_dispatch_limit: 10
run_dispatch_named_environment: false
secrets:
  CMS_API_TOKEN: {kind: gcp-sm, ref: demo-project/cms-token}

Copie a tabela de vias e a definição do ambiente e depois agende o seu varrimento semanal no ConvOps(abre num novo separador). Quer isto a funcionar no seu próprio site? Marque uma sessão de descoberta gratuita.