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