SolOS v1.0 RC1: quando agência deixa de ser mágica e passa a ser inspecionável

Há uma diferença enorme entre desenhar o futuro da computação e obrigar esse futuro a passar em testes.

O SolOS nasceu como uma tese: se agentes de inteligência artificial, identidade, wallets, apps e automações estão se tornando partes permanentes da vida digital, eles não deveriam continuar espalhados em abas, caixas de diálogo e processos invisíveis. Deveriam existir dentro de uma camada operacional coerente, legível e controlável pelo humano.

Com o SolOS v1.0 RC1, essa tese atravessa uma fronteira importante.

Ela deixa de ser apenas uma boa formulação de produto e passa a ter um caminho técnico demonstrável, versionado e verificável.

Linux na base, Rust na mediação, SolOS na operação

A arquitetura do SolOS está organizada em três camadas.

Linux é a base do sistema. Ele continua responsável por kernel, processos, rede, sessão, filesystem e serviços do host.

O runtime intermediário em Rust é a camada de mediação. Ele lê e normaliza o estado do host, descreve capacidades, aplica fronteiras e entrega contratos estáveis para a experiência.

O SolOS é a operating layer. É onde Home, Ghost Agent, Wallet, Apps e Approvals se tornam uma experiência única.

Essa separação evita duas promessas falsas: o SolOS não finge ter criado um kernel novo e também não reduz o projeto a uma interface bonita sobre Linux.

O que existe entre os dois é justamente o coração do produto: uma camada capaz de mediar intenção, contexto, permissão e resultado.

O runtime agora tem identidade própria

O snapshot principal passa a declarar o schema solos.runtime.snapshot.v1 e a versão de produto 1.0.0-rc1.

Um contrato versionado permite testar o que a shell espera, detectar regressões e evoluir o runtime sem depender de campos implícitos. O estado deixa de ser apenas um conjunto de textos úteis para a interface e passa a funcionar como uma fronteira verificável entre Linux, runtime e SolOS.

Capacidades bloqueadas por padrão

O RC1 introduz um manifesto tipado de capacidades.

Cada ação pode declarar escopos como leitura, escrita, rede, conteúdo sensível, wallet e publicação pública. Cada capacidade recebe nível de risco, regra de aprovação, exigência de auditoria e indicação explícita sobre estar ou não executável.

A política padrão é simples: default-deny.

Uma capacidade não nasce liberada porque é conveniente. Ela nasce bloqueada até que o runtime consiga explicar seu impacto e o usuário consiga consentir.

O Ghost agora deixa rastros duráveis

Antes desta atualização, o Ghost já conseguia mostrar classificação de pedido, nível de segurança, ferramentas necessárias, impacto de quota e explicação da rota.

O RC1 adiciona um trace store persistente e uma primeira semente determinística de avaliação. Os resultados podem ser aceitos, rejeitados ou corrigidos.

A avaliação inicial cobre documentação local, abertura segura de app, publicação pública, assinatura de wallet e pedido ambíguo. As cinco rotas esperadas passaram.

Isso não significa que o Ghost aprendeu tudo.

Significa algo mais sério: o sistema agora consegue comparar a rota escolhida com a rota esperada antes de afirmar que uma decisão está segura ou pronta.

Observabilidade vem antes de autonomia.

A primeira ação mediada

O primeiro fluxo completo é deliberadamente pequeno: abrir o módulo Workspace.

O pedido é classificado. A capability app.open.safe é identificada. A aprovação aparece. O usuário pode negar. Nada é executado quando existe negação. Quando há aprovação, o Workspace abre e o resultado entra no rastro.

Esse corte prova a gramática principal do SolOS:

intenção → classificação → capability → aprovação → ação → resultado → trace.

Wallet, Heart Pass e quota sem promessa escondida

O runtime distingue prova ERC-1155 observada, sessão local, necessidade de assinatura e permissão para uso patrocinado. Mesmo com holder verificado, chamadas patrocinadas continuam desligadas enquanto não existir um serviço real de sessão assinada.

O contrato de quota proxy exige prova assinada, idempotência, reserva atômica, adaptador independente de provedor, accounting explícito, rollback e fallback BYOK.

O contrato existe. O backend patrocinado ainda não é fingido.

Memória precisa ter saída

Memória de sessão expira automaticamente. Memória de projeto fica sob controle do repositório. Preferências duráveis exigem intenção explícita. Contexto sensível nasce bloqueado.

Cada classe declara retenção e revogação.

Uma inteligência útil precisa lembrar. Uma inteligência confiável também precisa saber esquecer.

Um release que pode ser repetido

O release gate executa formatação e testes Rust, invariantes do snapshot JSON, build da shell web, build da shell nativa Qt/QML/C++, validação dos scripts do appliance e presença do roteiro de demo e documentação.

Os três testes Rust passaram. A avaliação inicial do Ghost passou em cinco de cinco rotas. As duas shells compilaram. O CMS compilou suas 56 rotas. A tag v1.0.0-rc1 foi publicada.

O que o RC1 ainda não promete

O runtime ainda é liderado por snapshot, não por um serviço amplo de eventos. O demonstrador não assina wallets. Não executa comandos arbitrários. O backend patrocinado permanece desligado. O SolOS Pulso continua como protótipo até consentimento, moderação, exportação, exclusão, ledger, limites e antifraude existirem server-side.

Esses limites mostram maturidade: tornar evidente o que está pronto, o que está bloqueado e por quê.

Agência inspecionável

Quanto mais poder um agente recebe, mais legível deve ser sua ação.

O futuro não precisa ser uma inteligência invisível fazendo coisas em nosso nome.

Pode ser um ambiente em que a inteligência explica o pedido, mostra a rota, revela a capacidade, solicita permissão, registra o resultado e aceita correção.

Essa é a ideia por trás do SolOS v1.0 RC1.

Não autonomia mágica.

Agência inspecionável.

Conheça o projeto e acompanhe os próximos testes:

https://lbartes.com.br/solos