Changelog

O agente que fala MCP pede o mandato e confere a ação com recibo, com uma chave que não alcança mais nada.

Uma chave de API pode ser restrita a tipos de ato: cria só os que nomeia, e qualquer outro é recusado antes de qualquer efeito, assim como as demais operações de escrita. O painel tem um atalho que emite a chave do servidor MCP de mandato assim.

O SDK Python, hummand 0.4.0, e o núcleo do recibo, humanproof-core 0.8.1, estão no PyPI sob Apache-2.0. Com hummand[mcp], o servidor MCP de mandato dá ao agente três ferramentas: pedir o mandato, conferir se a ação cabe nele, com o recibo assinado inclusive na recusa, e consultá-lo. Nenhuma revoga.

O servidor avisa o agente; quem garante é o sistema que executa a ação, conferindo o recibo antes de agir. Testado de ponta a ponta em produção, com jornada real no celular.

A data de cada recibo passa a poder ser atestada por um terceiro que não é a Hummand. Versão de 2026-10-20, no ar desde 2026-10-24; a ancoragem fica desligada até o contrato com a autoridade.

Uma vez por dia, o ponto de conferência de cada cliente e cada recibo emitido, pelo hash, entram numa árvore cuja raiz recebe um carimbo do tempo de uma Autoridade de Carimbo do Tempo. Cada folha tem a sua prova, conferida antes de gravar; a autoridade recebe só a raiz, sem dado pessoal.

O dossiê leva a prova do recibo do ato, e quem recebe um dossiê compartilhado confere a ancoragem só com aquele recibo. O verificador em labs confere a prova com as raízes da ICP-Brasil embutidas, e a especificação pública passa à versão 1.3.

Em credenciamento: a ancoragem fica desligada até o contrato com uma autoridade credenciada na ICP-Brasil, e nenhuma prova foi emitida ainda.

Quem precisa acreditar na prova abre o dossiê do ato sem conta, e cada abertura vira um recibo.

O cliente gera, no dossiê de um ato terminado, um link com prazo para um destinatário e uma finalidade declarados; o link aparece uma única vez, e a Hummand guarda só o hash dele. A lista mostra quantas vezes cada link foi aberto, e o link pode ser revogado.

Quem recebe vê primeiro só o cabeçalho, que não gera recibo, porque a pré-visualização de mensageiro também abre links. Ao abrir o dossiê, sem a referência interna do cliente, a abertura é assinada como recibo de acesso de terceiro e aparece na linha do tempo do ato. Link revogado ou vencido deixa a tentativa registrada como negada.

No mesmo dia, o verificador em labs passou a conferir o pacote inteiro exportado do painel, e a especificação dos formatos ficou pública, com vetores de teste.

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.

Terceira release com binários para Linux, macOS e Windows, cada um com checksum.

Um lote pode trazer recibos de ato e recibos de acesso à evidência; o verificador agrupa por formato e por cliente e confere a cadeia de cada grupo. O relatório diz quem abriu, por papel e id opaco, o desfecho de cada abertura e quando. O motivo nunca, só o hash, que quem tem o texto confere com um subcomando.

O ponto de conferência da versão 2 afirma as duas cadeias, a de atos e a de acessos, e cada uma é conferida contra o que o ponto diz dela. Um ponto da versão 1 num lote com acessos não aprova por omissão.

O relatório sai também como página autocontida, sem script nem rede, para quem audita guardar junto com o lote e imprimir em PDF. Diz o que o texto diz, com as mesmas frases.

Quatro migrações aditivas numa janela só; nada muda no que o cliente já chama.

Abrir o conteúdo cifrado de um ato já exigia uma pessoa e um motivo e deixava registro. Agora cada abertura gera um recibo assinado, numa cadeia própria por cliente, verificável fora da Hummand com a mesma chave pública dos recibos de ato. Recusa e falha também viram recibo. Só hashes e ids opacos: o motivo nunca sai em claro.

Encerrar um contrato abre uma janela só leitura de trinta dias, imposta na credencial: o cliente lê e exporta, a escrita responde com o motivo e a data, e o pedido de apagamento continua atendido na hora. Ao fim da janela, a eliminação é automática e fica registrada.

