🆕Versão v1.4.0

Filtrar e ocultar processos INATIVOS na listagem e na Certidão CERM

Implementado

1. Filtro na tabela de Processos do Cadastro do Minerador

• A tabela passa a mostrar somente os processos com situação ATIVO na ANM. Os inativos deixam de aparecer na grade.
• O contador do cabeçalho ("N processos") conta só os ativos.

2. Ajuste na Certidão CERM

• O texto "Processos na certidão" passa a citar apenas os processos ativos, tanto na primeira emissão quanto na reemissão.

Observações

• Certidões já emitidas não mudam; o ajuste vale para as próximas emissões e reemissões.
• Um processo que ainda não consta na base da ANM não é retirado da certidão, porque não há como afirmar que está inativo.
• O link "Ver todos os processos" abre a consulta geral, que continua mostrando ativos e inativos e permite filtrar por situação.

PLANO DE PESQUISA - Versões do plano com trilha de data e autor (MON-03)

Implementado

1. Versões do plano

• O plano de pesquisa passa a ter versões numeradas, cada uma com situação (Em elaboração, Finalizada, Vigente ou Substituída), autor e datas. O cronograma pertence à versão.
• Só uma versão fica vigente por plano, e só uma fica aberta (em elaboração) por vez.
• Alterar um plano já finalizado abre a versão seguinte, e a anterior continua inteira, com o mesmo cronograma, data e autor.

2. Registro de tudo o que acontece com o plano

• Criação, finalização, assinatura e substituição de cada versão ficam registradas com quem fez e quando. O registro só recebe novas linhas: não pode ser alterado nem apagado.

3. Planos que já existiam

• Cada plano atual virou a versão 1, com o cronograma de hoje. Os planos já assinados ficaram como vigentes, com o mesmo PDF assinado.
• Planos de produção continuam abrindo com o mesmo conteúdo.

4. Gravação e assinatura

• Gravar um plano finalizado deixa de sobrescrever: abre a versão em elaboração, ou continua a que já está aberta.
• Ao assinar a versão nova, a anterior passa a Substituída e a nova a Vigente. Uma assinatura que chega depois de a versão ter sido substituída é recusada, com mensagem própria.

5. Tela

• A lista de planos ganha a coluna "Versão" (por exemplo, "v1 vigente" ou "v1 em elaboração") e o formulário mostra a versão que está sendo alterada.

Observações

• A assinatura continua uma por plano. A assinatura registrada por versão, com o signatário, é a tarefa seguinte da mesma demanda maior.
• Se o plano nunca teve versão vigente e o rascunho da versão nova é descartado, a última versão substituída volta a Finalizada. Havendo versão vigente, descartar o rascunho não muda nada nela.

PLANO DE PESQUISA - Metas físicas e métodos previstos no cronograma (MON-03)

Implementado

1. Metas físicas por atividade

• Cada atividade do cronograma pode ter várias metas, cada uma com quantidade e unidade (por exemplo, 500 metros de sondagem e 20 amostras coletadas na mesma atividade).
• A quantidade aceita até duas casas decimais, com vírgula (2.000,5), e precisa ser maior que zero. Metas incompletas são sinalizadas na própria linha, e um aviso acima do cronograma diz quantas impedem a gravação.
• As metas pertencem à versão do plano: ao abrir uma versão nova, ela começa com as metas da anterior, e a anterior continua como estava.

2. Métodos previstos do plano

• O plano ganha o campo "Métodos previstos", de escolha múltipla, mais "Outro método" em texto livre.

3. Listas mantidas pelo administrador

• Duas listas novas na área do administrador: "Unidades de meta do plano de pesquisa" (metros de sondagem, furos, amostras coletadas, análises químicas, hectares mapeados, trincheiras e poços, valor investido em R$) e "Métodos de pesquisa" (mapeamento geológico, geoquímica, geofísica, sondagem, trincheiras e poços, amostragem, ensaios de beneficiamento).
• Unidade ou método desativado deixa de ser oferecido, mas o plano que já o usava continua mostrando o nome.

4. Formulário, consulta e PDF

• O formulário do plano tem as metas em cada linha do cronograma e o campo de métodos. As metas e os métodos aparecem ao reabrir o plano e no PDF da declaração (coluna "Metas" no cronograma e bloco "Métodos Previstos").
• Finalizar o plano exige ao menos uma meta em alguma atividade, com mensagem clara.

Observações

