SolOS Ghost: uma IA só pode dizer ‘pronto’ quando consegue provar

Vídeo: https://bkmzbbohunqkmcaeppqf.supabase.co/storage/v1/object/public/videos/solos/ghost-resolution-loop-selecionado-resolvido.mp4 Código: https://github.com/luizpeixotobella/solos/commit/f352cffb61cc02674fc6d511c008ff6517f9899c --- Todo mundo quer uma inteligência artificial que faça coisas. Eu queria uma exigência mais difícil: **uma IA que saiba provar quando terminou.** Essa diferença virou o novo corte do SolOS RC1: o **Ghost Resolution Loop**. Até aqui, o Ghost já conseguia classificar um pedido, explicar a rota, mostrar risco, capacidade, custo de quota e necessidade de aprovação. Era uma base importante — mas ainda faltava uma linha contínua entre o começo e o fim. Faltava transformar intenção em resolução. ## O que é uma resolução Uma resolução não é uma resposta bonita, uma checklist decorativa nem um “pronto” otimista. Ela nasce com cinco coisas explícitas: - um objetivo selecionado; - um resultado-alvo verificável; - um plano limitado; - uma capacidade declarada; - uma evidência que permita confirmar o desfecho. O primeiro objetivo executável é deliberadamente pequeno: **restaurar o módulo Workspace com segurança**. O fluxo é: **selecionar → planejar → aprovar → executar → verificar → reter evidência.** O Ghost seleciona um objetivo pronto. Converte esse objetivo num plano limitado. Para antes do efeito colateral. Pede aprovação explícita. Executa apenas a capacidade declarada `app.open.safe`. Depois consulta `app.state.read` e só marca a resolução como concluída quando o estado-alvo aparece como ativo. No demonstrador, isso muda o estado operacional do módulo Workspace; não abre comandos arbitrários do host e não finge que já existe um launcher universal. ## A negação também faz parte do produto Se o usuário negar, nada é executado. O passo de aprovação fica bloqueado, os passos de execução e verificação permanecem pendentes e a negação vira evidência da própria resolução. Isso importa porque sistemas de IA costumam apresentar autonomia como desaparecimento: menos perguntas, menos telas, menos fricção. O SolOS aposta no contrário. Quanto maior o efeito possível, mais legível precisa ser a fronteira humana. ## Persistência de verdade O estado da resolução não pertence à tela. Ele agora vive num store versionado — `solos.ghost.resolutions.v1` — pertencente ao Daemon persistente em Rust. As gravações são atômicas. A shell nativa e a web apenas solicitam transições e apresentam o resultado. O snapshot agregado do RC1 continua existindo para compatibilidade, mas recebe o estado mais recente do Daemon em vez de fingir que um arquivo gerado é a única verdade do sistema. O teste mais importante não para no “100%”. Ele resolve o objetivo, encerra o Daemon, inicia novamente e verifica que aprovação, resultado e evidência continuam lá. Porque uma conclusão que desaparece no reinício não é conclusão. É animação de interface. ## O que o vídeo mostra O vídeo desta fase usa a interface real do SolOS. Ele mostra três estados distintos: 1. objetivo selecionado, com resultado-alvo e capacidade visíveis; 2. plano preparado, parado na aprovação; 3. resultado verificado em 100%, com cinco evidências retidas. O gate completo passou com 13 testes Rust, smoke do RPC, reinício do Daemon, build web, build Qt/QML e abertura nativa offscreen sem erro de runtime. O código está público no commit `f352cff`. ## O que continua bloqueado — de propósito A tela também mostra duas candidatas futuras: - pesquisar uma resposta fundamentada; - preparar e publicar um lançamento. As duas aparecem porque fazem parte da visão. As duas continuam indisponíveis porque ainda faltam capacidades reais: quota ou BYOK para pesquisa, e um adaptador de publicação vinculado a conta para envio público. Isso é produto, não vergonha. Uma interface honesta precisa mostrar não apenas o que está pronto, mas também o que está bloqueado e por quê. ## E onde entra a LBArtes A doideira da firma é esta: a mesma casa que escreve a tese, implementa o runtime, testa a shell, produz o vídeo e distribui a história. Não para misturar funções de forma irresponsável, mas para manter uma linha autoral entre ideia, engenharia e linguagem pública. **LBArtes × SolOS** significa que o produto e a narrativa precisam conseguir auditar um ao outro. Se a campanha promete mais do que o código entrega, a comunicação falhou. Se o código faz algo importante e ninguém entende por quê, o produto também falhou. Coeso por fora. Modular por dentro. Verificável de ponta a ponta. ## O próximo objetivo O Ghost Resolution Loop fecha uma pendência importante do RC1, mas não transforma o SolOS em produto diário pronto. Os próximos cortes continuam claros: - conectar pesquisa real ao accounting de quota; - endurecer o launcher de Apps; - ampliar os stores pertencentes ao Daemon; - provar o appliance em VM; - continuar dividindo controladores amplos sem fragmentar a experiência. O beta ficou mais beta porque parou de vender apenas movimento. Agora ele consegue mostrar começo, limite, decisão, efeito e prova. **Selecionado → resolvido.** Conheça o código: https://github.com/luizpeixotobella/solos Acompanhe e sustente a construção: https://luiz-bella-artes.net/solos/fundadores