Obrigado pela dica!
Status rápido: Atualmente estou executando três instâncias do meu importador Python ICS→Discourse (horário da Uni, reservas do Centro de Esportes e um calendário do Outlook). Comecei a empacotá-lo como um plugin do Discourse, mas a versão do plugin ficou aquém do conjunto de recursos do script — principalmente porque cada feed precisa de tratamento personalizado (excentricidades de UID, atualizações parciais, cancelamentos, revisões barulhentas, etc.). O plugin do Angus é ótimo para muitos casos; meus casos de uso parecem mais “específicos do feed”.
Também tenho um PR aberto contra o core com o objetivo de reduzir o ruído do botão azul “Mais Recentes” durante atualizações ICS grandes/intensas. Com feeds movimentados (como horários universitários), um lote de edições de baixo valor pode manter o “Mais Recentes” oscilando; o PR efetivamente desativa o botão “Novos Tópicos” quando o Mais Recentes ficou aberto enquanto um lote automatizado é executado. Ficarei feliz em cruzar o link desse PR aqui, se for útil.
A longo prazo: Estou atualmente no IONOS auto-hospedado. Se eu mudar para hospedagem oficial mais tarde, ainda adoraria uma maneira de manter o fluxo Python (ou um equivalente) sem precisar de recursos Enterprise, se o ICS inbound existir lá. Suspeito que uma solução genérica de core/plugin poderia funcionar se permitisse “adaptadores” plugáveis por feed, mantendo forte idempotência (UID ICS), tratamento de cancelamento e semântica de edição sem aumento.
Se houver interesse, posso esboçar uma interface de adaptador mínima e um caminho de migração do meu script Python para um job Ruby, ou contribuir com peças agnósticas de feed (mapeamento de UID, debounce/atualizações sem aumento, lógica de cancelamento) para o plugin de calendário/eventos.