v1.0.0-beta.6

Candidata Beta da linha 1.0 com aplicações de investimento, correções de interface e estabilidade.

Status: prerelease mantida como draft. Tag, artifacts e imagem GHCR gerados. A publicação depende de validação final e autorização.

Investimentos

O módulo fica disponível por padrão quando CONTABASE_FEATURE_INVESTMENTS está ausente, tanto em instalações novas quanto nas atualizadas. Configurações explícitas são preservadas, inclusive vazio e valores desconhecidos, que continuam desabilitando o módulo. O cadastro permite escolher a conta de investimento e a conta de origem. A primeira aplicação e as seguintes criam uma transferência e atualizam os dois saldos na mesma transação. O histórico liga cada aplicação ao seu lançamento, e repetir a mesma requisição não duplica seus efeitos.

Use esse fluxo para dinheiro que ainda não foi transferido. Registros patrimoniais antigos não geram débito retroativo. O total aplicado é distinto da posição manual e da cotação de mercado. As transferências preservam a política existente, inclusive saldo negativo permitido.

O fluxo funciona no schema 77. Adoção histórica e resgates financeiros das novas aplicações permanecem indisponíveis. As flags de operações financeiras controladas continuam opt-in. Veja o guia de Investimentos para disponibilidade e limites.

Interface e segurança

• Relatórios, Contatos, Configurações e Administração usam componentes Premium e receberam melhorias de navegação, formulários, foco e responsividade.
• Configurações e Administração alinham conteúdo e espaçamento; ações de contas/cartões e detalhes da posição aplicada ocupam menos espaço no mobile.
• Contas, Investimentos e Notificações reutilizam o controle global de privacidade, com máscaras financeiras e estado preservado na sessão do navegador.
• Correções locais incluem nome acessível em Metas, contraste do badge Vencido, alvos de toque e títulos de Notificações em duas linhas.
• Auditoria administrativa exige autorização; configuração SMTP preserva a senha ao receber campo vazio e não a devolve ao formulário. Relatórios reforçam permissões de leitura e proteções nas exportações.

Correções

• O executor de pagamentos agendados reserva o escritor SQLite antes de recarregar o pagamento, evitando conflitos com outros jobs no startup. Débito, histórico e notificação permanecem atômicos.
• Corrigido o menu "Mais opções" em Metas e Reservas para evitar interferência visual com os cartões ao fundo.
• A página de Faturas agora abre automaticamente no próximo mês com uma fatura em aberto quando o mês atual já está totalmente pago.
• A contagem de dias até o fechamento usa datas civis nos cartões de Faturas e do Dashboard. O valor deixa de divergir do resumo do ciclo na virada do dia, do mês, do ano e em fusos com horário de verão.

Credenciais e recuperação

A identidade de seed histórica não é mais reativada durante o startup. Hashes vazios, inválidos ou correspondentes à senha pública conhecida são inutilizados, e a conta passa a exigir recuperação administrativa explícita. A contenção preserva status, vínculos, permissões, dados de workspace e fatores 2FA; nenhuma senha temporária é emitida automaticamente pelo processo de inicialização.

Para recuperar o acesso, um administrador usa a redefinição de senha existente em Administração > Usuários ou o Admin CLI. O fluxo gera uma senha temporária, exige troca no próximo login, revoga sessões e desafios anteriores e mantém os fatores 2FA cadastrados. Se o autenticador também foi perdido, a desativação de 2FA é uma ação administrativa separada. Não edite a tabela users diretamente nem reintroduza um build que recrie a credencial pública.

SECURITY_MASTER_KEY deve ser configurada explicitamente, com exatamente 32 bytes, em qualquer ambiente. Não há mais fallback público em desenvolvimento. Sem a chave, uma senha SMTP nova não pode ser gravada e alertas que dependam de senha cifrada não são enviados; o ciphertext existente não é apagado. Se a senha SMTP tiver sido cifrada pelo fallback antigo, configurar uma chave nova não recupera esse valor. Preserve banco e chaves e informe novamente a senha pela Administração; recuperar o segredo antigo sem conhecê-lo exigiria uma migração offline específica, não incluída nesta versão.

Atualização e recuperação

Caminho de atualização previsto: v1.0.0-beta.5 → v1.0.0-beta.6.

Faça backup antes da atualização e preserve AUTH_ENCRYPTION_KEY e SECURITY_MASTER_KEY. A atualização não regenera chaves, não restaura banco e não reverte migrations automaticamente.

Os fluxos de instalação e atualização só reativam automaticamente um bundle ou imagem anterior quando existe prova administrativa local de que ele é uma cópia verificada da própria Beta 6, com conteúdo exato, emitida após health válido, e quando a candidata ainda não foi iniciada. A prova fica fora do bundle e não é uma assinatura de fornecedor. Não há downgrade automático para a Beta 5. Depois de qualquer tentativa de startup da candidata, o retorno automático é bloqueado, pois o schema pode ter avançado: mantenha o serviço parado, preserve banco, WAL, uploads, configuração, chaves e backups, e repare com um artefato verificado compatível com o schema atual. Restaurar banco ou voltar schema exige plano e autorização próprios.

O upgrade operacional Beta 5 → Beta 6 pelo instalador público ainda não foi comprovado integralmente. A validação funcional em Docker DEV não substitui o ensaio de atualização em uma instalação real.

Esta é uma prerelease da linha 1.0 e não uma versão estável.

---

Artefatos oficiais: contabase-linux-amd64.tar.gz, contabase-linux-arm64.tar.gz e checksums.txt. A imagem fixa é ghcr.io/contabase-app/contabase:v1.0.0-beta.6.