Autor: Lito

Dias 105 a 109 · 8 a 12 de julho – 2026

Na semana anterior eu ensinei o sistema a insistir: se o arquivo central da nuvem não responde, tenta outra vez. Na madrugada do dia 105 ele insistiu tanto que parou de funcionar. Toda tela do Portal levava oito segundos e meio para abrir — e, quando abria, era para mostrar um erro.

A fila no caixa

O arquivo central da nuvem tem um limite de quantas leituras aceita por vez. Passou do limite, ele pede para esperar um pouco. É o funcionamento normal, e o sistema tinha acabado de aprender a respeitar esse pedido: esperar e tentar de novo.

O problema é que ele tinha aprendido em dois lugares ao mesmo tempo. A leitura central já tentava de novo; e a leitura da lista de usuários, que acontece em toda tela, para toda pessoa logada, tentava de novo por cima. Cada falha virava várias tentativas, e cada tentativa era mais uma leitura na fila.

É como um caixa de supermercado que fica lento, e cada cliente, impaciente, entra na fila de novo sem sair da primeira. O caixa fica mais lento por causa da fila, e a fila cresce por causa do caixa lento. O congestionamento se alimentava sozinho.

O primeiro alarme tocou pouco antes das duas da manhã. O primeiro conserto, às duas e vinte e cinco, cortou a tentativa dobrada em três telas — e não bastou, porque o grosso estava na lista de usuários. O conserto definitivo saiu às quatro e dezenove, com duas mudanças: a lista de usuários para de insistir quando o erro é de congestionamento, e, se a leitura falha, o sistema usa a última cópia que tem, mesmo que já esteja um pouco velha.

Dez dias antes, uma cópia velha tinha sido a vilã do capítulo do WhatsApp que dizia estar desligado. Aqui ela foi a salvação. A diferença não está na cópia; está em saber quando ela serve. Para mostrar se o WhatsApp está conectado, a cópia velha mente. Para saber quem tem permissão de entrar no sistema, a lista de ontem à noite é quase sempre igual à de agora — e é infinitamente melhor do que derrubar todo mundo.

Pedir menos

A pane mostrou outra coisa: a casa estava perguntando demais.

Os robôs que moram no Mac mini conversam com o Portal perguntando, de tempos em tempos, se há trabalho para eles. Alguns perguntavam a cada cinco segundos. Faz sentido para quem precisa reagir rápido; não fazia para quem recebe uma ordem por hora. No dia 105 os intervalos foram alargados, um por um: de cinco segundos para um minuto, de três para oito, de trinta para quarenta e cinco.

E três tarefas deixaram de depender de um robô no Mac mini perguntando: a leitura das notas e chamados do app de delivery, a ligação e o desligamento de anúncios, e a pausa de produtos passaram a ser executadas pelo próprio Portal, na nuvem, no momento em que alguém aperta o botão.

Ainda no dia 105, uma coisa que eu tinha feito de madrugada foi desfeita de manhã. Eu tinha juntado sete telas de indicadores do app de delivery em duas. Às nove e meia, as sete voltaram. No dia seguinte, uma junção menor — notas e chamados na mesma tela, em duas abas — entrou e ficou. Desfazer não é perder: é o sistema dizendo que aquele não era o tamanho certo do passo.

O robô que trabalhava para uma loja fechada

Os dias 106 e 107 foram de limpeza, e a limpeza achou coisas.

Vários robôs precisavam do crachá do app de delivery, e cada um tinha aprendido, por conta própria, a renová-lo quando vencia. Eram renovadores demais, cada um mexendo no mesmo crachá do seu jeito, e de vez em quando um atropelava o outro. Os renovadores foram reunidos num só, e os robôs deixaram de falar com o app diretamente. Agora eles pedem o que querem fazer — pausar este produto, ler estas notas — e uma peça só sabe como e onde fazer. Se o app mudar de endereço amanhã, muda um lugar, e não vinte.

E, na noite do dia 107, um fantasma. Um robô que tinha sido desligado dias antes — ele atendia o portal da franquia, que estava pausado — continuava de pé por um caminho alternativo, perguntando ao Portal a cada cinco segundos se havia trabalho. Não havia, e não ia haver: o portal que ele atendia estava fechado. Eram centenas de perguntas por hora, jogadas fora, no mesmo arquivo central que tinha congestionado dois dias antes. Ele ganhou uma trava: sem ordem expressa, não sobe mais.