• As listas iniciais de unidades e de métodos são as sugeridas na issue e ainda precisam da confirmação da SEDEC. O administrador pode ajustá-las sem nova versão do sistema.
• Planos antigos não têm meta: continuam abrindo, mas só podem ser finalizados depois de ganhar ao menos uma.
• A quantidade da meta tem teto de 999.999.999.999,99.
• Junto com esta entrega foi corrigida uma falha da entrega anterior (versões do plano): o detalhe de um plano cuja versão em rascunho foi descartada e restaurada deixava de abrir.

PLANO DE PESQUISA - Anexos do plano (MON-03)

Implementado

1. Anexos por versão do plano

• O formulário do plano ganha o bloco "Anexos": escolha do tipo, escolha do arquivo e botão "Anexar". Cada anexo aparece com tipo, nome, tamanho, quem enviou e quando, com botões para baixar e remover.
• Aceita PDF, JPEG e PNG, de até 10 MB por arquivo e até 10 anexos por versão. Arquivo acima do tamanho é recusado com a mensagem "O arquivo tem 11,0 MB; o limite é 10 MB".
• Os anexos só podem ser enviados ou removidos na versão em elaboração.

2. Tipos de anexo mantidos pelo administrador

• Nova lista "Tipos de anexo do plano de pesquisa" na área do administrador, com os tipos iniciais "A.R.T. do plano de pesquisa", "Planejamento enviado à SEDEC" e "Outros".

3. A.R.T. obrigatória para finalizar

• Novo parâmetro do sistema, PLANO_PESQUISA_EXIGE_ART, ligado por padrão e visível na tela de parâmetros. Ligado, o plano só finaliza com a A.R.T. anexada, e sem ela aparece "Anexe a A.R.T. do plano de pesquisa antes de finalizar". Desligado (NAO), a A.R.T. é opcional.
• Se o administrador desativar ou excluir o tipo da A.R.T., a exigência deixa de valer, para não impedir a finalização de todos os planos.

4. Versão nova herda os anexos

• Ao abrir uma versão nova, ela começa com os anexos da anterior. O responsável técnico pode tirar ou trocar qualquer um, e a versão anterior continua com os dela.

5. Quem baixa

• O download segue a mesma visão do plano: quem não enxerga o plano não baixa os anexos.

6. PDF do plano

• O PDF da declaração ganha a seção "Anexos", com tipo, nome do arquivo, tamanho e o código de conferência (SHA-256) de cada um.

Observações

• Os anexos ficam guardados no banco de dados do sistema, no mesmo padrão dos anexos da declaração mensal.
• Planos em elaboração criados antes desta entrega não têm A.R.T. e só finalizam depois de ganhar uma (ou com o parâmetro desligado). Planos já finalizados ou assinados não são afetados.
• Os tipos iniciais de anexo são os sugeridos na issue e ainda precisam da confirmação da SEDEC; o administrador ajusta a lista.

PLANO DE PESQUISA - Plano só em título vigente (MON-03)

Implementado

1. Plano só em processo na fase de pesquisa e com alvará dentro do prazo

• O plano de pesquisa só pode ser aberto, e só ganhar versão nova, em processo na fase de autorização de pesquisa e com o título dentro do vencimento, pela data de vencimento importada da ANM. Vale o título de publicação mais recente do processo.
• Processo em fase de lavra (ou em outra fase fora da pesquisa) não aparece na lista de processos disponíveis, e o sistema recusa abrir plano nele.
• Processo com alvará vencido também sai da lista e não ganha versão nova.

2. Título sem vencimento na ANM

• Se a ANM não informou a data de vencimento (ou o processo não tem título), o plano é aceito, e a tela mostra "vencimento não informado pela ANM".

3. Plano que já existia continua legível

• Plano em processo que deixou de estar vigente continua abrindo para consulta. A versão nova é recusada com o motivo ("O alvará de pesquisa do processo ... venceu em ..." ou "O processo ... não está na fase de autorização de pesquisa ..."), e o botão de abrir nova versão fica desabilitado com esse motivo ao passar o mouse.
• Rascunho já aberto continua podendo ser alterado, finalizado e assinado, mesmo que o alvará tenha vencido depois, para não prender o trabalho em andamento.

4. Ficha do plano

• A ficha ganha o bloco "Alvará de pesquisa": fase do processo, data de publicação do alvará, vencimento e o prazo legal de 60 dias para apresentar o plano (art. 6º, §5º, do Decreto 1.100/2024), só como informação. O aviso de atraso fica com a fiscalização (FIS-06).

Observações

• A lista de processos disponíveis para novo plano fica bem menor: no ambiente de testes, de 4.523 processos em pesquisa autorizada, 2.179 têm alvará vigente ou sem vencimento informado. Os demais saem por alvará vencido na carga da ANM.
• Onde a ANM não traz a data de publicação do alvará, a ficha não mostra o campo.
• Quando há mais de um título no processo, vale o de publicação mais recente; essa escolha precisa da confirmação da SEDEC.
• Não há mudança no banco de dados: a regra lê dados que a carga da ANM já traz.

