Site de ecossistema de plugins

Um diretório de plugins é onde a confiança é ganha ou perdida. Visitantes não procuram adjetivos: querem saber o que um plugin faz, quem o mantém, se está pronto para produção, como instala e como se comporta em uma stack real do EmDash. Um site público estruturado transforma essas respostas em páginas consistentes, em vez de fragmentos espalhados de README.

O que cada página de plugin deve provar

Comece pelos resultados: problema resolvido, ambientes suportados e pegada operacional (Workers, D1, APIs externas). Em seguida, apresente compatibilidade, versionamento e licença. Exiba links para código-fonte, downloads e docs aprofundadas. Se algo estiver em beta, diga claramente e explique o que “beta” significa para dados e disponibilidade.

Etapas concretas de rollout

1. Defina um template único de página. Campos padrão podem incluir status, categoria, versão, modelo de preço, compatibilidade, link do repositório e changelog. Consistência ajuda usuários a comparar opções rapidamente.

2. Publique orientações de instalação que reflitam a realidade. Prefira comandos e trechos de configuração que funcionem com o layout atual do repositório, por exemplo referenciando packages/plugins/<name> no monorepo do EmDash quando essa for a fonte de verdade.

3. Entregue notas de release a cada mudança relevante. Mesmo uma lista curta de bullets é melhor do que silêncio. Sempre que possível, link para comparações no GitHub ou releases com tag.

4. Adicione sinais de confiança. Nome de mantenedor, canal de suporte e expectativas de segurança devem estar na página, não apenas em chat. Para plugins que chamam APIs de terceiros, documente secrets exigidos e limites de taxa.

5. Cruze links com casos de uso. Conecte plugins aos cenários que eles habilitam: Forms para captação de leads, Webhook Notifier para automação, Audit Log para equipes com múltiplos editores.

Exemplo: avaliando um novo plugin para listagem

Antes de a página ir ao ar, passe por este checklist: a descrição de uma linha corresponde ao que o código realmente exporta? Capturas ou diagramas estão corretos? A licença está correta? Uma pessoa nova consegue instalar sem conhecimento interno? Se alguma resposta for “não”, feche essa lacuna antes de promover o plugin.

Cadência operacional

Mensalmente: revise issues abertos e atualize campos de status. Trimestralmente: deprecie listagens abandonadas ou marque como “unmaintained” com notas de migração. Após releases importantes do EmDash: reteste os principais plugins e atualize as strings de compatibilidade.

Resultado

Builders descobrem plugins mais rápido, adotam com menos surpresas e tratam seu ecossistema como infraestrutura séria, não como folheto.