3 bugs reais que achamos revisando a própria curadoria externa
Revisamos 15 componentes de terceiro à mão, marcamos como revisados, e horas depois o cron tinha revertido tudo sozinho. Isto é o que investigar esse sintoma até a causa raiz encontrou.
O Índice Aberto da Reveno Agents indexa componentes públicos de terceiro do GitHub, roda uma triagem heurística automática, e espera revisão humana antes de qualquer item sair de "precisa revisão". Fizemos essa revisão de verdade em 15 itens: lemos o SKILL.md completo de cada um, confirmamos que nenhum era malicioso, marcamos como revisado. Horas depois, os 15 tinham voltado para "precisa revisão" sozinhos.
O sintoma parecia inofensivo
Nada quebrou, nenhuma página deu erro, nenhum log gritou. Só o estado que devia ser permanente (uma decisão humana registrada) tinha se desfeito sem nenhuma ação humana nova. Esse tipo de bug é o mais perigoso de todos porque não avisa: sem checar de novo por acaso, a decisão de revisão simplesmente deixaria de existir a cada 6 horas, para sempre, sem ninguém perceber.
A causa raiz: o cron não distinguia decisão humana de estado automático
O script que monitora os componentes já indexados (rodando de 6 em 6 horas para pegar mudança de conteúdo) recalculava o status de confiança de cada item a cada execução, e sobrescrevia o que já estava lá, sem checar se aquele valor já era uma decisão humana terminal (revisado, ou rejeitado). Um humano marcar "revisado" e o cron pisar em cima 6 horas depois é, na prática, o cron tendo a palavra final sobre uma decisão que deveria ser exclusivamente humana.
Um sistema de revisão humana que o próprio sistema desfaz sozinho não é revisão humana, é teatro de revisão humana.
Bug 2, achado enquanto corrigia o primeiro: duplicata silenciosa
Ao investigar, um componente aparecia duas vezes no índice, como se fossem dois arquivos diferentes. Eram o mesmo arquivo. A URL de download de um arquivo no GitHub inclui o identificador do commit mais recente, e o código usava essa URL como identidade do componente. Todo commit novo no repositório de origem, mesmo trocando uma linha, virava "um componente novo" aos olhos do indexador. Corrigido trocando a identidade de "URL literal" para "autor + repositório + caminho do arquivo", que é o que de fato não muda entre commits.
Bug 3: a própria verificação de duplicidade da execução não funcionava
Por último, um bug de eficiência: o script tentava não reprocessar duas vezes o mesmo item numa única execução, mas comparava URLs em dois formatos diferentes que nunca coincidiam entre si. Não corrompia dado, só gastava chamada de rede e de API à toa, processando cada item já indexado duas vezes por execução em vez de uma.
Como isso foi verificado, não só corrigido
Depois da correção, remarcamos os 15 itens como revisados e rodamos o script real em produção duas vezes seguidas, o mesmo comando que o cron executa sozinho. Os 15 permaneceram revisados nas duas vezes. Sem essa verificação de ponta a ponta, a correção seria só uma suposição de que o código novo funcionava.
Nenhum dado foi perdido, nenhum componente malicioso passou despercebido, e a decisão humana que existia continuava correta o tempo todo, só não estava sendo respeitada pelo sistema. Registrar isso em público é o mesmo princípio do Trust Score: "não testado" é sempre mais honesto do que fingir que nunca houve problema.