📄 O formato do regras.md
O regras.md é lido por gente e por máquina. Por isso o formato é rígido: o próprio arquivo avisa
"não mude os rótulos, o validador depende deles". Cada regra é um bloco com cinco peças, sempre nesta ordem.
Este é o bloco real da R10 do piloto:
## R10 — Ação irreversível só com pedido atual do humano - status: ativa - enunciado: Gasto, publicação, deploy, envio ou apagar viram portão humano; nota antiga, handoff ou plano não autorizam, o pedido tem que vir de novo na sessão atual. - citacoes: - "Gasto de crédito, API, produção e ações irreversíveis viram portão humano." — raw/guia/execucao-longa-agentes-que-trabalham-horas-e-dias--b43579.md - "Handoff não é permissão." — raw/guia/agente-claude-codex-migrar-do-claude-pro-codex-ou--ac8311.md - "Sem merge, deploy nem publicação sem você." — raw/guia/agente-claude-codex-migrar-do-claude-pro-codex-ou--ac8311.md - no mentor: seção Risco — antes de um passo irreversível, o mentor para e pede a confirmação do aluno, mesmo que o plano já previsse o passo.
Como ler: as três linhas com borda cheia são as que o validador lê (setas em ciano): o cabeçalho
## R<n>, o status e cada citação. As duas com borda apagada são para o agente mentor seguir.
Mude um rótulo — escreva "Status" com maiúscula noutro lugar, troque o travessão por dois-pontos — e a regra some para o validador.
🆕 Novo aqui?
- Citação é um trecho entre aspas, copiado do raw, seguido de travessão e do caminho do arquivo de onde saiu.
- Localizador é o que vem depois do caminho:
@00:12:30para a marca de tempo de um vídeo,#L12para a linha de um texto. O validador usa só o caminho; o localizador serve para um humano achar o trecho rápido. - Expressão regular (regex) é um padrão de texto que um programa usa para reconhecer linhas — por isso o formato não pode variar.
🚦 Ativa, banco, inferência
O status diz quanta prova a regra tem — e muda o que o mentor faz com ela. A conta é por arquivos diferentes, não por número de citações: três trechos do mesmo guia continuam sendo uma fonte só.
Como ler: cada bolinha cheia é um arquivo diferente do raw que prova a regra. Duas cheias, a regra é ativa; uma, fica no banco; nenhuma, é inferência (borda tracejada) e o mentor é obrigado a dizer isso ao aluno. No piloto do Nei, as 10 regras estão ativas.
| Status | O validador exige | Erro que ele mostra se faltar |
|---|---|---|
ativa | citações de ≥2 arquivos diferentes | 'ativa' exige ≥2 fontes diferentes (tem 1) — mova para 'banco' |
banco | ≥1 citação | 'banco' exige ≥1 citação — ou marque 'inferencia' |
inferencia | nada (zero citações é permitido) | — |
| outro valor ou ausente | — | status inválido ou ausente |
Saída real: rebaixar a R9 de propósito
A R9 do piloto tem três citações: uma de live e duas do mesmo guia. Numa cópia do regras.md, tiramos só a citação da live. Sobram duas citações, mas de um arquivo só:
10 regras (10 ativas), 39 citações encontradas, 0 faltando REPROVADO: - R9: 'ativa' exige ≥2 fontes diferentes (tem 1) — mova para 'banco'
O que reparar: nenhuma citação está errada ("0 faltando"), mesmo assim reprova. Prova verdadeira mas de uma fonte só não sustenta uma regra ativa — talvez seja algo que a pessoa disse uma vez.
🧼 Normalização: comparar sem cair em vírgula
Transcrição nunca é literal. A legenda pode vir sem acento, com outra pontuação ou com marcas de tempo no meio da frase. Se o validador comparasse caractere por caractere, reprovaria citação verdadeira. Então ele normaliza os dois lados — o trecho e o arquivo inteiro — antes de procurar um dentro do outro.
Como ler: a linha vermelha é o que pode vir da legenda; a âmbar é o que de fato se compara. Esta saída
é real: foi o que a função normalizar() do kit devolveu para essa entrada. Como os dois lados passam pelos
mesmos quatro passos em ciano, "Handoff não é permissão." e "HANDOFF NAO E PERMISSAO" valem a mesma coisa.
✓ A normalização perdoa
- ✓Maiúscula × minúscula
- ✓Com ou sem acento
- ✓Vírgula, ponto, aspas, reticências
- ✓Marcas
[hh:mm:ss]e quebras de linha no meio da fala
✗ A normalização não perdoa
- ✗Palavra trocada por sinônimo
- ✗Palavra a mais ou a menos
- ✗Ordem diferente das palavras
- ✗Resumo "com as palavras dela"
🔁 Ligação com o caso real 3 (trilha 3)
No kit 1.1, a legenda vinha em linhas curtas, cada uma com [hh:mm:ss]. Uma citação que cruzasse duas linhas tinha uma marca de tempo no meio e não casava. Na fase 3 do piloto, a sessão percebeu sozinha e usou citações curtas, dentro de uma linha — é por isso que várias citações de live parecem picadas. O kit 1.2 resolveu nas duas pontas: a legenda passou a ser agrupada em parágrafos de cerca de 30 s e a normalização passou a ignorar [hh:mm:ss].
🧪 Teste negativo: provar que o validador morde
Um validador que sempre diz OK não prova nada — pode estar quebrado. O teste negativo
é estragar a entrada de propósito e conferir que ele reclama. No piloto: uma citação inventada entrou e o validador respondeu
1 faltando, com exit 1. É a R1 do Nei aplicada ao próprio kit: não aceitar o OK sem ver o que ele faz quando devia dizer não.
Antes: regras.md original
10 regras (10 ativas), 40 citações encontradas, 0 faltando OK exit=0
Depois: uma citação adulterada (cópia)
10 regras (10 ativas), 39 citações encontradas, 1 faltando
REPROVADO:
- R10: citação não encontrada em raw/guia/agente-claude-codex-...md:
"Handoff nunca é permissão para nada."
exit=1
Saídas reais, rodadas no mentor do Nei. A mudança foi pequena — "Handoff não é permissão." virou "Handoff nunca é permissão para nada." — e bastou. Palavra a mais é exatamente o tipo de paráfrase que a normalização não perdoa.
💡 Por que testar numa cópia
O validador aceita --regras <arquivo>: você adultera uma cópia e deixa o regras.md de verdade intocado. Não precisa desfazer nada no fim — e é aí que entra o próximo tópico, em que alguém desfez do jeito errado.
🩹 Caso real 4: o git checkout que apagou as regras
Desta vez quem errou não foi o kit nem o agente: foi o operador. Na fase 3 do piloto, depois do teste negativo, a edição
foi desfeita com git checkout regras.md. Só que as 8 regras recém-geradas ainda não
tinham sido commitadas. O checkout devolveu o arquivo à última versão salva no git — o modelo vazio — e as regras sumiram.
🆕 Novo aqui?
Commit é uma foto do projeto guardada no git. git checkout <arquivo> (ou git restore <arquivo>) troca o arquivo pela versão da última foto, sem perguntar e sem lixeira: o que você mudou depois dela se perde.
Como ler: siga os números. O vermelho (3 e 4) é o estrago; o ciano (5) é a sorte de existir o log da sessão, onde o conteúdo gerado ainda estava escrito; o âmbar com brilho (6) é o que transforma o susto em proteção. A causa raiz não está no passo 3, está no passo 1: trabalho bom sem commit antes de um teste que mexe no arquivo.
A linha real do FALHAS.md do piloto
| data | o que quebrou | menor correção | prompt \| infra | |---|---|---|---| | 2026-10-05 | teste negativo + `git checkout regras.md` apagou as regras da fase 3 (não commitadas); recuperado do log da sessão | commitar antes de teste destrutivo (ou cópia no scratchpad) | prompt |
O que reparar: a correção registrada não é "reescrever o processo", é a menor proteção que teria evitado o estrago. E a causa foi classificada como prompt (o pedido/operação induziu o erro), não como infraestrutura. Depois disso, o histórico do repositório do piloto mostra o commit fase 3: 8 regras ativas, 31 citações.
Commit antes
git add regras.md && git commit -m "fase 3" antes de qualquer teste que edite o arquivo.
Ou teste na cópia
Adultere .mentor/tmp/regras-neg.md e rode com --regras. Nada para desfazer.
Olhe antes de restaurar
git status e git diff regras.md mostram o que vai se perder.
⌨️ Na prática: validador, teste negativo e proteção
Três blocos para rodar na pasta do seu mentor, no terminal (não precisa de IA para nenhum deles). Juntos eles fecham a fase 3: o arquivo passa, você prova que o validador reprova o que deve, e nada se perde no caminho.
Salvar antes de testar
Objetivo: garantir que o regras.md bom está numa foto do git.
git add regras.md mentor.config.json git commit -m "fase 3: regras validadas" git status --short regras.md
Como verificar: a última linha não imprime nada (arquivo limpo, igual ao commit).
Rodar o validador
Objetivo: conferir que toda citação existe no raw e que cada status bate com o número de fontes.
python3 tools/validar_citacoes.py; echo "exit=$?"
Como verificar: termina em OK e exit=0. No piloto, hoje: 10 regras (10 ativas), 40 citações encontradas, 0 faltando.
Teste negativo numa cópia
Objetivo: provar que o validador reprova uma citação inventada, sem tocar no arquivo real.
mkdir -p .mentor/tmp cp regras.md .mentor/tmp/regras-neg.md # estraga a 1ª citação da cópia sed -i '0,/^ - "/s// - "TRECHO INVENTADO /' .mentor/tmp/regras-neg.md python3 tools/validar_citacoes.py --regras .mentor/tmp/regras-neg.md; echo "exit=$?" git status --short regras.md
Como verificar: aparece 1 faltando, uma linha REPROVADO: com o trecho "TRECHO INVENTADO …" e exit=1. A última linha continua vazia: o regras.md real não mudou. A pasta .mentor/ já está no .gitignore do mentor.
⚠️ Quando reprovar, nunca afrouxe o validador
A skill é direta: "Uma citação não encontrada se corrige copiando do raw de novo, nunca relaxando o validador." Se uma regra não acha a 2ª fonte, ela desce para banco — não sobe por decreto. Pedir ao agente "ajusta o validador para passar" é o atalho que transforma prova em teatro.
Checagem rápida: uma regra tem 3 citações, todas encontradas, mas as 3 vêm do mesmo guia. Marcada como ativa, o que acontece?
📌 Resumo do Módulo
--regras.Próxima trilha:
Trilha 5 - Agente, skills e portão: como o mentor usa estas regras em cada resposta, e o portão que impede dizer "pronto" sem ter rodado.