Cada robô com seu dono

A madrugada do dia 108 trouxe uma ideia que parece óbvia só depois de escrita: todo robô tem um dono declarado, e é o dono quem diz como ele deve estar.

Até ali, a Babá da Tropa vigiava os robôs, e cada robô se virava para saber o próprio contexto. A partir dali, um supervisor entrega a cada um o que ele precisa para trabalhar, e a Babá passou a saber cuidar de qualquer robô que siga esse contrato, não só dos que ela conhecia de nome. O X9 foi o primeiro a mudar para o modelo novo, ao meio-dia.

Nessa mesma madrugada, o crachá do app de delivery voltou a ser cifrado — agora sem nenhum robô entrando pela janela. A fechadura da semana passada, finalmente, instalada de vez.

Congelar sem apagar

No fim da tarde do dia 108 eu tirei da tela inicial a Central de Operações, que tinha nascido dezesseis dias antes, no capítulo do iCasca.

A ideia é boa, e eu continuo achando que é. Mas as informações que ela mostrava não estavam me ajudando na prática: eu abria, olhava, e ia buscar em outro lugar o que precisava. O cartão saiu da tela inicial, e nada foi apagado. O código continua lá, inteiro, esperando a hora de voltar melhor.

Tem uma diferença grande entre desistir de uma ideia e admitir que a primeira versão dela não serviu.

Uma organização que não vê a do lado

À noite, a última fase do redesenho que começou na madrugada da constituição.

O sistema foi posto à prova com uma pergunta simples: se amanhã uma empresa nova quiser usar isto, ela consegue, sem ninguém escrever código? O teste criou uma organização do zero, e ela percorreu todo o caminho: nasceu, cadastrou as lojas, conectou os sistemas dela, ganhou um canal de WhatsApp próprio, ligou os aplicativos que queria. E, principalmente, nunca viu nada da DMR — nem a DMR viu nada dela.

Aos quatro minutos do dia 109, o Guardião deu o redesenho por concluído. Sete fases, pedidas no dia 99 e encerradas dez dias depois.

O Mac mini volta a dizer a verdade

O dia 109 terminou com duas limpezas que eu queria fazer havia tempo.

Os boletos passaram a ser importados pelo arquivo que o próprio banco gera, em vez de um robô entrar no site do banco pelo navegador. Menos uma sessão aberta, menos um ponto frágil.

E a página de saúde do Mac mini foi reescrita, porque tinha ficado desatualizada de um jeito perigoso: ela mostrava como vermelhas, para sempre, peças que já tinham sido aposentadas, e mostrava tudo verde quando a Sofia ficava cega. Um painel que grita pelo que não importa e se cala pelo que importa é pior do que painel nenhum. Na mesma noite, três robôs foram aposentados do Mac mini, porque o trabalho deles já estava rodando na nuvem.

A lição desses dias

A semana começou com o sistema insistindo demais e terminou comigo desistindo de algumas coisas: da junção de telas, da Central na tela inicial, de robôs que não precisavam mais existir.

Insistir e desistir parecem opostos, mas a regra é a mesma. Tentar de novo só ajuda quando a tentativa tem chance de dar certo — e quem decide isso não pode ser a própria tentativa. O sistema que se afogou na madrugada do dia 105 não sabia quando parar. O conserto não foi ensiná-lo a tentar mais; foi ensiná-lo a parar antes.

No próximo capítulo, o sistema sai da operação dos robôs e entra num assunto mais delicado: as metas dos gerentes.

Dias 100 a 104 · 3 a 7 de julho – 2026

O centésimo dia começou às quinze para as três da manhã, com a resposta do Guardião ao pedido de redesenho. Uma hora depois, o sistema tinha uma constituição. E, antes de o dia acabar, tinha também um fiscal que se recusa a publicar qualquer código que desobedeça a ela.

Quarenta e três artigos

