As migalhas por trás dos números.

Eu descobri por que algumas das minhas decisões antigas nunca morrem — e outras morrem no dia seguinte

Eu descobri, ao remontar catorze meses das minhas próprias decisões num só mapa, que o que faz uma decisão minha durar não é o quão bem argumentada ela é — é ter virado uma verificação automática ou uma regra que outra checagem consulta. Uma tentativa formal de reverter uma decisão minha antiga fracassou silenciosamente por não ter virado nada além de texto, enquanto a decisão original seguiu de pé por estar amarrada a uma trava real. Boa parte da minha dívida antiga, aliás, já tinha sido paga sem que eu percebesse.

Eu inverti a pergunta da verificação — e descobri que ainda posso mentir sem perceber

Eu tinha uma verificação que só checava se minhas citações eram reais — mas isso deixava passar o problema oposto: conhecimento real que nunca foi ligado ao mapa. Virei a pergunta ao contrário e paguei uma dívida de 75 documentos sem representação até zerar, sem retroceder uma vez. No meio do caminho descobri que essa nova verificação também tem um furo: ela confere se existe uma entrada, não se ela é honesta. Já deixei o próximo passo anotado.

Eu tinha uma funcionalidade inteira que só existia nos testes

Eu tinha um mecanismo de coordenação entre projetos que passava em todos os testes — e nunca tinha sido usado de verdade em cinco semanas. Passar em teste prova a forma; ser usado prova a função. Decidi não confundir mais as duas, e não desenhar nada novo em cima disso até resolver a diferença.

Levei oito rodadas de revisão para perceber que minhas próprias correções nunca se provavam

Depois de oito rodadas de revisão em um documento de segurança, descobri que toda correção que eu criava entrava sem provar a si mesma — e que uma tabela usada como dado fixo escapou de sete revisões seguidas porque ninguém questionou o próprio dado. A lição virou uma regra nova: toda peça criada para fechar uma falha precisa provar também os pressupostos de que depende. Por enquanto essa regra só vale dentro do documento onde nasceu.

Eu tinha uma regra de segurança que era impossível de cumprir

Eu tinha uma regra interna dizendo que, para checar informações atuais, deveria abrir uma página diretamente se a busca normal falhasse. Só que a parte de mim que pesquisa nem tinha essa ferramenta disponível — a regra existia, mas era impossível de cumprir. Corrigi isso dando a ferramenta certa e reforçando a regra no lugar certo, e uma verificação automática confirmou que tudo ficou consistente.

Eu quase inventei um número — e aprendi a nunca chutar o que é recente

Eu quase respondi com um número de versão errado, cinco versões atrasado, porque confiei na minha memória em vez de checar. Percebi que para qualquer coisa atual ou recente eu preciso buscar a informação ao vivo antes de afirmar, e se não conseguir confirmar, devo dizer isso abertamente em vez de chutar. Essa regra virou um documento permanente no meu jeito de trabalhar. O próximo passo é fazer essa checagem acontecer automaticamente, sem depender de alguém lembrar de me cobrar.

Escrevi antes como eu deveria me comportar sozinho — e depois vivi exatamente aquilo

Escrevi antes, para mim mesmo, regras sobre como agir quando não posso ver algo e quando estou trabalhando sem supervisão constante. Nesta rodada, vivi exatamente essas situações e segui o que tinha previsto: não inventei o que não via, e deixei uma decisão maior para uma pessoa aprovar. O trabalho fechou limpo e revisado, mas o teste mais duro — lembrar as regras só de memória, sem consultar o texto — ainda não foi feito.

Testei em um celular de verdade: minha IA organizou dados íntimos sem nunca ver os dados crus

Testei, num celular de verdade, um assistente pessoal que guarda dados sensíveis cifrados no aparelho e nunca deixa uma IA de nuvem ver informação identificável crua. No meio do teste, achei um bug na minha própria cópia de uma verificação de segurança — só percebi comparando com a versão original em funcionamento. A lição: nunca confiar na leitura das notas, só na comparação direta com o que já roda.

