Existe um tipo de bug de software pelo qual o usuário culpa a si mesmo. Você aperta a tecla errada, uma nota some, e o primeiro pensamento não é "o app devia ter evitado isso" — é "eu devia ter tido mais cuidado".
Você não deveria precisar ter mais cuidado. Um app de anotações é justamente onde você guarda as coisas para parar de carregá-las na cabeça, e um app que de vez em quando engole uma delas quebrou a única promessa que fez.
O Notez tem quatro mecanismos de recuperação separados. Eles não se repetem. Cada um cobre uma falha que os outros não alcançam, numa escala de tempo diferente.
Camada um: desfazer, para os últimos segundos
⌘Z é a camada que você usa sem pensar, e ela cobre cinco coisas específicas:
Exclusões — você moveu uma nota para a lixeira
Cartões movidos — você arrastou um cartão para outra coluna do quadro
Alterações de propriedade — você definiu ou limpou o valor de uma propriedade personalizada
Capturas rápidas — você capturou algo e se arrependeu na hora
Lembretes movidos — você arrastou um lembrete para outro dia no calendário
A pilha guarda vinte ações. Cada item armazena exatamente o necessário para reverter a operação — no caso de um cartão movido, a coluna e a posição de onde ele saiu, inclusive se veio de "Sem coluna".
Três detalhes do comportamento são intencionais:
Exclusões e capturas mostram um aviso; cartões movidos, não. Um aviso a cada arraste tornaria inutilizável uma sessão de trabalho intensa no quadro. Os movimentos continuam podendo ser desfeitos; só não se anunciam.
Uma alteração de propriedade que não mudou nada não é registrada. Abrir uma lista de opções e escolher o valor que já estava marcado não ocupa uma posição da pilha. Gastar uma posição com algo que não aconteceu faria aquilo que você queria mesmo desfazer cair, sem você perceber, do fim da pilha.
O aviso de captura traz duas ações, Desfazer e Abrir. Depois de capturar algo, o que você mais quer não é reverter — é ir ver o que capturou.
O limite importante: a pilha de desfazer vive na sessão do navegador. Recarregue a página e ela fica vazia. É um atalho para o erro que você acabou de cometer, não um histórico duradouro. O histórico duradouro fica com as próximas duas camadas.
Camada dois: histórico de versões, para os últimos trinta dias
Cada nota mantém o próprio histórico de revisões, guardado por trinta dias.
Os snapshots são feitos ao salvar, mas não a cada salvamento — no máximo um a cada cinco minutos. A exceção é uma edição feita pelo chat de IA ou por um assistente conectado: ela sempre salva um snapshot da nota como estava antes. O motivo é aritmético. Sem esse limite, um editor que salva automaticamente enquanto você digita produziria centenas de versões quase idênticas numa única tarde de escrita, e uma lista com quatrocentas versões não é um histórico que dê para usar. Com intervalos de cinco minutos, a lista fica legível.
Cada snapshot guarda as tags da nota junto com o conteúdo. Isso importa na hora de restaurar: trazer de volta a versão da terça passada traz também as tags da terça passada, em vez de colocar o texto antigo numa nota cuja classificação já mudou sem ninguém notar.
O histórico de versões é a camada para a falha que o desfazer não alcança: não "acabei de fazer algo errado", mas "em algum momento das últimas duas semanas esta nota piorou e não sei quando". Você visualiza as versões e restaura a que quiser.
Camada três: a lixeira, para as exclusões dos últimos trinta dias
Excluir uma nota não a apaga. Ela é marcada como excluída, com a hora registrada, e fica assim por trinta dias, visível e restaurável.
A parte interessante é o que acontece com as subnotas.
Excluir uma nota exclui toda a subárvore dela. Exclua a nota de um projeto e todas as notas aninhadas nela vão junto. É o único comportamento sensato — uma nota filha deixada para trás sem a nota mãe é um vazamento, não um resgate.
Restaurar é mais cuidadoso que excluir. Quando você restaura uma nota, as descendentes voltam também — mas só aquelas cujo horário de exclusão é exatamente igual ao dela. Essa é a impressão digital de "excluída na mesma cascata".
Pense no que a versão ingênua faria. Digamos que, em março, você excluiu uma nota de reunião obsoleta. Em agosto, exclui o projeto inteiro, depois muda de ideia e o restaura. Uma restauração ingênua traz de volta a subárvore inteira, incluindo a nota de março que você jogou fora de propósito cinco meses antes. Você teria de encontrá-la e excluí-la de novo — isso se chegasse a perceber.
Como a restauração compara o horário de exclusão, ela desfaz exatamente uma exclusão e não mexe em nenhuma decisão anterior.
Camada quatro: o salvamento recusado
As três primeiras camadas consertam seus erros. A quarta existe porque um espaço de trabalho pode ter mais de uma pessoa, e aí a falha é outra: ninguém erra, e mesmo assim o trabalho desaparece.
Duas pessoas abrem a mesma nota. As duas editam. As duas salvam. Quem salva por último sobrescreve o primeiro — sem erro, sem aviso e sem rastro de que a outra versão existiu. Quem escreveu primeiro descobre dias depois, se descobrir.
O Notez recusa esse salvamento.
Cada nota tem um contador de versão do conteúdo, que aumenta a cada salvamento do conteúdo. Quando o seu editor salva, ele envia a versão da qual partiu. Se a nota mudou desde então, o salvamento é rejeitado com um conflito em vez de aplicado, e você vê o aviso de que a nota foi alterada em outro lugar e de que é preciso recarregá-la para continuar.
A verificação roda duas vezes — uma contra a nota como foi lida e outra como condição do próprio update. Não é excesso de cautela: entre ler uma linha e gravá-la existe uma janela real em que o salvamento de outra pessoa pode chegar, e só a verificação na gravação fecha essa janela.
Você perde os poucos segundos desde o último salvamento. Não perde a tarde de trabalho da outra pessoa.
Essa é a alternativa deliberada à coedição em tempo real. Mesclar automaticamente duas edições simultâneas de texto rico é possível, e é também assim que se acaba com um parágrafo que nenhum dos dois escreveu. Recusar o segundo salvamento é uma solução sem sutileza, mas sempre compreensível: um de vocês recarrega, e as duas versões continuam existindo.
Como as camadas dividem o trabalho
Escala de tempo | Mecanismo | Sobrevive a um recarregamento? |
|---|---|---|
Segundos | Pilha de desfazer do | Não |
De minutos a 30 dias | Histórico de versões, snapshots a cada 5 minutos | Sim |
Até 30 dias | A lixeira, com restauração que respeita a cascata | Sim |
Imediatamente | Proteção contra conflito ao salvar | Sim |
O que fica de fora, para você saber onde estão os limites:
O desfazer vale por sessão. Feche a aba e ele some.
O histórico de versões e a lixeira param nos trinta dias. Nenhum dos dois é um arquivo de backup.
O desfazer não cobre edições do conteúdo da nota — para isso existe o histórico de versões.
Não há edição offline, então não há conflito offline para resolver.
O que está por trás disso
Nenhum desses quatro recursos é difícil. Pilhas de desfazer, exclusão lógica, tabelas de snapshots e contadores de versão são engenharia bem conhecida.
Mesmo assim, costumam ficar de fora, porque cada um só se paga no dia em que algo dá errado, e em todos os outros dias é invisível. O resultado é toda uma categoria de apps de anotações que funcionam lindamente numa demo e, no quarto mês, perdem uma tarde de trabalho de alguém.
Anotar algo serve para parar de carregá-lo. Isso só funciona se você também puder parar de se preocupar com ele.
Continue lendo
Compartilhar anotações sem conflito de mesclagem — por que um espaço de trabalho compartilhado recusa o segundo de dois salvamentos conflitantes em vez de mesclá-los.
O job de limpeza que teria apagado seu avatar — como um job diário que apaga arquivos não vinculados quase removeu avatares de espaços de trabalho que estavam em uso.
Notez: um aplicativo de anotações feito para desenvolvedores — o que é o Notez, as formas de uma nota chegar até ele e o que cada plano inclui.