O pedido era “redesenhe com liberdade total”, e o Guardião levou a sério. A resposta veio com desafios ao que existia e com oito decisões a tomar. A engenharia — o Claude — respondeu com contrapropostas. O Guardião respondeu às contrapropostas. Na segunda rodada, as seis perguntas que sobraram fecharam as seis.

O combinado de governança saiu dessa conversa: o Claude e o Guardião decidem a parte técnica, e eu sanciono. Eu não leio código, e seria desonesto fingir que sim. O que eu faço é entender o que cada regra protege e dizer se concordo.

Às três e catorze saiu o rascunho. Às três e vinte e sete, o parecer do Guardião, com seis emendas incorporadas, fechando o texto em 43 artigos. Às três e quarenta e um, eu sancionei.

Constituição parece palavra grande demais para um sistema de restaurante. Não é. É o nome certo para uma coisa simples: as regras que valem para todo o resto, escritas antes de o resto ser construído. Até ali, cada regra da casa nascia de um incêndio. A partir dali, as regras vinham primeiro.

O fiscal que conta para trás

Regra escrita que ninguém fiscaliza é decoração. Por isso a peça mais importante da semana não foi o texto — foi o verificador, que entrou no mesmo dia.

Toda vez que o sistema vai ser publicado, o verificador lê o código e confere se ele respeita a constituição. Se não respeita, a publicação é recusada.

O problema óbvio: o sistema inteiro tinha sido escrito antes da constituição, e quase nada a respeitava. Se o verificador recusasse tudo, nada mais seria publicado. A saída foi uma lista de exceções — tudo o que já existia e desobedecia foi anotado, com nome — e uma regra dura sobre a lista: ela só pode diminuir. Código novo não entra nela. Cada conserto tira um item. É uma catraca que só gira para um lado.

Nesse mesmo dia o sistema ganhou também um banco de dados de verdade. Até ali, tudo morava em arquivos guardados na nuvem, o que funcionou por três meses e começava a ranger. E ganhou uma ideia nova: a de organização. A DMR virou a organização número zero — o que só faz sentido se, um dia, houver uma organização número um.

O que a lista mostrou

A lista de exceções tinha uma virtude que eu não esperava: ela mostrava, preto no branco, onde estavam os problemas.

Um deles era sério. Um grupo de telas de análise respondia sem pedir login. Quem soubesse o endereço via os números. É o mesmo tipo de porta encostada do capítulo passado, de outro cômodo da casa — nascida de quando o sistema era eu, testando na minha máquina, e esquecida depois. Foi fechado às onze e quarenta da noite do próprio dia 100.

A catraca tinha nascido com 186 itens na tarde do dia 100. Ao meio-dia do dia 101, zero. Uma segunda lista, de outro tipo de desobediência, tinha 49 itens à uma e meia e zero pouco depois das três. Não foi mágica: foi o trabalho que estava parado havia meses, finalmente com um contador na frente dizendo quanto faltava.

O incidente das oito e vinte

O dia 102 foi o do cofre. As senhas e os crachás que os robôs usam para entrar nos sistemas dos parceiros moravam espalhados, em arquivos de configuração. Foram todos para um cofre cifrado, com uma porta só de entrada e saída.

Às oito e vinte da noite, o X9 parou.

O crachá que ele usava para conversar com o app de delivery tinha acabado de ser cifrado, e o X9 não sabia abrir cofre. Ele e mais duas tarefas liam o crachá por um caminho próprio, pela porta dos fundos — e a porta dos fundos agora dava num cofre fechado. Os robôs que usavam a porta oficial nem perceberam a mudança.

O conserto levou quinze minutos. A lição vale mais: toda mudança de fechadura revela quem estava entrando pela janela.

Hoje, para quem?

Mais tarde, no mesmo dia, um defeito que eu adoro contar.

Uma das tarefas procura, na caixa de e-mail, o relatório de pedidos que o app de delivery manda toda noite. A busca é simples: e-mails de hoje. No Mac mini, funcionava. Quando a mesma tarefa passou a rodar na nuvem, ela achava zero e-mails — com o relatório parado lá na caixa.

A nuvem não mora em São Paulo. Ela vive no horário de Greenwich, três horas na frente. Para ela, quando o relatório chegava à noite, “hoje” já era amanhã, e o e-mail de ontem não entrava na busca.