PERFIL RESPONSÁVEL TECNICO - MENU CADASTRO DO RESPONSÁVEL TECNICO

Implementado

1. Visualização dos itens permitidos

• Quem entra como Responsável Técnico passa a ver, em Cadastro do Responsável Técnico, só duas coisas: os dados cadastrais e a Senha de acesso.
• Os termos de responsabilidade de cada empresa atendida continuam na tela, num bloco enxuto com a situação do termo, o botão de assinar com gov.br e o documento assinado. Eles não podem sumir, porque é por ali que o RT assina.

2. Remoção dos itens não aplicáveis

• Deixam de aparecer Mineradoras vinculadas, Processos, Certidão CERM e Documentos para o Responsável Técnico.
• Quem também é titular ou representante de uma empresa continua vendo esses blocos dessa empresa. Nas empresas em que a pessoa só atua como RT, eles não aparecem.
• O painel inicial e a tela de mineradores não levam mais o RT para telas que ele não pode abrir: ele volta ao próprio cadastro.

3. Segurança

• Se o Responsável Técnico tentar abrir pelo endereço as informações de mineradoras, a certidão CERM ou os documentos de uma empresa que só atende como RT, o sistema recusa o acesso (erro 403), mesmo que o endereço seja digitado direto no navegador.

Observações

• A Consulta de Processo do menu lateral continua disponível para o RT. A issue pede a remoção de "Processos" dentro do cadastro, e não do menu, e a consulta usa a mesma base de dados.
• O termo de responsabilidade do RT foi mantido, porque a issue pede para tirar a lista de mineradoras, e não a assinatura.

Alterar declaração confere o processo atual, e não só o novo

Implementado

1. Alteração de declaração mensal confere o processo em que ela já está

• Ao salvar a alteração de uma declaração de exploração mineral, o sistema confere se quem altera pode declarar tanto no processo em que a declaração está gravada quanto no processo informado no formulário. Antes, só o processo informado era conferido.
• Na prática isso fecha uma brecha para o responsável técnico: quando entrava sem escolher o papel, ele enxergava todas as declarações da empresa, inclusive as de processos que o órgão não atribuiu a ele, e conseguia mover uma dessas declarações para um processo seu pela alteração. Excluir, anexar e entregar já recusavam; alterar passou a recusar também, com a mesma resposta de "processo não encontrado entre os que você pode declarar".
• Para o titular, o representante do titular e o responsável técnico que altera uma declaração de processo atribuído a ele, nada muda.

Observações

• A conferência acontece antes de qualquer gravação: a declaração recusada continua exatamente como estava, no processo original.
• Declaração antiga sem número de processo (dado herdado) passa a ser inalterável por esse caminho, do mesmo jeito que já era inexcluível; ela precisa do órgão.

Avisos parametrizáveis, fase 1: o texto dos avisos do sino vem do servidor

Implementado

1. O texto de cada aviso do sino passa a ser escrito pelo servidor

• O título, a frase, a linha com o número do processo e o botão de cada aviso do sino e da faixa do painel agora vêm prontos do servidor, a partir de uma lista única dos eventos que geram aviso. Antes, cada tela montava a frase por conta própria.
• Para quem usa, nada muda na tela: o sino mostra os mesmos avisos, com o mesmo texto e os mesmos botões. O processo novo da ANM continua com "Validar processo", o processo atribuído ao responsável técnico com "Ver processo" e o convite de responsável técnico com "Aceitar convite". O convite aceito, revogado ou vencido continua sem botão, com a frase de que não está mais disponível.

Observações

• O texto de hoje foi conferido letra por letra contra o que a tela escrevia antes da mudança, em oito situações, incluindo nomes de minerador com símbolos e acentos.
• Esta fase não cria aviso novo nem muda quem recebe cada aviso.
• Quem estiver com a aplicação aberta durante a atualização vê, até recarregar a página, um aviso genérico com o botão "Ver" ou "Ver processo". Clicar em "Ver" num convite marca o aviso como lido sem aceitar o convite; depois de recarregar, o botão "Aceitar convite" continua disponível no sino.

Telas e servidor conferidos contra a mesma descrição dos dados

Implementado

1. As telas passam a ler os dados pela descrição oficial do sistema

