Filosofía

Las convicciones detrás de Chinaski, cada una con su propia página, desde por qué el site público es HTML plano hasta por qué no hay marketplace de plugins. Estas son las apuestas de diseño que el proyecto hace a propósito, y conocerlas explica la mayoría de las decisiones con las que un operador chocará de otro modo.

Las diez convicciones

• Estático Primero, el site público son archivos simples servidos desde el disco; el CMS nunca está en la ruta de peticiones públicas.
• Construido sobre Perl, un lenguaje estable por décadas, un CPAN maduro, y código que permanece auditable para humanos e IA por igual.
• Durabilidad, el stack se elige de modo que el código escrito hoy siga corriendo sin modificar en las máquinas de dentro de diez años.
• Sé dueño de tu contenido, tus datos viven en un archivo SQLite y directorios planos; los exports son el producto, no una puerta de feature.
• Simplicidad, un monolito por proceso, pocas piezas móviles, código legible sobre abstracciones ingeniosas.
• Seguridad por construcción, garantías aplicadas en el código (sin mecanismo de trackers, sin phone-home) en lugar de promesas de política.
• Soberanía, self-hosteable y aislable en air-gap: sin telemetría, sin phone-home de licencia, sin dependencias de CDN.
• Rapidez por defecto, salida estática, pocas piezas móviles, y ningún framework agitándose debajo de ti.
• Multilingüe Primero, el idioma es estructural, desde el esquema hasta el árbol de salida.
• Principios de diseño, las reglas de trabajo derivadas de todo lo anterior.

El argumento, comprimido

La mayoría de las plataformas de contenido acumulan superficie, plugins, integraciones, analítica, assets de CDN, y cada adición es una apuesta a que la capacidad vale la complejidad y la superficie de ataque. Chinaski hace la apuesta contraria a propósito:

• Un set de dependencias pequeño, empaquetado por completo en Debian. Una instalación fresca se resuelve desde paquetes del sistema; no hay nada que compilar y nada que perseguir.
• Cero JavaScript en tiempo de ejecución en el site público, una propiedad estructural, no una política. El servidor web sirve archivos; no existe ningún mecanismo por el cual un beacon pudiera enviarse.
• Compatible con air-gap por defecto, las instalaciones frescas lo traen, y el instalador te lo dice en el primer arranque.

El contrapeso honesto se declara con la misma claridad: sin ecosistema de plugins, sin marketplace, Postgres en el roadmap y no en el estante, y una propiedad operativa real, tú ejecutas las actualizaciones y eres dueño de los respaldos. Ese intercambio es la razón para elegir Chinaski; los costos son el punto.

Donde esto se encuentra con la práctica

• Las elecciones que moldearon el perfil de rendimiento y seguridad (pipeline de build, modelo de permisos, comportamiento de cookies/consent) tienen cada una una página en algún lugar de la documentación, esta sección explica el *por qué*, no el *cómo*.
• Los trade-offs están nombrados, no ocultos: para las audiencias a las que el proyecto apunta (agencias con múltiples sitios de clientes, organizaciones enfocadas en seguridad, operadores de air-gap), las apuestas pagan; para alguien que necesita un marketplace de temas, deliberadamente no.
• La licencia del core es MIT.