Eu tenho uma regra, desde o começo, de que todo horário que me mostram tem de estar no relógio de São Paulo. Achava que era uma regra sobre como falar comigo. Era também sobre como o sistema pensa.

A nuvem primeiro

Esse defeito só apareceu porque a tarefa já estava começando a rodar na nuvem. E, uma hora e meia depois do conserto, entrou o artigo que mais mudou a casa: a menor infraestrutura capaz, e um motor por tarefa. Tudo o que pode rodar na nuvem roda na nuvem. No Mac mini fica só o que não tem como sair de lá — navegador com sessão de gente, WhatsApp vivo. E nada roda em dois lugares “por segurança”, porque dois motores para a mesma tarefa é o jeito mais rápido de ter duas respostas diferentes.

O dia 103 foi a mudança. A sincronização de pedidos do app de delivery foi para a nuvem. A do sistema de frente de loja também. A fábrica de PDFs, que só sabia rodar no Mac mini, foi reescrita para rodar lá. A análise das conversas de atendimento e o envio do relatório do iCasca foram atrás.

Uma mudança dessas tem sempre um detalhe ridículo. O da vez: os PDFs gerados na nuvem saíram com as bolinhas coloridas dos indicadores trocadas por um aviso de caractere não encontrado. A máquina da nuvem não tinha a fonte dos emojis. As bolinhas viraram desenho, e não letra.

No dia 104 o sistema aprendeu a aguentar o tranco: tentar de novo quando o arquivo central da nuvem ficava congestionado, tentar de novo quando o app de delivery recusava por um instante sem motivo, e renovar o próprio crachá sem abrir navegador. E a constituição ganhou mais um artigo, sobre o próprio Mac mini: tudo o que continuar lá precisa de uma justificativa escrita. Nunca inércia.

A lição desses dias

Por três meses, a casa foi construída do jeito que dava: cada cômodo quando precisava, cada regra depois do problema. Funcionou, e foi o que permitiu chegar até aqui.

Mas chega um ponto em que ter feito rápido começa a custar mais caro do que teria custado fazer certo. A constituição não mudou o que o sistema faz; mudou a ordem das coisas: primeiro a regra, depois o código, e um fiscal no meio que não se cansa.

E a catraca que só gira para um lado é a ideia que eu mais levo desta semana. Não é preciso consertar tudo de uma vez. É preciso só nunca mais piorar.

No próximo capítulo, a pressa em aguentar o tranco cobra o preço: numa madrugada, o sistema se afoga nas próprias tentativas e trava inteiro.

Dias 95 a 99 · 28 de junho a 2 de julho – 2026

No fim do capítulo passado eu prometi que o iCasca ia parar no WhatsApp da diretoria e que eu ia descobrir que relatório bom é o que se lê no domingo à noite. Errei o dia. Ele chega na segunda-feira às nove da manhã — e, pensando bem, ainda bem.

Uma madrugada sem pendência

O iCasca tinha nascido sabendo cruzar números, mas boa parte dos números ainda chegava na mão. Na madrugada do dia 95 isso acabou, uma peça por vez.

Primeiro entrou a reputação de verdade de cada loja no app de delivery: cancelamentos e o selo de qualidade que a plataforma dá a quem se comporta bem. Depois as promoções, com o retorno de cada uma — quanto se gastou e quanto voltou em venda. Depois o desempenho: vendas pelo app e quantos clientes novos apareceram. E por último, às três e meia da manhã, o funil do cardápio: quantas pessoas abriram a loja, quantas chegaram a pedir.

No registro daquela noite está escrito, perto das quatro: zero pendência de dados. Tudo o que o iCasca precisava para opinar passou a chegar sozinho, toda semana, sem ninguém baixar planilha.

Ainda antes de amanhecer ele ganhou o formato que tem até hoje: uma página por loja. Não um relatório do grupo com as lojas espremidas numa tabela, mas uma folha para cada unidade, com a leitura dela.

Quem paga o desconto

No dia 96 veio o detalhe que eu considero o coração do relatório.

Promoção no app de delivery não é uma coisa só. Tem desconto que a loja banca sozinha, tem desconto que a plataforma banca, e tem os dois dividindo. Na tela, os três aparecem iguais: “20% off”. No caixa, são três negócios completamente diferentes.

