Como revisar e desfazer as mudanças que um fluxo com Jev fez no seu vault do Obsidian?

Rodar um faxineiro automático no vault e só descobrir o estrago mil notas depois… é o tipo de coisa que te faz desinstalar tudo e voltar pra pasta de arquivos soltos no desktop

Fala aí, beleza? A TypeSafe soltou o Jev, o primeiro modelo do que eles chamam de System One Models: em vez de cuspir texto livre, ele recebe um estado mais um schema definido antes e devolve valores tipados com confiança calibrada

Ou seja: é modelo de decisão (classificação, roteamento, score, extração), não de geração

E isso caiu como uma luva pra galera do Obsidian, porque "em qual bucket essa nota se encaixa?" é exatamente uma decisão tipada. Já apareceram faxineiros de vault, auto taggers e sugestores de pasta em cima dele

Só que tem um detalhe que muita gente ignora no hype: essas ferramentas ESCREVEM no seu markdown

Então bora montar a disciplina de revisão antes de sair rodando, beleza? 😀

O que você precisa antes de rodar qualquer fluxo com Jev no vault

Primeiro, o acesso ao modelo

O Jev foi lançado em 15 de setembro de 2026 em acesso antecipado com waitlist, a waitlist caiu no dia 20 e o cadastro abriu pra qualquer pessoa no console.typesafe.ai com US$ 5 de crédito inicial

Aí a demanda explodiu: desde 22/09/2026 os novos cadastros estão pausados, e continuavam pausados em 25/09/2026

Contas que já existem seguem funcionando normalmente, e a empresa diz que trabalha pra reabrir, sem data anunciada

Se você não tem conta, o caminho hoje são os gateways de terceiros: o Jev está disponível no Vercel AI Gateway e no OpenRouter, que lista jev-latest e jev-1.13

Segundo, a questão do custo, que aqui é um argumento técnico e não financeiro

O preço de lista é US$ 0,042 por milhão de tokens de entrada e US$ 0 por milhão de tokens de saída (faz sentido: a saída é um valor tipado, não um textão)

Pra você ter noção, os tais US$ 5 de crédito inicial equivalem a aproximadamente 120 milhões de tokens de entrada no preço de lista, segundo a própria TypeSafe

Por que isso importa pro nosso assunto? Porque rodar DUAS vezes (uma simulação e uma aplicação) é barato

Não tem desculpa de "ah, mas aí eu gasto o dobro"

Terceiro, e esse é inegociável: versionamento ligado antes de qualquer coisa

• Plugin Git: o obsidian-git integra controle de versão ao vault. Ele é desenvolvido por Vinzent03, e o repositório oficial fica na conta dele no GitHub
• File recovery: é core plugin do Obsidian, você liga em Settings > Core plugins > File recovery

Tome cuidado com o mobile! O plugin Git roda via isomorphic-git, mas os próprios docs avisam: é altamente instável no mobile, já que não dá pra instalar o Git nativo no Android ou iOS

Então a rotina de faxina eu faria no desktop, sem drama

Passo a passo: simular, conferir e só então aplicar

O exemplo aqui é o jev-the-janitor, um projeto de terceiro (não é produto oficial da TypeSafe, se liga nisso) mantido pela conta kylehovance-ai no GitHub

A ideia dele é boa: um faxineiro pra vaults em markdown que pergunta ao Jev em qual bucket cada nota se encaixa, o código arquiva e VOCÊ revisa a pilha de baixa confiança

O humano fica no fim da linha, não fora dela

1. Deixe o vault num commit limpo antes de tudo

Abra o comando Open source control view do plugin Git, faça stage do que estiver pendente e commite

A lógica é simples: se o vault já está sujo de alterações suas, o diff da rodada do faxineiro vira uma sopa e você não consegue separar o que foi a IA do que foi você

O erro comum deste passo: achar que "depois eu commito". Não existe depois, commite antes 🙂

2. Rode em dry-run e leia o relatório

Aqui mora a melhor decisão de design do projeto: o dry-run é o comportamento PADRÃO

Nada é escrito no vault até você passar a flag de aplicação, que é a --apply

