v0.1.0-beta.8 — RETIRADA / NÃO USAR PARA ATUALIZAÇÃO

⚠️ ATENÇÃO — ESTA VERSÃO FOI RETIRADA

A v0.1.0-beta.8 foi retirada das superfícies mutáveis de distribuição (GHCR :beta e canal beta) devido a um incidente de portabilidade no backup canônico que impede a atualização em GNU/Linux e BusyBox.

Resumo do incidente:

• Fresh install da beta.8 é funcional.
• O problema está no caminho de atualização/backup canônico.
• O updater aborta de forma fail-closed antes de qualquer mutação (migrations ou troca de bundle).
• Nenhuma corrupção de dados foi demonstrada no incidente reproduzido.

O que fazer:

• Se você já está na beta.8 (fresh install ou update funcional): mantenha-se nela. A beta.9 corrigirá o problema e suportará upgrade a partir da beta.8.
• Se você está na beta.7: permaneça na beta.7. O canal beta voltou a apontar para beta.7.
• Não force o update para beta.8. Aguarde a beta.9.

A v0.1.0-beta.9 está em preparação e corrigirá a incompatibilidade stat BSD/GNU no fluxo de backup/restore canônico. Ela suportará atualização direta a partir de beta.7 e beta.8.

---

As notas abaixo são preservadas como registro histórico da publicação original. O aviso de retirada acima representa o estado operacional atual desta versão.

---

ContaBase v0.1.0-beta.8

Destaques

Esta Beta evolui o tratamento de datas financeiras para preservar a data de calendário sem depender do fuso horário do servidor. Novos lançamentos, pagamentos, agendamentos e recorrências passam a registrar também a data civil correspondente.

As recorrências ficam mais previsíveis e seguras. A edição de uma série valida a sua cadeia antes de gravar; os cortes em "Este e futuros" respeitam a data escolhida; e "Toda a série" aplica a mudança de forma atômica.

Correções importantes

• Repetir uma confirmação de pagamento não duplica movimentação de saldo, troca de conta nem histórico.
• A conta de pagamento pode ser ajustada apenas em receitas e despesas pendentes simples. Transferências, faturas, cartões e recorrências permanecem protegidos.
• A exclusão de "Apenas este lançamento" em uma recorrência deixa um registro persistente para que a ocorrência não seja criada novamente pela projeção.
• Estados, totais pagos e saldo pendente de faturas passam a usar pagamentos efetivos de forma consistente. Faturas históricas, seus pagamentos e lançamentos vinculados não são reabertos nem alterados automaticamente.
• Pagamentos de fatura podem ser revertidos por usuário autenticado, com motivo, responsável, data e lançamento de reversão registrados no histórico.

Recorrências

• Apenas este lançamento: a ocorrência removida continua ausente nas próximas projeções.
• Este e futuros: encerra o intervalo correto da série sem apagar o passado elegível.
• Toda a série: encerra a recorrência completa de forma atômica.
• Lançamentos pagos, exceções manuais e itens em faturas fechadas ou pagas permanecem protegidos.

Atualização self-hosted

O build de CSS usa Tailwind CSS 4.3.3 travado pelo lockfile. Node.js 24 LTS é a versão recomendada; Node.js 22 LTS continua compatível. No fluxo source, a compatibilidade é validada antes de interromper o serviço, e os assets de autenticação passam a usar versões para reduzir cache desatualizado.

Backup canônico obrigatório

Os updaters Docker, source e release exigem backup canônico completo (banco SQLite + uploads) antes de qualquer mutação. Falha no backup interrompe o update; --no-backup é rejeitado; e não há fallback em cópias cruas de DB/WAL/SHM.

Rollback e restore explícito

Se o healthcheck do novo runtime falhar, o serviço permanece parado e o runtime antigo não é reativado automaticamente. O retorno à versão anterior exige restore explícito do pacote pré-update.

Data e timezone visíveis

O rodapé das páginas autenticadas agora mostra a data, a hora e a timezone reconhecidas pelo ContaBase. Isso ajuda administradores de instalações self-hosted a confirmar visualmente se a aplicação está usando a configuração temporal esperada.