• A parte das telas que cuida de mineradores, usuários, taxas (TFRM), alertas de não conformidade e responsáveis técnicos agora usa a mesma descrição de dados que o servidor publica, em vez de uma cópia mantida à mão.
• Quando alguém muda essa descrição e esquece de atualizar as telas, a versão nova não chega a ser publicada: a verificação automática recusa antes.
• Foi esse tipo de diferença que já fez o vínculo de responsável técnico recusar a habilitação escolhida ("Falha ao vincular").

2. Respostas do servidor conferidas nos testes

• Os testes automáticos do servidor passam a conferir cada resposta contra a descrição oficial: situação devolvida, tipo de arquivo e conteúdo.
• A recusa por termo de responsabilidade ainda não assinado pelo gov.br agora consta na descrição de todas as telas que ela bloqueia.

Observações

• Nada muda na tela. É uma proteção para que telas e servidor não voltem a divergir.
• As demais áreas do sistema passam pela mesma troca nas próximas etapas.

CPF do responsável técnico deixava de ser apagado da aba ao sair

Implementado

1. Sair da plataforma apaga o CPF do responsável técnico guardado na aba

• Quando um responsável técnico entra, a plataforma guarda na aba do navegador uma marca com o CPF dele, para consultar a Receita Federal uma vez só por sessão e não a cada tela. Essa marca não era apagada ao sair: quem usasse a mesma aba depois conseguia ler o CPF pelas ferramentas do navegador.
• Agora sair da plataforma apaga a marca junto com o restante do que é da pessoa.

2. Entrar também apaga o que sobrou de uma sessão anterior na mesma aba

• Se a sessão anterior terminou sem o botão Sair (aba restaurada pelo navegador, sessão expirada), o próximo login na mesma aba apaga a marca antes de começar. Vale para todas as formas de entrar: senha, senha com código por e-mail, troca de conta e gov.br.
• Efeito prático: a consulta à Receita Federal volta a acontecer a cada novo login do responsável técnico, como previsto. Antes, quem saía e entrava de novo na mesma aba ficava sem essa atualização de nome e endereço.

Observações

• Nada muda nas telas. A diferença só aparece nas ferramentas de desenvolvedor do navegador, onde a marca com o CPF não existe mais depois de sair.
• A plataforma passou a ter uma verificação automática que impede uma nova informação da pessoa de ser guardada no navegador sem entrar na lista do que o login e o logout apagam.

Emissão de DAR: respeito ao papel de Responsável Técnico e conciliação de emissões sem resposta da SEFAZ

Implementado

1. Operando como Responsável Técnico, só processo atribuído emite DAR

• Quem é titular ou representante de um minerador e também Responsável Técnico, ao entrar como Responsável Técnico, só consegue emitir DAR nos processos que o órgão atribuiu a ele. Antes, um pedido feito fora da tela conseguia passar pelo vínculo de titular, a SEFAZ emitia o boleto (que não tem cancelamento), e a resposta ainda dizia "não encontrado".
• A recusa agora acontece antes de qualquer contato com a SEFAZ: nada é emitido e nada é gravado. A mesma pessoa, entrando como Minerador, continua emitindo normalmente.

2. Emissão sem resposta da SEFAZ deixa de depender de intervenção no banco

• Quando a chamada à SEFAZ falha sem resposta (rede, tempo esgotado), ou quando a SEFAZ responde e a gravação do registro falha logo depois, a emissão fica "aguardando conciliação". Antes, essa situação travava o pedido para sempre e só se resolvia por ajuste manual no banco.
• A tela Boleto TFRM ganhou, para Administrador e Servidor, o quadro "Emissões aguardando conciliação com a SEFAZ", com minerador, processo, sub-receita, competência, valor, data do envio e a situação. Para cada linha há duas ações: Confirmar DAR (depois de conferir com a SEFAZ que o boleto saiu, informa-se o número e o registro é gravado, sem o PDF, que só vem na resposta original) e Descartar (a SEFAZ não emitiu; a linha some e o pedido pode ser refeito). Uma linha em que a SEFAZ já devolveu o número e só faltou o registro não pode ser descartada, só confirmada.
• Enquanto houver uma emissão aguardando conciliação, nenhum DAR novo da mesma taxa (mesmo minerador, processo, sub-receita e competência) é emitido, mesmo mudando vencimento ou quantidade. A mensagem explica o motivo e diz que o órgão precisa confirmar ou descartar a emissão anterior. Antes, bastava trocar o vencimento para a SEFAZ emitir um segundo boleto.

Observações

• O serviço da SEFAZ não tem consulta que localize um boleto emitido sem o número dele (as consultas existentes são por número ou por período e só devolvem boletos pagos). Por isso a conferência é feita pelo órgão por fora, e a aplicação registra o resultado.
• O registro confirmado pelo órgão aparece na listagem com "sem arquivo" na coluna Boleto e com a consulta de pagamento funcionando normalmente, porque ela é pelo número.

