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

Cómo funciona cmssy

Qué vive en cmssy, qué vive en tu repositorio y qué ocurre entre una petición y una página renderizada.

cmssy guarda tu contenido y nunca lo renderiza. Tu aplicación renderiza tu contenido y nunca lo guarda. Todo lo demás se deriva de esa única separación.

Qué vive dónde

  • En tu repositorio: los esquemas de bloques y los componentes. Un bloque es un componente de React más un esquema de campos, declarado con defineBlock. Es código: revisado, versionado, desplegado.
  • En cmssy: páginas, instancias de bloques y sus valores, medios, modelos y registros, formularios. Son datos: editados visualmente o por un cliente de IA, publicados sin desplegar.

La frontera entre ambos no se mueve. Añadir un campo implica publicar código. Cambiar un titular, no.

Qué es una página

Una página es un nodo de un árbol. Tiene un slug derivado de sus padres, una lista ordenada de instancias de bloque que forman su cuerpo y un layout: bloques de cabecera y pie que posee o hereda de su padre.

Cada instancia de bloque guarda sus valores indexados por idioma, así que content.es.title y content.en.title son el mismo campo de la misma instancia en dos locales. No hay una página traducida aparte.

De la petición a la página renderizada

Un frontend de cmssy necesita una sola ruta. Esta es entera:

// app/[[...path]]/page.tsx
import { createCmssyPage } from "@cmssy/next/server";
import { cmssy } from "@/cmssy/config";
import { blocks } from "@/cmssy/blocks";

export const revalidate = 3600;

export default createCmssyPage(cmssy, blocks);

Qué ocurre cuando llega una petición:

  1. La ruta catch-all recibe la ruta y la convierte en un slug.
  2. El SDK pide a la API de entrega la página publicada en ese slug, junto con sus bloques de layout. Sin token: el contenido publicado es público.
  3. Cada instancia de bloque devuelta lleva un type. El SDK busca ese tipo en el registro que pasaste como segundo argumento.
  4. Tu componente se renderiza con el contenido de esa instancia para el locale activo. Los campos de relación llegan ya resueltos a registros completos.
  5. Un tipo de bloque que falte en tu registro no renderiza nada en tu sitio, y muestra una tarjeta de diagnóstico con el nombre del tipo al abrir el editor. Un bloque que lanza, en su loader o en su render, queda contenido igual. El contenido no puede tumbar tu aplicación.

El registro es un array corriente que mantienes tú:

// cmssy/blocks.ts
import { heroBlock } from "@/blocks/hero/block";
import { pricingBlock } from "@/blocks/pricing/block";

export const blocks = [heroBlock, pricingBlock];

Los paquetes

El framework es un adaptador, nunca el cimiento:

  • @cmssy/core: transporte, consultas, configuración, protocolo del editor. Cero framework. Corre en Node, en el edge, en un navegador, en un cron.
  • @cmssy/react: renderizado: registro de bloques, componentes, puente de edición, hooks.
  • @cmssy/next: solo enlaces con Next.js: middleware, route handlers, Metadata, sitemap y robots, fábricas de páginas.

Los adaptadores para otros frameworks se sitúan junto a next, no encima, así que una app de Astro o Remix nunca instala React solo para pedir una página.

@cmssy/next se divide por runtime y las entradas no se mezclan: @cmssy/next/middleware corre en el edge, /server en RSC y route handlers, /client en el navegador.

Edición

Dos vías de entrada, un solo contenido.

El editor visual carga tu sitio real en un marco y habla con él por postMessage. Editas los componentes de verdad, no una aproximación de vista previa; por eso el puente de edición vive en core y no en el paquete de React.

El servidor MCP da a un cliente de IA el mismo acceso de escritura: crear páginas, editar contenido de bloques, subir medios, publicar. Edita contenido, nunca tu código.

Borradores y publicación

Las ediciones aterrizan en un borrador. La API de entrega pública solo devuelve contenido publicado, así que una página sin terminar es invisible para tu sitio por construcción, no por un filtro que debas recordar aplicar.

Para ver borradores durante el desarrollo, añade ?cmssyDev=1 a cualquier URL. Requiere CMSSY_API_TOKEN y renderiza tu propia capa de borrador; sin el flag obtienes contenido publicado.

Publicar no despliega. Tu aplicación cachea páginas según su propio valor de revalidate, y cmssy puede llamar a un webhook de revalidación al publicar para invalidarlas antes.

Siguientes pasos