Cada etapa passa a registrar quando começou, e o painel mostra a latência por fonte como medida, sem juízo. A revogação de mandato, que não tinha recibo, passa a ter. O detalhe do ato serve os consentimentos por camada. O certificado de cliente por contrato entra no código, desligado até a borda autenticar a origem.

humanproof-acesso/1 e humanproof-ponto/2, com as mesmas regras em Rust no servidor, na linha de comando e no navegador.

O recibo de acesso é um formato irmão do recibo de ato, assinado com a mesma chave, numa cadeia separada por cliente e com gênesis próprio: acesso não é ato. Diz quem abriu, por papel e id opaco, o que foi tocado e o desfecho; o motivo entra só como hash.

A verificação de lote passa a aceitar lotes mistos, agrupados por formato e cliente, e o ponto de conferência da versão 2 afirma as duas cadeias. O formato humanproof/1 continua humanproof/1.

Distribuída por release, com checksums e inventário de componentes.

Sem migração: o deploy é troca de imagem.

O gateway passa a assinar e a conferir o próprio recibo com a mesma biblioteca que o verificador de linha de comando, o SDK e a página em labs. aplicam: coerência de mandato, revogação como resultado próprio e a receita do hash do contexto.

Vinte e seis rotas passam a declarar no contrato o que devolvem. A forma da resposta não muda; o que muda é o contrato dizer isso, e os clientes gerados deixam de estreitar o tipo à mão.

Segunda release com binários para Linux, macOS e Windows, cada um com checksum.

Um recibo positivo cuja concessão não autoriza a ação passa a ser recusado, e o relatório conta o mandato em palavras: a concessão, o uso, a queda e o motivo. Antes, um ato delegado positivo se lia como qualquer outro positivo, e é justamente o mandato que o sustenta.

Com um ponto de conferência guardado antes por quem audita, o verificador confere o lote contra ele e acusa a remoção dos últimos recibos, que a cadeia sozinha não acusa. Duas contagens sempre, a do lote e a do ponto, porque quem audita precisa da diferença e não só do veredito. O relatório da cadeia passa a dizer contínua desde o gênesis, porque íntegra prometia uma completude que só o ponto sustenta.

Revogação como resultado próprio, coerência de mandato e a receita do hash do contexto no formato.

A revogação de um mandato passa a ser resultado próprio do recibo, e a coerência cobra o que o schema não cobria: concessão e uso nunca no mesmo recibo, escopo e mandatário juntos, resultado sustentado pelas afirmações do mandato. A receita do hash do contexto entrou no formato, para quem enviou o contexto conferir sozinho. O formato humanproof/1 continua humanproof/1.

O ponto de conferência é um formato irmão, assinado com a mesma chave: quantos recibos existiam e qual era o último, para quem audita guardar e comparar depois.

Primeira etiqueta do repositório: a biblioteca passa a ser distribuída por release, com checksums e inventário de componentes, e o verificador do navegador em labs. usa a mesma versão.

Sem migração: o deploy é troca de imagem.

O apagamento a pedido do titular passa a alcançar a validação documental avulsa pelo identificador do veredito, que é o que o cliente recebe desde que a rota existe. O alvo anterior pedia um id que nunca saía do servidor; este alcança também as validações já feitas. Consentimento, veredito e trilha morrem juntos, e o pedido registra o que morreu.

Mandato a agente, ato delegado e o passo de presença do revisor passam a disponível no catálogo que o painel lê, fechando uma divergência entre o que este site dizia e o que o cliente via na tela de política. O rótulo é declaração, não comportamento: nenhuma rota passou a aceitar o que recusava.

Uma dependência de rede subiu para a versão corrigida, e o comando que cria o primeiro revisor da fila passou a viajar na imagem.

Quem revisa um ato não ganha de brinde a visão de todos os clientes.

Um ato que precisa de decisão humana vai para uma fila com superfície própria: autenticar, ver a fila, abrir o caso, abrir a evidência e registrar o veredito, e nada além disso. Não há cliente, chave, faturamento nem configuração ali, e não porque a tela não mostre: a rota não existe.

