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