O que aconteceu

Quando a capacidade de cobranças agendadas foi lançada na v0.5.0, ela trazia um feature gate por vendedor (seller_config.scheduled_charges_enabled) que começava em false. A ideia era ligar manualmente para design partners antes da abertura geral. O recurso ficou disponível na API, no SDK, no MCP e no painel — mas o gate continuou ligado, e não havia interface para alternar.

Consequência: você podia criar uma cobrança via POST /api/scheduled-charges (ou MCP create_scheduled_charge), o painel exibia a cobrança como "Agendada" normalmente, mas no dia do vencimento o cron silenciosamente pulava o disparo — sem e-mail, sem evento na timeline, sem 4xx na API, sem alerta no Sentry. Só dava para descobrir via ticket de cliente.

A correção

• Backfill: toda linha de seller_config foi atualizada para scheduled_charges_enabled = true. Vendedores sem linha receberam uma com a flag já ligada.
• Default da coluna: novos vendedores agora nascem com a capacidade habilitada.
• Crons: o billing cron (D-day) e o dunning cron (D+1/D+2/D+3) não consultam mais a flag — eles disparam para todo schedule elegível.
• Coluna: continua na base por uma versão, mas sem uso de runtime. Será removida na próxima migração de limpeza.

Cobranças que já estavam com due_date no passado não disparam retroativamente — o cron usa filtro estrito due_date = today. Se você tem uma cobrança que perdeu o e-mail do dia, use postpone_scheduled_charge (ou o botão "Adiar" no painel) para reagendar.

Dashboard

A página /cobrancas-agendadas/:id foi ajustada para seguir o padrão visual de produtos e transações:

• Cartões com cantos arredondados (12px) e sombra suave em vez do contorno chapado.
• Breadcrumb "Cobranças agendadas → ID" no topo.
• Botões de ação (Adiar / Pausar / Retomar / Marcar como paga) na altura correta — antes esticavam para acompanhar a altura da coluna do valor.
• A lista /cobrancas-agendadas também trocou o Paper chapado por Card com a mesma sombra.

Próximos passos

• Migração de limpeza removendo a coluna scheduled_charges_enabled.
• Endpoint admin para futuros kill switches por capacidade (quando precisarmos pausar algo, faremos via tabela de feature flags, não em colunas espalhadas em seller_config).