Filosofia

As convicções por trás do Chinaski, cada uma com a sua própria página , de por que o site público é HTML puro a por que não existe um marketplace de plugins. Estas são as apostas de design que o projeto faz de propósito, e conhecê-las explica a maior parte das decisões com que, de outra forma, um operador iria esbarrar.

As dez convicções

• Estático primeiro , o site público são arquivos simples servidos do disco; o CMS nunca está no caminho público das requisições.
• Construído sobre Perl , uma linguagem estável há décadas, um CPAN maduro e código que permanece auditável para humanos e para IAs igualmente.
• Durabilidade , a stack é escolhida para que o código escrito hoje ainda rode sem modificações nas máquinas daqui a dez anos.
• Seja dono do seu conteúdo , seus dados vivem em um único arquivo SQLite e em diretórios simples; as exportações são o produto, não um recurso bloqueado por plano.
• Simplicidade , um monólito por processo, poucas peças móveis e código legível em vez de abstrações espertas.
• Segurança por construção , garantias impostas no código (nenhum mecanismo de rastreamento, nenhuma conexão de volta) em vez de promessas em políticas.
• Soberania , auto-hospedável e compatível com air-gap: sem telemetria, sem verificação de licença pela internet, sem dependências de CDN.
• Rápido por padrão , saída estática, poucas peças móveis e nenhum framework mudando por baixo de você.
• Multilíngue primeiro , o idioma é estrutural, do schema à árvore de saída.
• Princípios de design , as regras de trabalho derivadas de tudo o que vem antes.

O argumento, condensado

A maioria das plataformas de conteúdo acumula superfície , plugins, integrações, analytics, assets de CDN , e cada acréscimo é uma aposta de que a funcionalidade vale a complexidade e a superfície de ataque. O Chinaski faz a aposta oposta de propósito:

• Um conjunto pequeno de dependências, totalmente empacotado no Debian. Uma instalação nova resolve a partir de pacotes do sistema; não há nada para compilar e nada para correr atrás.
• Zero JavaScript em runtime no site público , uma propriedade estrutural, não uma política. O servidor web serve arquivos; não existe mecanismo pelo qual um beacon pudesse ser embarcado.
• Compatível com air-gap por padrão , instalações novas vêm com isso, e o instalador avisa no primeiro boot.

O contrapeso honesto é enunciado com a mesma clareza: sem ecossistema de plugins, sem marketplace, Postgres no roadmap em vez de na prateleira, e propriedade operacional de verdade , você executa as atualizações e é dono dos backups. Esse trade-off é a razão para escolher o Chinaski; os custos são o ponto.

Onde isso encontra a prática

• As escolhas que moldaram o desempenho e a postura de segurança (pipeline de build, modelo de permissões, comportamento de cookies/consentimento) têm uma página em algum lugar da documentação , esta seção explica o porquê, não o como.
• Os trade-offs são nomeados, não escondidos: para os públicos que o projeto visa (agências com múltiplos sites de clientes, organizações focadas em segurança, operadores de air-gap), as apostas se pagam; para alguém que precisa de um marketplace de temas, deliberadamente não.
• A licença do core é MIT.