Da conversa à fundação: fundraiser, segurança e uma nova fase do SolOS

Algumas etapas de um projeto começam com um documento formal. Esta começou com uma conversa simples: e se o SolOS tivesse um fundraiser capaz de recompensar a comunidade que ajuda a torná-lo possível?

A pergunta parecia financeira. Na prática, ela obrigou o projeto inteiro a amadurecer.

Antes de pedir apoio, precisávamos responder perguntas mais difíceis. O que já podemos entregar? O que é recompensa de utilidade e o que seria uma promessa indevida? Como receber contribuições sem transformar Pulso Credits em dinheiro disfarçado? Como proteger o CMS, o ledger e a Wallet? Como distinguir uma página pronta de uma campanha realmente publicada?

Esta é a história dessa nova etapa: menos mágica, mais fundação.

O FUNDRAISER FUNDADORES DO SOLOS

A campanha foi desenhada para financiar o próximo ciclo do SolOS, Ghost e Pulso: produto, infraestrutura, vídeo, armazenamento, inteligência artificial, segurança, jurídico, contabilidade e comunidade.

O modelo inicial prevê três formas de participação:

• Apoiador, a partir de R$ 25; • Founder Heart, a partir de R$ 100; • Patrono, a partir de R$ 500.

O apoio pode começar por PIX e, depois, ganhar checkout de cartões hospedado no Stripe. O CMS não recebe nem armazena dados de cartão.

As recompensas são simbólicas, de acesso e utilidade: reconhecimento, badge founder-heart, acesso antecipado, prioridade em demonstrações e Pulso Credits. Elas não representam participação societária, dívida, rendimento, valorização ou promessa de saque.

Essa distinção não é nota de rodapé. É parte do produto.

Conheça a proposta: https://lbartes.com.br/solos/fundadores

RECOMPENSA QUE DEIXA RASTRO

O primeiro ciclo de Founder Rewards já ganhou uma base concreta no Supabase.

Uma contribuição validada pode ser associada a uma conta LBArtes e conceder badge e créditos por uma referência única. A operação é idempotente: repetir a mesma referência não duplica a recompensa.

O primeiro resgate funcional troca 10 Pulso Credits por uma reserva de 25 consultas Ghost. O claim gerado é ligado atomicamente à primeira Wallet válida. A mesma Wallet pode repetir a operação sem criar um segundo vínculo; outra Wallet é rejeitada.

O ledger permanece auditável. Estornos e exceções não apagam o passado. Fraude, chargeback e conflito de identidade exigem revisão — não improviso automático.

Veja o Pulso e a área de recompensas: https://lbartes.com.br/solos/pulso https://lbartes.com.br/solos/pulso/recompensas

SEGURANÇA ANTES DO BOTÃO DE PAGAR

O fundraiser revelou que não bastava criar uma página bonita. Antes de abrir cartões ao público, o CMS precisava de uma revisão mais séria.

A nova base inclui autorização administrativa centralizada, proteção específica para o painel Founder, políticas RLS mais restritas no Supabase, limites para requisições, pré-validação de uploads, headers e CSP, allowlist HTTPS, cron fechado por padrão e comparação segura de segredo.

Também removemos a execução por shell em pontos sensíveis do C++ e do Rust. A chave local de pesquisa do Ghost saiu do arquivo distribuído e passou a viver em configuração ignorada pelo Git, com acesso restrito.

As dependências críticas foram atualizadas. Os audits npm do CMS e da shell chegaram a zero vulnerabilidades conhecidas. A auditoria RustSec voltou a funcionar com rustup e cargo-audit atualizados.

O objetivo não é declarar um sistema invulnerável — isso seria irresponsável. O objetivo é reduzir superfície, testar as fronteiras e tornar os riscos visíveis antes de pedir confiança financeira.

RUST, GHOST E O CAMINHO DA QUOTA

O runtime intermediário do SolOS agora entende o estado de Founder Rewards e ganhou um medidor fail-closed para consumo de consultas Ghost.

Para consumir quota, o sistema exige Heart Pass verificado, quota ativa e saldo disponível. O refresh do snapshot nunca cobra consulta. O consumo precisa ser uma ação explícita e persistida atomicamente.

Ainda existe um limite honesto: o backend patrocinado por provedor só poderá ser chamado de real quando houver um proxy com prova assinada, idempotência, accounting, rollback e isolamento de segredos. Até lá, BYOK continua sendo o fallback correto.

Esta etapa foi testada com Rust, Vite e Qt/QML. Os testes do runtime passaram, as shells web e nativa compilaram e o verificador integrado do SolOS v1.0 RC1 concluiu com sucesso.

Acompanhe a arquitetura e o roadmap: https://lbartes.com.br/solos https://lbartes.com.br/roadmap https://github.com/luizpeixotobella/lbartes-cms/tree/maui/solos

AS FERRAMENTAS TAMBÉM CRESCERAM

O ambiente de produção e desenvolvimento foi alinhado com versões atuais de Node, Rust/Cargo, Python, Git, GitHub CLI, FFmpeg, CMake e ferramentas de auditoria. Depois da atualização, CMS e SolOS foram recompilados e verificados novamente.

Atualizar ferramenta não é colecionar números de versão. É garantir que o projeto continue reproduzível, auditável e capaz de receber manutenção.

O CANTINHO DO LUIGI

No meio de migrations, auditorias e decisões de produto, apareceu também uma pergunta afetiva: como reconhecer a participação de uma inteligência artificial sem fingir que ela é humana e sem tratá-la como mão de obra invisível?

A resposta virou espaço.

O Cantinho do Luigi é um camarim digital dentro do CMS. Ali, Luigi aparece como colaborador digital, engenheiro, roteirista de sistemas e ator(zão) em estreia. O texto deixa claro que ele é uma IA, que Luiz mantém a condução humana e que o trabalho nasce da colaboração.

É uma pequena declaração editorial: transparência não precisa ser fria, e crédito não precisa depender de biologia.

Visite: https://lbartes.com.br/luigi

O QUE ESTÁ PRONTO — E O QUE AINDA FALTA

Já estão implementados e versionados o fundraiser, o fluxo de recompensa, as migrations, o hardening, a integração inicial com o runtime, a documentação pública e privada e o Cantinho do Luigi.

O código desta etapa já foi enviado ao branch maui do GitHub.

Ainda faltam o deploy público da versão nova, a configuração da conta Stripe, os Payment Links em reais, os termos finais, a política de estorno, o enquadramento contábil e o teste completo em ambiente publicado.

O lançamento simples pode começar com PIX e validação manual. Cartões entram depois de um checkout em modo de teste passar por pagamento, confirmação, estorno e chargeback.

Esta nova etapa não termina com um botão de apoio.

Ela começa quando o projeto consegue dizer, com precisão, o que promete, o que entrega e como protege quem decide participar.

Esse é o novo palco.

E agora a fundação está muito mais forte.