Cómo Funciona

Chinaski es un sistema de dos piezas con un ciclo simple: edita mientras el CMS es privado, compila bajo demanda, y sirve lo que escribió. Esta página es todo el ciclo de vida en un solo lugar.

El ciclo

1. Editar: inicia sesión en el admin y gestiona todo: páginas, posts, bloques, snippets, categorías, redirecciones, navegación, formularios y medios. Todo vive en un solo archivo de base de datos SQLite.
2. Compilar: un proceso builder separado lee esa base de datos, renderiza tus plantillas y escribe el sitio terminado como archivos estáticos al disco. Compilar ocurre solo cuando tú o un webhook lo dicen: es una operación explícita con su registro correspondiente, no un efecto secundario en segundo plano.
3. Servir: tu servidor web entrega los archivos compilados directamente desde el disco. Los visitantes nunca tocan la aplicación del CMS ni la base de datos.
4. Repetir: cambia el contenido, haz clic en Build (o deja que un webhook o la API lo disparen), y la siguiente copia estática se intercambia a su lugar.

Por qué esta forma

• El admin es privado. En producción el CMS se enlaza únicamente a una dirección de loopback; los visitantes de internet alcanzan el host estático, nunca la aplicación de escritura ni la base de datos.
• El sitio público no tiene aplicación que atacar. Lo que se entrega es un directorio plano de HTML y assets. No hay renderizado por solicitud ni JavaScript en tiempo de ejecución: nada donde inyectar, nada que filtrar, y un tracker no tiene mecanismo para existir.
• El fallo de un proceso no puede tocar al otro. Un build fallido nunca tumba el sitio: la salida se escribe en un directorio staging y se renombra a su lugar solo cuando está completa; de lo contrario, el build anterior sigue sirviendo.

Lo que los visitantes reciben realmente

• Páginas y posts como archivos index.html en sus propias rutas, por idioma, bajo el subárbol de cada idioma en output/
• Assets compartidos sincronizados en cada árbol de idioma (medios, fuentes, favicons)
• Archivos generados por idioma: sitemap, índice de búsqueda, feed RSS, robots.txt, página de error: y extras de PWA cuando están habilitados
• Páginas de redirección y una configuración de redirecciones del servidor generada, para que las URLs retiradas sigan funcionando

Las dos excepciones deliberadas a "totalmente estático"

• Los formularios públicos (bloques de contacto/newsletter) envían a /forms/<slug>, que la configuración de servidor estándar redirige por proxy al CMS para que los envíos puedan guardarse.
• Las páginas protegidas por contraseña envían su contenido dentro del HTML y se desbloquean en el navegador del visitante: una verificación del lado del cliente, claramente un compromiso para la privacidad a nivel de página en un sitio estático.

Bajo el capó

• Una instancia = un archivo SQLite. Sin servidor de base de datos, sin credenciales, sin red entre la aplicación y el almacenamiento. Varias instancias (por cliente, por etapa) llevan cada una su propio archivo.
• Actualizar es levantar-el-servicio: cada arranque ejecuta automáticamente migraciones de esquema idempotentes, así que las instancias se auto-reparan el esquema en el camino.
• La integridad es demostrable: cada build firma un manifest guardado aparte de la salida, de modo que el sitio live puede attestarse contra el build que lo produjo.

Entrar el primer día

Una instalación fresca te entrega una cuenta de admin placeholder: el navegador se redirige a /setup en la primera visita, donde estableces la contraseña real del admin (al menos 12 caracteres con mayúsculas, minúsculas y un dígito), eliges el contenido de la interfaz y los idiomas iniciales, y defines la URL del sitio. Después de eso, la página de setup desaparece: y el ciclo de arriba queda a tu disposición.