MIAMI DJ BEAT LLC · Road Map IA
Humanos y agentes de inteligencia artificial trabajando en equipo: las personas deciden, los agentes preparan el terreno. Este recorrido te enseña la parte que te toca a ti — y lo conduce el propio sistema, que es la mejor forma de demostrar que funciona.
Miami DJ Beat no es un sitio web con una base de datos detrás: son diez capas apiladas, cada una con un trabajo distinto y con permiso para hablar solo con sus vecinas.
Léelo de abajo hacia arriba y de arriba hacia abajo. Arriba está lo que el público toca. Abajo está lo que ningún usuario ve nunca: el esquema de datos, las políticas de acceso y el gobierno del proyecto.
La regla que sostiene todo el mapa es una sola: un concepto de negocio tiene un solo dueño. El dinero se calcula en un único motor; la identidad se decide en una única capa; la agenda vive en un único lugar. Cuando una pantalla necesita un dato, lo pide — no lo vuelve a calcular.
El número al final de cada franja es cuántas piezas reales del repositorio viven hoy en esa capa. Ese número lo cuenta el generador, no yo.
Antes de que nada funcione, el sistema tiene que saber quién eres. No hay una sola cuenta con superpoderes: hay categorías, y cada una vive en su propio portal.
Cliente, Artista y Staff son tres mundos separados a propósito. Cada portal se implementa por su cuenta, incluida su barra de navegación. Compartir un menú entre portales ya fue una regresión en V1 y por eso no se repite.
El Owner no es un DJ. Son dos cuentas distintas, con correo y login distintos, aunque las manejen las mismas manos. Esa separación es lo que permite auditar quién hizo qué.
La decisión de qué puede ver cada quien no se toma en el navegador. Se toma en la base, con políticas RLS. El frontend solo esconde botones; la base es la que niega el dato.
Cada rol entra por su propia barra, y esa decisión se toma antes de que la página se pinte. La sesión ya vive en el navegador y el rol viaja dentro del token, así que no hay que preguntarle nada al servidor para saber qué menú dibujar. Antes se pintaba uno y se cambiaba después: la barra saltaba a la vista. Elegir antes no da permisos —eso lo sigue decidiendo la base con RLS—, solo evita el parpadeo.
Desde que alguien busca un DJ en Miami hasta que la noche termina y queda la factura pagada. Este es el recorrido que más veces se repite en la plataforma.
El cliente entra por la capa pública, pide una fecha y con eso nace un lead. Ese lead es el mismo objeto que después se convierte en evento: no se vuelve a teclear en otro sistema.
Antes de que el evento se confirme hay dos compuertas que no se saltan: el documento (acuerdo de servicio) y el depósito. Si una falla, el evento no avanza de estado, aunque la fecha ya esté en el calendario.
Después del evento, el cliente conserva su portal: su historial, sus facturas, sus comprobantes y el chat con el equipo. No se le cierra la puerta cuando termina la noche.
Cuando alguien sin cuenta llega a la ficha de un DJ, ve el perfil entero —presentación, biografía, valoraciones, disponibilidad, comentarios y QR— pero con la barra de Inicio, no con la estación de trabajo del artista. La ficha es una página de conversión: está para que ese visitante explore, se suscriba y contrate, no para enseñarle herramientas que no le pertenecen.
Un artista no es un recurso que el sistema asigna: es un usuario con su propio portal, su propia agenda y su propio dinero.
El artista entra por onboarding, arma su perfil público y define su disponibilidad. Ese perfil es lo que el cliente ve en el catálogo, así que la calidad del perfil es parte del producto.
Cuando hay un evento que le calza, recibe una oferta de asignación que puede aceptar o rechazar. La asignación no se le impone en silencio.
Su centro financiero le muestra lo suyo y solo lo suyo. Un artista nunca ve el ledger de otro; eso lo garantiza la capa de identidad, no una pantalla.
La reserva de un DJ escribe en el sistema (source assignment).
La estación del artista es la misma en todas sus pantallas: Academia, Agenda, DJ Tools, Cursos, Conocimiento, Configuración y su propia ficha. Y una precisión que conviene no confundir: lo que el artista ve en Agenda es el Calendario Operacional Inteligente, el mismo motor que usa la casa. Su calendario personal sigue existiendo, pero no es lo que se le muestra.
El portal de staff es el puesto de mando: aquí se ve lo que los otros dos portales no pueden ver, y aquí se toman las decisiones que mueven dinero y fechas.
El staff trabaja sobre agregadores: la agenda y el Matrix leen datos de toda la plataforma pero reparten hacia abajo solo lo necesario. Es un flujo de una sola dirección, y quien lo hace cumplir es RLS.
Las acciones que importan — confirmar un cobro, asignar un artista, cambiar el estado de un evento — dejan rastro. Una acción consecuente sin registro es un defecto, no una comodidad.
Dentro del staff hay grados: management y ventas no ven lo mismo. El portal es uno, los permisos son varios.
El el sistema lleva riel interno —con Fénix AI y el atajo a Staff— en las nueve pantallas de gestión, no solo en dos. Antes, entrar en el panel de administración devolvía el menú del visitante.
Un solo motor calcula. Todo lo demás lo consulta. Esa es la única regla que el núcleo financiero no negocia.
El dinero entra por Stripe o por comprobante manual, se registra, y desde ahí lo consume todo el que tenga permiso: la factura del cliente, el payout del artista, la caja del owner.
el motor correspondiente es el único que produce cifras. Ninguna pantalla suma por su cuenta y ningún agente inventa un número: cuando ELIXIS habla de dinero, llama al motor.
Sound For Tips corre sobre el mismo esquema: propina del fan, comisión de plataforma, liquidación. No es un segundo sistema financiero, es otra entrada al mismo.
La capa más joven del ecosistema y la que se vigila más de cerca. ELIXIS lee, calcula, anota, agenda y cotiza en borrador. No envía mensajes ni mueve dinero.
ELIXIS corre del lado del servidor, verifica el rol de quien pregunta contra la base antes de responder, y recibe contexto vivo: artistas, bookings, pipeline, residencias, finanzas y catálogo de Miami DJ Beat LLC.
Las tools pasan por el sistema y el catálogo vive en el motor correspondiente. Lectura: finanzas, agenda, catálogo de precios. Escritura auditada: nota de lead, bloque de agenda, borrador de cotización.
el motor correspondiente persiste un draft en el motor correspondiente con totales calculados en el RPC. No crea órdenes formales ni sesiones de Stripe: eso lo hace staff con el motor correspondiente y el motor correspondiente.
Un límite de diseño que conviene conocer: el bucle de herramientas de ELIXIS da tres vueltas. Si una petición encadena más llamadas que eso, ELIXIS cierra en texto contando lo que quedó hecho y lo que falta. Por eso una tarea muy larga se pide mejor por partes.
La parte que nadie ve y que decide si la plataforma envejece bien o se contradice a sí misma.
Cada decisión con impacto duradero deja documento. Los tickets, los runbooks y las auditorías forenses del repositorio son el historial de por qué la plataforma es como es.
La regla de oro para lo que viene: ningún documento puede afirmar un estado que el código contradice. Cuando los dos discrepan, se audita — no se crea una segunda verdad. Este mapa existe justamente para que esa discrepancia se vea sola.