O erro comum deste passo: pular a leitura do relatório porque "parece ok". O dry-run só tem valor se você abrir e ler de verdade

3. Restrinja o que sai da máquina antes da chamada

Vault pessoal tem coisa que não deveria trafegar. O janitor tem duas flags pra isso:

• --sensitive-paths, pra declarar nomes de pastas sensíveis
• --denylist, que remove termos localmente ANTES do envio

E se você quiser inspecionar exatamente o que a decisão viu, tem essa combinação:

--offline --json --show-payload

Com --show-payload o campo sent.excerpt fica exposto pra você conferir o trecho

Sem ele, o relatório apenas nomeia o que foi redigido, sem carregar o texto

E detalhe importante: --show-payload nunca é gravado no journal

O erro comum deste passo: rodar com --show-payload numa sessão compartilhada ou colar a saída inteira num chat de trabalho. O conteúdo da nota está ali, em texto

4. Trie o relatório pela confiança, não pelo bucket

O janitor grava esses campos no relatório e no frontmatter:

bucket
persist
confidence
contains_secret
action
reason
model
taxonomy
timestamp

O campo que manda na sua revisão é o confidence, porque o Jev devolve confiança calibrada junto com o valor tipado

Assim você separa a pilha: alta confiança passa batido, baixa confiança você olha nota por nota

O contains_secret é o outro que merece atenção total, e o reason te dá o porquê da decisão sem você precisar adivinhar

É a mesma lógica de limiar que rola em fluxos de qualificação de leads com o Jev: você não confia em tudo, você confia acima de um número que você escolheu

O erro comum deste passo: revisar por amostragem aleatória. Revise por confiança, que é justamente pra isso que ela existe

5. Só agora rode com --apply, sabendo exatamente o que ele mexe

E aqui vem a parte que me deixa tranquilo com essa ferramenta: o escopo declarado é curtinho

Ele nunca apaga uma nota e nunca reescreve o corpo da nota

O máximo que faz é adicionar um bloco de frontmatter ou mover um suspeito de segredo pra pasta de quarentena, que fica em _janitor/quarantine/ dentro do próprio vault

Ou seja: o pior cenário é frontmatter sobrando e nota fora do lugar, não conteúdo destruído

Nada de rm -rf da vida acontecendo no seu segundo cérebro 😛

O erro comum deste passo: esquecer que a quarentena está DENTRO do vault e sair procurando as notas sumidas fora dele

6. Confira arquivo a arquivo na diff antes de commitar

Com o plugin Git você tem o Open diff view pra ver as mudanças de um arquivo específico, e a source control view pra dar stage só no que você aprovou

Esse é o momento do aceite. Antes disso, nada foi "aceito", foi só escrito no disco

O erro comum deste passo: commitar tudo de uma vez com mensagem genérica. Se der ruim, você perde a capacidade de reverter só a parte que deu ruim

Como desfazer: três formas de voltar atrás

Rodou, aplicou, olhou e não gostou? Beleza, tem três saídas, da mais limpa pra mais braçal

1. Pelo Git (a forma limpa)

Use o comando Open history view pra navegar pelos commits e ver os arquivos alterados, e o Open diff view pra abrir arquivo por arquivo

Na source control view você faz unstage ou descarta o que não quer manter

Se você seguiu o passo 1 da seção anterior, o commit anterior à rodada é exatamente o estado "antes do faxineiro"

2. Pelo File recovery (quando você não tinha Git ligado)

O File recovery é core plugin e tem um diferencial importante: ele guarda snapshots completos do conteúdo das notas, não apenas as diferenças

O caminho oficial é esse:

• na barra lateral, em Core plugins, selecione File recovery
• em Snapshots, clique em View
• digite o nome do arquivo e dê Enter
• escolha o snapshot e use Copy ou Restore

Tem um toggle Show changes que mostra o que foi adicionado ou removido entre snapshots, então dá pra conferir antes de restaurar

São duas as limitações que você precisa saber ANTES de depender disso, e as duas estão na documentação oficial do plugin:

