O problema
Um mandato legislativo acumula histórico: leis aprovadas, projetos em tramitação, números por ano. Esse histórico precisa existir em dois formatos ao mesmo tempo — como dado estruturado que alimenta geração de conteúdo, e como algo navegável por humano, que qualquer pessoa da equipe consegue abrir e entender sem ler código. E precisa, além disso, estar refletido no site público: cada lei relevante merece um post, e alguém precisa saber quais já têm e quais ainda faltam.
Fazer essa checagem na mão — abrir o site, procurar cada lei, anotar o que falta — não escala a partir de umas 20 entradas. Com quase 90, é trabalho de meio dia repetido toda vez que alguém pergunta “o que falta publicar”.
A arquitetura: vault como camada de leitura, não como fonte
Construí um vault no Obsidian com cerca de 90 notas organizadas por categoria (leis aprovadas, projetos em tramitação, contexto editorial, entidades recorrentes), cada uma com frontmatter estruturado e um badge de status logo no topo. Internamente eu chamava isso de “painel da verdade” — até perceber que o nome estava errado.
A fonte canônica do dado continua sendo o repositório de configuração que o pipeline de IA lê pra gerar copy — versionado, é ali que um número é corrigido de verdade. O vault é a camada de navegação: um grafo de notas com backlink automático, feito pra ser consultado visualmente, não editado como fonte. Separar “onde o dado é editado” de “onde o dado é navegado” é decisão de arquitetura, não estética — e vale corrigir o apelido quando ele descreve errado o que o sistema faz.
O padrão de frontmatter + badge não é só organização: é o que torna cada nota parseável por script, além de legível por humano. Isso é o que viabiliza a próxima peça.
A automação: reconciliação em três vias
Um script varre o vault, extrai o badge de cada nota de lei/projeto e normaliza o identificador. Em paralelo, ele consulta a API pública do site (sem precisar de credencial — é leitura de dado já público) e limpa os títulos publicados. Depois cruza as duas listas com o que existe no legislativo, em cascata de confiança decrescente:
- Override manual — uma tabela de exceções pra casos onde o nome no vault e o nome no site divergem por sinônimo, e a correspondência só é sabida por quem acompanha o processo.
- Match por identificador normalizado — quando o número da lei bate exatamente nas duas fontes.
- Match difuso por texto — só entra se os dois anteriores falharem: similaridade mínima de tokens, com stopwords em português removidas antes da comparação, pra não deixar “de”, “da”, “projeto” inflar uma correspondência que não existe.
O script gera uma planilha com a ação recomendada por item — atualizar post existente ou criar um novo — mais os casos de conflito (mesmo identificador, nomes divergentes: sinal de erro de digitação em algum lado) e duplicatas com conteúdo que já cobre o mesmo tema.
A decisão que sustenta a confiabilidade do resultado
Cada linha da planilha carrega não só o match, mas como ele foi feito. Isso é o que separa esse script de um “match burro” por nome: cada camada da cascata tem uma taxa de falso-positivo diferente e conhecida, e fica registrada. Auditando o resultado, dá pra saber se aquele match é confiável (número bateu) ou arriscado (só texto, dois tokens em comum) — informação que se perderia se fosse um único critério de comparação. É o mesmo esqueleto usado em deduplicação de registro (entity resolution) em qualquer pipeline de dados: cascata de match com confiança decrescente e fallback auditável, não uma regra única aplicada cegamente.
O resultado
O que antes era checagem manual item a item virou uma planilha gerada em segundos, com toda lei e projeto do mandato classificado: publicado e atualizado, publicado mas desalinhado, ou faltando. Essa planilha virou a lista de trabalho pra recriar o conteúdo público de cada lei — sem precisar abrir o site e comparar um por um pra saber por onde começar.
Como eu trabalho nisso
Especifiquei e dirigi a arquitetura via Claude Code — a separação entre fonte e camada de leitura, o desenho da cascata de match, a decisão de registrar o “como” de cada correspondência — revisando o resultado linha a linha antes de confiar nele. Não escrevi o parser de regex à mão; entendo por que cada camada existe e sei quando um resultado do script merece checagem humana antes de virar ação.