For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /es/docs/web/content.md (or send Accept: text/markdown).
Gestión de contenido
Entradas CMS tipadas con un ciclo de vida libre y un límite de lectura público.
Guía paso a paso para principiantes
Requisitos previos: lea las dos guías para principiantes a continuación, finalice la configuración local web y abra este monorepo en la raíz de su editor. La configuración web pertenece a apps/web/.env.local; Next.js no lee la raíz .env. /dashboard en el modo falso predeterminado es una demostración sin base de datos; /auth necesita una base de datos migrada.
Términos breves: un espacio de trabajo son los usuarios, datos y configuraciones separados de un equipo. El servidor es el backend confiable; Mantenga las claves del proveedor fuera del código del navegador y del teléfono. Una migración es un cambio de base de datos versionada que crea o actualiza tablas. Un modelo de IA es el motor que responde; el catálogo de modelos es la lista del servidor de ID de modelos disponibles y precios. Un proveedor es un servicio externo, como inteligencia artificial, correo electrónico o servicio de facturación. Un derecho es una concesión que permite que un espacio de trabajo utilice una función. Un webhook es un mensaje que un servicio envía al URL de otro servicio.
1. Inicie sesión como propietario o administrador del espacio de trabajo, abra /content y use el formulario para crear una publicación, página, documento o informe con un slug único. Guárdelo como borrador y luego publíquelo.
2. Confirmar los cambios de estado a publicado; un slug o miembro duplicado sin acceso de administración debería fallar.
3. Para una prueba cerrada, utilice required_entitlement=ai.reference-task; sin una concesión verificada, la página debe mostrar solo su avance.
Para obtener código personalizado, comience con el prompts/README.md proporcionado y copie el mensaje más cercano: prompts/new-app-screen.md para una pantalla de aplicación o prompts/new-landing-page.md para una página pública. Para trabajos de servidor, base de datos o proveedor, asigne a su agente de codificación la tarea de esta guía y pídale que lea AGENTS.md, .ai/PROJECT_CONTEXT.md y los espejos .ai/ correspondientes; inspeccionar los archivos fuente exactos nombrados aquí; enumerar archivos y verificaciones antes de editarlos; preservar la propiedad del espacio de trabajo y los secretos exclusivos del servidor; y mostrarte la diferencia. Dígale el comportamiento que desea, los campos de entrada y salida, los roles permitidos, los éxitos y errores esperados y la cuenta, proveedor o dispositivo de prueba. Utilice valores de muestra; Nunca pegues un verdadero secreto.
Crea entradas del espacio de trabajo
El gestor /content administra entradas de tipo post, page, doc y report. Las filas content_entry tienen estado draft/published/archived, slugs con ámbito de espacio de trabajo y autoría. Las acciones de administración requieren el rol owner/admin adecuado.
Este CMS es independiente del catálogo tipado de documentación/blog público del kit en src/resources. Un producto puede representar entradas del CMS mediante la composición de su propia página.
Protege el cuerpo en el servidor
required_entitlement acepta null: las entradas sin valor no están protegidas. En las entradas protegidas, content-queries.ts, solo en el servidor, proyecta el contenido legible o una vista previa bloqueada con el cuerpo vacío. content-access.ts gestiona la proyección; nunca confíes en una afirmación de derechos enviada por el cliente.
La publicación emite content.published; los resúmenes programados pueden condensar las entradas recientes del equipo que publica. El contenido creado también se incluye en la exportación de la cuenta.
Verifica la publicación y el acceso
Prueba la visibilidad de borradores, las transiciones de publicación/archivo, slugs duplicados, otro espacio de trabajo, entradas gratuitas y permisos de pago inactivos. Usa el bloque de control de acceso de pago para la presentación, mientras el servidor sigue siendo responsable del acceso.
Configuración y ajustes
La superficie de workspace /content gestiona entradas CMS — post, page y doc son los tipos sugeridos, pero la columna acepta cualquier tipo de producto seguro para URL (minúsculas, dígitos, guiones, guiones bajos, hasta 64 caracteres). La tabla content_entry delimita cada fila por workspaceId, estampa createdBy y mantiene los slugs únicos por workspace y tipo.
Las entradas atraviesan un ciclo de vida libre draft ↔ published ↔ archived — evaluateContentStatusChange en src/content.ts rechaza transiciones inválidas o sin cambios, y publishedAt se estampa en la primera publicación y sobrevive a despublicaciones posteriores para que los lectores conserven la fecha original.
/content workspace CMS surface
src/content.ts input + lifecycle rules
src/content-actions.ts member+ mutations
content_entry workspaceId, type, slug, statusFlujo de implementación
Los miembros y superiores crean entradas — cada mutación resuelve la sesión, el workspace activo y al menos el rol de miembro mediante requireWorkspaceWriter (workspace-access.ts), así que los invitados son de solo lectura. normalizeContentEntryInput valida el tipo, un título de 1–255 caracteres y un slug seguro para URL antes de cualquier escritura.
listPublishedContentEntries es el límite de lectura público deliberado: toma un workspaceId explícito, no necesita sesión y devuelve solo filas publicadas — la vía que las páginas de tienda, blogs y docs usan para renderizar contenido del workspace. Publicar emite un webhook saliente content.published, y las entradas creadas se unen a la exportación de datos GDPR.
Verificación y solución de problemas
Ejercita un ciclo draft → publish → archive completo, un slug duplicado dentro del mismo tipo y una lectura entre workspaces. Confirma que el límite público nunca devuelve borradores ni filas de otro workspace, y que content.published se dispara una vez por acción de publicación.