Um motor web concebido
como um sistema operativo

O painel de controlo mostra o que o espera sem abrir um único plugin: encomendas pagas por enviar, pedidos nunca vistos, erros críticos, os compromissos do dia. Um distintivo, um número, uma cor; o detalhe fica na dica. Cada mosaico tem a faixa da sua categoria, que fica vermelha quando algo é crítico e pulsa quando há novidades desde a sua última visita.

Para um programador, é uma pasta dashboard/ no plugin e um ficheiro que devolve alguns números: o motor trata dos níveis de acesso, dos grupos, da memória do «visto» e da apresentação. Adicionar um diagnóstico ao seu plugin (francês) →

O BeamReactor não é um conjunto de scripts. É um sistema construído em torno de um núcleo centralizado — o motor XDP — inspirado na estrutura interna de um sistema operativo.

Cada pedido HTTP entra por um ponto único. O núcleo trata do encaminhamento, da aplicação dos protocolos de segurança, da gestão de sessões, do carregamento dos plugins e da renderização da saída. Nenhum script PHP pode ser executado sem passar por ele. Não é uma convenção — é uma impossibilidade estrutural imposta pela própria arquitetura.

Esta centralização garante a aplicação uniforme dos protocolos de segurança em todo o sistema, desde a autenticação do utilizador até à renderização final da página. Os plugins não podem contornar a sanitização, não podem emitir SQL em bruto e não podem interromper a execução (exit / die são estruturalmente proibidos). O núcleo mantém sempre o controlo para assegurar o encerramento correto da sessão e a gestão coerente dos erros.

Cada funcionalidade do BeamReactor vive como um plugin autónomo. O núcleo encaminha, protege e orquestra — nada mais. Isto significa que a superfície de ataque de uma dada instalação é exatamente proporcional ao que ativar. Um plugin inativo representa zero linhas de código expostas.

Quando um plugin é chamado, o motor trata automaticamente do carregamento da configuração, da injeção das bibliotecas, da seleção da locale segundo a língua do utilizador e do registo das rotas. Vários plugins coexistem na mesma página sem colisão — cada um opera no seu próprio espaço de nomes, com os seus próprios recursos CSS e JavaScript.

Cada plugin inclui a sua própria documentação (/doc/), o seu próprio conjunto de testes (/tests/), o seu próprio mapeamento de moderação para a conformidade com o RGPD (.moderation.json) e a sua própria declaração de sitemap (.sitemap.json) para o motor de pesquisa. A instalação é colocar uma pasta. A remoção é retirá-la.

A segurança no BeamReactor não é uma camada acrescentada por cima. É a própria arquitetura. Cada dado que entra ou sai do sistema passa pelo Sanitizer\Parser, que valida contra tipos estritos: primitivos (bool, int, float, string com restrições de comprimento), estruturados (email, URL, UUID, IP, data, JSON), ricos (HTML com whitelist de etiquetas, Markdown, SQL apenas em consultas preparadas) e de negócio (ficheiros com validação de MIME/tamanho/extensão, imagens, tokens).

As interações com a base de dados usam exclusivamente consultas preparadas. A concatenação direta de parâmetros é estruturalmente impossível através da camada de abstração SQL (BDAL). O sistema deteta e previne as injeções SQL, o XSS, os ataques por overflow de cadeias, as injeções de comandos shell, o path traversal e as manipulações NaN/Infinity.

As sessões são protegidas pelo rastreio permanente do IP, pela impressão digital do User-Agent, pela limitação adaptativa do débito de pedidos e pela expiração temporal. A autenticação usa Argon2id do lado do servidor e PBKDF2 do lado do cliente, com salt individual por utilizador, 2FA e tokens anti-CSRF de utilização única. Honeypots ativos — campos de formulário ocultos, URLs armadilhados, análise da temporização dos pedidos — identificam e colocam em quarentena os atacantes antes que cheguem aos seus dados.

O BeamReactor gere os níveis de privilégios de forma dinâmica. Os valores por defeito são definidos na configuração, mas podem ser substituídos em runtime a partir da base de dados ou de um include — em função da carga do servidor, do nível de ameaça ou do desempenho dos plugins.

Sob carga elevada, os plugins que consomem muitos recursos ficam automaticamente restritos aos utilizadores de nível superior. Em caso de ataque, o sistema pode limitar o acesso apenas aos administradores sem nova implementação. Um plugin que ultrapasse um segundo de tempo de geração é automaticamente colocado em quarentena — desativado para os utilizadores normais, enquanto os administradores mantêm o acesso para o diagnóstico.

É load balancing ao nível aplicacional, baseado na hierarquia de privilégios. O sistema mede o tempo de geração por plugin, avalia a carga atual face ao número de ligações e à capacidade, decide se restringe ou não o acesso e preserva o acesso de administração para o diagnóstico. Nenhuma intervenção humana necessária. Um plugin com erros ou atacado não derruba o site — isola-se sozinho.

O BeamReactor assenta num princípio simples: os dados dos seus utilizadores pertencem-lhes. Recolha mínima, dados sensíveis cifrados, nenhum rastreio de terceiros, eliminação real (não uma simples flag) e exportação completa dos dados. Estes princípios estavam em vigor desde 2003 — doze anos antes da redação do RGPD.

Cada plugin inclui um ficheiro .moderation.json que mapeia exatamente que dados de utilizador guarda e como esses dados devem ser tratados numa anonimização, num apagamento ou no tratamento de uma queixa. Quando é feito um pedido RGPD, o motor percorre o mapeamento de moderação de cada plugin instalado e executa a ação adequada — anonimizar, eliminar ou exportar — sem intervenção manual plugin a plugin.

Do mesmo modo, cada plugin declara um .sitemap.json que mapeia o seu conteúdo público para o motor de pesquisa interno e para o gerador de sitemap. Isto garante que a indexação do conteúdo está sempre exata, sempre atualizada e sempre sob o controlo do autor do plugin, em vez de um crawler global frágil.

Até os formatos de documentos são concebidos para o desempenho. Os formatos .dta e .err são zero-parse, zero-BD, zero-função em runtime: uma diretiva por linha, chave-valor separados por um espaço, carregados uma única vez no bootstrap em constantes PHP puras colocadas em cache pelo opcache. O parsing demora menos de 0.01µs. Uma página de erro completa pesa menos de 2 KB.

O editor WYSIWYG, o sistema multilingue, o motor de analytics, o catálogo de bots — nenhum destes componentes depende de serviços externos. Nada de Google Analytics, nenhuma dependência de CDN, nenhum script externo a comunicar com o exterior. Tudo corre no seu servidor, sob o seu controlo.

O BeamReactor foi concebido, desenvolvido e mantido pelo mesmo arquiteto desde 2003. Não houve nenhuma transferência, nenhuma reescrita, nenhuma decisão de comité. Cada linha de código segue a mesma filosofia security-first, performance-first definida desde o primeiro dia.

O resultado é uma coerência arquitetural que nenhum CMS comunitário consegue igualar. O código é 100% auditável. O historial de segurança é público: zero CVE conhecidas em 22 anos. O sistema funciona com zero dependências de terceiros — sem Composer, sem Node, sem etapa de build. Upload FTP, configuração, execução.

Os CMS populares são alvos massivos. Uma vulnerabilidade descoberta no WordPress afeta milhões de sites em simultâneo. A arquitetura única do BeamReactor e a sua base de instalação confidencial tornam-no estruturalmente desinteressante para os atacantes automatizados — uma segurança pela originalidade arquitetural, em complemento de uma verdadeira segurança técnica.