🆕Versão v1.4.1

PLANO DE PESQUISA - RT cadastrado no plano e assinatura gov.br do RT por versão (MON-03)

Implementado

1. O RT deixa de ser texto livre

• No formulário do plano (novo plano ou nova versão), "Responsável técnico" passou a ser uma lista. Aparecem só os responsáveis técnicos ativos, vinculados ao titular do processo e com aquele processo atribuído. A lista mostra o nome e o registro profissional.
• O sistema recusa gravar um responsável que não esteja nessa lista, mesmo que alguém tente por fora da tela.
• A nova versão já nasce com o RT da versão anterior. Planos antigos, que só têm o nome digitado, continuam mostrando esse nome; ao abrir a próxima versão, o RT precisa ser escolhido na lista.

2. Só o RT atribuído assina

• O botão "Assinar com gov.br" só aparece para o RT ativo com o processo atribuído ao seu vínculo, qualquer que seja o perfil escolhido ao entrar.
• O titular, o representante do titular, o RT sem o processo atribuído e os servidores da SEDEC não assinam: o sistema responde "plano de pesquisa não encontrado", como para quem não alcança o plano.
• O titular continua vendo o plano, baixando o documento e finalizando a versão, como antes. Só a assinatura ficou restrita ao RT.

3. A assinatura fica registrada na versão

• Cada versão guarda o seu PDF assinado, o código de conferência (hash), a data e quem assinou (nome, documento e qualidade "Responsável técnico"). Isso aparece na ficha do plano, em cada versão, com o botão "Baixar PDF assinado", e também no histórico ("Assinatura da versão 2").
• Se a versão que gerou o PDF for substituída antes de a assinatura voltar do gov.br, a assinatura é recusada com o motivo "versão substituída", e nada é gravado.
• Duas assinaturas simultâneas da mesma versão não se atropelam: só uma é aplicada.
• O PDF assinado deixou de ser copiado também para o registro antigo do plano: fica uma só cópia, na versão.

4. O PDF da declaração

• Traz o número da versão, o responsável técnico cadastrado, as metas físicas de cada atividade, os métodos previstos e a lista de anexos com tipo, nome, tamanho e hash (SHA-256).

5. Assinar a versão nova a torna vigente

• Ao assinar a versão 2, ela vira a vigente e a versão 1 passa a "substituída". O PDF assinado da versão 1 continua baixável.

Observações

• A regra da A.R.T. continua valendo: com o parâmetro ligado, a versão só finaliza com a A.R.T. anexada. Isso apareceu na validação, e o aviso orienta anexar.
• O nome de quem assinou vem do certificado usado na assinatura. Na bancada de teste esse nome carrega o número do documento junto; em produção o gov.br define o formato, e vale conferir na primeira assinatura real.
• Plano antigo sem RT cadastrado continua sendo exibido e baixado normalmente; só a próxima versão pede a escolha.

EXECUÇÃO DE PESQUISA - Declaração de execução por período sobre a versão vigente do plano (MON-04)

Implementado

