🏗️ Arquitectura de Microkernel Reactivo

Firefly JS se basa en una arquitectura de microkernel altamente desacoplada y reactiva. Se compone de cuatro pilares fundamentales que trabajan en armonía:

🧭 Los 4 Pilares del Orquestador

1. Config (firefly.config.ts) 📋

Es la declaración de intenciones. Define qué piezas existen y con qué parámetros operan. El Kernel no adivina; lee lo que hay aquí para saber qué cargar y cómo configurarlo.

2. Bootstrap 🚀

Es el director de escena. Su única misión es despertar a las piezas en el orden correcto (secuencial) y decidir el ciclo de vida:

• Modo Run: Ejecuta y cierra el sistema cuando el trabajo termina.
• Modo Watch: Mantiene el Kernel en memoria, permitiendo que el sistema permanezca "vivo".

3. Kernel (Cerebro Reactivo) 🧠

Es el "aire" que respiran las piezas. No contiene lógica de negocio. Solo ofrece:

• Registro: Quién es quién en el sistema.
• Bus de Eventos: Un canal de comunicación asíncrono donde las piezas emiten y escuchan sucesos.

4. Plugins vs Tools 🔌🛠️

• Plugins (Capacidades): Exponen datos o conexiones externas (ej: leer archivos, conectar con una IA).
• Tools (Acciones): Orquestan acciones usando las capacidades de los plugins. Son el "pegamento" que decide qué hacer con la información.

---

🔄 Dinámica Reactiva: Drivers vs Procesos

En Firefly JS, diferenciamos cómo interactúan los componentes según su naturaleza:

🧩 Plugins de Ejecución (Procesos)

Responden a una llamada directa y suelen ser síncronos en su flujo lógico (ej: await plugin.process()). Son predecibles y su ciclo termina al devolver el dato.

📡 Plugins de Mensajería (Drivers)

Actúan como sensores activos. Se conectan a fuentes externas (IA, Sockets, APIs, File Watchers). Su inicialización es rápida para no bloquear el arranque, pero dejan un listener activo que emite eventos al Kernel constantemente.

🛠️ Tools Orquestadoras

Pueden pedir datos a un plugin de proceso y luego quedarse escuchando los eventos de un driver para repetir o actualizar la acción.

---

📊 Ciclo de Vida y Flujo (Bootstrap)

1. Carga: El CLI lee la configuración y entrega los plugins y herramientas al Bootstrap.
2. Registro Secuencial: El Bootstrap instancia el Kernel e inicializa cada componente uno por uno. Si un componente es un Driver, se considera "listo" en cuanto abre su canal de comunicación, no cuando termina su trabajo.
3. Ejecución Inicial: Se disparan las herramientas (await tool.run(kernel)).
4. Vida en Memoria (Watch vs Run):
   • En RUN: Cuando las herramientas terminan, el Bootstrap ejecuta kernel.shutdown() y los Drivers mueren.
   • En WATCH: El Bootstrap omite el cierre. El proceso de Node.js se mantiene vivo porque los Drivers tienen escuchas activos en el Event Loop, transformando la "selva" externa (mensajes asíncronos) en eventos limpios para que las herramientas los procesen.