Quem revisa tem credencial própria, que não abre o console de operação, e a sessão do console não abre a fila. Decidir exige presença provada na hora, pelo próprio revisor, na mesma jornada que qualquer pessoa percorre.

O veredito segue um protocolo versionado que o servidor serve, com justificativa de vocabulário fechado que não pode contradizer o veredito: "aprovado porque a fonte não respondeu" deixa de ser escrevível. O terceiro veredito devolve o ato para nova tentativa em vez de concluí-lo.

Mais a telemetria do console interno.

Abrir o conteúdo cifrado de um ato passa a exigir uma pessoa, um motivo declarado e deixa registro encadeado. O cliente lê no painel dele quem abriu, quando e por quê, inclusive quando quem abriu foi a Hummand, e a lista carrega antes de qualquer abertura: é ela a razão de existir do bloco.

A ausência vai declarada em três estados distintos, aberto, apagado e nunca houve, porque somar os dois últimos apagaria a diferença entre um apagamento que aconteceu e um campo nunca preenchido.

O recibo passa a dizer quando cada etapa aconteceu, medido.

O formato não mudou: ele já previa o instante por etapa, e o que mudou é que o valor passou a ser medido em vez de omitido. Três ausências ficaram declaradas em vez de preenchidas: ato anterior à mudança, etapa resolvida no mesmo instante em que o ato nasce, e sandbox, que não executa etapa.

Toda visualização de dado de cliente pelo console interno passou a deixar registro atribuível, e não só as alterações: é o mecanismo de controle de um console que, por decisão, não tem níveis. O cliente consulta a trilha de acesso ao que é dele.

Cabeçalhos de segurança de navegador nos cinco hosts, com transporte estrito e subdomínios incluídos, e resposta da API sem cache por padrão.

A dívida mais velha do painel: nenhum endpoint checava quem chamava.

Três níveis, do mais estreito ao mais amplo: analista, supervisor e administrador. A autorização é por piso, cada rota de sessão declara o nível mínimo que a abre, e uma suíte lê o roteador para provar que nenhuma ficou sem piso. Quem assina o contrato virou marca à parte, não um nível de acesso.

Quem era visualizador passou a analista e ganhou escrita, e isso está escrito na própria migração: migrar acesso em silêncio seria decidir por quem opera. O mínimo de dois administradores é trava na saída e aviso na entrada.

Junto, as métricas operacionais no painel: atos a expirar, distribuição por tipo e por versão de política. A tela declara, ao lado da coluna, que latência por fonte não existe, porque o ato registrava só criação e conclusão.

A cadeia não acusa o corte do fim. O ponto acusa.

Uma cadeia isolada denuncia buraco no meio, inserção, reordenação e bifurcação, e não denuncia a remoção dos últimos recibos, porque o que sobra continua contínuo desde o gênesis. Numerar não resolve: uma sequência de 1 a N não revela que existia N+1.

O ponto de conferência é um objeto assinado com a mesma chave dos recibos, dizendo quantos existiam e qual era o último hash. Quem audita guarda fora da Hummand e compara depois. Sem tabela nossa de pontos emitidos: a única cópia que vale é a de quem audita.

Criar o mesmo ato duas vezes deixa de criar dois atos.

Criação de ato aceita uma chave de idempotência: a mesma chave com o mesmo corpo devolve o mesmo ato, e corpo diferente é recusado. Quem retenta por queda de rede não duplica nada.

Consulta barata do estado de um mandato, e revogação em lote por mandatário ou por cliente, com um recibo por mandato derrubado. Os eventos do ato passam a sair no vocabulário do domínio.

A receita do hash do contexto passou a usar a canonicalização do próprio formato, e está publicada: quem tem o contexto original recomputa o hash sozinho, sem nada da Hummand.

O teto passou a valer para o cliente inteiro, e não por processo.

Contagem compartilhada no banco, com tetos por chave de API, por cliente e por endereço nas rotas públicas. Antes, cada processo contava o seu, e o teto real era o número de processos.

A API passou a responder atrás de uma borda que termina a conexão cifrada, com limite também na borda e a documentação interativa fechada por acesso.

Três coisas que não aparecem para quem usa, e que mudam o que dá para prometer.

Rastreamento e logs estruturados no serviço e nos workers, com alertas configurados e entrega de notificação provada, não presumida.

