Definir y organizar la evolución de Nebulina IA dentro del ecosistema Nebula ERP, contemplando internacionalización, integración con MCP/Backend, componente UI Kit, manejo de contexto, soporte multi-cliente y personalización visual por cliente.
Objetivo: definir cómo se manejarán los textos de Nebulina en español/inglés y evitar textos fijos dentro del componente.
El componente de Nebulina queda completamente preparado para i18n y no contiene textos visibles hardcodeados.
Objetivo: validar cómo Nebulina obtiene información contextual del sistema para poder responder sobre la pantalla actual.
## Puntos por revisar
- ¿Cómo se conecta MCP con el Backend?
- ¿Qué información puede recibir MCP?
- ¿Cómo se identifica el usuario?
- ¿Cómo se identifica la empresa?
- ¿Cómo se identifica el producto?
- ¿Cómo se identifica la pantalla actual?
- ¿Se envía el breadcrumb?
- ¿Se envían permisos/roles?
- ¿Qué información puede consultar Nebulina?
- ¿Qué información no debe salir del contexto actual?
- ¿Cómo se controla la seguridad de la información enviada al modelo?
Este contexto debería poder formar parte de la conversación para que Nebulina pueda responder preguntas relacionadas con la pantalla actual sin que el usuario tenga que explicar dónde se encuentra.
---
# 3. Componente de panel lateral + UI Kit (Propuesta Inicial)
Actualmente Nebulina se presenta como un **panel lateral / drawer** que se superpone sobre la aplicación.
La recomendación es llevar este componente al **UI Kit**, evitando que quede acoplado a Finanzas, Tesorería, Facturación u otro producto específico.
## Estructura conceptual
```text
NebulinaPanel
│
├── Header
│ ├── Avatar Nebulina
│ ├── Nombre
│ ├── Minimizar
│ └── Cerrar
│
├── Conversation
│ ├── Mensaje bienvenida
│ ├── Mensajes usuario
│ └── Respuestas IA
│
└── Composer
├── Contexto actual
├── Adjuntar
├── Micrófono
├── Input
└── Enviar
El componente debería ser agnóstico respecto al módulo:
Cerrar y minimizar deben tener comportamientos diferentes.
El botón X debe finalizar la sesión visual/conversacional actual.
Cerrar
↓
Panel desaparece
↓
Se limpia la conversación
↓
Se limpia el contexto
El botón de minimizar debe ocultar el panel sin eliminar la información actual.
Minimizar
↓
Panel desaparece
↓
NO se elimina conversación
↓
NO se elimina contexto
Cuando el usuario vuelve a abrir Nebulina:
Conversación anterior
+
Contexto anterior
↓
Continúa la conversación
Usuario:
"Explícame esta orden de pago."
↓ Minimiza Nebulina
Usuario:
Revisa información de la pantalla.
↓ Abre nuevamente Nebulina
Nebulina:
Mantiene la conversación y el contexto anterior.
Esta etapa debe contemplarse antes de implementar una conversación compartida entre diferentes clientes.
El contexto no debe quedar como un estado global sin asociación al cliente.
Cliente
│
└── Nebulina Context
│
├── Empresa
├── Producto
├── Usuario
├── Ruta
└── Conversación
Ejemplo:
Cliente A
└── Conversación A
Cliente B
└── Conversación B
La conversación y el contexto de un cliente no deben mezclarse con los de otro.
Este aislamiento también debe contemplarse en Backend y MCP.
Actualmente el fondo de las pantallas iniciales está definido visualmente dentro del diseño.
La evolución propuesta es obtener la configuración visual según el cliente:
Backend
↓
Configuración del cliente
↓
Frontend
↓
Fondo correspondiente
| Cliente | Fondo |
|---|---|
| Cliente A | Fondo corporativo azul |
| Cliente B | Fondo personalizado |
{
"clientId": "123",
"background": {
"type": "image",
"url": "/assets/backgrounds/client-123.webp"
}
}
Si posteriormente se requiere mayor personalización:
{
"clientId": "123",
"theme": {
"backgroundImage": "...",
"primaryColor": "#...",
"secondaryColor": "#..."
}
}
La configuración debe evitar valores hardcodeados directamente en el componente.
Este punto debe trabajarse conjuntamente con Backend.
Cliente
└── Nebulina configuration
├── background
├── logo
├── colors
└── configuration
GET /api/v1/nebulina/configuration
{
"clientId": "123",
"backgroundUrl": "...",
"logoUrl": "...",
"theme": {
"primaryColor": "#..."
}
}
Crear un servicio dedicado:
NebulinaConfigurationService
y mantener la configuración mediante signals/store:
readonly configuration =
signal<NebulinaConfiguration | null>(null);
De esta forma, la configuración visual queda desacoplada del componente de presentación.
↓
NebulinaPanel.↓
↓
↓
↓
El componente de Nebulina no debe conocer la lógica de negocio de los productos.
El contexto debe entregarse de manera estructurada y no depender de leer directamente información de una pantalla específica.
La conversación debe poder mantenerse aunque el panel se minimice.
Cada cliente debe tener su propio contexto y conversación.
Los fondos, logos y temas deben provenir de una configuración administrable y no estar hardcodeados en Nebulina.
El contexto enviado a MCP/Backend debe estar limitado a la información necesaria y respetar los permisos del usuario y del cliente.
Consultar al equipo de IA cómo funcionaría.
Usuario pregunta:
"Explícame esta orden."
↓
Minimiza
↓
Continúa trabajando
↓
Abre Nebulina
↓
La conversación continúa.
Usuario termina la conversación
↓
Presiona X
↓
Se elimina el contexto conversacional
↓
Nueva apertura inicia una nueva conversación.
Cliente A
↓
Conversación A
Cambio de cliente
↓
Cliente B
↓
Conversación B
Nunca debe utilizarse la conversación de Cliente A para responder una consulta de Cliente B.
Usuario ingresa a Nebula
↓
Se identifica el cliente
↓
Frontend consulta configuración
↓
Backend devuelve branding
↓
Se carga el fondo correspondiente definido por la compañía.