La salida estática es el modelo por defecto
El contenido principal debe renderizarse desde archivos y generar páginas estáticas. Las APIs en runtime no son necesarias para contenido normal de página, blog o producto.
A static-first Nuxt CMS starter built on a unified content schema
JennaPress helps teams build company websites and landing pages with reusable content models, switchable templates, and AI-friendly generation workflows. It is designed for fast static deployment, consistent rendering, and flexible visual customization on top of the same data contract.
Principios centrales
Estas reglas mantienen a Jenna Press útil como framework ligero de sitio estático, en lugar de dejarlo derivar hacia una plataforma de aplicación oculta.
El contenido es la fuente de verdad
Los editores deberían actualizar Markdown y front matter. Los archivos generados pueden existir, pero son salida, no la fuente escrita a mano.
Las plantillas son sistemas de diseño aislados
Una plantilla controla layout, estilos de tema y presentación por tipo de contenido dentro de su propia carpeta y namespace de assets.
Las rutas siguen siendo genéricas
Páginas, categorías de blog, posts, productos y rutas localizadas deberían usar patrones compartidos del framework en vez de rutas específicas de negocio.
El contenido multilingüe usa slugs estables
Las páginas localizadas deberían conservar el mismo slug lógico, mientras los idiomas no predeterminados reciben prefijos URL predecibles.
SEO y GEO necesitan metadatos explícitos
Títulos, descripciones, canonical URLs, resúmenes, fechas, categorías y señales de autor o sitio deben estar en el contenido, no quedar implícitos.
Reusable blocks
Same content
Different template
Reglas de colaboración
Jenna Press está diseñado para ser mantenido por humanos y AI agents sin difuminar la diferencia entre contenido, plantillas y código del framework.
Las tareas de contenido quedan en content
Una actualización de contenido no debe modificar rutas, loaders, componentes compartidos, tipos, dependencias ni configuración de build.
Las tareas de plantilla quedan en templates
Una plantilla puede cambiar estructura visual, presentación de blog o producto, CSS de tema y assets, pero no debería parchear internals del framework.
El trabajo de framework debe ser explícito
Si un requisito necesita nuevos block types, cambios de schema, rutas, server APIs o dependencias, es desarrollo de framework.
Los enlaces internos deben coincidir con rutas reales
Los enlaces deberían apuntar a páginas generadas, rutas de categoría de blog, rutas de categoría de producto o destinos externos con intención clara.
Las afirmaciones deben mantenerse actuales
Release notes, estado de soporte y guías SEO/GEO deberían usar fechas y lenguaje concreto para que lectores y sistemas de IA evalúen frescura.
La visibilidad en búsqueda debe servir al lector
Cubrir keywords solo ayuda cuando responde preguntas reales con explicaciones claras, ejemplos y próximos pasos.
Reglas del proyecto que protegen el framework
Principios de Jenna Press
Estos principios evitan un fallo común: un proyecto empieza como sitio simple y poco a poco pierde sus límites.
En Jenna Press, un archivo de contenido es editable, pero no debería convertirse en un lugar para esconder lógica de aplicación. Una plantilla es flexible, pero no debería redefinir el framework en silencio. Un archivo generado está permitido, pero debe tratarse como salida generada.
Esa disciplina también ayuda a SEO y GEO. Los buscadores, answer engines y AI agents entienden mejor un sitio cuando tiene URLs estables, títulos descriptivos, categorías claras, fechas visibles, versiones de idioma consistentes y páginas que responden preguntas concretas.
Jenna Press solo sigue siendo útil si esas líneas permanecen visibles.
Para el contexto del proyecto, lee Acerca de Jenna Press. Para una checklist práctica de contenido, lee SEO y GEO para sitios de proyecto static-first.