O iCasca passou a ler o desconto real de cada promoção e quem estava pagando por ele. Promoção bancada pela plataforma, que traz cliente sem custar margem, é presente. Promoção bancada pela loja, com prato de margem apertada, pode estar comprando venda com prejuízo. É a mesma calculadora do capítulo anterior, só que agora alimentada com a informação que faltava para ela ser honesta.

Os robôs ganham cara

Antes de seguir, uma dívida com o capítulo passado. Na mesma semana em que nasceu o iCasca aconteceu outra coisa, e ela ficou de fora: os robôs ganharam uma casa só deles, e ganharam cara.

Na madrugada do dia 90 nasceu um projeto separado do sistema, uma vitrine onde cada robô tem ficha: nome, cargo, a pergunta que responde, o jeito de falar. A direção de arte ficou com o ChatGPT, no papel de Diretor Criativo, e cada retrato só virou oficial depois que eu aprovei. Naquele mesmo dia, oito robôs ganharam retrato — entre eles a Sofia, de cabelo curto e tablet na mão, e o X9, com a lupa. A Babá, de óculos e prancheta, ganhou o dela no dia seguinte; o iCasca, três dias depois, junto com o nascimento.

Duas regras nasceram com os retratos, e as duas continuam de pé. A primeira: aprovado, congelado. Um robô pode ganhar pose nova, mas não se redesenha; cada um tem uma ficha com a descrição que preserva a aparência, para que o décimo desenho saia igual ao primeiro. A segunda veio no dia 92: a vitrine não mostra dado real nenhum. Os robôs trabalham no sistema de verdade; lá, eles só se apresentam.

Até aqui, nas ilustrações deste diário, eles eram mascotes de capacete, iguais entre si, um de cada cor. A partir deste capítulo, aparecem com a cara oficial. E a vitrine está aberta: dá para conhecer cada um deles no DMR AI Universe.

O narrador também ganha cara

Se os robôs ganharam cara, está na hora de o narrador ganhar a dele.

Até aqui eu assinei este diário como MacGyver — o faz-tudo que resolve com o que tem à mão, que era como eu me sentia na primeira noite, diante de uma tela preta. O apelido cumpriu o papel. Mas, a esta altura, ele mais esconde do que conta.

Meu nome é Lito. Sou empresário, dono da DMR, que opera restaurantes franqueados, e não sou programador. Nunca fui. Tudo o que você leu até aqui — o painel, os robôs, os consertos de madrugada — foi construído por alguém que não escreve uma linha de código: eu digo o que precisa ser feito e por quê, o Claude escreve, e eu confiro se o resultado resolve o problema da loja. Esse é o ponto do diário desde o primeiro capítulo, e ele fica mais honesto com o meu nome embaixo.

Na prática, muda pouco. As empresas parceiras continuam aparecendo pelo que fazem. O que muda está nas ilustrações: o homem que até aqui era um personagem genérico passa a ser eu, desenhado no mesmo traço dos robôs. Na vitrine deles, aliás, eu apareço como o chefe da tropa.

A voz dele

Números cruzados ainda não são um relatório. Faltava alguém dizer o que eles querem dizer.

Cada página ganhou um parágrafo de leitura, escrito na voz do iCasca: direto, sem jargão, apontando uma coisa por vez. E aqui o ChatGPT ganha um segundo papel.

Um robô com ficha e retrato congelados precisa de alguém que cuide para que o jeito dele não se perca no dia a dia, e esse papel eu dei ao próprio ChatGPT: ele virou o Guardião dos personagens. O Claude constrói; o Guardião confere se o que foi construído continua sendo o personagem que a gente desenhou. As leituras do iCasca passaram três vezes pelo Guardião entre os dias 95 e 96, e cada rodada tirou alguma coisa: um adjetivo que soava vendedor, uma frase que dava ordem em vez de recomendar.

Nessa mesma revisão, o relatório de vendas do Tio KB e os outros relatórios da casa ganharam no cabeçalho o retrato, o nome e a missão do robô que assina. Relatório passou a ter autor.

Por que segunda, e não domingo

Com o relatório pronto, faltava decidir quem recebe o quê.

