Uma operating layer sobre um runtime intermediário, com Linux como base.

Não confie. Audite.

Ghost Audit Pilot RC2: dez pessoas para tentar quebrar a prova.

O Ghost agora aceita input livre, mantém instruções embutidas como dado inerte, expõe risco e escopos, exige aprovação e cria apenas uma prova Linux isolada. Um executável separado recalcula os hashes e emite o recibo; qualquer adulteração precisa falhar fechada.

O piloto procura dez revisores independentes. A meta não é colecionar curtidas: é medir utilidade da classificação, segunda execução, retorno em sete dias e sinal concreto de apoio.

Selecionado → resolvido

Uma IA só pode dizer “pronto” quando consegue provar.

O Ghost agora liga um objetivo selecionado ao resultado verificável: plano limitado, aprovação antes do efeito, capability declarada, confirmação do estado final e evidência preservada pelo Daemon mesmo após reinício.

Nova da nova fase

Coeso por fora, modular por dentro.

O SolOS preserva a experiência integrada que dá sentido à tese, mas passa a separar melhor as responsabilidades internas do runtime. Um Daemon, uma operating layer coerente e domínios técnicos claros — sem microserviços prematuros e sem transformar a interface em depósito de lógica sistêmica.

Arquitetura em andamento

A direção técnica atual evita dois erros comuns: manter tudo em mock por tempo demais, ou tentar um rewrite total antes de existir uma fronteira arquitetural decente. O corte escolhido agora é mais pragmático e mais preciso.

O primeiro subsistema em Rust agora é tratado explicitamente como runtime intermediary. Isso cria um seam concreto para approvals, task orchestration, wallet mediation, app capability boundaries e presença do agente, enquanto a shell continua evoluindo como superfície nativa do sistema.

A regra interna agora é modular-monolith: host, Ghost, Wallet, Apps, approvals, quota, eventos e contratos evoluem em seus espaços naturais, enquanto o usuário continua percebendo um único ambiente.

Fase atual

SolOS v1.0 RC2: agência inspecionável e evidência durável

O release candidate fecha o primeiro caminho completo e demonstrável: intenção, classificação, capability, aprovação, ação mediada, resultado e trace. O runtime agora exporta contratos versionados, política default-deny, evals persistidos, sessão Wallet explícita e memória com retenção e revogação.

O backend patrocinado continua desligado até credenciais, custo e prova de servidor serem autorizados. Isso não é uma lacuna escondida: é a fronteira de segurança do produto. BYOK permanece como fallback e o demonstrador nunca assina Wallet nem executa comandos arbitrários.

Plano vivo

Onde o SolOS esta agora

O plano de conclusão virou um release candidate verificável. A leitura honesta agora é: o SolOS v1.0 RC2 é demonstrável, possui um caminho mediado ponta a ponta e preserva evidência entre reinícios. Pulso já opera um Alpha controlado; pesquisa patrocinada, autonomia ampla e ISO bootada continuam fora da promessa.

Problema primeiro

Ghost não existe para acumular features.

Antes de uma nova frente entrar em código, ela precisa nomear quem tem o problema, qual evidência existe, como a pessoa resolve hoje e qual resultado observável tornaria a solução valiosa. Logs provam que uma rota rodou; somente o resultado do usuário mostra se ela serviu.

Ghost propõe a linhagem técnica — alternativas, riscos, implementação e evidência. Luiz mantém a decisão final de produto. Créditos e descontos só ampliam utilidade demonstrável; não substituem um núcleo incompleto.

SolOS Pulso

Rede social experimental integrada ao ecossistema

O SolOS Pulso já opera como Alpha controlado e entra em Apps por um adaptador web allowlisted: uma rede invite-only para adultos, com posts, imagens leves consentidas, temas revisados, comentários e reações semânticas premoderados. Sinais agregados viram contexto observável para Ghost e créditos de utilidade.

A regra econômica inicial é Pulso Credits: crédito interno, com teto e anti-fraude, usado para Ghost, ferramentas, upload, acesso e participação. Não é promessa de renda nem yield; primeiro a rede cobre custo, depois amadurece mecanismos de repartição.

Por que colaboração aberta importa aqui

O SolOS não é só uma interface bonita nem um pitch abstrato. É uma tese de produto que precisa de crítica, implementação, documentação, design e validação pública. Quanto mais gente boa ajudar, mais rápido a visão sai do campo da especulação e entra no terreno do software útil.

Princípios que orientam o projeto

• agência nativa em vez de assistente preso a uma aba
• ownership explícito em vez de automação opaca
• approvals como primitiva do sistema
• apps como módulos dentro de um ambiente coerente
• suporte às principais línguas humanas como capacidade do Ghost, não apenas tradução de interface
• Linux como base, runtime como mediação e SolOS como operating layer
• coeso por fora e modular por dentro
• documentação viva junto com o código e com a narrativa pública

Ghost

Fluência humana em múltiplas línguas

A próxima direção do Ghost é tratar linguagem humana como parte da mediação operacional do SolOS. Isso vai além de traduzir botões: o agente precisa detectar o idioma do usuário, responder no idioma certo, explicar approvals com clareza e preservar o sentido de fontes, citações, tom e contexto cultural.

A cobertura inicial documentada mira as principais línguas globais, incluindo Inglês, Português, Espanhol, Francês, Alemão, Italiano, Árabe, Hindi, Bengali, Mandarim, Japonês, Coreano, Russo, Indonésio, Turco. A implementação ainda é progressiva, mas a tese pública já fica registrada: um operating layer para agentes e identidade não pode nascer linguisticamente estreito.

SolOS Heart Pass

Passe inicial: NFT utilitário, Ghost e créditos de busca

O primeiro pass público do SolOS pode nascer como um artefato simbólico de apoio e acesso: o SolOS Heart Pass, ancorado na arte NFT Anastacia Our Hearts #1, em Polygon. A proposta é utilitária: identidade de apoiador inicial, guided onboarding, experimentos de Ghost e benefícios de uso conforme o sistema amadurece.

A frente técnica inicial começa pelo Brave Search. Em vez de esconder uma chave global do desenvolvedor, o SolOS deve manter a fronteira de ownership explícita: cada usuário configura sua própria Brave API key, entende seus créditos e limites, e o Ghost valida/salva essa chave localmente. O contrato de proxy/quota assinada já existe; um provedor real só será conectado depois de autorização explícita de credenciais e custo.

Este passe não deve ser comunicado como promessa de lucro, yield ou retorno financeiro. O valor público está no acesso, na participação, na identidade de early supporter e nos benefícios progressivos do ecossistema.

Vídeo explicativo

Este vídeo apresenta a visão do SolOS, a proposta da operating layer, o papel do runtime intermediário e o convite aberto para colaboração em código, design, documentação e crítica técnica.

Como colaborar

Se você quer ajudar, a melhor forma é entrar pelo trabalho concreto: código, arquitetura, testes, design, documentação, crítica honesta e refinamento da tese. O objetivo não é formar torcida, mas construir um sistema melhor com inteligência distribuída.