Ahora con creación de páginas por IA vía el servidor MCP

Cuenta

Qué concede tu plan, qué límites se aplican y cómo los roles deciden quién puede qué.

Un workspace lleva un plan, un conjunto de límites y una lista de miembros. Los tres se pueden leer por programa, lo que hace que merezca entenderlos en vez de descubrirlos en el peor momento.

Plan y límites

Cada workspace informa de su plan y de los topes que trae:

{
  "name": "Acme",
  "slug": "acme",
  "plan": "enterprise",
  "limits": {
    "maxPages": 999999,
    "maxMembers": 999999,
    "maxWorkspaces": 999999,
    "maxStorageMb": 999999,
    "maxAiTokensMonth": 999999,
    "maxApiRequestsMonth": 999999999,
    "maxBandwidthGbMonth": 999999,
    "canRemoveBranding": true,
    "canUseCart": true
  }
}

Esas cifras vienen de un workspace enterprise, donde los topes están tan altos que resultan prácticamente ilimitados. Los planes menores devuelven valores reales, y por eso conviene leerlos en vez de fijar una suposición en el código.

Ahí conviven dos clases de cosa. Los topes -páginas, miembros, almacenamiento, tokens de IA, peticiones de API, ancho de banda- son cantidades que puedes agotar. Las banderas de capacidad -canRemoveBranding, canUseCart- son funciones encendidas o apagadas.

Léelos en vez de suponerlos. Un paso de build que crea páginas, o un script que sube medios en masa, debería saber bajo qué tope trabaja.

El límite de entrega falla de forma confusa

Supera el cupo mensual de entrega y public.siteConfig deja de responder. Tu sitio se comporta entonces exactamente como si el slug del workspace fuera erróneo o la red estuviera caída.

Por eso el preflight de cmssy link distingue los tres casos en vez de informar un único "no se alcanza el workspace". Si tu sitio de pronto no carga nada y no cambiaste la configuración, revisa el consumo antes que el DNS.

Roles

Los permisos usan la forma recurso:acción: pages:view, media:upload, forms:submissions:manage, workspace:billing. Un rol es un paquete con nombre de esos permisos.

Los roles llevan dos banderas que conviene conocer:

  • isSystem: integrado y no editable. Owner es el rol de sistema y tiene *: todos los permisos, incluidos los futuros. Ese comodín es justo el punto: una función nueva no obliga a actualizar el rol.
  • isDefault: el rol que reciben los miembros nuevos. Defínelo a propósito; lo que contenga es lo que concede una invitación antes de que nadie la revise.

Roles de equipo y roles de miembro son cosas distintas

Un workspace puede tener un rol sin ningún permiso, normalmente llamado algo como Customer. No es un error de configuración.

Los miembros del sitio que inician sesión en tu web pública no son las personas que la editan. Un rol de miembro existe para etiquetar y agrupar a esos visitantes; no concede nada en el workspace porque un cliente de tu tienda no pinta nada en tu CMS. Los roles de equipo conceden permisos del workspace; los de miembro identifican audiencias.

Confundirlos es como un rol de cliente acaba adquiriendo pages:edit en silencio.

La granularidad es deliberada

La lista separa cosas que esperarías juntas. pages:edit y pages:publish son distintos: puedes dejar que alguien escriba sin dejar que publique. forms:view y forms:submissions:view son distintos: construir un formulario de contacto no exige leer lo que la gente envió por él.

Tómate en serio esa división al componer roles. La tentación por defecto es repartir espacios de nombres enteros, y en cuanto lo haces, "puede editar textos" y "puede leer mensajes de clientes" pasan a ser la misma concesión.

Siguientes pasos