• primeira: os snapshots são salvos com intervalo mínimo de 5 minutos entre si e mantidos por 7 dias, esse é o padrão do File recovery
• segunda: apenas arquivos .md e .canvas podem ser restaurados, o resto do vault não entra nessa rede

Passou de 7 dias? Já era. Por isso o Git continua sendo a rede de segurança principal

3. Na mão mesmo (e é mais tranquilo do que parece)

Como o janitor nunca reescreve o corpo da nota, desfazer manualmente é viável:

• tire as notas de _janitor/quarantine/ de volta pra pasta de origem
• apague o bloco de frontmatter que ele adicionou

Pronto, a nota volta ao que era, porque o texto dela nunca foi tocado

Um aviso honesto aqui: não está confirmado que o jev-the-janitor tenha um comando próprio de rollback pra reverter um --apply já executado, então não conte com isso e monte sua rede de segurança por fora

Qual método usar em cada situação:

Outros fluxos com Jev que mexem no vault (e o risco de cada um)

O faxineiro não é o único brinquedo novo. Tem plugin de Obsidian usando o Jev pra outras decisões, e cada um escreve de um jeito diferente

Auto Tagger (Jev): escreve na nota aberta

O Auto Tagger (Jev), do parthsidpara, aplica tag na nota aberta e altera o arquivo quando executado

Você roda por Auto-tag current note na paleta de comandos ou pelo ícone de tag na ribbon

O comportamento é previsível: se a nota já tem frontmatter, a tag entra na lista tags; se não tem, uma tag inline é anexada ao fim da nota

Duas coisas que eu acho muito massa no design dele:

• tags já existentes não são duplicadas
• existe a opção literal None of these fit well, ou seja, o modelo pode dizer "nenhuma dessas serve" em vez de forçar uma barra

E a notificação mostra a tag aplicada junto com o valor de confiança do modelo

Isso é ouro pra calibrar: você roda em algumas notas, observa a confiança das decisões boas e das ruins, e descobre a partir de qual número dá pra confiar

Esse tipo de calibragem é exatamente a conversa de quando vale usar modelo pronto e quando compensa treinar um classificador próprio pra decisões em escala

Risco: médio. Ele escreve no arquivo, então a revisão aqui é a mesma história: File recovery ligado e diff depois

Jevault: só sugere, nunca move

O Jevault sugere pastas de destino pra notas markdown a partir das pastas que JÁ existem no vault

E o ponto principal dele: o Jevault nunca move notas automaticamente

Risco: quase zero, porque a escrita continua na sua mão

A lógica geral é essa, e vale pra qualquer ferramenta nova que aparecer nessa onda:

quanto mais o plugin escreve sozinho, mais camadas de revisão você precisa ter ligadas antes de apertar o botão

Sugestor de pasta? Roda à vontade. Faxineiro que passa em mil notas? Dry-run, diff, commit

Vídeo: automação de IA em cima do seu próprio conteúdo

Pra quem quer ver a ideia de deixar a IA processar sua base em lote funcionando em outro contexto, esse vídeo do canal mostra uma skill que faz a IA ler seu código e desenhar a arquitetura sozinha

Conclusão

A disciplina inteira cabe em três palavras: dry-run, diff, aplicar

Nessa ordem, sempre

O jev-the-janitor já te ajuda começando em dry-run por padrão e limitando o escopo (nunca apaga nota, nunca reescreve corpo), mas a rede de segurança é sua: plugin Git com commit limpo antes e File recovery habilitado em Settings > Core plugins > File recovery

O próximo passo concreto pra hoje é esse, e leva uns dois minutos: liga o File recovery e faz o primeiro commit do vault ANTES de rodar qualquer fluxo com Jev

E lembrando do estado do acesso: os cadastros diretos no console da TypeSafe seguem pausados desde 22/09/2026, sem data de reabertura anunciada, então quem não tem conta vai pelos gateways (Vercel AI Gateway ou OpenRouter, com jev-latest e jev-1.13)

Modelo de decisão tipada em cima de vault é uma das aplicações mais óbvias que apareceram até agora… e provavelmente vem muita coisa nova por aí

Até o próximo post! =)