Os segredos de produção saíram do arquivo em disco e passaram a ser lidos de um cofre gerenciado, em memória. Nenhum segredo persiste no servidor.

Backups automáticos com cópia externa cifrada, fora do servidor, e o primeiro ensaio de restauração feito em produção. Backup que nunca foi restaurado é promessa, não garantia.

Quatro defeitos achados em revisão adversarial, corrigidos antes de subir.

A retenção não alcançava o contexto dos atos criados pela API nova; o apagamento irreversível passou a exigir um escopo próprio que nenhuma integração recebe por padrão; o comprovante público deixou de expor a posição do ato na cadeia; a revogação de mandato herda o modo sandbox.

Documentado o limite do apagamento: naquela versão, as validações avulsas de documento não eram alcançadas por pedido, só pelo prazo. Fechado depois, na 0.13.0.

Três fases do plano num release, substituído pela 0.5.1 antes de ir ao ar.

Operador em dupla com recibo composto; mandato de agente com escopo e revogação; ato delegado; prova de exceção por gatilho do cliente ou de uma fonte; alertas computados na leitura, com o evento de expiração; a decisão da fila de revisão exige presença fresca do revisor.

Dois tenants de teste e quatro cenários como suíte de aceitação, cada ato com recibo verificado fora do gateway. Política em leitura, privacidade do titular, recibo pelo token do link e revogação pelo painel.

Painel, jornada e console falam de atos, recibos, mandatos e política.

Painel: telas de atos, recibos com exportação do lote, mandatos com revogação, alertas, política em leitura e privacidade sobre as rotas reais. Jornada: etapa de escopo do mandato, comprovante ao final, acessibilidade para público idoso, bundle inicial de 1,39 MB para 209 kB. Console: decisão da fila só com presença fresca do revisor.

Tipos gerados do contrato OpenAPI nos três; noventa tipos escritos à mão eliminados.

Decisão de produto: API e recibo passam a dizer o mesmo.

Presença viva com match reprovado é ato negativo, não mais positivo com veredito à parte. Match pedido e não computado é falha técnica, com o motivo no recibo.

Correção após o deploy da 0.3.0.

O app não subiu porque a política da chave negava a leitura da chave pública ao serviço de recibos. Agora o erro fica no log, o JWKS sai vazio sem cache e é tentado de novo a cada pedido; a política da chave foi corrigida e documentada.

Emissão em toda transição terminal, endpoints, webhook, chave pública e expiração pelo prazo.

Recibo por ato e lote na ordem da cadeia; evento recibo.emitido com ids e hashes, nunca conteúdo; JWKS público; varredura de expiração a cada minuto levando atos vencidos a expirado, com recibo.

Primeira release, com binários para Linux, macOS e Windows e checksums.

Verificar recibo ou lote contra um JWKS por arquivo, relatório em texto ou JSON, códigos de saída 0, 1 e 2; hash, gênesis e canonicalização. Offline por construção.

Uma implementação em Rust para o servidor, a linha de comando e o navegador.

Canonicalização RFC 8785 restrita a inteiros seguros, hash, assinatura ES256, JWKS, cadeia por cliente com gênesis, coerência e o schema do formato embutido. Binding Python com emissão em duas etapas para assinar no módulo de chaves; alvo WebAssembly só de verificação.

O verificador no navegador e a primeira nota.

Página de verificação inteira no navegador, com JWKS por colagem ou buscado do gateway; nota "O formato humanproof/1". Publicado pelo Cloudflare Pages a partir da branch principal.

Checks viram atos; a política resolve as etapas; o contrato vem primeiro.

Catálogo dos doze tipos com defaults, política global v1 e resolução pura e determinística; rotas de atos com o link da jornada; lote com prazo comum; contrato OpenAPI versionado e cliente TypeScript gerado dele, conferidos no CI. As rotas de checks seguem como alias.

O que estava em produção depois de junho a agosto de 2026.

Verificações com presença viva e match transiente, consentimento por etapa, jornada por link dirigida por política, autenticação do painel com MFA, console de operação, webhooks assinados, notificações, envelope por registro, trilha de decifragem, isolamento por linha e crypto-shred.