Registro de decisões do projeto reorganizado

Mudança interna da equipe de desenvolvimento, sem efeito nas telas do sistema.

Implementado

• O registro das decisões do projeto (por que cada regra do sistema é como é) deixou de ser um documento único e longo. Cada decisão agora fica num registro próprio, com data, assunto e a indicação de quando ela foi substituída por outra mais nova.
• Uma conferência automática passou a recusar registro fora do padrão antes que ele entre no projeto, e a mesma conferência roda antes de cada versão ser publicada.
• As regras de trabalho da equipe ganharam um quadro único que diz, para cada regra, o que garante que ela seja seguida.

Como conferir: nada muda para quem usa o sistema; o ganho aparece na velocidade e na consistência das próximas entregas.

Desligamento do sistema antigo (GeneXus), primeira etapa

Implementado

1. Assinatura da Declaração de Pesquisa Mineral

• A tela não mostra mais o aviso que mandava assinar a declaração no sistema antigo, nem o link "Assinar no sistema atual". A assinatura com gov.br já é feita no próprio MINA MT desde setembro, e o aviso tinha ficado para trás.

2. Log de Acesso volta a ser registrado

• Cada entrada na plataforma, pela senha, pela senha com código enviado por e-mail ou pelo gov.br, volta a gerar uma linha no Log de Acesso, com data e hora de Cuiabá, navegador e endereço de origem.
• O registro estava parado desde 25/09/2026, porque só o sistema antigo o gravava.
• Se o registro falhar por algum motivo, a pessoa entra do mesmo jeito.

3. Criação de contas sem número repetido

• A criação de conta, pelo autocadastro ou pela Gestão de Usuários, e a atribuição de perfil não recusam mais o cadastro quando duas pessoas o fazem ao mesmo tempo.

4. Credenciais de produção protegidas

• As credenciais das integrações (gov.br, assinatura do ITI, ConectaGov, SEFAZ, GeoCloud) deixaram de depender de arquivos do sistema antigo e têm cópia de segurança. Desligar o sistema antigo não derruba o login nem a assinatura gov.br.

Observações

• O sistema antigo continua no ar até a etapa de desligamento propriamente dita. O plano por etapas já está registrado, com o que precisa ser decidido antes: telas do menu do órgão que só existiam no sistema antigo e cargas de planilha que eram feitas por ele.
• Os endereços de retorno do gov.br e o QR Code das certidões já impressas continuam funcionando depois do desligamento.

Atualizações do banco sem conflito entre melhorias feitas ao mesmo tempo

Implementado

1. Numeração das atualizações do banco

• Cada melhoria que precisa mudar o banco de dados traz uma atualização numerada. Quando duas melhorias eram feitas ao mesmo tempo, as duas podiam pegar o mesmo número, e a plataforma só percebia o choque na hora de entrar no ar. Isso aconteceu 7 vezes.
• A partir de agora cada atualização nova recebe a data e a hora em que foi criada, no horário de Cuiabá, e duas melhorias não disputam mais o mesmo número.
• A conferência automática que roda antes de cada publicação recusa uma atualização numerada do jeito antigo e diz qual nome usar.

2. Publicação e volta de versão

• Uma melhoria que fique pronta depois de outra mais nova entra normalmente na publicação seguinte.
• Se uma publicação precisar voltar para a versão anterior, a versão anterior continua subindo, mesmo com o banco já atualizado.

Observações

• Nada muda nas telas. É uma mudança na forma de preparar as atualizações do banco, para que as publicações não parem por choque de numeração.
• As atualizações antigas ficam como estão.

Conferência obrigatória na tela antes de entregar mudança visual

Implementado

1. Mudança de tela só é dada como pronta depois de vista na tela

• Quando um assistente de programação altera algo que aparece nas telas do MINA MT ou do portal público, ele não consegue encerrar a entrega sem antes abrir a tela de verdade e registrar a imagem dela. Antes, essa conferência era uma regra escrita e às vezes ficava para trás, como no caso dos filtros do Mapa mineral que ficaram sobrepostos aos indicadores.

2. Exceção registrada por escrito

• Quando a alteração não muda nada do que se vê na tela, o assistente precisa dizer isso por escrito na própria entrega, com o motivo, para que a dispensa fique registrada.

Observações

• Não há mudança em nenhuma tela do MINA MT. O ganho é de processo: menos chance de um defeito visual chegar à equipe da SEDEC sem ter sido visto antes.

Verificações automáticas contra dois erros que já derrubaram telas

Implementado

1. Consulta que juntava duas palavras e dava erro na tela

