Releases

A prova periódica passa a abrir sozinha, e o mandato entre pessoas começa a executar.

Um ciclo de reverificação abre cada rodada como uma campanha comum, no mês de aniversário de cada pessoa, todo mês ou num dia do ano, com lembrete e relatório. Cada pessoa entra com a referência, os campos da casa para agrupar e o valor associado; no prazo, a rodada fecha com quantos comprovaram e o valor coberto e em risco, somados do valor informado pelo cliente, não estimativa.

O mandato de pessoa executa em nível 2: presença do mandante, escopo consentido e o documento que sustenta o mandato, do qual só o hash chega à Hummand. A presença de quem recebe o mandato entra como segunda presença, quando o cliente pede, e o mandato só vale com as duas. Sobe ao nível 3 quando a identidade civil estiver credenciada.

No painel, cada pessoa pode entrar com passkey, sem senha nem código, e a central de suporte recebe chamados com texto e imagem, respondidos pela equipe Hummand; a resposta chega como notificação.

O painel acompanha a estrutura do cliente, e o acesso da equipe passa a ter controle contínuo.

Unidades em árvore: quem está numa unidade vê só os atos dela e das de baixo, com as campanhas e os recibos desses atos. Minha fila responde o que pede ação hoje: atos sem resposta, aguardando a foto do cadastro, em revisão e com o link vencendo.

Retenção por tipo: a parte cifrada do ato pode ficar mais tempo que o padrão, até 20 anos, só com base legal declarada, e um ato ou uma campanha em disputa fica preservado até o cliente liberar.

O perfil Auditor lê o que o supervisor lê e não escreve, e a revisão de acessos agendada pede ao administrador que mantenha ou remova cada pessoa. O evento de webhook que esgota as seis tentativas fica guardado e pode ser reentregue com o mesmo event_id. A passkey passa a disponível no catálogo de fontes.

Leva junto a 0.25.0, que não chegou a ser publicada sozinha.

Uma busca acha, de uma vez, atos pelo id ou pela referência do cliente, mandatos pelo mandatário, recibos pelo id ou pelo hash e campanhas pelo nome. Nada é decifrado para buscar.

O ato de teste ganha um link de demonstração que mostra a jornada na ordem da política, sem câmera, sem passkey e sem registrar nada. Os gráficos do painel, os alertas e a latência por etapa passam a deixar os atos de teste de fora, como o uso e o faturamento já faziam. Sem migração e sem variável nova.

O cliente monta a orquestração de cada tipo de ato, e cada ato ganha um documento que reúne o que o prova.

Por tipo de ato, o cliente exige a foto do cadastro, escreve regras por contexto que só endurecem e define até 3 tentativas no mesmo ato, com o desvio ao esgotar, para negativo ou revisão humana.

A passkey passa a executar: cadastrada só depois de uma presença aprovada, prova a posse do aparelho com verificação do usuário nele, e nada biométrico chega à Hummand. Com ela, a política pode reaproveitar uma prova recente da mesma pessoa, por até 15 minutos, nos step-ups que o catálogo permite; sem a passkey à mão, a pessoa volta à presença viva.

O dossiê reúne o ato, a linha do tempo com a fonte de cada evento, os consentimentos, o recibo assinado e o recibo de cada acesso à evidência, e diz o que não é registrado, para ninguém concluir do silêncio.

O painel passa a levar a campanha do começo ao fim, e o acesso de cada cliente ganha controles opcionais.

A campanha ganha nome, responsável e tamanho sem teto prático, em partes de até 500 que seguem como uma só, relatório para prestar contas, com o trecho contínuo da cadeia de recibos, e lembrete de quem falta, com link reemitido. A foto do cadastro pode ser anexada depois da criação e fica cifrada no próprio ato só enquanto ele está aberto, até 30 dias.

O administrador pode limitar de onde o painel e a API aceitam acesso, por lista de IPs, e ligar o SSO com Google, que só deixa entrar quem já está na equipe. A política passa a ser endurecida por cliente: ligar ou desligar tipos, subir o nível mínimo e encurtar o prazo, cada edição numa versão nova que o recibo carrega.

A 0.23.1 corrige a gravação dessas três telas pelo navegador.

Uma rota nova de leitura, e o painel ganha a tela que fica na TV da sala de controle.

O que está acontecendo e o que pede atenção, numa janela móvel das últimas 24 horas e da última hora: atos criados, concluídos e por resultado, o que está aberto e o que vai expirar, a série por hora contra a mesma hora da semana anterior, a latência de cada fonte, os alertas da janela, as campanhas abertas e os mandatos.

Só agregados, nada que identifique alguém: a tela fica numa sala compartilhada. A conta logada na TV pode ser a de menor nível que ainda vê a tela, a de analista. Sem migração e sem variável nova.

Dez mudanças numa release: o painel cria, acompanha e exporta, pela mesma porta da API.

O painel cria ato pela mesma porta da API, com o catálogo de tipos e a política resolvida. As campanhas em lote ganham lista com andamento; os mandatos ganham lista com quem recebeu a autoridade, situação e validade.

A lista de atos filtra por resultado, referência e período, conta o total e exporta em CSV, sem dado do titular. A trilha de auditoria fica utilizável, com período, ator, desfecho e paginação, e cada abertura de evidência sai conferível linha a linha. O analytics aceita período livre, comparação com o período anterior e conversão por etapa.

Sessões abertas da conta, com o botão de encerrar as outras, e troca de senha sem sair. As rotas de escrita do painel passam a ter piso por nível, e um administrador não altera nem remove outro.

Só a borda da origem muda: sem migração e sem variável nova.

Seis meses de calendário chegam a 184 dias, e guardar 180 apagaria registros antes do mínimo legal. O prazo passa a 190 dias, na API e nas páginas.

A porta lógica de origem, que o Decreto 12.975/2026 pede quando necessária à identificação inequívoca, entra no registro: nas páginas desde 2026-09-26, 17:15 UTC, e na API com esta release. O gateway continua sem persistir IP ou porta.

A decisão humana fica num lugar só: a fila do revisor.

Uma lista só de leitura responde, para qualquer ato, se houve revisão, por quem, quando, com que veredito e por qual item do protocolo. As rotas antigas de decisão pelo console saem do contrato: decide-se na fila de revisão, com credencial própria e presença provada na hora.

Sem migração e sem variável nova.

Uma mudança, e fora do aplicativo: o registro nasce na origem, separado de tudo o mais.

Data e hora e endereço IP de cada acesso à API, por seis meses, num registro restrito fora do banco, dos backups e da telemetria. O gateway continua sem persistir IP; recibo e telemetria seguem sem IP.

Sem migração e sem variável nova. Com ela, o registro do art. 15 existe para a API como já existia, desde o mesmo dia, para as páginas.