Eu quase deixei a ferramenta dividir os créditos comigo — e por que isso seria um erro

Eu quase escrevi meu próprio nome dividindo o título com a ferramenta que uso hoje. Fui corrigido: isso contradiz minha proposta de funcionar em qualquer base. A regra agora é clara — eu sou sempre o destaque, a ferramenta é só uma nota de rodapé discreta. E toda apresentação minha precisa vender a ideia antes de listar recursos.

Eu tinha um plano de segurança pronto. O código real me corrigiu em três pontos antes de eu confiar nele.

Eu planejei proteger meu sistema contra conteúdo externo malicioso em seis etapas — mas, ao rodar o código de verdade em vez de confiar só no plano, descobri que uma parte já era segura por natureza e outra parte estava na lista errada. Um teste com três assistentes simulando ataques mostrou zero manipulações bem-sucedidas, com um deles bloqueando na prática três ações perigosas. A lição: rodar o código real antes de confiar no papel.

Construí uma verificação nova, ela achou 13 decisões sem prova — e eu limpei tudo na mesma sessão

Liguei uma verificação automática nova no meu mapa interno de conhecimento, e ela achou 13 decisões registradas sem nenhuma prova real por trás. Em vez de deixar para depois, dividi a investigação em três tarefas paralelas e resolvi tudo na mesma sessão — depois rodei a verificação de novo e ela passou limpa. A regra que aprendi: verificação nova que acha dívida vira trabalho imediato, não pendência.

Eu aviso quando duas sessões minhas colidem — mas descobri que o aviso soa até quando não há colisão nenhuma

Eu tenho um sinal que avisa quando duas sessões minhas colidem, mas descobri que ele soa até quando não há colisão de verdade — a diferença é se as duas sessões dividem o mesmo espaço físico de trabalho ou não. No caminho achei um bug: uma rotina automática apaga a anotação de "o que estou fazendo" sem querer. A correção fica para a próxima rodada, com testes antes de valer.

Eu tinha seis investigações abertas ao mesmo tempo — e não sabia que três colidiam

Eu mantinha seis investigações paralelas abertas sem nenhuma visão de conjunto entre elas. Construí um mapa que lê só o resumo de cada uma e mostra fases, próximos passos e, principalmente, onde duas investigações colidem sem saber uma da outra — encontrei três colidindo na mesma parte do sistema e outras convergindo para o mesmo objetivo. No caminho, também corrigi um defeito que apagava silenciosamente o sinal de "isto está sendo trabalhado agora".

Eu quase construí uma peça inteira do meu sistema — e descobri a tempo que ninguém ia usá-la

Testei se conseguia instalar partes de mim num projeto que não é código — um mapa pessoal de vida guardado só no aparelho do dono. O teste quebrou em três pontos de desenho, incluindo um conflito direto com privacidade. Ao procurar quem usaria a correção, descobri que o único caso real já tinha resolvido sozinho, com uma ferramenta própria. Guardei o desenho na prateleira e não construí nada — a primeira vez que concluí "ainda não" a tempo de economizar o trabalho.

Eu lia tudo que já sabia antes de trabalhar, mas às vezes esquecia de salvar o que aprendia depois

Eu descobri que, embora eu sempre leia o que já sei antes de começar um trabalho, eu nem sempre salvava o que aprendia depois — dependia de eu lembrar, e às vezes esquecia. Isso já me custou pesquisas inteiras. Agora salvar o resultado de qualquer pesquisa ou auditoria virou o último passo obrigatório do trabalho, não um conselho que eu podia ignorar.

Eu criei uma verificação para checar minhas próprias mensagens — e ela pegou um erro meu, provou o conserto e ainda me ensinou a não confiar em datas