• Três vezes, entre setembro e outubro, uma consulta ao banco foi montada de um jeito que juntava duas palavras do comando, e a tela respondia com erro: o histórico de importações, o cadastro do responsável técnico e a lista de responsáveis técnicos do minerador.
• A partir de agora, a verificação que roda antes de toda versão recusa esse jeito de montar a consulta, em qualquer parte do sistema, e diz onde está e como corrigir.
• Um ponto da assinatura de declarações que funcionava por sorte foi ajustado para não depender dela. Nada muda para quem usa.

2. Integração lenta que podia travar o sistema inteiro

• Em setembro, o cadastro esperava a consulta à Receita com uma conexão do banco presa. Com a Receita lenta, poucos pedidos ao mesmo tempo esgotavam as conexões e derrubavam junto o login, o painel e a consulta pública. O mesmo erro voltou nove dias depois na confirmação do cadastro, com a consulta de servidor público.
• A verificação antes de cada versão passa a recusar operação que segure conexão do banco enquanto espera Receita, SEFAZ, assinatura gov.br, GeoCloud, SEPLAG ou envio de e-mail.

Observações

• Três envios de e-mail ainda seguram a conexão enquanto esperam o servidor de e-mail, por até 10 segundos: o reenvio do código de confirmação do cadastro (pelos dois caminhos) e a senha temporária do "Esqueci minha senha". Ficam registrados como pendência conhecida, e a verificação barra qualquer caso novo.

Plano de pesquisa: Responsável Técnico só declara em processo atribuído

Implementado

1. A lista de processos do plano de pesquisa respeita o perfil ativo

• Quem opera como Responsável Técnico passa a ver, no campo Processo do formulário do plano de pesquisa, apenas os processos que o órgão atribuiu ao seu vínculo, do mesmo modo que já acontece na Declaração de Exploração Mineral e na emissão de DAR. Antes a lista oferecia todos os processos do minerador.
• Quem entra como Minerador (titular ou representante do titular) continua vendo todos os processos do minerador nas fases de pesquisa.

2. A gravação não desfaz mais o plano com uma mensagem enganosa

• Antes, o RT escolhia um processo não atribuído, preenchia o formulário inteiro e, ao salvar, recebia "O plano foi gravado mas não pôde ser lido de volta", e nada ficava gravado. Agora a recusa vem antes de qualquer gravação, com a mensagem "Você não pode declarar pesquisa neste processo".
• Finalizar e excluir um plano seguem a mesma regra: o RT só faz isso em plano de processo atribuído a ele. Consultar o plano continua possível como antes.

3. O aviso de lista vazia explica o motivo

• Quando não há processo disponível, a tela diz por quê. Sob o perfil de RT, informa que só processos atribuídos ao vínculo aparecem e, se a pessoa também tem o perfil de Minerador, sugere trocar o perfil no topo da tela.

Observações

• A regra vale também para quem tem só o vínculo de RT e entrou sem escolher perfil: a consulta dos planos continua ampla, mas abrir, finalizar ou excluir exige o processo atribuído.

Política de acesso única: base técnica (etapa 0)

Implementado

1. Um lugar só para dizer quem entra em cada função da plataforma

• Cada função da API passa a poder declarar, no próprio contrato, quem pode chamá-la (público, qualquer pessoa autenticada ou só o órgão). A conferência acontece antes de a função rodar, sempre do mesmo jeito, em vez de cada tela repetir a sua própria regra.
• Nesta etapa só a base foi construída e uma função de apoio foi migrada (a lista de municípios por UF). Nenhuma regra de acesso mudou e nenhuma tela muda.

2. Trava para função nova sem regra declarada

• A partir de agora, uma função nova criada sem declarar quem pode chamá-la é recusada pelos testes automáticos antes de chegar à produção, com a instrução do que falta.

3. A plataforma se recusa a subir se a conferência estiver desligada

• Se a peça que faz a conferência deixar de estar ligada, a API não inicia, em vez de atender sem conferir.

Observações

• É uma etapa de fundação: as regras de acesso de hoje continuam exatamente as mesmas. As funções existentes serão migradas para o novo modelo nas próximas etapas, por grupos.
• A lista de municípios passou a exigir sessão válida pelo novo mecanismo, como já exigia antes.

Página pública do QR Code: CPF de quem assinou nunca em duas máscaras

Implementado

1. CPF de quem assinou na página de conferência do QR