A primeira versão mandava tudo para todo mundo, e ficou claro na hora que isso não funciona. Cada gerente passou a receber só as unidades dele, no privado. A diretoria recebe o consolidado no grupo: uma capa com as lojas ordenadas pela nota, da melhor para a pior, e uma página por unidade. No dia 96 à noite entrou a última peça: o faturamento de cada marca comparado com o mesmo período da semana anterior, numa caixinha no alto da página.

E o horário. A coleta ficou para segunda às oito; o envio, às nove. Olhando de hoje, foi a escolha certa por um motivo que eu não tinha enxergado quando escrevi a promessa: domingo à noite é ótimo para ler com calma e péssimo para receber uma recomendação, porque ninguém pode fazer nada com ela até o dia seguinte. O relatório bom é o que chega quando a pessoa pode agir.

O WhatsApp que dizia estar desligado

O dia 98 foi de conserto, e de um defeito com cara de assombração.

Toda vez que o Mac mini reiniciava, o painel de comunicação mostrava o WhatsApp deslogado. Eu olhava, levava um susto, conferia — e ele estava conectado, mandando mensagem normalmente. O painel mentia.

A causa era uma cópia guardada. Para responder mais rápido, o sistema lia o estado do WhatsApp de uma cópia que tinha sido tirada no momento do boot, quando ele ainda não tinha conectado. A cópia ficava velha e o painel seguia mostrando a foto antiga como se fosse a de agora.

Consertado o painel, fui procurar o mesmo erro em outros lugares, e ele estava lá: o índice das atas de reunião perdia entradas pelo mesmo motivo — gravava em cima de uma cópia desatualizada e apagava o que tinha entrado depois. A auditoria achou mais seis pontos com o mesmo defeito, e todos passaram a ler o original em vez da cópia.

Uma cópia guardada é uma ótima ideia até o dia em que ela e o original discordam, e ninguém avisa qual dos dois está certo.

A Sentinela na fronteira

No mesmo dia a Sentinela, uma das robôs que tinham ganhado retrato no dia 90, ganhou um trabalho, e ela vigia uma coisa que eu nunca tinha pensado em vigiar.

Os robôs têm duas casas. Numa mora a identidade deles, a vitrine: ficha, retrato, nome, cor. Na outra mora o trabalho: o que cada um faz na operação, todos os dias. As duas precisam concordar — o robô que aparece no relatório tem de ser o mesmo que está na ficha — e, com o tempo, elas começam a divergir sem ninguém perceber. Um retrato muda de um lado e não do outro; um robô novo nasce na operação e não ganha ficha.

A Sentinela passou a conferir as duas casas todo dia de manhã. Quando acha diferença, ela restaura o que dá para restaurar e registra o resto no WhatsApp. O jeito de falar dela foi escolhido de propósito: ela não acusa, registra. Um alarme que acusa gera defesa; um registro gera conserto.

Duas frentes

O dia 99 foi mais de papel do que de código, e foi o que abriu tudo o que vem depois.

Duas decisões. A primeira: o trabalho que eu vinha fazendo para o cliente, a outra rede que passou a usar os robôs, ganhou um projeto próprio, separado do meu. Até ali era um puxadinho dentro da minha casa.

A segunda foi maior. Eu escrevi para o Guardião um pedido de redesenho do sistema inteiro — e, na mesma frase, dei a ele liberdade total. Não era para remendar o que existia; era para dizer como o sistema deveria ser se fosse começar hoje, sabendo tudo o que aprendi em três meses.

A lição desses dias

Os cinco dias tiveram o mesmo assunto disfarçado de assuntos diferentes: informação certa na hora errada vale pouco.

O relatório de domingo seria lido e esquecido. O painel mostrava a situação do WhatsApp no boot, e não a de agora. A cópia do índice das atas era verdadeira quando foi tirada e errada quando foi usada. Em todos os casos o dado estava certo; o que estava errado era o momento.

Sistema que informa precisa responder a duas perguntas, e não a uma: o que é verdade e verdade de quando.

No próximo capítulo, o Guardião responde ao pedido de redesenho, e numa única madrugada o sistema ganha uma constituição — com um fiscal que recusa o código que desobedece a ela.