Estoy de acuerdo en que la documentación del plugin debería actualizarse en este punto. El objetivo del período de “obsolescencia”, durante el cual los plugins siguen funcionando pero el sitio muestra una advertencia de que pronto dejarán de hacerlo, es dar a los autores de los plugins suficiente tiempo para corregirlos. Sin embargo, en ese mismo período, un equipo de desarrolladores remunerados a tiempo completo no pudo actualizar la documentación central de desarrollo de plugins. Es una expectativa extraña imponerla a desarrolladores individuales cuando un equipo no puede gestionarla completamente en el mismo lapso.
Para mí, esto indica que la velocidad de desarrollo es demasiado rápida y/o que los autores de plugins no son una prioridad significativa para Discourse. Personalmente, creo que es más bien lo segundo. Entiendo que algo tiene que quedar de lado, así que esto es una observación por mi parte y no una crítica. Discourse sigue siendo totalmente personalizable mediante plugins y agradezco las mejoras continuas.
Dicho esto, creo que estamos en un momento en el que una guía paso a paso para construir un plugin base es una idea obsoleta. Ahora, para un autor de plugins aficionado, solo se necesita un documento de contexto único para que un agente lo lea y genere un esqueleto de plugin. De hecho, para una base de código de código abierto como Discourse, la documentación ni siquiera es necesaria, ya que los agentes obtienen el contexto directamente de la propia base de código. Cuando trabajaba en mis plugins, vi a Claude leer los plugins existentes como una forma de aprender los patrones de diseño. Incluso pude detectar un error en el código central: Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time
Básicamente, para cualquier persona que lea esto y aspire a ser un autor de plugins aficionado, la documentación puede estar desactualizada, pero es 1000 veces más fácil construir un plugin que nunca antes lo haya sido.