Princípios de design

O Chinaski descreve o seu próprio livro de regras no material de origem: algumas regras são posições de engenharia, outras são promessas sobre comportamento, e outras ainda são regras de estilo voltadas a contribuidores. Esta página reúne as regras a que o projeto se obriga , úteis se você está avaliando o software ou planejando trabalhar nele.

As promessas

• Lista pequena de dependências. São nove dependências de produção, e esse número é um alvo que o projeto se recusa a fazer crescer sem cuidado. Cada uma delas vem com o sistema operacional, e é isso que torna instalações novas reproduzíveis e auditorias tratáveis.
• Nenhum código em execução para os leitores. O site público são arquivos simples; a aplicação de publicação nunca responde a requisições de leitores. As páginas voltadas a leitores não carregam JavaScript em runtime , isso é estrutural: não existe mecanismo pelo qual um rastreador ou beacon pudesse ser adicionado, logo não pode ser embarcado "acidentalmente".
• O site funciona após a instalação sem um bando de serviços em nuvem. Sem telemetria, sem servidor de licenças para acionar, sem fontes ou ícones puxados dos CDNs de outras pessoas. Operação em air-gap é uma regra declarada; até o licenciamento comercial planejado foi desenhado para funcionar offline.
• Builds são deliberados. A publicação nunca acontece silenciosamente em segundo plano: um build é algo que você dispara , pelo painel, por um webhook ou pela linha de comando , sempre com logs que você pode inspecionar depois.
• Os trade-offs são declarados, não enterrados. O projeto diz com franqueza o que não fará: ainda não há editor de arrastar e soltar, não há ecossistema de plugins, o banco de dados é single-tenant e a responsabilidade do self-hosting fica com você. Nada nesta lista é negociável-pelo-marketing; se algo não existe, a documentação diz que não existe.

O raciocínio por trás delas

• O chato vence o esperto , a linguagem do core não mudou seus idiomas em décadas, o banco de dados trata seus dados como um arquivo, e as dependências não se renomeiam por baixo de você. Um programa escrito há anos ainda roda, e um operador que não conhece o sistema consegue ler o código de ponta a ponta às 2 da manhã.
• A superfície de ataque é uma decisão de design. Toda funcionalidade que alguém propõe faz uma aposta: a capacidade vale a superfície que ela adiciona? A posição do projeto é que a maioria das apostas perde em produção, então o padrão mais seguro é dizer não até que se prove o contrário , daí a ausência de hooks, de registro de plugins e de marketplace.
• Assistida por IA, auditável por humanos. A base de código é desenvolvida com assistência de IA, e o projeto trata a fluência em IA, e não a fluência em Perl, como a habilidade de entrada para contribuidores , justamente porque código chato e estável permanece legível por pessoas e LLMs igualmente, com trinta anos de idioma consistente de uma vez.

As regras para contribuidores

Se você vai trabalhar na interface de administração, as notas de implementação são explícitas:

• Nada de estilos inline , use as classes utilitárias fornecidas.
• Nada de ícones decorativos; todo ícone precisa vir acompanhado de um rótulo de texto visível.
• A paleta de cores é fechada , cores novas quebram a consistência do sistema; use as CSS custom properties existentes.
• Mantenha o aninhamento raso; a nomenclatura de classes segue convenções no estilo BEM.
• Botões em cabeçalhos e rodapés de cards vão nos contêineres de ação prescritos.

Para templates de blocos, a especificação de blocos é a referência autoritativa , escrita para ser seguida por um humano ou uma IA trabalhando apenas a partir da especificação, com cada tipo de bloco consistindo de um template de builder e um partial de formulário de administração como um par correspondente. Tipos de bloco precisam ser registrados no sistema antes do uso.

Trabalhando no sistema de temas públicos em vez disso? A Template Reference tem regras próprias , variáveis planas, partials com prefixo _, diretivas proibidas, o requisito do portão de senha , e elas se aplicam a autores de temas, não a contribuidores da UI de administração.

O que está planejado (e declarado como não lançado)

• Um editor visual de arrastar e soltar , no roadmap, bloqueado por decisões de estrutura de página; não existe hoje.
• Geração de conteúdo por LLM ligada à biblioteca de blocos , planejado, tier comercial.
• Rastreamento de cliques com atribuição de campanhas , o módulo comercial planejado.
• Multi-tenancy com Postgres , no roadmap, não iniciado; o caminho de migração ainda não está definido.

Os módulos comerciais Pro são desenhados para serem licenciados localmente (arquivos de licença assinados, sem validação externa), de modo que a promessa de air-gap sobreviva à monetização , e o core permanece sob licença MIT, com as funcionalidades Pro vivendo em um namespace separado.

O resumo em uma linha

Toda regra acima se reduz à mesma disciplina: reduza a superfície, prefira nada que precise de rede ou de um plugin para ser seguro, mantenha a saída burra, registre logs em abundância, documente os trade-offs com honestidade , e resista à tentação quando uma funcionalidade tentadora pedir para quebrar a regra.