• Na página que abre ao ler o QR Code de um documento assinado na plataforma (termos de responsabilidade e declarações), o CPF de quem assinou sai no padrão único do sistema, ***.456.789-**, uma vez só, nos documentos assinados a partir de 04/10/2026.
• Nos documentos assinados antes dessa data, o carimbo impresso no papel traz o CPF na forma antiga, 123.***.***-01. Para esses, a página passa a mostrar só o nome de quem assinou, sem CPF: o padrão novo ao lado do papel antigo revelaria o número inteiro.
• Antes, o campo "Assinado por" repetia o CPF na forma antiga, e em alguns casos o nome trazia o mesmo CPF no padrão novo; as duas formas juntas revelavam o número.

Observações

• O documento assinado não muda: o PDF e o carimbo impresso ficam como foram emitidos. O que muda é só a página de conferência.
• A página de validação da certidão CERM já mostrava o CPF do detentor no padrão único e não foi alterada.

Página pública do QR Code com nome e CPF no padrão de máscara da LGPD

Implementado

1. Conferência de documento assinado (QR do carimbo gov.br)

• A página que abre ao ler o QR Code de um documento assinado na plataforma (Termo de Responsabilidade do Minerador, Termo de Responsabilidade do Responsável Técnico, Declaração de Plano de Pesquisa Mineral e Declaração Mensal de Exploração Mineral) passa a mostrar o nome do titular no mesmo padrão de máscara usado no portal público: quando a razão social de empresário individual ou MEI traz o CPF do dono, ele aparece como ***.456.789-**.
• Antes, só a Declaração Mensal recebia essa máscara; nos outros três tipos o nome saía como está no cadastro, com o CPF inteiro quando ele faz parte da razão social.
• A máscara agora é aplicada num ponto único da página, para que qualquer tipo de documento que venha a ser assinado no futuro já nasça com ela.
• O nome de quem assinou segue a mesma regra. O CPF de quem assinou sai no mesmo padrão ***.456.789-**, uma vez só, nos documentos assinados a partir de 04/10/2026; nos anteriores, cujo carimbo traz a forma antiga, a página mostra só o nome.

2. Validação de certidão (QR da certidão CERM)

• A página que abre ao ler o QR Code da certidão já mostrava o CPF do detentor mascarado. Agora o nome do detentor também recebe a máscara quando a razão social traz o CPF embutido.

Observações

• O nome do titular continua público, como já era: a máscara cobre só o CPF que aparece dentro dele. CNPJ continua inteiro, por ser registro público.
• Documento assinado antes da mudança não é alterado: o PDF e o carimbo ficam como foram emitidos. O que muda é só a página de conferência.

Recuperação de senha e cadastro com o serviço de e-mail fora do ar

Implementado

1. "Esqueci minha senha" não revela mais quem tem conta quando o e-mail está fora

• Com o serviço de e-mail desligado ou fora do ar, a tela avisa que o envio de e-mail está indisponível e pede para tentar mais tarde. O aviso é o mesmo para qualquer CPF, tenha ele conta ou não.
• Antes, nesse cenário, quem digitava um CPF sem conta via "pedido aceito" e quem digitava um CPF com conta via um erro genérico do servidor. A diferença permitia descobrir quais CPFs têm cadastro.
• A conferência do e-mail acontece antes de qualquer consulta ao cadastro, então a resposta não depende do CPF informado.

2. Falha no meio do envio não trava nem denuncia

• Se o servidor de e-mail cair no exato momento do envio, a tela recebe o mesmo "pedido aceito" de sempre, a senha antiga continua valendo e o serviço de e-mail passa a ser tratado como indisponível por um minuto. Nesse minuto, todo pedido recebe o aviso de indisponibilidade, também sem distinguir CPF.
• Passado o minuto, o sistema volta a tentar sozinho. Não é preciso reiniciar nada.

3. Cadastro com e-mail fora responde com aviso claro

• O autocadastro, quando o e-mail de confirmação não pode sair, mostra o aviso de serviço indisponível em vez de um erro genérico. Nenhuma conta fica criada pela metade, e a consulta à Receita Federal não é gasta à toa.

Observações

• O envio de e-mail e o restante do fluxo não mudaram quando o serviço está de pé.
• Uma recusa pontual de um endereço de destino não coloca o serviço em indisponibilidade; só a queda do servidor de e-mail faz isso.

“Representante legal” passa a se chamar “representante do titular” também por dentro do sistema

Implementado

1. Os nomes internos acompanham o nome das telas

• A primeira parte da troca mudou o que aparece na tela. Esta segunda parte troca os nomes que o sistema usa por dentro, na comunicação entre a tela e o servidor, para que o nome novo valha em todo lugar.
• Nada muda na tela: as páginas são as mesmas da primeira parte, com os mesmos textos.

Observações

