SolOS: coeso por fora, modular por dentro

Existe uma pergunta incômoda que todo sistema ambicioso precisa encarar: a arquitetura está ficando realmente melhor ou apenas maior? O SolOS chegou a esse ponto. A tese sempre buscou uma experiência menos fragmentada. Ghost, Wallet, Apps e approvals não deveriam parecer produtos soltos colados a um desktop. Para quem usa, o ambiente precisa ser legível como um único sistema. Mas integração de experiência não pode significar concentração de código. Por isso, esta nova fase ganhou uma regra curta: ## Coeso por fora, modular por dentro O SolOS continua com três camadas claras: - Linux como base confiável do sistema; - Daemon/runtime em Rust como mediação persistente; - SolOS como operating layer visível. Dentro do runtime, porém, as responsabilidades passam a seguir seus espaços naturais: host, Ghost, Wallet, Apps, approvals, quota, eventos e contratos. Não é uma corrida para criar microserviços. É um monólito modular: um Daemon, uma experiência coerente e fronteiras internas que podem ser testadas, observadas e evoluídas sem transformar tudo em um arquivo ou controlador central. ## A correção já entrou no código Esta não é apenas uma mudança de redação. O primeiro corte separou a descoberta do host Linux e a montagem do catálogo operacional em módulos próprios do runtime. O contrato externo da RC1 foi preservado, então a shell continua entendendo o mesmo estado enquanto o núcleo ganha fronteiras melhores. A auditoria também encontrou dois defeitos reais que uma compilação verde não mostrava: - a Home e o Agent abriam com bindings QML inválidos em listas importantes; - o servidor web local retornava 404 quando o caminho de assets não era configurado manualmente. Os dois foram corrigidos. E o gate mudou. Agora não basta compilar: a verificação sobe o servidor web, inicia o Daemon, abre a shell nativa e falha se encontrar erro QML, módulo ausente ou encerramento precoce. ## Uma tese menos exagerada e mais precisa O SolOS não precisa abandonar a ideia de um ambiente integrado. Essa é uma das suas partes mais fortes. O que ele precisava era separar duas coisas: - unidade para a pessoa; - limites para a engenharia. Home pode resumir o todo. Ghost pode conversar com Wallet e Apps. Approvals podem atravessar a experiência. Mas cada domínio precisa continuar reconhecível, revogável, observável e governado por contratos explícitos. Isso torna o sistema mais seguro e também mais humano. Uma pessoa não deveria precisar compreender a estrutura interna para sentir continuidade. Já quem desenvolve e audita precisa conseguir localizar responsabilidade, falha e impacto. ## O que ainda falta O SolOS continua sendo um release candidate, não um sistema diário pronto. Os próximos cortes precisam: - dividir o controlador amplo da shell por domínio; - mover estado e eventos duráveis para stores pertencentes ao Daemon; - manter o snapshot agregado como leitura de compatibilidade, sem transformá-lo no único barramento interno; - provar o appliance em VM; - completar uma jornada real de Ghost, aprovação, execução e resultado persistido. Sem fingir autonomia. Sem esconder custo. Sem sacrificar segurança para parecer pronto antes da hora. ## Construir e comunicar também custa Código, infraestrutura, vídeo, distribuição e marketing exigem recursos. O Fundraising do SolOS existe para sustentar exatamente essa travessia: transformar uma tese autoral em software utilizável, testado e conhecido por pessoas reais. Os apoios são avulsos e oferecem reconhecimento e utilidade dentro do ecossistema. Não são investimento, equity, dívida, rendimento ou promessa de retorno financeiro. Quem apoia ajuda a financiar desenvolvimento, segurança, infraestrutura e a comunicação necessária para o SolOS encontrar seus primeiros usuários. Uma nova fase não precisa fazer mais barulho. Precisa organizar melhor o que já nasceu — e levar essa construção até as pessoas certas. https://luiz-bella-artes.net/solos/fundadores