Un motor web concebido
como un sistema operativo

El panel de control muestra lo que le espera sin abrir un solo plugin: pedidos pagados por enviar, tickets nunca vistos, errores críticos, las citas del día. Una insignia, un número, un color; el detalle está en la información emergente. Cada mosaico lleva la franja de su categoría, que se vuelve roja cuando algo es crítico y late cuando hay novedades desde su última visita.

Para un desarrollador, es una carpeta dashboard/ en su plugin y un archivo que devuelve unas cifras: el motor se encarga de los niveles de acceso, los grupos, la memoria de lo «visto» y la presentación. Añadir un diagnóstico a su plugin (francés) →

BeamReactor no es un conjunto de scripts. Es un sistema construido en torno a un núcleo centralizado — el motor XDP — inspirado en la estructura interna de un sistema operativo.

Cada petición HTTP entra por un único punto. El núcleo se encarga del enrutamiento, de la aplicación de los protocolos de seguridad, de la gestión de sesiones, de la carga de los plugins y del renderizado de la salida. Ningún script PHP puede ejecutarse sin pasar por él. No es una convención — es una imposibilidad estructural impuesta por la propia arquitectura.

Esta centralización garantiza la aplicación uniforme de los protocolos de seguridad en todo el sistema, desde la autenticación del usuario hasta el renderizado final de la página. Los plugins no pueden eludir la sanitización, no pueden emitir SQL en bruto y no pueden interrumpir la ejecución (exit / die están estructuralmente prohibidos). El núcleo conserva siempre el control para asegurar el cierre limpio de la sesión y la gestión coherente de los errores.

Cada funcionalidad de BeamReactor vive como un plugin autónomo. El núcleo enruta, protege y orquesta — nada más. Esto significa que la superficie de ataque de una instalación dada es exactamente proporcional a lo que usted active. Un plugin inactivo representa cero líneas de código expuestas.

Cuando se llama a un plugin, el motor se encarga automáticamente de cargar la configuración, inyectar las bibliotecas, seleccionar la locale según el idioma del usuario y registrar las rutas. Varios plugins conviven en la misma página sin colisiones — cada uno opera en su propio espacio de nombres, con sus propios recursos CSS y JavaScript.

Cada plugin incluye su propia documentación (/doc/), su propio conjunto de pruebas (/tests/), su propia cartografía de moderación para la conformidad con el RGPD (.moderation.json) y su propia declaración de sitemap (.sitemap.json) para el motor de búsqueda. La instalación consiste en dejar una carpeta. La eliminación, en retirarla.

La seguridad en BeamReactor no es una capa añadida por encima. Es la propia arquitectura. Cada dato que entra en el sistema o sale de él pasa por Sanitizer\Parser, que lo valida contra tipos estrictos: primitivos (bool, int, float, string con restricciones de longitud), estructurados (email, URL, UUID, IP, fecha, JSON), ricos (HTML con whitelist de etiquetas, Markdown, SQL solo en consultas preparadas) y de negocio (archivos con validación de MIME/tamaño/extensión, imágenes, tokens).

Las interacciones con la base de datos usan exclusivamente consultas preparadas. La concatenación directa de parámetros es estructuralmente imposible a través de la capa de abstracción SQL (BDAL). El sistema detecta y previene las inyecciones SQL, el XSS, los ataques por desbordamiento de cadenas, las inyecciones de comandos shell, el path traversal y las manipulaciones NaN/Infinity.

Las sesiones están protegidas por el seguimiento permanente de la IP, la huella del User-Agent, la limitación adaptativa del ritmo de peticiones y la caducidad temporal. La autenticación usa Argon2id en el servidor y PBKDF2 en el cliente, con salt individual por usuario, 2FA y tokens anti-CSRF de un solo uso. Honeypots activos — campos de formulario ocultos, URL trampa, análisis de la temporización de las peticiones — identifican y ponen en cuarentena a los atacantes antes de que lleguen a sus datos.

BeamReactor gestiona los niveles de privilegios de forma dinámica. Los valores por defecto se definen en la configuración, pero pueden sustituirse en tiempo de ejecución desde la base de datos o desde un include — en función de la carga del servidor, del nivel de amenaza o del rendimiento de los plugins.

Con carga elevada, los plugins que consumen muchos recursos se restringen automáticamente a los usuarios de nivel superior. En caso de ataque, el sistema puede limitar el acceso solo a los administradores sin volver a desplegar. Un plugin que supera un segundo de tiempo de generación se pone automáticamente en cuarentena — desactivado para los usuarios normales, mientras los administradores conservan el acceso para el diagnóstico.

Es load balancing en el nivel de la aplicación basado en la jerarquía de privilegios. El sistema mide el tiempo de generación por plugin, evalúa la carga actual frente al número de conexiones y la capacidad, decide si restringe o no el acceso y preserva el acceso de administración para el diagnóstico. No se requiere intervención humana. Un plugin con errores o atacado no tumba el sitio — se aísla por sí solo.

BeamReactor se basa en un principio sencillo: los datos de sus usuarios les pertenecen. Recogida mínima, datos sensibles cifrados, ningún rastreo de terceros, eliminación real (no una simple marca) y exportación completa de los datos. Estos principios estaban en vigor desde 2003 — doce años antes de la redacción del RGPD.

Cada plugin incluye un archivo .moderation.json que describe exactamente qué datos de usuario almacena y cómo deben tratarse en una anonimización, un borrado o la tramitación de una queja. Cuando se formula una solicitud RGPD, el motor recorre la cartografía de moderación de cada plugin instalado y ejecuta la acción adecuada — anonimizar, eliminar o exportar — sin intervención manual plugin por plugin.

Del mismo modo, cada plugin declara un .sitemap.json que describe su contenido público para el motor de búsqueda interno y el generador de sitemap. Así, la indexación del contenido es siempre exacta, siempre está al día y siempre está bajo el control del autor del plugin, y no de un crawler global frágil.

Incluso los formatos de documento están diseñados para el rendimiento. Los formatos .dta y .err son zero-parse, zero-BD, zero-función en tiempo de ejecución: una directiva por línea, clave-valor separados por un espacio, cargados una sola vez en el bootstrap como constantes PHP puras guardadas en caché por opcache. El análisis tarda menos de 0.01µs. Una página de error completa pesa menos de 2 KB.

El editor WYSIWYG, el sistema multilingüe, el motor de analítica, el catálogo de bots — ninguno de estos componentes depende de servicios externos. Nada de Google Analytics, ninguna dependencia de CDN, ningún script externo que se comunique con el exterior. Todo funciona en su servidor, bajo su control.

BeamReactor ha sido diseñado, desarrollado y mantenido por el mismo arquitecto desde 2003. No ha habido ninguna cesión, ninguna reescritura, ninguna decisión de comité. Cada línea de código sigue la misma filosofía security-first, performance-first establecida desde el primer día.

El resultado es una coherencia arquitectónica que ningún CMS comunitario puede igualar. El código es 100% auditable. El historial de seguridad es público: cero CVE conocidas en 22 años. El sistema funciona con cero dependencias de terceros — sin Composer, sin Node, sin etapa de build. Subida por FTP, configuración, ejecución.

Los CMS populares son objetivos masivos. Una vulnerabilidad descubierta en WordPress afecta a millones de sitios a la vez. La arquitectura única de BeamReactor y su base de instalación confidencial lo hacen estructuralmente poco interesante para los atacantes automatizados — una seguridad por originalidad arquitectónica, como complemento de una verdadera seguridad técnica.