Esta etapa entrega a base da declaração de execução: as regras e o registro por trás. Ainda não há tela nem PDF nem assinatura (vêm na tarefa da tela, #200), e o confronto com as metas e o limite de desvio vêm nas tarefas seguintes (#198 e #199).

1. Declaração de execução por período

• O responsável técnico (RT) registra, por período, quanto foi executado de cada meta do plano de pesquisa, com uma justificativa opcional por meta e uma observação geral.
• A declaração nasce em elaboração, pode ser alterada enquanto está assim, e depois é enviada.

2. Marcos da pesquisa (art. 21, XII)

• Cada declaração pode registrar a data de início, suspensão, retomada e encerramento da pesquisa, e a data do relatório parcial ou final protocolado na ANM (com o número do protocolo, se houver). Cada tipo de marco aparece uma vez por declaração, dentro do período.
• A declaração com o marco "encerramento" é identificada pelo sistema, e a lista dos planos encerrados fica disponível para o servidor da SEDEC. É o que a FIS-06 (#185) vai usar.

3. Regras do período

• O período precisa ficar dentro da vigência do plano, e a data final não pode ser futura: declara-se o que já aconteceu.
• Um período que cruza outro do mesmo plano é recusado, e a mensagem diz com qual período e em que situação ele conflita. O período recusado fora da vigência também recebe mensagem clara.
• A periodicidade esperada é um parâmetro do sistema (padrão: 6 meses), que o administrador vê na tela de parâmetros. Com base nele, o sistema sugere o próximo período a declarar.

4. A versão do plano fica gravada

• A declaração usa a versão do plano que estava vigente na data final do período e guarda qual foi. Se depois a versão 2 for assinada, a declaração do período antigo continua mostrando a versão 1.
• Para planos antigos, vindos do sistema anterior, pode não haver data de assinatura da versão. Nesse caso o sistema usa a versão vigente hoje e marca a declaração como "versão presumida".

5. Retificação

• Corrigir uma declaração já enviada é uma retificação, com justificativa obrigatória. Ela abre uma nova declaração, copiada da anterior, e só pode corrigir quantidades e marcos: o período é o mesmo da declaração retificada. Para outro período, cria-se outra declaração.
• Ao enviar a retificação, a anterior passa a "substituída" no mesmo momento. As duas continuam consultáveis, com a trilha de quem fez o quê e quando.

6. Quem pode

• Só o RT ativo com o processo atribuído cria, altera, envia e retifica. O titular e o representante do titular consultam, e o servidor da SEDEC consulta tudo. Quem tenta escrever sem ser o RT recebe a recusa com a explicação.
• Nada disso aparece no portal público.

Observações

• "Enviar" ainda não é assinar: a assinatura gov.br do RT entra na #200, sobre a declaração enviada. Por ora a declaração enviada já conta como entregue.
• A execução não depende de o alvará estar vigente: quem já pesquisa com o alvará vencido ainda precisa declarar.
• Duas escolhas minhas, que a SEDEC pode corrigir: a data final do período não pode ser futura, e a retificação não muda o período.
• Aguardam resposta da SEDEC, sem bloquear: periodicidade e prazo de entrega, e quem avisa na FIS-06.

EXECUÇÃO DE PESQUISA - Confronto plano versus execução por meta e por título (MON-04)

Implementado

Esta etapa entrega o cálculo do confronto e o seu registro, por trás do sistema. Ainda não há tela nem PDF para mostrá-lo: isso vem na tarefa da tela (#200), e o limite de desvio com a justificativa obrigatória vem na #199.

1. Previsto até o fim do período, por meta

• Para cada meta do plano, o sistema calcula quanto já deveria ter sido feito até o fim do período: a quantidade da meta vezes a parte já decorrida da atividade no cronograma, contada em dias corridos entre o início da atividade e o fim do período, e limitada a 100%.
• Atividade que ainda não começou tem previsto zero, e a meta não entra no confronto daquele período.

2. Executado acumulado

• É a soma do que foi declarado na meta nas declarações enviadas do plano até o fim do período, mais a da própria declaração. Declarações substituídas por uma retificação não entram, e a retificadora conta no lugar da retificada.
• A meta é acompanhada entre versões do plano pelo código da atividade e pela unidade. Se uma versão nova do plano tirou uma meta, o executado dela não entra na versão nova, e a conta avisa isso.

3. Percentual e desvio

• O percentual é o executado acumulado dividido pelo previsto. O desvio é o percentual menos 100, em pontos. Uma meta que executou 6 de 2,2286 previstos tem 269,23% e desvio de +169,23.
• Os números mostram duas casas, e o previsto usa quatro, sem arredondar a fração antes da multiplicação, para a conta bater com a feita à mão.

4. Consolidado do título

• É a média simples dos percentuais das metas que entraram, cada uma limitada a 100%, para uma meta adiantada não esconder o atraso de outra. Uma meta com 120% e outra com 50% dão consolidado de 75%, e não 85%.
• Sem nenhuma meta que entrou (por exemplo, plano sem metas), não há consolidado.

5. Memória de cálculo

• Cada meta traz a conta explicada: dias decorridos e dias totais da atividade, fração, quantidade, previsto, quais declarações compõem o executado e o percentual. Há avisos quando algo ficou de fora.

6. O resultado fica registrado no envio

• Ao enviar a declaração, o confronto é gravado. Se o plano ganhar uma versão nova depois, o confronto já entregue não muda.
• Declaração em elaboração mostra uma prévia, calculada na hora. Declaração enviada antes desta etapa, que ainda não tem confronto gravado, é calculada na consulta e marcada assim.
• Se um período anterior for retificado depois, os períodos seguintes não são recalculados: cada um mostra o que valia quando foi entregue. A retificação gera um confronto novo na retificadora, e o da substituída fica como estava.

7. Consulta

• O detalhe da declaração passa a trazer o confronto, e há uma consulta do histórico dos períodos do plano, com o consolidado de cada um. Quem pode ler a execução (RT, titular, representante do titular e servidor da SEDEC) lê o confronto. Nada aparece no portal público.

Observações

• A tela, o PDF e a assinatura chegam na #200, e o limite de desvio na #199. Até lá o confronto só pode ser conferido pelo serviço, com apoio do time técnico.
• Escolhas que a SEDEC pode corrigir: o confronto fica congelado no envio, e o percentual de cada meta mostra o valor real (por exemplo, 269,23%), com o limite de 100% valendo só na média do título.
• Aguardam resposta da SEDEC, sem bloquear: periodicidade, prazo de entrega e a fórmula do desvio e do consolidado.

EXECUÇÃO DE PESQUISA - Limite de desvio parametrizado e justificativa obrigatória (MON-04)

Implementado

1. Limite de desvio parametrizado

• O limite é o parâmetro PESQUISA_LIMITE_DESVIO_PERCENTUAL, com padrão de 20 pontos, e aparece na tela de parâmetros do sistema, com a descrição. Aceita número decimal de 0 a 1000; se estiver ausente ou inválido, vale 20.
• O administrador muda o valor sem precisar de ninguém do time técnico: na tela Parâmetros do sistema, a linha do parâmetro ganhou o botão Editar. Mudar o limite vale para as próximas declarações.

2. Justificativa obrigatória no envio

• Ao enviar a declaração de execução, toda meta cujo desvio, em valor absoluto, passa do limite precisa de justificativa preenchida (espaços em branco não valem). Isso vale também para a retificação.
• Com o limite em 20: uma meta com 44,87% de execução (desvio de −55,13) exige justificativa, e uma com 84,81% (desvio de −15,19) não exige. Desvio exatamente igual ao limite não exige. Meta que não entra no confronto (a atividade ainda não começou) nunca exige.
• Sem a justificativa, o envio é recusado pelo sistema, e não só pela tela. A mensagem diz quais metas faltam e o desvio de cada uma, por exemplo: "O desvio passa do limite de 20 pontos e a justificativa está em branco nas metas: W0007 (AEROFOTOGRAFIA, Amostras coletadas, desvio de −55,13 pontos)."

3. A declaração guarda o limite do envio

• No envio, o limite que valia fica gravado na declaração. Se o administrador mudar o limite depois, a declaração já enviada continua mostrando o limite do envio (por exemplo, 20), e a seguinte passa a usar o novo.
• O confronto de cada declaração mostra o limite e, por meta, se ela exige justificativa. Para a declaração em elaboração, a prévia usa o limite de hoje. Declaração enviada antes desta etapa não tem limite gravado, e a regra não vale para ela.

4. Edição pelo administrador, só de três parâmetros

• O administrador pode editar na tela os parâmetros: o limite de desvio, a periodicidade da execução (inteiro de 1 a 36) e a exigência da A.R.T. no plano (SIM ou NAO). O botão Editar abre uma janela com a descrição, a regra e o valor atual, e recusa valor fora da faixa com mensagem clara (por exemplo, 2000 no limite: "Informe um número decimal de 0 a 1000"). O limite aceita vírgula ou ponto.
• Os demais parâmetros do sistema continuam somente consulta e com os valores ocultos, porque guardam chaves de integração. Quem não é administrador não consegue editar, nem por fora da tela. Cada alteração fica registrada no log, com quem mudou e de qual valor para qual.

Observações

• Mostrar as metas acima do limite e abrir o campo de justificativa na própria declaração são da tela da execução (#200). Até lá, a regra vale e a recusa aparece pelo serviço.
• A mudança do limite não recalcula nada: vale só para os próximos envios.
• Escolhas que a SEDEC pode corrigir: a regra é estrita (só exige quando o desvio passa do limite) e o padrão de 20 pontos segue o proposto na demanda.

EXECUÇÃO DE PESQUISA - Tela, PDF e assinatura gov.br do RT (MON-04)

Implementado

1. Telas da execução da pesquisa

• Execuções do plano: a partir de cada plano de pesquisa (botão "Execuções do plano"), uma tela lista as declarações de execução do plano, com período, versão do plano usada, situação, assinatura, consolidado e se a declaração encerra a pesquisa. Abaixo fica o histórico dos períodos, com o consolidado de cada um e se foi gravado no envio. O RT vê "Nova declaração", já com o período sugerido pela periodicidade.
• Declaração de execução: o RT preenche o período, as observações, os marcos (início, suspensão, retomada, encerramento, relatório parcial e final, com o protocolo da ANM nos relatórios) e o executado por meta, com justificativa. A tela mostra, por meta, previsto, executado acumulado, percentual e desvio, o consolidado do título, a versão do plano usada, o limite de desvio e a memória de cálculo. A meta acima do limite ganha o selo "Justificativa obrigatória" e o campo de justificativa aberto.
• Execuções da pesquisa (lista geral): acessível pelo botão "Execuções da pesquisa" no topo da tela de planos. Mostra as declarações do alcance de quem entra, com filtros por busca, processo, município, substância, situação e assinatura.

2. Enviar, retificar e assinar

• O RT salva, envia e assina com gov.br na própria tela, no mesmo fluxo do plano. O envio sem a justificativa exigida é recusado e a tela mostra quais metas faltam e o desvio de cada uma.
• Retificar exige a justificativa da retificação, abre uma nova declaração do mesmo período com o conteúdo da anterior, e a nova precisa ser assinada de novo. A anterior fica "substituída", com o PDF assinado guardado e a trilha de quem fez o quê.
• A declaração enviada e ainda não assinada aparece como "enviada, aguardando assinatura". Assinar não muda nenhum número do confronto.
• Só o RT com o processo atribuído envia, retifica e assina. O titular, o representante do titular e o servidor da SEDEC consultam e baixam o PDF, e não veem os botões de enviar, retificar nem assinar.

3. PDF da declaração

• O PDF traz o plano e a versão usada, o período, os marcos com o protocolo da ANM, a tabela por meta (previsto, executado, percentual e desvio), as justificativas, o consolidado, o limite vigente no envio, a memória de cálculo e o signatário. O carimbo da assinatura traz o código de validação, que a conferência pública de documentos reconhece.
• O titular e o servidor baixam o arquivo assinado. O RT baixa a cópia de leitura, no mesmo padrão do plano. Declaração ainda não assinada tem prévia, sem assinatura.

4. O servidor acompanha tudo

• O servidor da SEDEC vê as declarações de todos os processos e filtra por município, substância e situação, e vê também quais aguardam assinatura. O RT e o titular veem só o que alcançam.

Observações

• O confronto fica gravado no envio. Por isso o PDF e a tela mostram o que valia quando a declaração foi entregue, mesmo que o plano ganhe uma versão nova ou um período anterior seja retificado depois.
• A assinatura real pelo gov.br só pode ser conferida em produção; no ambiente de desenvolvimento ela é simulada pela bancada de assinatura.
• Os PDFs assinados antes de uma mudança de formato não são regerados: um documento assinado não muda.
• Escolhas que a SEDEC pode corrigir: a declaração enviada e ainda não assinada conta para o confronto, e o RT recebe a cópia de leitura, e não o arquivo assinado, como no plano.

Avisos parametrizáveis, fase 2: o administrador configura cada aviso e o texto fica gravado no aviso

Implementado

1. Tela "Avisos e notificações" para o administrador

• No menu Sistema, o perfil ADMINISTRADOR ganha a tela Avisos e notificações, com a lista dos eventos que geram aviso no sino: processo novo em nome do minerador, processo atribuído ao responsável técnico e convite para responsável técnico. Para cada um, a tela mostra se está ligado, quem recebe, a versão da regra e quando foi alterada.
• Clicar em Editar abre o painel da regra: ligar ou desligar o evento, escolher quem recebe, e editar o título e o texto do cartão. O texto pode usar os marcadores {{processo}} e {{minerador}}, que viram o número do processo e o nome do minerador em cada aviso; clicar no marcador o insere no texto.
• A prévia mostra o cartão como ele vai aparecer, com valores de exemplo, e quantas contas ativas o aviso alcançaria hoje. No convite a contagem não se aplica, porque o convidado só existe quando o convite é feito.
• Marcador que o evento não tem (por exemplo {{cpf}}), chave sem par, destino fora dos possíveis e texto vazio são recusados no próprio campo, com a mensagem do que corrigir. Se outra pessoa salvar a mesma regra enquanto a tela está aberta, a gravação é recusada e a tela recarrega a versão atual para o administrador decidir de novo.
• O convite para responsável técnico não pode ser desligado: o interruptor fica travado, com a explicação de que o aviso é o único caminho de aceite para quem perdeu o e-mail.

2. O texto de cada aviso fica gravado no momento em que ele nasce

• O título e o texto do cartão passam a ser gravados no aviso no instante do fato (a atribuição, o convite, a carga da ANM), com o nome do minerador e o número do processo daquele momento. Editar a regra depois muda só os avisos seguintes; os cartões já existentes não mudam.
• Os avisos que já estavam no sino receberam o texto de hoje, letra por letra, e continuam aparecendo iguais.
• Evento desligado não gera cartão novo nem e-mail: vale para o e-mail de processo novo da carga da ANM e para o de processo atribuído. O registro interno do que a carga da ANM já avisou continua sendo feito, então religar o evento não despeja avisos antigos de uma vez nem reenvia os e-mails do período em que esteve desligado.

Observações

• A linha "Processo X" do aviso da ANM e a frase de convite indisponível ("Este convite não está mais disponível") continuam vindo do sistema e não são editáveis nesta fase: elas dependem de algo que só se sabe na hora de mostrar o cartão.
• Esta fase não cria evento novo, não muda quem recebe cada aviso, não muda o texto do e-mail (segue fixo) e não altera o comportamento do sino para quem usa. A única mudança no e-mail é a do item anterior: evento desligado também para o e-mail dele.
• Só o perfil ADMINISTRADOR vê e usa a tela; os demais recebem acesso negado.

Avisos parametrizáveis, fase 3: o aviso aparece no sino na hora, sem recarregar a página

Implementado

1. O sino recebe o aviso em tempo real

• Com o sistema aberto e a ligação em tempo real de pé, um aviso novo aparece no sino em até um segundo depois do fato que o gerou: um processo atribuído ao responsável técnico ou a carga de processos novos da ANM. O convite para responsável técnico chega assim que o e-mail do convite é enviado. Antes, o sino só conferia a caixa a cada minuto.
• Não é preciso recarregar a página nem abrir o sino. O número de não lidas e a lista mudam sozinhos.
• Cada pessoa continua vendo só os avisos que já via antes. O sistema só avisa a tela de que há novidade, e ela busca a caixa como sempre.
• Quando outra pessoa fecha um aviso seu (o minerador desfaz a atribuição do processo, encerra o vínculo ou reenvia o convite; o titular valida um processo que o representante também via), o cartão deixa de contar como não lido na mesma hora: o número do sino cai, e o cartão fica na lista, já como lido. Marcar um aviso como lido numa aba continua valendo nas outras abas da mesma pessoa em até 5 minutos.

2. O sino continua funcionando quando a ligação cai

• Se a ligação em tempo real cair (rede instável, reinício do servidor), a tela volta a conferir a caixa a cada minuto e tenta religar sozinha, com intervalos crescentes. Ao religar, ela busca a caixa na hora, para não perder o que chegou enquanto estava desligada.
• Com a ligação de pé, a tela ainda confere a caixa a cada 5 minutos, como garantia.

Observações

• Uma carga da ANM que gera muitos avisos de uma vez faz o sino buscar a caixa uma vez só, e não uma vez por aviso.
• O aviso de convite para responsável técnico só aparece depois que o e-mail do convite é enviado, então pode levar alguns segundos a mais que os outros.
• Quando a sessão vence, a ligação em tempo real fecha junto e a pessoa é levada a entrar de novo, como já acontecia.
• Até cinco abas abertas da mesma pessoa recebem o aviso ao mesmo tempo, e nenhuma delas perde o tempo real por causa de outra. A sexta aba confere a caixa a cada minuto até conseguir entrar no tempo real. Ao recarregar uma das cinco, ela voltou ao tempo real em até 4 segundos nas medições; quando a vaga demora a ser liberada, a aba continua conferindo a cada minuto e tenta de novo, até cerca de um minuto depois.
• Os perfis do órgão (servidor e administrador) não têm avisos no sino, e por isso não abrem a ligação em tempo real.