Este artigo faz parte da série “Plugin do Zero ao WP.org com IA”, onde documento a jornada real de criação do PAP Afiliados Pro — com acertos, erros e aprendizados.
No artigo anterior, contei as 3 lições de segurança que aprendi quando o WordPress.org rejeitou meu plugin. Nonces bypassáveis, escaping inconsistente, queries sem prepare. Cada rejeição me ensinou algo. Mas aprender a lição não resolve o problema se você não muda o processo.
Porque o que me incomodava não era ter cometido erros — erros acontecem. O que me incomodava era não ter um mecanismo para impedir que o mesmo erro acontecesse de novo. Eu corrigia o nonce no arquivo A, e a IA gerava código novo no arquivo B com o mesmo problema. Resolvia o escaping numa tela, e outra tela saía sem. Era um jogo de whack-a-mole: batia num problema aqui, aparecia ali.
Foi aí que pensei: se eu consigo documentar a arquitetura do projeto em contratos técnicos, por que não documentar as regras de segurança da mesma forma? Não como guia de estudo — como sistema de validação obrigatório. Algo que não dependa de memória, nem minha nem da IA.
Nasceu o que chamo de Guardian de Conformidade.
O que é, sem romantizar
Não é um software. Não é uma ferramenta automatizada. Não é nada sofisticado do ponto de vista tecnológico. É um conjunto de documentos e regras que criam uma barreira entre “código pronto” e “código entregue.”
Na prática, são três componentes:
O primeiro é um checklist de segurança com 8 regras não negociáveis — as mesmas que o WordPress.org exige. Nonces obrigatórios com retorno verificado. Capabilities em todas as operações admin. Sanitização em todos os inputs. Escaping em todos os outputs. SQL preparado em todas as queries. Prefixo único. Text domain correto. Internacionalização completa. Oito itens. Todos precisam estar 100% conformes. Falhar em um bloqueia a entrega.
O segundo é um documento de regras preventivas — lições aprendidas com cada erro real do projeto. Não é teoria. Cada regra ali existe porque eu errei de uma forma específica e documentei para não repetir. “Nonce bypassável: pattern bail-out obrigatório.” “Escaping: todo echo precisa de esc_*.” “SQL: toda query com variável usa prepare, independente da origem da variável.” Quando cometo um erro novo, vira regra nova. O documento cresce com o projeto.
O terceiro é o template de prompt obrigatório. Todo prompt que vai para a IA implementadora inclui uma seção chamada “Conformidade Obrigatória” — o checklist de segurança completo, os prefixos corretos, e uma referência aos documentos de regras. Não é opcional. Não é “quando lembrar.” É estrutural. Faz parte do formato do prompt como o endereço faz parte de uma carta.
Três componentes. Nenhum é tecnicamente impressionante. Juntos, mudaram completamente a qualidade do que sai do outro lado.
Como funciona no dia a dia
Deixa eu mostrar o fluxo real. Eu preciso implementar uma nova funcionalidade — digamos, o sistema de importação de produtos por CSV.
Antes de qualquer coisa, paro e penso: essa funcionalidade envolve entrada de dados? Sim — o usuário faz upload de um arquivo. Envolve processamento server-side? Sim — o PHP precisa ler e interpretar o CSV. Grava no banco? Sim — cria produtos novos. Tem interface admin? Sim — botão de importar, feedback de progresso.
Só com essa análise rápida, já sei quais regras de segurança se aplicam: nonce no formulário de upload, capability check (só admin pode importar), sanitização de cada campo do CSV antes de gravar, escaping de qualquer feedback mostrado na tela, SQL preparado para os inserts no banco.
Aí monto o prompt para o CCW. E a seção de conformidade já vem preenchida com tudo isso, explicitamente. Não é “implemente com segurança.” É “nonce com check_ajax_referer e retorno verificado para o handler AJAX de importação, current_user_can(‘manage_options’) no início do handler, sanitize_text_field em campos de texto do CSV, absint em campos numéricos, esc_html em todas as mensagens de feedback, $wpdb->prepare em todos os inserts.”
A IA recebe isso e implementa seguindo os padrões. Quando a implementação volta, eu valido contra o checklist. Nonce presente e com retorno verificado? Sim. Capability check? Sim. Sanitização em cada campo? Vou verificar campo por campo. Escaping nos outputs? Vou verificar cada echo. SQL preparado? Vou verificar cada query.
Se tudo passa: entrega aprovada. Se qualquer item falha: entrega bloqueada. Sem exceção. Sem “depois eu ajusto.” Sem “é só um campo, não precisa.” Bloqueada.
Parece rígido? É. E é justamente por isso que funciona.
Por que isso resolve o problema da IA sem memória
Lembra do problema que descrevi no Artigo 2 — cada sessão de IA começa do zero, sem memória? O Guardian resolve isso de forma elegante, mesmo que simples.
A IA não precisa lembrar que na sessão anterior eu corrigi um nonce bypassável. Não precisa saber que o revisor do WordPress.org me mandou de volta por falta de escaping. Não precisa ter contexto histórico nenhum. Ela só precisa receber, no prompt atual, as regras que deve seguir. E as regras já incorporam todos os aprendizados passados.
É como se cada erro do passado virasse uma vacina no presente. Eu errei com nonce bypassável? Agora o prompt diz explicitamente “pattern bail-out obrigatório.” A IA de hoje se beneficia do erro que a IA de ontem cometeu — mesmo sendo sessões completamente independentes. A ponte entre elas é o documento.
Tem uma frase que repito para mim mesmo quando estou montando um prompt: “Se não está no prompt, não existe.” A IA não vai adivinhar. Não vai lembrar. Não vai inferir a partir de boas intenções. Se a regra de segurança não está escrita ali, para aquela sessão específica, ela não existe.
O efeito colateral que não esperava
Quando criei o Guardian, o objetivo era evitar rejeições do WordPress.org. Era pragmático — eu queria que o plugin fosse aprovado. Mas o efeito colateral foi mais valioso que o objetivo original.
O Guardian me deu confiança.
Antes, quando eu terminava uma implementação, tinha sempre aquela ansiedade: “será que está seguro? Será que esqueci alguma coisa? Será que o revisor vai encontrar algo que eu não vi?” Era um estado constante de incerteza, porque eu dependia de intuição — e a minha intuição sobre segurança de código era, sendo generoso, limitada.
Com o Guardian, a ansiedade deu lugar a processo. Eu não preciso mais “achar” que está seguro. Eu verifico. Item por item. Se passou no checklist, está conforme. Se não passou, sei exatamente o que corrigir. A incerteza virou checklist, e checklist tem resposta binária: sim ou não.
Isso pode parecer pouca coisa para um programador experiente que já internalizou essas práticas. Mas para alguém que não é programador e está orquestrando IA para gerar código — essa diferença é tudo. É a diferença entre “estou navegando no escuro” e “tenho um mapa.”
O que isso ensina sobre trabalhar com IA
Tem uma lição mais ampla aqui que vai além de plugins WordPress. Quem trabalha com IA para produção — seja código, texto, análise, qualquer coisa — enfrenta o mesmo problema fundamental: a IA é poderosa mas não é consistente. Ela pode gerar algo excelente numa sessão e medíocre na seguinte, porque cada sessão é independente.
A consistência não vem da IA. Vem do processo ao redor dela.
Vou dar um exemplo concreto fora do WordPress. Imagina que você usa IA para escrever propostas comerciais. Na segunda-feira, a proposta sai impecável — tom certo, estrutura clara, dados precisos. Na quarta, você abre uma nova sessão e pede outra proposta. Sai com tom diferente, estrutura diferente, esqueceu de incluir o disclaimer legal que a sua empresa exige. Não é porque a IA piorou. É porque ela não lembra da segunda-feira.
Se você tem um template obrigatório com tom, estrutura, dados de referência e regras — cada proposta sai no padrão. Não perfeita, mas consistente. E consistência, em produção profissional, vale mais que perfeição eventual.
Documentação estruturada garante que a IA receba o contexto correto toda vez. Checklists de qualidade garantem que o output atinja um padrão mínimo toda vez. Regras preventivas garantem que erros do passado não se repitam. É o mesmo princípio de qualquer sistema de qualidade — a ISO 9001 não torna os funcionários mais inteligentes, torna o processo mais previsível.
No meu caso específico, o Guardian de Conformidade é sobre segurança WordPress. Mas o conceito se aplica a qualquer pessoa que usa IA de forma profissional. Se você depende de IA para produzir algo com qualidade consistente, precisa de um sistema externo que defina, verifique e imponha padrões. Porque a IA sozinha não vai fazer isso por você.
O que o Guardian não substitui
Preciso ser honesto sobre os limites. O Guardian é um sistema de prevenção, não de detecção. Ele funciona porque eu sei quais regras incluir — e eu sei porque o revisor do WordPress.org me ensinou, da forma mais direta possível.
Se existe uma vulnerabilidade que eu desconheço — e certamente existem — o Guardian não pega. Ele só protege contra problemas conhecidos e documentados. É uma rede de segurança, não uma blindagem completa.
Por isso a revisão do WordPress.org continua sendo essencial. É a segunda camada. O Guardian é a primeira — pega os problemas que eu já conheço antes de chegar no revisor. O revisor é a segunda — pega os que eu ainda não conheço. E quando o revisor aponta algo novo, isso vira regra preventiva, e o Guardian fica mais forte.
É um ciclo virtuoso: erro → aprendizado → regra → prevenção → menos erros. Não elimina erros completamente — nenhum sistema faz isso. Mas reduz drasticamente a reincidência. E num processo de revisão onde cada rodada leva dias ou semanas de espera na fila, evitar reincidência é economizar tempo de todo mundo.
Para quem quer montar o seu
Se a ideia de um Guardian de Conformidade faz sentido para o seu contexto, aqui vai o que eu sugiro como ponto de partida:
Comece pelo que dói. Não tente mapear todas as regras possíveis antes de começar — comece pelas que já te causaram problema. Cada erro real que você cometeu é uma regra preventiva. Documente o erro, documente a solução, transforme em checklist.
Coloque no prompt, não na cabeça. Se a regra não está escrita no prompt que vai para a IA, ela não existe para aquela sessão. Não confie em “a IA deve saber isso.” Ela não sabe. Explicite.
Seja binário. O checklist tem resposta sim ou não. Não tem “parcialmente.” Não tem “na maioria dos casos.” Passou ou não passou. Se não passou, bloqueia. Sem negociação.
Atualize sempre. Cada erro novo é uma regra nova. Cada feedback de revisão é um aprendizado. O Guardian não é um documento que você escreve uma vez e esquece — é um documento vivo que fica mais inteligente a cada interação.
E talvez o mais importante: não tenha vergonha de precisar disso. Eu não sou programador. Eu preciso de um checklist explícito porque não internalizei essas práticas em anos de código. Mas mesmo programadores experientes usam code review, CI/CD, linters, análise estática — ferramentas que existem justamente porque humanos esquecem. O Guardian é a minha versão de tudo isso, adaptada para um fluxo de trabalho com IA.
Se tem uma coisa que esse projeto inteiro me ensinou é que disciplina supera talento quando talento não tem disciplina. Eu não tenho talento para programação. Tenho disciplina para documentar, verificar, e não aceitar “provavelmente está certo” como resposta. E no final das contas, é isso que o WordPress.org avalia: não se o seu código é elegante, mas se é seguro e confiável. Elegância é bônus. Segurança é obrigação.
No próximo artigo — o último da série — vou consolidar tudo com números reais. Timeline, milestones, decisões-chave, e o que levaria comigo se fosse começar do zero outra vez.
Próximo artigo da série: Timeline real: 3 meses, 8 milestones, 20 classes, aprovação no WP.org — números e aprendizados
Navegação da série:
◀ Artigo anterior: WordPress.org rejeitou meu plugin por segurança — 3 lições que aprendi do jeito difícil
▶ Próximo artigo: Timeline real: 3 meses, 8 milestones, 20 classes, aprovação no WP.org — números e aprendizados