Las 14 Leyes
Estas reglas rigen cada decisión, cada línea de código y cada module. Son innegociables. El núcleo es la base — no se cambia la base, se construye sobre ella.
1. Todo es un path
Cada recurso, servicio, dispositivo, API, fichero o acción se accede a través de un path. Un path es la dirección universal. Sin excepciones.
/node/module/resource
/local/serial/com1/read
/local/web/api/v1/users
/remote-dc1/db/postgres/query
/local/auth/login
Si existe, tiene un path. Si tiene un path, se puede alcanzar.
2. Todo es un mensaje
Toda la comunicación fluye a través de una única estructura: el Message. Petición, respuesta, evento, notificación — todo son mensajes.
Un mensaje tiene: un path, un method, headers, un body y un contexto. Nada se comunica fuera de esta estructura. Sin puertas traseras, sin atajos.
3. El núcleo no hace nada
El núcleo es un router, un cargador y un árbitro. No implementa lógica de negocio. Enruta mensajes, carga módulos, aplica control de acceso y traza la ejecución.
Toda la funcionalidad reside en los módulos. Un servidor web es un module. Un conector de base de datos es un module. Un lector RS232 es un module. Un proveedor de autenticación es un module.
El núcleo sin módulos está en silencio. Eso es correcto.
4. Sin dependencias rígidas
Si el module A necesita al module B y B no está cargado, A no falla catastróficamente. A recibe una respuesta limpia de «no disponible» y decide qué hacer.
Toda dependencia es blanda. Toda ausencia es elegante. Un module debe estar diseñado para funcionar en modo degradado, no para exigir perfección.
5. Hot-load para todo
Los módulos se cargan, descargan y recargan en tiempo de ejecución sin detener el núcleo. El sistema nunca se detiene. Las piezas van y vienen. El núcleo perdura.
portal:/> module load web
portal:/> module reload iot
portal:/> module unload mqtt
6. Una interfaz, universal
Un module que lee RS232 habla el mismo idioma que un module que sirve HTTP. La estructura de mensaje es la lingua franca. Apréndela una vez, construye cualquier cosa.
Un module de interfaz web puede consultar un module de puerto serie usando el mismo mecanismo que utiliza para consultar un module de base de datos. Sin adaptadores, sin código de unión.
7. Los nodos son iguales
Un nodo es un núcleo en ejecución. Los nodos se conectan para formar una red. Un path remoto funciona exactamente igual que un path local — el núcleo gestiona la federation de forma transparente.
/local/db/users/query # procesado localmente
/node-west/db/users/query # enrutado a node-west, mismo formato
Un module no necesita saber si un recurso es local o remoto.
8. Propiedades de los recursos
Cada recurso declara su modo de acceso: READ, WRITE o RW. Ningún recurso existe sin un modo de acceso declarado. Esto se aplica en el momento del registro.
9. Autenticación de módulos
Cada module se autentica al cargarse. Las credenciales provienen de la configuración (usuario + contraseña o API key). Por defecto = root. Los permisos se heredan por todo el código que ejecuta.
10. Todo es un evento
Cada escritura, ejecución o modificación emite un evento. Los eventos se encadenan: un evento dispara N más. Nada sucede en silencio.
Este es el sistema nervioso de TLS. Una escritura en caché emite un evento. Un webhook escucha. Un cron job se dispara. Un registro de auditoría lo graba. El sistema se observa a sí mismo.
11. Los ficheros de configuración son documentación
Cada fichero .conf enumera TODAS las opciones con comentarios, descripciones y valores por defecto. El fichero de configuración ES la documentación. Un usuario nuevo lee la configuración y comprende el module.
12. Nombres universales de recursos
Todos los recursos usan la misma sintaxis de path en todas partes. ls, get, set funcionan de forma idéntica para local y remoto. Los recursos se encuentran por nombre automáticamente en todos los nodos. Una sintaxis, todos los módulos, todos los paths.
13. Nunca bloquear el event loop
Las operaciones de módulos que realizan E/S deben usar thread pool o epoll. El tamaño del thread pool debe ser configurable. Los nuevos clientes esperan cuando los hilos están ocupados. El event loop es sagrado.
14. Bloqueo exclusivo de recursos
Los recursos físicos (serial, GPIO, IoT) se bloquean automáticamente en la primera escritura. Keepalive implícito por uso. Liberación automática tras 60 segundos de inactividad. La configuración queda protegida mientras está bloqueada. Las suscripciones a eventos permanecen siempre abiertas.
Resumen
| # | Principio | En una frase |
|---|---|---|
| 1 | Path | Todo tiene una dirección |
| 2 | Message | Una estructura para toda la comunicación |
| 3 | Core | Enruta y carga, nada más |
| 4 | Soft deps | La ausencia se gestiona, nunca es fatal |
| 5 | Hot-load | Los módulos van y vienen en tiempo de ejecución |
| 6 | Universal | Misma interfaz para puertos serie y APIs REST |
| 7 | Nodes | Federation transparente de núcleos |
| 8 | Properties | Cada recurso declara READ, WRITE o RW |
| 9 | Auth | Cada module tiene identidad |
| 10 | Events | Cada cambio es observable |
| 11 | Config | Los ficheros de configuración son documentación |
| 12 | URN | Una sintaxis, todos los módulos, todos los nodos |
| 13 | Non-blocking | El event loop es sagrado |
| 14 | Locking | El acceso físico es exclusivo |