Como Funciona

O Chinaski é um sistema de duas peças com um ciclo simples: edite enquanto o CMS é privado, faça build sob demanda e sirva o que ele escreveu. Esta página é todo o ciclo de vida em um só lugar.

O ciclo

1. Editar: entre no admin e gerencie tudo: páginas, posts, blocos, snippets, categorias, redirecionamentos, navegação, formulários e mídia. Tudo vive em um único arquivo de banco de dados SQLite.
2. Build: um processo builder separado lê esse banco de dados, renderiza seus templates e escreve o site pronto como arquivos estáticos em disco. O build acontece apenas quando você ou um webhook determina. É uma operação explícita com um log adequado, não um efeito colateral em segundo plano.
3. Servir: seu servidor web entrega os arquivos construídos direto do disco. Os visitantes nunca tocam na aplicação CMS nem no banco de dados.
4. Repetir: mude o conteúdo, clique em Build (ou deixe um webhook ou a API dispará-lo), e a próxima cópia estática entra no lugar.

Por que esse formato

• O admin é privado. Em produção, o CMS faz bind apenas em um endereço de loopback; os visitantes da internet chegam ao host estático, nunca ao aplicativo de escrita nem ao banco de dados.
• O site público não tem aplicação para atacar. O que é entregue é um diretório simples de HTML e assets. Não há renderização por requisição e nenhum JavaScript em tempo de execução: nada para injetar, nada para vazar, e um rastreador não tem mecanismo para existir.
• A falha de um processo não pode afetar o outro. Um build que falha nunca derruba o site: a saída é escrita em um diretório de staging e renomeada para o lugar apenas quando completa; caso contrário, o build anterior continua sendo servido.

O que os visitantes realmente recebem

• Páginas e posts como arquivos index.html em seus próprios caminhos, por idioma, sob a subárvore de cada idioma em output/
• Assets compartilhados sincronizados em cada árvore de idioma (mídia, fontes, favicons)
• Arquivos gerados por idioma: sitemap, índice de busca, feed RSS, robots.txt, página de erro, e extras de PWA quando habilitados
• Páginas de redirecionamento e uma configuração de redirecionamento de servidor gerada, para que URLs aposentadas continuem funcionando

As duas exceções deliberadas ao "totalmente estático"

• Formulários públicos (blocos de contato/newsletter) enviam para /forms/<slug>, que a configuração padrão do servidor coloca atrás de proxy para o CMS, para que os envios possam ser armazenados.
• Páginas protegidas por senha entregam seu conteúdo dentro do HTML e desbloqueiam no navegador do visitante: uma verificação no lado do cliente, claramente uma troca por privacidade em nível de página em um site estático.

Por baixo do capô

• Uma instância = um arquivo SQLite. Sem servidor de banco de dados, sem credenciais, sem rede entre aplicação e armazenamento. Múltiplas instâncias (por cliente, por estágio) carregam cada uma seu próprio arquivo.
• Atualizar é subir o serviço: cada inicialização roda migrações de schema idempotentes automaticamente, então as instâncias reparam o próprio schema no caminho.
• A integridade é comprovável: cada build assina um manifest guardado separadamente da saída, para que o site ao vivo possa ser atestado contra o build que o produziu.

Entrando no primeiro dia

Uma instalação nova lhe entrega uma conta de admin provisória: o navegador é redirecionado para /setup na primeira visita, onde você define a senha real de admin (pelo menos 12 caracteres com maiúsculas, minúsculas e um dígito), escolhe o conteúdo da UI e os idiomas iniciais, e define a URL do site. Depois disso, a página de setup desaparece, e o ciclo acima é seu para comandar.