Roadmap

O Chinaski cresce de forma lenta e deliberada: a mesma filosofia que mantém pequena a superfície entregue se aplica ao que será adicionado em seguida. Esta página reúne as melhorias atualmente em planejamento, agrupadas pelos pilares que atendem. Tudo o que está listado aqui é uma proposta: as afirmações sobre "o que existe hoje" são descrições precisas do software atual, e o restante é intenção, não implementação.

Maturidade de Formulários

O módulo de formulários funciona (envios, notificações, webhooks, proteção contra spam), e quatro refinamentos estão sendo planejados para levá-lo ao nível de hospedagem de produção:

• Quarentena de spam em vez de descarte silencioso. Hoje o honeypot e os filtros de markup/links impedem que os bots aprendam: eles veem a mesma tela de "obrigado" que as pessoas reais veem, e o envio nunca é armazenado. O custo: um falso positivo (uma pessoa real que cola URLs numa mensagem, por exemplo) some sem deixar rastro e sem nenhuma forma de verificar se os filtros estão bem calibrados. Planejado: envios em quarentena que um administrador possa revisar, liberar ou verificar.
• Saúde da entrega no próprio formulário. O registro de entrega de webhooks com novas tentativas já existe e pode ser consultado no admin de webhooks, mas os webhooks disparados por formulário não registram a qual formulário pertencem, então a tela de edição de um formulário não tem nada a mostrar sobre a saúde da sua entrega. Planejado: vincular as entregas disparadas por formulário de volta ao seu formulário, para que a tela de edição de cada formulário exiba o status do seu próprio webhook.
• Labels e mensagens por idioma. Labels de formulário, placeholders, a mensagem de sucesso e o texto do botão de envio são strings únicas hoje, uma barreira rígida para sites multilíngues. Primeiro passo delimitado: cobrir apenas as strings no nível do formulário, reaproveitando a maquinaria de traduções existente em vez de construir um sistema paralelo por idioma.
• Double opt-in para formulários no estilo newsletter. Um envio conta no momento em que é armazenado; não há uma etapa de confirmação antes de um contato ser tratado como inscrito. Planejado como uma opção de higiene para formulários de inscrição, para que as listas se mantenham limpas.

Descoberta de SEO

Ajudar os mecanismos de busca a encontrar conteúdo novo mais rápido: hoje o sitemap e o robots.txt estão corretos, mas são inteiramente passivos:

• Diretivas personalizadas de robots.txt e suporte a sitemap index: o robots.txt é atualmente construído a partir de um template fixo, sem como adicionar diretivas (crawl-delay e similares), e cada idioma publica um único arquivo de sitemap, sem arquivo de índice, então um idioma que ultrapasse o teto de 50.000 URLs por sitemap não tem caminho para dividi-lo.
• Um subsistema de ping para mecanismos de busca: hoje não existe nenhum mecanismo de notificação (o webhook de build avisa seus próprios sistemas, não os mecanismos de busca). Planejado: suporte a Google Indexing API / Bing URL Submission com novas tentativas e visibilidade dos envios, para que você veja o que foi enviado e quando.
• Suporte ao protocolo IndexNow: o precursor: notificar proativamente os mecanismos participantes sobre quais URLs mudaram a cada build, em vez de depender da descoberta orgânica por rastreamento. Mesma meta de maturidade do item anterior: novas tentativas e um registro visível dos envios.
• Gerenciamento completo de taxonomia: as categorias são planas hoje (sem aninhamento pai/filho), e as tags são uma coluna de texto simples separada por vírgulas, sem suporte a sinônimos ("CMS" e "Content Management System" não se reconhecem). Planejado: hierarquia de tags, sinônimos e as páginas de arquivo que tornam útil a navegação por taxonomia.

Controle de Acesso

O modelo de permissões hoje é deliberadamente simples (dois papéis mais restrições grosseiras de conteúdo/idioma por usuário), e as adições planejadas dão às equipes em crescimento um controle mais preciso:

• Um papel de Manager entre admin e editor: para líderes de equipe que precisam publicar e convidar usuários sem acesso destrutivo completo (o conjunto de papéis é atualmente exatamente dois).
• Chaves de API com permissões delimitadas: as chaves de API existentes carregam leitura ou escrita; planejado: escopos mais granulares para que integrações entre serviços não precisem de acesso total.
• Contas de serviço: contas não humanas com sua própria matriz de permissões, allowlists de IP e expiração/rotação, para automações que não deveriam usar as credenciais de uma pessoa.
• Uma tabela unificada de capacidades: substituindo as convenções de "somente estas páginas / somente estes formulários" por um único sistema de capacidades que suporte concessões tanto por entidade quanto globais.
• Permissões em nível de página: restringir uma página ou post específico (a um proprietário, ou a papéis designados) para sites com várias equipes e rascunhos sob embargo; hoje as restrições existem apenas no nível de tipo de entidade e de idioma.
• Controle de acesso em nível de campo: proteger por papel os campos críticos para SEO (URL canônica, noindex, dados estruturados), para que uma edição de conteúdo não alcance por acidente configurações que afetam a indexação do site inteiro.

O que não está neste roadmap

O roadmap público lista o que o projeto pretende construir; ele não promete datas nem uma ordem de lançamento. Os comportamentos já entregues mencionados acima (logs de entrega de webhooks, restrições por entidade, o sistema de dois papéis) estão documentados em suas próprias páginas; o trabalho planejado aqui se apoia neles, e os referencia em vez de repeti-los.

'Roadmap' em uma frase: os pilares acima são o trabalho de conclusão: um sistema de formulários pronto para marketing baseado em listas, assistência de descoberta para mecanismos de busca e controle de acesso que escala de um operador solo a organizações com muitas equipes. Nada aqui é entregue sem que sua cláusula de "o que faz hoje" continue verdadeira, então volte a conferir à medida que os itens forem chegando.