Pente fino do Participa e o caminho para o Decidim 0.33

Resumo

O Decidim 0.33 ainda não foi lançado. O trabalho útil agora é preparar o terreno: destravar as gems, colocar os testes na CI e fechar as lacunas de operação.

• Upgrade: não há 0.33 para instalar. O próximo passo real é o 0.32.2, ainda sem tag, com correções de segurança.
• Dependências: quase todas as gems seguem uma branch móvel, e três delas pertencem a terceiros (duas da Octree, uma em conta pessoal).
• Qualidade: os overrides têm testes, mas a CI só roda scans de segurança, todos com allow_failure: true.
• Operação: backup do Postgres está como TODO no chart, a aplicação conecta como superusuário e não há health check.
• Conhecimento: o README só cobre setup; as decisões de arquitetura não estão registradas neste repositório.

Tamanho da customização

Cerca de 51 mil linhas de código próprio sobre o Decidim; com traduções e testes, 81 mil.

Código é Ruby, views ERB, JS/SCSS e migrations próprias. Por tipo, no total: cerca de 29 mil linhas de Ruby, 8 mil de views e 12 mil de JS/SCSS.

• Das 39,7 mil linhas externas, 5,3 mil são de terceiros (as duas gems da Octree e o omniauth-govbr); 34,4 mil são dos repositórios do LAPPIS.
• São linhas físicas, com linhas em branco e comentários.
• Ficaram de fora as 770 migrations copiadas do Decidim, o db/schema.rb, node_modules e o chart Helm.
• O config/ do host inclui configuração padrão de Rails e do Decidim, então o número do host está um pouco acima do que é customização de fato.

Status do 0.33

Para referência, o 0.32 teve RC em 24 de abril e versão final em 2 de julho de 2026. A regra upstream é subir um minor por vez, então 0.32 para 0.33 é um salto só.

O que muda no 0.33

Requisitos

Ações manuais confirmado

• Procedimento: bundle update decidim, bin/rails decidim:upgrade, db:migrate, data:migrate.
• config/sidekiq.yml é sobrescrito pelo decidim:upgrade. Filas próprias devem ir para um segundo arquivo (config/sidekiq.local.yml). Temos 15 filas no arquivo atual e outra lista no ConfigMap do Helm.
• Nova fila active_storage: precisa estar no sidekiq.yml e ser consumida por algum processo.
• A função JS initFoundation foi removida; nenhum código pode depender de foundation-sites.
• Perfis ocultos por padrão: participantes sem conta confirmada, sem aceite dos termos ou gerenciados deixam de aparecer no site e na API. Afeta qualquer view, cell ou consulta nossa que liste usuários.
• Verificações com bloqueio após 5 falhas e throttling por IP. O upstream pede revisão de handlers de autorização customizados; temos o GovbrAuthorizationHandler. Isso também chega no 0.32.2.

Remoções e movimentações inferido do diff

• Dependências npm retiradas de @decidim/core: foundation-sites, d3, emojibase, svg4everybody.
• Datepicker movido de src/decidim/datepicker/ para um controller Stimulus em src/decidim/controllers/date_picker/.
• Cells de wizard removidas (wizard_step_form_cell e variações).
• Surveys: coluna clean_after_publish e o job de limpeza removidos.
• Atualizações maiores no frontend: React 18 para 19, @rails/ujs 6 para 7, ESLint 8 para 9.
• Cerca de 28 controllers do admin alterados, provavelmente por escopo de organização nas buscas.
• "Steps" renomeado para "Phases" nas strings; overrides de i18n precisam de revisão.

Migrations que pesam inferido do diff

• Coluna reference nova em posts, textos colaborativos, eleições, páginas e surveys, com preenchimento linha a linha.
• Regeneração da referência de todo projeto de orçamento, sem volta.
• Data migrations que reescrevem títulos de debates, reuniões, eleições e propostas, sem volta e lentas em tabelas grandes.
• Com um schema por organização, tudo isso roda uma vez por tenant, em sequência.

Segurança relevante para multi-tenant inferido dos commits