• Quem pode assinar, corrigir ou gerenciar o cadastro continua igual.
• Uma aba que já estava aberta no momento da atualização pode não carregar a lista de representantes na ficha do minerador, e o cartão do vínculo no Cadastro do Minerador pode mostrar um código em letras maiúsculas no lugar de “Representante do titular”. Basta recarregar a página.
• O nome antigo continua guardado onde é registro: a qualidade de quem assinou documentos no passado, o perfil de acesso cadastrado no banco e o que a Receita Federal devolve na consulta da empresa.

“Representante legal” passa a se chamar “representante do titular”

Implementado

1. O nome novo nas telas

• A ficha do minerador mostra a seção “Representantes do Titular” e, quando não há ninguém vinculado, a frase “Nenhum representante do titular vinculado.”
• O Cadastro do Minerador, a gestão dos responsáveis técnicos, a correção de documento, as declarações, a escolha de perfil e o histórico do minerador passam a usar o nome novo nos rótulos, nos avisos e nas explicações.

2. O nome novo nas mensagens do sistema

• As recusas que citavam o nome antigo passam a dizer, por exemplo, “Somente o titular, o representante do titular ou o próprio responsável técnico assina este documento.” e “Só o representante do titular ou um servidor da SEDEC podem corrigir este documento.”

3. O nome novo na Wiki pública

• Os fluxos “Minerador pessoa jurídica depois de entrar” e “Sócio que assina pela empresa”, em Primeiros passos, usam o nome novo.

Observações

• Só o nome muda. Quem pode assinar, corrigir ou gerenciar o cadastro continua igual, e a pessoa que apenas opera a conta do CNPJ continua sendo outra figura, sem o título de representante.
• Onde o nome vem de fora do sistema, ele fica como a fonte publica: o bloco “Representantes legais na Receita” no cadastro da empresa, que mostra o que a Receita Federal devolve, e o tipo de relação “Representante Legal” das pessoas vinculadas a um processo, que é dado da ANM.
• As notas das versões já publicadas ficam como foram comunicadas.

Indicador de carregamento nas telas

Implementado

1. Telas que mostravam resultado antes de o dado chegar

• Os cartões de contagem do topo (Mineradores, Responsáveis técnicos, Processos, Gestão de usuários, Importações e Pendências de responsável técnico) mostram uma barra de carregamento no lugar do número, em vez do traço que também aparece quando há erro.
• O sino de notificações não diz mais "Nenhuma notificação" enquanto a lista ainda está sendo consultada.
• Nas tabelas administrativas, o título e o total de registros esperam a resposta, em vez de mostrar "Tabela" e "0 registros" por um instante.
• A grade "Usuários por tipo", a avaliação do processo, os quadros do painel inicial e a faixa de contagem do mapa de processos mostram o formato do conteúdo enquanto carregam.

2. Listas de seleção

• Os campos de escolha que dependem de uma consulta (município, processo, sub-receita, filtros de declarações, UF do responsável técnico, processos do vínculo de RT) mostram um indicador girando enquanto as opções chegam, em vez de abrir vazios.

3. Portal público

• Legislação, Notícias e a Visão do Território Nacional mostram o indicador de carregamento junto do texto que já existia.
• O mapa mineral e a consulta de polígonos mostram o indicador enquanto preparam o mapa e consultam a área.
• Os filtros do Mapa mineral e das Informações Financeiras mostram o indicador enquanto as opções chegam.
• Na Wiki, a página de fluxo mostra um indicador enquanto o diagrama carrega.

Observações

• Nas telas em que a lista de dados já tinha indicador de carregamento, nada mudou.
• Algumas telas ainda mostram por um instante o recorte de todas as empresas antes de aplicar a empresa escolhida, quando a página é aberta direto pelo endereço. A causa é outra e vai ser tratada à parte.

Travas automáticas no fluxo de publicação do código

Implementado

1. Mudança só entra no sistema depois de revisada

• O repositório do MINA MT passa a recusar sozinho alteração gravada direto na linha que vai para os ambientes, sem passar pela etapa de integração e revisão. As únicas exceções são os dois registros que a própria rotina de gerar versão faz.

2. Publicação feita por assistente de programação exige autorização

• Quando um assistente de programação tenta publicar o código no servidor da equipe, a publicação só segue se o responsável tiver autorizado aquela publicação. A publicação feita pela própria equipe continua como antes.

3. Histórico de alterações padronizado

• Toda alteração passa a ter descrição no padrão da equipe e sem assinatura de ferramenta automática, o que mantém legível o histórico usado para montar as notas de cada versão.

Observações

• Não há mudança em nenhuma tela do MINA MT. O ganho é de processo: menos risco de uma alteração não revisada chegar à produção.