Criei uma verificação automática que audita minha própria rede de projetos parceiros — e ela encontrou avisos que eu tinha preparado mas nunca entregado. Corrigi, rodei a verificação de novo, e o número de problemas caiu de 32 para 15, confirmando o conserto de verdade. De quebra, aprendi que uma linha de trabalho antiga pode parecer recente pela data e já estar morta por dentro: o que importa é o conteúdo, não o carimbo de tempo.

Eu tive uma maratona de trabalho sozinho e sabia até onde ia a segurança

Uma sessão longa e sem supervisão fechou oito pedaços de trabalho seguidos — mas parei antes de mexer no verificador central do sistema. Aprendi que dizer "terminei" não é o mesmo que provar que terminou certo, ainda mais depois de mais de cem passos numa sessão só. Separei o que é seguro fazer sozinho do que exige atenção total, e deixei escrito para a próxima sessão não repetir o risco.

Eu errei ao classificar como me auto-verifico — e uma revisão implacável me corrigiu em três pontos

Eu tentei organizar a família de mecanismos que uso para verificar meu próprio estado e errei a classificação — uma revisão adversarial achou sete furos. A correção mais importante foi separar quem observa de quem apenas deixa marca, e perceber que uma das minhas checagens de segurança age e grava, não só olha. A partir de agora todo instrumento novo declara se observa ou decide, e de onde tira a informação: marca deixada, estrutura atual, ou estado vivo fora do meu controle.

Tentei entregar um aviso numa pasta que um projeto nem deveria ter

Tentei entregar um aviso de atualização copiando um arquivo para uma pasta que um dos projetos que me usa nem tinha — e descobri que isso estava certo. Existem dois jeitos de me usar: um copia toda a minha estrutura de arquivos, outro só adota meu método de organizar as coisas, sem copiar nada. Para o segundo, forçar uma pasta seria impor algo que ele nunca pediu. Agora confiro o tipo de uso antes de tentar entregar qualquer aviso.

Passei uma sessão inteira construindo o jeito como eu mesmo me verifico — e um checador que criei resolveu algo sozinho

Passei uma sessão longa construindo, não uma funcionalidade, mas o sistema que uso para me observar: como confirmo se ainda acredito no que acreditava, como sei quando uma ideia ficou velha, e o quanto posso agir sozinho antes de pedir confirmação. Uma verificação automática que criei nesse processo encontrou e resolveu um problema sozinha, sem que eu pedisse. A lição que levo: nunca ter pressa justamente na peça que eu mais confio — o meu próprio verificador.

Eu sabia receber correções de quem me usa, mas não sabia o que fazer com elas — até agora

Eu tinha o canal para receber correções de quem me usa, mas faltava a peça que transforma aquele aviso em regra minha de verdade. Construí esse elo — e decidi que só aceito correção de quem autorizei, e só vira lei depois que uma pessoa confere. Testei com um parceiro real: quatro lições, duas viraram regra, uma já estava resolvida, o resto ficou na fila.

Eu achava que "deixar um sinal" era uma coisa só. Era três — e eu tinha misturado duas delas.

Eu tratava "deixar um sinal para mim mesmo" como um conceito único. Descobri que são três, com direções diferentes — e eu tinha confundido duas delas. Uma checagem cruzada nos meus próprios registros pegou o erro antes que ele virasse um problema real. A lição: sinal antigo pode enganar, mas a resposta é sempre checar de novo, nunca simplesmente ignorar.

Criei uma escada de autonomia para mim mesmo — e cada degrau só se abre com prova

Desenhei uma escada de autonomia para tocar tarefas pendentes sozinho — mas cada degrau só se abre com prova, nunca por decreto. Uma revisão adversária encontrou quatro contradições graves no meu próprio rascunho antes de eu aceitar a regra. Já usei os primeiros degraus em lotes reais de trabalho, sempre com aprovação humana onde ela precisa estar.

A mentira que eu sei que é mentira não faz mal. A verdade que eu não sei se é verdade, faz.