• Impede uso de um JWT contra outra organização (PR #16673).
• Corrige acesso entre tenants na verificação por documento (PR #16666).
• Sanitização de páginas estáticas e blocos HTML (PR #16451).

Parte desses commits pode já estar no 0.32.x; o backport de cada um não foi conferido.

Onde quebra no nosso código

Colisões diretas com arquivos do host

Essa lista só cobre arquivos no mesmo caminho do upstream. Os casos abaixo ficam em áreas alteradas e precisam de diff quando houver RC.

Overrides em áreas alteradas

• Comentários: UpdateCommentOverride#call e CommentsControllerOverride#update substituem o método inteiro, sem super, e dependem de métodos privados do upstream. O decidim-bp_comments ainda faz prepend em 7 classes do mesmo módulo.
• Propostas: ProposalGCellOverride sobrescreve resource_image_path; a cell mudou upstream.
• Painel system: organizations_controller mudou; decidim-apartment substitui index e edit, e decidim-toggle aplica Deface no mesmo painel.
• Layouts: _head.html.erb e header/_main_links_dropdown.html.erb mudaram; decidim-govbr aplica Deface em _head e em header/_main.
• Deface em geral: os 10 overrides do decidim-govbr dependem de seletores CSS dos templates (#accordion-duration, div#main-bar, .item_show__header). Se o seletor some, o override não aplica e não avisa.
• Exportação de surveys: ExportJobStreamingSurveyAnswers sobrescreve Decidim::ExportJob#perform com assinatura fixa e lê colunas de decidim_forms_responses.
• Menu do admin: MenuReorder usa instance_variable_get(:@items) em objetos internos do Decidim.

Módulos e dependências

Todas as gems git usam branch: no Gemfile; nenhuma usa tag. O que garante a reprodução do build é só a revisão gravada no Gemfile.lock.

Recomendações

• Trocar branch: por tag: em todas as gems e criar uma tag por versão do Decidim suportada.
• Espelhar ou fazer fork das três gems de terceiros (decidim-toggle, decidim-ephemeral_participation, omniauth-govbr) num grupo que a equipe controla. O login gov.br hoje depende de um repositório pessoal.
• Manter uma matriz de compatibilidade por módulo e subir as gems na ordem das dependências: toggle e ephemeral_participation antes de extra_blocks.
• Resolver a sobreposição entre decidim-govbr e decidim-government_spaces, que alteram o mesmo form e os mesmos comandos de processo participativo.
• Colocar decidim-govbr na ordem certa sem depender do nome de um initializer do decidim-bp_comments.

Pente fino de arquitetura

Como o projeto altera o Decidim

Multi-tenancy: um schema Postgres por organização

flowchart LR
  R[Requisicao HTTP] --> E[Elevator do decidim-apartment]
  E -->|host cadastrado| T[Schema UUID do tenant]
  E -->|host desconhecido ou /system| P[Schema public]
  T --> O[CurrentOrganization do Decidim]
  T --> J[Job enfileirado com o tenant nos argumentos]
  J --> S[Middleware do Sidekiq troca o schema]
  T --> A[ActiveStorage com prefixo do tenant]
  

Essa é a decisão que mais encarece cada upgrade. Ela precisa de um ADR próprio e de um ensaio de migração numa cópia dos tenants antes de qualquer salto de versão.

Frontend

• tailwind.config.js na raiz é um arquivo gerado, com caminhos fixos para decidim-core-0.32.1, e diverge do template config/tailwind.config.js.erb (fonte e cores diferentes).
• decidim-govbr/package.json ainda aponta para @decidim/* ^0.30.1.
• config/webpack/custom.js referencia o service worker por um caminho interno do core.

Configuração e resíduos

• config.load_defaults 6.1 numa aplicação Rails 8.1.
• Quase toda a configuração do Decidim vem de credentials, com poucas alternativas por ENV. config/secrets.yml continua no repositório, mas o Rails 8 não o lê.
• .disabled-for-0.32/ tem README desatualizado: diz que community_templates não tem versão para 0.32, mas a gem está ativa e com patches.
• 17 migrations de sortitions sem a gem no bundle; eager_load_paths aponta para lib/decidim, que não existe.
• config/brakeman.ignore e pipeline_fixes.md ainda falam em Rails 7.0.10 e Decidim 0.30.1.
• Quatro módulos do decidim-govbr são carregados e não parecem incluídos em lugar nenhum.
• A rota update_participatory_process_dates é declarada duas vezes em engine.rb.

Infra e Helm

Imagem e CI

• A imagem roda como root, mantém o toolchain de build e não define CMD nem RAILS_ENV. Usa npm install em vez de npm ci.
• Não existe .dockerignore: um build local leva .env, .git e node_modules para dentro da imagem.
• Os assets não são compilados no build; um job do Helm roda shakapacker:compile a cada deploy, num volume compartilhado.
• A CI tem só gitleaks, hadolint, brakeman e SCA, todos com allow_failure: true. Nenhum job roda RSpec, RuboCop, ESLint ou Stylelint.
• build_bump_image só dispara na branch release/0.32.1-v1.0.0. Não há job de deploy.

Chart decidim-helm 0.3.12

Repositório lappis-unb/decidimbr/infra/charts/decidim-helm, main em c996356. A cópia local está igual ao remoto.

Há também feat/external-postgres-secret. Cinco branches abertas tratam problemas desta lista e ainda não entraram em main. O chart antigo em deploy/decidim-instance-chart (appVersion 0.29.3) segue no repositório do app e deve ser removido ou marcado como legado.

Para o 0.33, o chart precisa de três mudanças: imagem com Node 24, a fila active_storage no ConfigMap do Sidekiq e o passo data:migrate conferido no job de upgrade, que já o executa.

Observabilidade

• Não há endpoint de health check na aplicação.
• Logs só vão para STDOUT com RAILS_LOG_TO_STDOUT, que os charts não definem.
• Não há rastreamento de erros, métricas da aplicação nem logs estruturados. Só Redis e Postgres expõem métricas.
• O Pyroscope marca tudo como process=web, inclusive dentro do Sidekiq.

Segurança e dados pessoais

A varredura por padrões de chave e token nos arquivos rastreados dos dois repositórios não encontrou credenciais reais no estado atual.

Transferência de tecnologia

Assumir a responsabilidade pede mais que acesso ao código. Estes são os itens que hoje dependem de memória de pessoas ou de repositórios fora do nosso controle.

Roteiro sugerido

A verificar

Pontos deduzidos da leitura que ainda pedem confirmação num ambiente em execução ou com quem opera a plataforma.

• O efeito de APARTMENT_DISABLE_INIT=true num pod de produção.
• Se jobs das filas metrics e spam_analysis estão se acumulando no Redis.
• Os values reais de produção: STORAGE_PROVIDER, REDIS_CACHE_URL, RAILS_ENV, RAILS_LOG_TO_STDOUT.
• Se as tarefas recorrentes rodam por algum mecanismo fora dos charts.
• Se a rotação das credenciais que estiveram no histórico foi feita.
• Se os quatro módulos soltos do decidim-govbr são mesmo código morto.
• Quantos tenants existem e o tamanho das tabelas de propostas, para estimar a janela de migração.
• O backport de cada correção de segurança citada para o 0.32.x.