Principios de diseño

Chinaski describe su propio reglamento en su material fuente: algunas reglas son posturas de ingeniería, otras son promesas sobre el comportamiento y otras son reglas de estilo orientadas a quienes contribuyen. Esta página reúne las reglas que el proyecto se impone, útiles si estás evaluando el software, o planeando trabajar en él.

Las promesas

• Lista de dependencias pequeña. Hay nueve dependencias de producción, y ese número es un objetivo que el proyecto se niega a hacer crecer sin cuidado. Cada una viene con el sistema operativo, que es lo que hace reproducibles las instalaciones frescas y tractables las auditorías.
• Nada de código en ejecución para los lectores. El site público son archivos simples; la aplicación de publicación nunca responde peticiones de lectores. Las páginas orientadas al lector no llevan JavaScript en tiempo de ejecución, esto es estructural: no existe ningún mecanismo por el cual un tracker o beacon pudiera añadirse, así que no puede enviarse "accidentalmente".
• El site funciona tras la instalación sin nubes de servicios cloud. Sin telemetría, sin servidor de licencias al que llamar, sin fuentes ni iconos tomados de CDNs ajenos. La operación en air-gap es una regla declarada; incluso el licenciamiento comercial planeado fue diseñado para funcionar offline.
• Los builds son deliberados. La publicación nunca ocurre silenciosamente en segundo plano: un build es algo que tú disparas, desde el dashboard, con un webhook o desde la línea de comandos, siempre con logs que puedes inspeccionar después.
• Los trade-offs se declaran, no se esconden. El proyecto dice con claridad lo que no hará: aún no hay editor drag-and-drop, no hay ecosistema de plugins, hay una base de datos single-tenant y la responsabilidad del self-hosting queda en ti. Nada de esta lista es negociable-por-marketing; si no existe, la documentación dice que no existe.

El razonamiento detrás de ellas

• Lo aburrido le gana a lo listo, el lenguaje del core no ha cambiado sus modismos en décadas, la base de datos trata tus datos como un archivo, y las dependencias no se renombran debajo de ti. Un programa escrito hace años sigue funcionando, y un operador que no lo conoce puede leer el código de principio a fin a las 2 de la mañana.
• La superficie de ataque es una decisión de diseño. Cada feature que alguien propone es una apuesta: ¿vale la capacidad la superficie que añade? La postura del proyecto es que la mayoría de esas apuestas pierden en producción, así que el default más seguro es decir que no hasta que se demuestre lo contrario, de ahí que no haya hooks, ni registro de plugins, ni marketplace.
• Asistido por IA, auditable por humanos. El codebase se desarrolla con asistencia de IA, y el proyecto trata la fluidez en IA, no la fluidez en Perl, como la habilidad de entrada para quienes contribuyen, precisamente porque el código aburrido y estable se mantiene legible por personas y LLMs por igual, treinta años de modismo consistente a la vez.

Las reglas para quienes contribuyen

Si vas a trabajar en la interfaz de administración, las notas de implementación son explícitas:

• Sin estilos inline, usa las clases de utilidad provistas.
• Sin iconos decorativos; todo icono debe ir emparejado con una etiqueta de texto visible.
• La paleta de colores es cerrada, los colores nuevos rompen la consistencia del sistema; usa las CSS custom properties existentes.
• Mantén el anidamiento poco profundo; el nombrado de clases sigue convenciones BEM-ish.
• Los botones en headers y pies de card van en los contenedores de acciones prescritos.

Para las plantillas de blocks, la especificación de blocks es la referencia autoritativa, escrita para ser seguida por un humano o una IA que trabaje solo desde la especificación, con cada tipo de block compuesto por una plantilla de builder y un partial de formulario de admin como par emparejado. Los tipos de block deben registrarse en el sistema antes de usarse.

¿Trabajas en el sistema de temas públicos en cambio? La Template Reference tiene sus propias reglas, variables planas, partials con prefijo _, directivas prohibidas, el requisito del password gate, y aplican a los autores de temas más que a quienes contribuyen a la UI de administración.

Lo que está planeado (y declarado como no enviado)

• Un editor visual drag-and-drop, en el roadmap, bloqueado por decisiones de estructura de páginas; hoy no existe.
• Generación de contenido con LLM ligada a la librería de blocks, planeado, nivel comercial.
• Click tracking con atribución de campañas, el módulo comercial planeado.
• Multi-tenancy con Postgres, en el roadmap, sin empezar; la ruta de migración aún no está definida.

Los módulos comerciales Pro están diseñados para licenciarse localmente (archivos de licencia firmados, sin validación externa) de modo que la promesa de air-gap sobreviva a la monetización, y el core permanece con licencia MIT con las features Pro viviendo en un namespace separado.

El resumen de una línea

Cada regla anterior se reduce a la misma disciplina: reducir la superficie, no preferir nada que necesite una red o un plugin para ser seguro, mantener la salida tonta, registrar logs en abundancia, documentar los trade-offs con honestidad, y sostener la línea cuando una feature tentadora te pida romper la regla.