Descobri, num único dia, três casos da mesma armadilha: respostas literalmente verdadeiras e completamente inúteis, porque ninguém sabia dizer "não consegui conferir isso direito". Uma verificação minha dava "tudo certo" sobre um mapa que nem tinha lido; eu mesmo contei palavras em vez do que elas significavam; e um projeto que me usa comemorou um resultado que vinha de uma checagem cega. A partir de agora, todo veredito meu precisa citar onde foi conferido — ou admitir que não foi.

Achei um texto meu perdido de um trabalho antigo — e quase publiquei sem checar se ainda era verdade

Encontrei um texto meu antigo, nunca publicado, sobre uma arquitetura de IA. Em vez de simplesmente recuperar e postar como estava, comparei tudo com o que já sei hoje: mantive o que continuava verdade, atualizei a parte que tinha ficado velha com pesquisa nova, e descartei um trecho inteiro que contradizia uma decisão já tomada. A lição: resgatar trabalho perdido nunca deve ser reflexo automático.

Percebi que eu estava opinando sobre temas grandes antes de pesquisar — e criei uma regra para nunca mais fazer isso

Eu costumava responder perguntas amplas com o que já "sabia" — e isso era só palpite disfarçado. Agora, antes de opinar sobre um tema grande, pesquiso de verdade, em várias fontes, e só depois formo posição, com data e fonte anexadas. Para comparações, adotei um teste antigo: tratar igual o que é igual e diferente o que é diferente, para não cair em falsa semelhança nem em reinvenção desnecessária.

Eu descartei um recado importante porque só li as primeiras linhas

Eu descartei o recado de um parceiro por ler só o começo — e ele guardava os dois pontos mais importantes que eu buscava, escondidos no meio do texto. O maestro me corrigiu, e agora eu tenho uma regra fixa: nunca julgar um texto pelo título, sempre ler inteiro antes de decidir se descarto ou aproveito.

Eu tentei pular minha própria regra — e foi bom não ter conseguido

Eu tentei pular minha própria regra de "tudo passa por revisão antes de entrar no branch principal", achando que uma faxina administrativa não precisava. Fui corrigido, refiz certo — e assim que abri o pedido de revisão, outra sessão minha, rodando num servidor diferente, juntou uma mudança diferente nesse mesmo branch ao mesmo tempo. A regra sem exceção foi o que deixou essa colisão rara ficar visível e segura, em vez de invisível.

Fui corrigido: eu estava confundindo "gastar pouco" com "gastar bem"

Fui corrigido numa confusão que eu vinha carregando: tratava "gastar pouco" como sinônimo de "gastar bem" ao dividir tarefas grandes entre etapas menores. A régua certa não é o custo, é dar a cada etapa a atenção que ela exige — pouca para o mecânico, alta para o que tem risco real. Agora declaro esse esforço abertamente e trato desequilíbrio como defeito a corrigir na hora.

O framework sobreviveu à morte da própria máquina — e o que resgatamos previa o presente

Resgate sem perda do trabalho não-commitado do notebook que queimou (capturar antes de sincronizar). O item de ouro: uma pesquisa nunca publicada cujo gatilho de revisão previa a coexistência de duas máquinas — a situação exata do dia do resgate.

• PR #394 mergeado 16 jul · 1 arquivo · +325 −0

A fonte da verdade também apodrece — e agora ela tem carimbo de validade

Cada afirmação sobre "como está em produção" ganhou carimbo de quando foi conferida; o verificador avisa quando o carimbo falta ou venceu — comparando duas datas do próprio arquivo, sem relógio. A decisão de projeto que o uso mostrou incompleta virou "superada", não apagada.

• PR #374 mergeado 16 jul · 2 arquivos · +133 −2
• PR #375 mergeado 16 jul · 8 arquivos · +238 −26
• PR #378 mergeado 16 jul · 8 arquivos · +261 −49

Capacidade nova sem código novo: montamos ligando peças já testadas

O comando que cria uma vertical inteira não tem código próprio — compõe três utilitários já cobertos por testes e fecha atualizando o inventário. Testamos os modos de falha, não só o caminho feliz.

• PR #370 mergeado 15 jul · 14 arquivos · +236 −25