O horário é renderizado pelo servidor, usando a configuração global da aplicação, e é atualizado em carregamentos completos. Não existe relógio em tempo real. O indicador não modifica lançamentos, vencimentos ou datas históricas, nem garante sincronização NTP ou integridade financeira.

Faturas — movimentação manual

Lançamentos individuais de cartão de crédito podem ser movidos manualmente entre faturas elegíveis. A mudança persiste em invoice_override_id e respeita:

• faturas abertas ou fechadas financeiramente elegíveis;
• preservação de pagamentos modernos e legados;
• proteção de faturas quitadas ou liquidadas;
• proteção da fatura de origem contra reabertura indevida quando há pagamento legado;
• retorno ao vínculo automático quando apropriado;
• manutenção da competência, data e valor originais da compra.

A movimentação é coberta por testes de concorrência (CAS), replay e rollback para garantir unicidade do vencedor e consistência dos saldos.

Reservas — planejamento mensal

Adicionado o núcleo matemático puro para projeções de reservas, incluindo:

• cálculo determinístico de aporte necessário por alvo e data;
• projeção com rendimento composto;
• estimativa de meses/mês;
• saldo projetado;
• indicadores de suficiência/insuficiência;
• arredondamento e tratamento de centavos;
• correção da fronteira de precisão usando FV raw.

O resumo de planejamento mensal usa essas projeções para orientar a situação das reservas.

Banco de dados

A atualização evolui o schema da versão 51 para a 59. Ela preserva os dados existentes, mas executa validações de integridade antes de concluir o upgrade:

• 52 — civil_date_columns: cria as colunas de data civil usadas pelos fluxos atuais. O preenchimento de dados legados é uma operação separada e controlada; não ocorre automaticamente durante a migration ou na inicialização da aplicação.
• 53 — recurring_rules_active_leaf_invariant: valida a cadeia de versões das recorrências e interrompe o upgrade com diagnóstico se encontrar uma regra ativa com descendentes.
• 54 — recurring_occurrence_skips: grava tombstones para exclusões unitárias persistentes de recorrências.
• 55 — box_monthly_recharge_identity: identifica aportes automáticos por reserva e mês para impedir duplicidade.
• 56 — box_contribution_lifecycle: registra o ciclo de vida de aportes automáticos de reservas.
• 57 — workspace_monthly_planning_references: adiciona referências mensais de planejamento por workspace.
• 58 — invoice_payment_reversal_identity: registra a identidade e a proveniência de reversões de pagamento de fatura, com unicidade por workspace.
• 59 — recurring_occurrence_blocks: impede resultados terminais contraditórios para uma mesma ocorrência recorrente.

Compatibilidade e rollback

Faça um backup WAL-consistente antes de atualizar bancos com dados importantes. Caso uma validação de integridade encontre uma cadeia recorrente, uma identidade de pagamento ou uma ocorrência em conflito, o upgrade é interrompido sem escolher ou corrigir os dados automaticamente. Resolva o diagnóstico indicado antes de tentar novamente.

Depois que uma exclusão unitária for registrada, não faça downgrade para um binário anterior que não reconheça recurring_occurrence_skips: ele pode recriar a ocorrência que foi removida intencionalmente. Mantenha o schema e volte apenas para uma versão que respeite esses tombstones. As migrations 55 a 59 também introduzem identidades e referências usadas pelos fluxos atuais; faça restore explícito do pacote pré-update se precisar retornar os dados ao estado anterior.

Monitoramento self-hosted

O endpoint GET /health pode ser usado por Docker e por ferramentas de monitoramento como o Uptime Kuma para verificar a disponibilidade do ContaBase.

• 200 {"status":"healthy"} indica que o processo HTTP está respondendo e o acesso básico ao SQLite está funcionando.
• 503 {"status":"unhealthy"} indica que o processo responde, mas o banco de dados não está acessível.
• Métodos diferentes de GET são rejeitados com 405 Method Not Allowed.
• As respostas não contêm detalhes internos do banco, caminhos de arquivo ou dados de usuários.
• O status healthy não substitui backup, auditoria financeira ou verificação de integridade dos dados.

Há orientações na documentação para configurar um monitor interno (rede Docker ou IP privado) e um monitor externo por HTTPS com verificação de certificado TLS.

Problemas conhecidos

Nenhum problema adicional foi incluído nesta nota para a topologia self-hosted oficialmente suportada.