Concordo que a documentação do plugin deve ser atualizada neste momento. O objetivo do período de “descontinuação”, onde os plugins ainda funcionam, mas o site exibe um aviso de que eles deixarão de funcionar em breve, é dar tempo suficiente aos autores dos plugins para corrigi-los. No entanto, nesse mesmo período, uma equipe de desenvolvedores remunerados em tempo integral não conseguiu atualizar a documentação central de desenvolvimento de plugins. É uma expectativa estranha impor isso a desenvolvedores individuais quando uma equipe não consegue gerenciar totalmente a mesma tarefa no mesmo período.
Isso me sinaliza que a velocidade de desenvolvimento é muito alta e/ou que os autores de plugins não são uma prioridade significativa para o Discourse. Pessoalmente, sinto que é mais o segundo caso. Entendo que algo precisa ser deixado de lado, então isso é uma observação minha, e não uma crítica. O Discourse permanece totalmente personalizável por meio de plugins, e agradeço pelas melhorias contínuas.
Dito tudo isso, acho que chegamos a um momento em que um guia de documentação passo a passo para criar um plugin boilerplate é uma ideia obsoleta. Um único documento de contexto para um agente ler e construir um esqueleto de plugin é tudo o que é necessário agora para um autor de plugins amador. Na verdade, para uma base de código de código aberto como o Discourse, a documentação nem é necessária, já que os agentes obtêm contexto diretamente da própria base de código. Quando estava trabalhando nos meus plugins, vi o Claude lendo os plugins existentes como uma forma de aprender os padrões de design. E até consegui identificar um bug no código principal: Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time
Basicamente, para qualquer pessoa que esteja lendo isso e aspire a ser um autor de plugins amador, a documentação pode estar desatualizada, mas criar um plugin é 1000 vezes mais fácil do que nunca foi antes.