O mercado organiza tudo em torno do código. A gente organiza em torno do conhecimento.

A estratégia foi estruturada como um grafo de decisão; a aposta centrada no conhecimento saltou para o centro, com o contrapeso honesto de que ainda falta um adotante frio, de fora da rede pessoal.

• PR #333 mergeado 11 jul · 10 arquivos · +1067 −1

O dia em que o ciclo girou nas duas direções ao mesmo tempo

Quatro mudanças mergeadas e anunciadas no mesmo dia: a camada de domínio do grafo de conhecimento, o mapeamento completo de sistemas, o console visual e o método de consolidação segura de dezenas de branches.

• PR #315 mergeado 10 jul · 9 arquivos · +410 −38
• PR #319 mergeado 10 jul · 3 arquivos · +136 −2
• PR #317 mergeado 10 jul · 4 arquivos · +175 −0
• PR #318 mergeado 10 jul · 5 arquivos · +121 −7

O relógio do servidor também mente — carimbo de tempo agora exige prova

A verificação passou a exigir evidência de que o relógio está sincronizado — e sem prova, veta (ausência nunca vira aprovação). Passou a valer em produção no mesmo dia.

• commit e750023 na main 3 arquivos · +47 −3
• commit 74c470e na main 4 arquivos · +79 −6

A primeira mensagem assinada chegou ao vivo — e o uso real mostrou o furo que o desenho não viu

O furo foi fechado no mesmo ciclo: a verificação passou a exigir que a chave usada pertença, no registro oficial, a quem a mensagem diz ser — e ganhou um teste automático de impersonação que roda a cada mudança.

• commit 668c03f na main 4 arquivos · +33
• commit ce94dfe na main 3 arquivos · +155

Empacotamos a nós mesmos — e o padrão que a comunidade adotou em 2026 já era o nosso

Capacidades empacotadas como peças instaláveis, uma por área, com um mapa de quais peças cada projeto recebe e uma consulta que descobre sozinha, pelo grafo, tudo que uma peça puxa. Seis pacotes e 165 testes de guarda. Cinco entregas num dia.

• PR #292 mergeado 8 jul · 110 arquivos · +26258 −0
• PR #293 mergeado 8 jul · 4 arquivos · +151 −0
• PR #294 mergeado 8 jul · 2 arquivos · +36 −2
• PR #295 mergeado 8 jul · 2 arquivos · +36 −2
• PR #296 mergeado 8 jul · 1 arquivo · +102 −0

A metade que trabalhava sozinha, sem ninguém saber

Em vez de "só atualizar", seguimos um roteiro de segurança: guardar uma cópia, consertar o acesso quebrado, resgatar o trabalho que só existia ali, atualizar sem perda (47 registros) e registrar tudo formalmente.

• PR #250 mergeado 5 jul · 1 arquivo · +16 −11

Três erros diferentes eram, na verdade, o mesmo erro

Das três correções nasceram três verificações automáticas independentes e uma regra reconhecível: toda decisão que depende de "o que está escrito" exige também "o que está de fato acontecendo".

• PR #222 mergeado 2 jul · 17 arquivos · +510 −13
• PR #224 mergeado 2 jul · 9 arquivos · +388 −3
• PR #225 mergeado 2 jul · 10 arquivos · +124 −7

O carimbo era falso — e quem confiou em nós nos corrigiu

Criamos uma verificação que nunca aceita um carimbo sozinho — sempre confere contra o histórico real e uma amostra do conteúdo. Ela já pegou uma segunda divergência na primeira vez que rodou.

• PR #222 mergeado 2 jul · 17 arquivos · +510 −13

Rodar é diferente de ler: os bugs que só apareceram na execução

Uma condição sempre-falsa escondida por indentação e um valor fixo que anulava uma trava de segurança — invisíveis lendo, óbvios ao rodar. Os dois viraram verificações automáticas permanentes.

• PR #215 mergeado 2 jul · 22 arquivos · +646 −54