v0.5.13 - Graficos sem sobreposicao

v0.5.13 — Eixos dos gráficos sem sobreposição

Os horários no rodapé dos gráficos eram criados a cada redesenho sem remover os anteriores. Durante uso prolongado, os textos se sobrepunham e a quantidade de objetos no canvas crescia continuamente.

A interface agora substitui os dois rótulos do eixo temporal em cada atualização, junto com a série e os demais elementos dinâmicos. O histórico armazenado, as medições e as configurações permanecem preservados.

Uma regressão usa um canvas Tcl/Tk real, sem exibir janela, para verificar que 100 redesenhos mantêm a quantidade de objetos constante e que os rótulos desaparecem quando não há amostras. A troca de interface não reinicia a mineração nem o serviço do rig.

O SRBMiner permanece na versão 3.8.4. Esta correção não introduz mineração dual nem altera clocks ou limites térmicos.

HashPilot v0.5.12 — Exploração térmica baseada em medições

v0.5.12 — Margem de exploração baseada na estabilidade térmica

O perfil de desempenho podia manter um clock aprovado em 74 °C mesmo com alvo suave de 76 °C: exigia sempre 3 °C de folga para tentar o próximo degrau. A margem passa a depender de observações reais, sem aumentar os limites térmicos.

Comportamento

• No perfil de desempenho, uma referência validada e uma janela recente estável permitem tentar um degrau de até 15 MHz com 1 °C de folga. O clock só sobe se a temperatura atual e o pico da janela estiverem abaixo desse limite.
• A janela usa até 60 segundos de sensores válidos, ao menos 15 observações, cobertura mínima de 45 segundos, nenhum intervalo acima de 10 segundos, amplitude máxima de 1 °C e diferença entre os cinco sensores finais e iniciais de no máximo 0,2 °C.
• Dados insuficientes, aquecimento, lacunas ou referência não validada mantêm os 3 °C anteriores. Os perfis equilibrado e frio também preservam essa margem.
• Os alvos suaves e duros continuam derivados do driver e limitados pelo produto a 76/83 °C. Não há aumento automático de teto térmico, potência de fábrica ou tamanho do degrau. A validação posterior do ajuste e sua reversão permanecem.
• O status publica a janela e a decisão em probe_gate; assim uma pausa de exploração tem motivo explícito.
• A placa de referência do autor pode reiniciar no preset explicitamente aprovado de 1725 MHz, além dos anteriores. Exige suporte atual do driver e continua restrito à unidade autorizada; o padrão sem opt-in segue em 1560 MHz. Não aceita um clock arbitrário de reinício.

Evidência e limites

O controle anterior foi observado aprovando 1710 → 1725 MHz com 74,86 → 75,53 TH/s, e depois retendo a subida para 1740 MHz em 74 °C. Essa observação motivou a regra de margem medida. O resultado físico da nova regra deve ser consultado no asset de validação; não é presumido a partir da alteração do código.

Novas regressões cobrem estabilidade, aquecimento, sensores esparsos, lacunas, referência não validada, perfis conservadores e temperaturas no limite. Os testes não alteram hardware. Somente uma RTX 3070 está disponível para validação física; não há prova de desempenho máximo absoluto nem certificação para todos os modelos.

O SRBMiner permanece na 3.8.4. O teste local de memória a 405 MHz falhou e foi revertido para 5001 MHz; o afinador nativo experimental permanece desligado. Análise e medições.

HashPilot v0.5.11 — SRBMiner 3.8.4 e eficiência Pearl

v0.5.11 — SRBMiner 3.8.4 e experimento de memória na RTX 3070

O pacote Windows oficial da versão 3.8.4 mudou o local interno do executável. O atualizador agora aceita esse caminho exato, verifica o SHA-256 do ZIP e do executável e continua extraindo somente o binário revisado. A instalação é paralela e mantém a versão anterior para rollback.

Mudanças

• SRBMiner 3.8.4 entrou no catálogo verificado. O binário Windows fica em SRBMiner-Multi-3-8-4/Win/SRBMiner-Multi-3-8-4/SRBMiner-MULTI.exe dentro do ZIP; o caminho instalado permanece simples e compatível com o gerenciador.
• A unidade de referência autorizada do autor pode testar memória em 405 MHz com reference_memory_mhz: 405 nas configurações locais. O ajuste só é aplicado a essa unidade e ao minerador 3.8.4 ou posterior. O padrão continua 5001 MHz; versões anteriores mantêm esse valor mesmo com o opt-in salvo.
• Para uma comparação com o mesmo núcleo, a unidade pode usar o preset explícito reference_start_core_mhz: 1710, condicionado ao suporte atual do driver. Sem esse opt-in, mantém o início em 1560 MHz. Não aceita clocks arbitrários como preset de reinício.
• Alterar esses dois opt-ins reconcilia apenas a GPU de referência. Reverter a memória para 5001 ou remover o preset de núcleo volta ao comportamento anterior; parar mineração continua restaurando os padrões do driver.

Isso não é um perfil validado para todas as RTX 3070, outras placas ou rigs. Somente uma RTX 3070 está disponível para teste físico; os casos multiGPU são simulados.

Revisão do changelog

Foi consultada a release 3.8.4 integralmente, a documentação atual de parâmetros, a ajuda do executável oficial verificado e o histórico de releases disponível na API. A análise prática está em SRBMiner 3.8.4 e RTX 3070.

O afinador nativo de potência permanece desativado: exige um desenho separado de controle exclusivo e recuperação. O HashPilot mantém seu supervisor como único responsável pelos ajustes dinâmicos de núcleo.

Verificação

Regressões adicionais exercitam o novo caminho interno do ZIP, recusa de caminhos não revisados, extração exclusiva do binário, opt-in por versão, reversão sem afetar outra GPU e limites do preset de núcleo. As evidências de pacote e teste físico ficam nos assets de validação da release, sem tratar uma observação curta como estabilidade de 12 horas.

Validacao fisica nesta maquina

O teste de memoria a 405 MHz foi interrompido: o hashrate ficou em 33-34 TH/s. A memoria foi restaurada para 5001 MHz, mantendo o SRBMiner 3.8.4. Em tres amostras com nucleo a 1710 MHz, a media foi 74,93 TH/s e 151,8 W. Esses testes curtos nao comprovam estabilidade prolongada nem resultado em outras placas.

O primeiro ajuste automatico de 1710 para 1725 MHz foi aprovado com duas amostras independentes: 74,86 para 75,53 TH/s, sem rejeicoes ou erros de hardware nessa validacao. O acompanhamento do limite sustentavel continua. O afinador nativo experimental permanece desativado. Foram aprovados 462 testes automatizados.

HashPilot v0.5.10 — Tuning gradual e interface mais leve

v0.5.10 — Exploração de desempenho e menos trabalho de layout

O controle automático podia encerrar um benchmark válido e permanecer indefinidamente no mesmo perfil: uma orientação de IA para manter/restaurar o clock já ativo substituía a tentativa de desempenho. Agora, no objetivo de desempenho, uma orientação sem alteração efetiva mantém a exploração limitada ao próximo degrau suportado de até 15 MHz. Orientações de redução continuam possíveis, e os limites térmicos e a validação posterior permanecem obrigatórios.

• Restaurar um perfil com o mesmo clock retorna uma operação sem alteração e sem clock de destino fictício. Antes, o plano podia indicar hold junto com um clock inferior.
• O objetivo de eficiência continua aceitando a orientação de manter o perfil atual. Perfis conservadores não aceitam aumento de clock sugerido pela IA.
• Eventos repetidos de configuração da janela, sem mudança de tamanho, deixam de reconfigurar todas as fontes e estilos globais. A interface continua adaptando o layout quando suas dimensões mudam.

Validação

Sete regressões adicionais cobrem restauração sem alteração, exploração com orientação sem efeito, prioridade térmica, objetivo de eficiência, perfis conservadores, teto do driver e restauração gradual de um perfil inferior. Os testes não alteram hardware.

A QA nativa de responsividade e maximização verifica a interface em janelas reais. A causa do consumo excessivo observado numa sessão antiga de Tk ainda não foi comprovada: reabrir o painel normalizou o consumo; a proteção de layout reduz trabalho redundante, mas não comprova eliminar todas as causas de CPU elevada.

O pacote mantém os dados em %LOCALAPPDATA%\PearlMonitor. Atualizar o painel e atualizar o serviço são ações separadas; o serviço exige UAC e uma breve interrupção da mineração. Somente uma RTX 3070 foi validada fisicamente. Ajustes não garantem ganho e devem ser acompanhados por hashrate, consumo, temperatura e respostas da pool.

HashPilot v0.5.9 — Continuidade da mineração

v0.5.9 — Continuidade da sessão e recuperação térmica

Um processo do SRBMiner continuava minerando depois que o gerenciador perdeu seu PID. O painel passou a registrar parada e tentativas de recuperação apontavam para logs novos, enquanto o processo anterior seguia ativo. A versão corrige a reconciliação e preserva as evidências da sessão.

• Reconhece um sucessor pelo executável verificado, criação do processo, GPU, carteira, pool, worker e caminho do log. Só recupera controle automaticamente quando o processo pai também corresponde à sessão anterior.
• Sem comprovação do pai, a sessão reencontrada permanece somente leitura. Processos ambíguos, com argumentos duplicados ou que disputam a mesma GPU bloqueiam a adoção.
• Preserva por 120 segundos a identidade da sessão encerrada durante uma recuperação, permitindo reconhecer um sucessor que aparece com atraso. Uma parada manual descarta essa autorização.
• Verifica conflitos antes de substituir o registro e antes de consumir o orçamento de reinícios. Uma tentativa bloqueada preserva o log e a identidade anteriores.
• Reiniciar um processo no mesmo arquivo de log zera os contadores da sessão, sem apagar o histórico persistido. Eventos térmicos atrasados não sobrescrevem eventos mais recentes.
• A RTX 3070 de referência autorizada inicia em 1560 MHz, em lugar de 1740 MHz. O supervisor continua responsável pelos ajustes dinâmicos. Esse perfil não é aplicado a outros modelos.

Evidência e limites

Na investigação local de 3 de novembro, houve 43 mensagens de pausa térmica no trecho de aproximadamente 20h25–22h55. Nesse período o histórico do painel indicava parada, mas o log ativo continha mineração e shares aceitas. O início de um novo processo é compatível com reinício interno do minerador; o vínculo com o pai precisa ser confirmado antes de atribuir a causa definitivamente.

A limitação temporária do núcleo a 1560 MHz reduziu a temperatura observada de 81–82°C para cerca de 65°C, com a ventoinha ainda em 100%. Isso é uma observação curta, não um teste de estabilidade de 12 horas nem uma garantia de hashrate.

Testes de regressão cobrem sucessor confirmado, observação sem controle, atraso e expiração da identidade, parada manual, conflito de GPU, metadados preservados, orçamento e troca de sessão no log. Apenas uma RTX 3070 está disponível para validação física; cenários com várias GPUs são simulados.

HashPilot v0.5.8 — Configurações numa janela única

v0.5.8 — Configurações numa janela única

O botão Configurar abria um assistente que levava a outras quatro janelas, e o cabeçalho tinha oito botões. Agora há uma janela Configurações, com navegação lateral, e um cabeçalho com quatro botões. Regras de carteira, contribuição, mineração, UAC e Defender não mudaram; as confirmações existentes continuam.

As 10 melhorias

1. Janela única com navegação lateral: Carteira e ajuda, GPUs, Minerador, Segurança, IA, Atualizações, Operação e Sobre. As telas que antes abriam janelas dentro de janelas viram seções; botões internos como "Revisar bloqueio no Defender" e "Atualizar painel" levam à seção correspondente.
2. Assistente inicial só no primeiro uso. "Configurações" abre direto as seções; o assistente continua disponível em Sobre → Refazer assistente inicial.
3. Instalar e iniciar o minerador é uma ação própria, na seção Minerador, com confirmação. Salvar uma configuração nunca inicia a mineração.
4. Salvar sem reiniciar o painel. Só a troca da carteira global ou da pasta dos logs pede para reiniciar o painel, com pergunta e sem interromper a mineração. GPUs, IA, contribuição e demais opções valem sem reinício.
5. Cabeçalho com quatro botões: Iniciar todas, Parar, Configurações e "⋯" (Benchmark / IA, Resumo compacto, Console, Recolher para a bandeja, Sair).
6. Responsiva: abaixo de 900 px a lateral vira uma lista de seções no topo; os textos acompanham a largura; cada seção tem rolagem própria quando falta altura.
7. Um só estilo visual: botões principal, secundário e de perigo com os tokens do painel, foco de teclado visível e ttk (abas, listas, botões da Operação) no tema escuro.
8. Carteira validada enquanto se digita, com aviso destacado quando ainda é a carteira do autor, botão Colar e a carteira que recebe a contribuição de 5% visível ao lado da opção.
9. Estado de cada área na navegação (carteira, GPUs detectadas, versão do minerador, IA, versões de painel e serviço, serviço ativo ou parado). Atualizar serviço (UAC) agora confirma a parada de cerca de 30 a 60 s, usa o python.exe de console e acompanha o resultado até o serviço novo responder, avisando se ele não voltar em 4 min.
10. Lembra a última seção e o tamanho da janela. Atalhos: Ctrl+, abre as Configurações, Esc fecha, Ctrl+S salva a seção atual.

Validação

• 436 testes, incluindo test_settings_ui.py (validação da carteira, quando reiniciar, papéis dos botões, acompanhamento da atualização do serviço, comportamento das seções embutidas).
• tools/qa_settings.py: as oito seções em 1280×760 e em 760×620 (modo estreito), sem erro de montagem nem de layout, com capturas de tela revisadas.
• QAs existentes: painel (test_responsive_ui.py --run --native-dpi, 0 overflow), Operação, minerador, Defender, IA e assistente inicial. A QA do Defender estava desatualizada desde a v0.5.3 (esperava a chamada sem a versão do minerador) e foi corrigida.

As telas continuam abrindo como janelas próprias quando chamadas diretamente, como nas QAs e em versões antigas dos scripts.

HashPilot v0.5.7 — atualização do serviço sem parar a mineração

v0.5.7 — atualização do serviço sem parar a mineração por engano

Correção de um defeito que já existia antes da v0.5.6 e foi encontrado ao atualizar o serviço na máquina de referência.

O problema. O botão Configurar → Central de operação → Atualizar serviço (UAC) passa aos scripts o Python do próprio painel. Aberto pelo atalho, o painel roda em pythonw.exe, que não tem saída de console. Atualizar-Rig.ps1 encerrava o serviço atual e chamava Iniciar-Rig.ps1, que lia o caminho do minerador pela saída de miner_update.py --path. Com pythonw.exe essa saída vinha vazia, o script abortava e a mineração ficava parada, sem serviço novo e sem log de erro do serviço.

A correção. Iniciar-Rig.ps1 e Atualizar-Rig.ps1 trocam pythonw.exe pelo python.exe da mesma pasta antes de qualquer outra ação. Como a correção está nos scripts, ela vale também quando o pedido vem de um painel de versão anterior.

• Na máquina de referência, a parada durou cerca de 7 minutos (23:33 a 23:40) até o serviço ser iniciado de novo com python.exe. Depois disso: serviço v0.5.6 ativo, SRBMiner conectado e hashrate de 75,9 TH/s.
• Teste de regressão: test_optimizations.ServiceScriptInterpreterTests executa no PowerShell a linha de cada script e confirma a troca.
• Os scripts de parada não leem a saída do Python e não foram alterados.

O código Python do serviço é o mesmo da v0.5.6. Quem já está com o serviço v0.5.6 ativo só precisa atualizar o painel; a Central de operação pode mostrar o serviço como versão anterior até a próxima atualização do serviço.

As otimizações de desempenho estão nas notas da v0.5.6.

HashPilot v0.5.6 — menos processos, menos disco e interface mais leve

Use a v0.5.7. Ela corrige um defeito anterior a esta versão: Atualizar serviço (UAC) com o painel aberto pelo atalho (pythonw.exe) encerrava o serviço e não o iniciava de novo, deixando a mineração parada.

v0.5.6 — menos processos, menos disco e interface mais leve

Versão de eficiência: o painel e o serviço do rig fazem o mesmo trabalho com menos processos externos, menos leitura de disco e um banco que cresce bem menos. Nenhuma regra de mineração, carteira, contribuição, limite térmico ou identidade de GPU mudou.

Medições nesta máquina

RTX 3070 física, Windows 11, serviço v0.5.5 minerando. Medidas com a mesma GPU e o mesmo log, comparando o commit da v0.5.5 com esta versão:

O quê	v0.5.5	v0.5.6
Ciclo de coleta do painel (15 ciclos)	152 ms e 2 processos por ciclo (tasklist + nvidia-smi)	8 ms e 0 processos, usando o snapshot recém-gravado pelo serviço
Detecção de GPU (a cada 30 s, no painel e no serviço)	15 chamadas nvidia-smi, 712 ms	3 chamadas, 148 ms; 1 chamada, 43 ms, com capacidades em cache
Listar o processo do minerador	tasklist: 73 ms	Toolhelp32: 7 ms
gpu_telemetry.miner_json por amostra	cerca de 2,6 KB (incluía 35 linhas de log)	cerca de 0,3 KB

A identidade detectada (driver, PCI, VBIOS, limites, clocks suportados, catálogo) foi comparada campo a campo e é idêntica nas duas versões. Com seis placas, a detecção antiga faria cerca de 90 chamadas a cada 30 s em cada processo; o cenário de seis GPUs continua simulado nos testes. A economia de banco é uma estimativa: cerca de 95 MB por dia e por GPU a menos com amostras a cada 2 s. Linhas já gravadas não são alteradas nem apagadas.

As 20 melhorias

1. Detecção NVIDIA com uma consulta de capacidades por placa; se o driver não aceitar um campo, volta ao modo campo a campo anterior.
2. Capacidades fixas (VBIOS, serial, PCI, limites, clocks suportados) em cache por UUID/PCI/nome por até 10 min, no painel e no serviço.
3. Com o serviço ativo, o painel usa o latest.json por GPU com até 5 s, sem nova consulta ao driver nem novo parsing do log; sem ele, consulta diretamente.
4. PIDs do SRBMiner pelo Toolhelp32 do Windows (ctypes); tasklist fica só como reserva.
5. Linha de comando de um processo consultada ao PowerShell uma vez por identidade (PID, horário de criação e executável); PID reutilizado continua sendo outro processo.
6. Parsing do log reaproveitado quando o texto é idêntico; a janela de 900 s dos pontos é reaplicada e linhas com horário futuro passam a valer no tempo certo.
7. Cauda do log lida de forma incremental: só os bytes acrescentados, conferindo a emenda; log reescrito é lido de novo.
8. Expressões regulares compiladas uma vez e conversão de horário com cache.
9. Posição de arquivamento de cada log persistida depois do commit; reabrir o painel não relê logs inteiros. A chave SHA-256 das linhas foi mantida para continuar deduplicando o histórico existente.
10. Linhas de log gravadas em lote (executemany) num único commit, em vez de um commit por linha.
11. SQLite em WAL com synchronous=NORMAL: commits sobrevivem ao encerramento forçado do processo; numa queda de energia, os últimos commits podem ser perdidos, sem corrupção.
12. gpu_telemetry deixa de copiar recent_logs e rate_points a cada amostra; as linhas brutas continuam arquivadas uma vez em events.
13. Snapshots reescritos a cada ciclo em JSON compacto; o latest.json do painel passa a ser gravado de forma atômica.
14. settings.json lido de novo apenas quando muda (mtime e tamanho), no painel e no serviço.
15. Busca de logs (mining-*.log) refeita só quando o diretório muda; com o log informado pelo serviço, não há busca.
16. Gráficos recriam título, grade e rótulos só quando tamanho ou fonte mudam; a cada amostra, só a série é redesenhada.
17. Gráficos em abas ocultas ou com o painel na bandeja não são desenhados; ficam marcados e são atualizados ao aparecer.
18. A aba de rendimentos é recalculada quando chegam dados da pool e, por telemetria, no máximo a cada 10 s.
19. Laço da interface a cada 250 ms com a janela visível e a cada 1 s na bandeja; ui-request.json só é lido quando muda; flush() do histórico espera por condição, sem laço de 10 ms.
20. Hook .githooks/pre-push com testes (e os 5 mais lentos), verificação da documentação, sintaxe dos .ps1 versionados (tools/check_powershell.ps1) e gitleaks.

Validação

• Suíte local: 427 testes, incluindo test_optimizations.py para cada cache (invalidação, cópias isoladas, retomada após reinício, fallback de campos não suportados).
• QA opt-in de interface: test_responsive_ui.py --run --native-dpi (12 casos, sem erros ou overflow) e test_windowing.py --run --native-dpi.
• Os novos módulos file_cache.py e process_list.py fazem parte do inventário do runtime instalado (data/rig-runtime.json).

Para o serviço do rig usar as otimizações dele (2, 5 e 14), é preciso atualizá-lo em Configurar → Central de operação → Atualizar serviço (UAC), o que interrompe a mineração por alguns segundos e pede aprovação do administrador. Atualizar só o painel já traz as melhorias do painel.

HashPilot v0.5.5 — continuidade de mineração e SRBMiner 3.8.3

v0.5.5 — continuidade de mineração e SRBMiner 3.8.3

O catálogo passa a aceitar o pacote oficial Windows do SRBMiner 3.8.3, com SHA-256 fixado para ZIP e executável. Essa versão do minerador anuncia uma correção de flutuação de hashrate/potência do Pearlhash; isso não garante aumento de desempenho.

• Atualização e reversão preservam os mecanismos existentes de validação, carteira e histórico.
• O assistente opcional do Defender reconhece a nova versão e continua solicitando aprovação do administrador para uma exceção ao executável exato.
• As versões 3.8.0 e 3.8.1 permanecem disponíveis no catálogo. A instalação inicial continua fixada em 3.8.0; a atualização é oferecida separadamente.
• Testes de correspondência de pacote e permissões simuladas cobrem todas as versões catalogadas.

Fonte: release oficial 3.8.3. Hashes verificam integridade/origem; não representam análise de segurança independente.

23 melhorias de continuidade

1. Catálogo do SRBMiner 3.8.3 com hashes do pacote oficial e do executável.
2. Verificação de integridade antes de enumerar dispositivos ou lançar o minerador.
3. Estado específico para executável ausente/bloqueado, sem gastar tentativas de recuperação em um arquivo inválido.
4. Retomada quando esse executável volta a passar na verificação e o sensor permite iniciar.
5. Retomada manual sem ficar presa no intervalo das falhas automáticas anteriores; o histórico permanece intacto.
6. Limite persistente de uma tentativa manual a cada 30 segundos, evitando rajadas por cliques repetidos.
7. Recuperação do controlador de GPU sem derrubar um minerador saudável.
8. Limite persistente separado de recuperação do controlador: três tentativas por hora e intervalo mínimo de 60 segundos.
9. Remoção de pedidos antigos de parada antes de substituir um controlador encerrado.
10. Tolerância de 90 segundos a detecção NVIDIA temporariamente vazia ou parcial, antes de tratar a GPU como desconectada.
11. Pedido temporário ao Windows para evitar suspensão automática por inatividade durante mineração gerenciada; o monitor pode apagar normalmente, e o pedido é liberado ao parar.
12. Janela de 60 segundos após lacuna do serviço ou ajuste regressivo do relógio, evitando reinício imediato com telemetria antiga.
13. Confirmação de travamento por pelo menos três observações ao longo de dez segundos, além dos limites existentes.
14. Erro de leitura do log deixa de ser tratado como evidência suficiente para reiniciar o minerador.
15. Hashrate malformado, booleano, NaN ou infinito deixa de quebrar a avaliação de saúde.
16. Hashrate anterior ao início da sessão deixa de confirmar que um processo novo já está calculando.
17. ACK anterior ao início da sessão deixa de confirmar uma sessão nova.
18. ACK persistido no futuro é ignorado após correção do relógio, sem apagar o histórico.
19. Recuperações persistidas no futuro deixam de prender o serviço em espera após correção do relógio.
20. Jobs recebidos restauram a informação de conexão quando a linha inicial já saiu da cauda do log; linhas atrasadas de conexão/ACK não substituem evidências mais novas.
21. Registro persistente e deduplicado de inícios, paradas, falhas e recuperações por GPU.
22. Central operacional mostra falha do controlador/gerenciador e se o Windows confirmou o bloqueio de suspensão por inatividade.
23. Reutilização de um pacote local verificado para reinstalar sem repetir o download; ZIP e executável continuam sendo conferidos, e cache corrompido é recusado.

O novo módulo faz parte do inventário do runtime instalado. Há testes de falha simulada para essas políticas. Apenas uma RTX 3070 é validada fisicamente; isso não torna a mineração imune a falta de energia, desligamento explícito, bloqueio do sistema, falha de hardware ou temperatura excessiva. Recuperações preservam as verificações de identidade, os limites térmicos e a decisão de parar/desabilitar a GPU.

v0.5.4 - Pagina publica e confirmacao da carteira

v0.5.4 — descoberta, documentação e confirmação de carteira

Simplifica a entrada do README em português/inglês, destaca instalação e limitações, adiciona uma página pública bilíngue e um formulário de experiência externa. Capturas recentes da UI v0.5.3 usam telemetria real de uma RTX 3070; saldos, previsões, carteira e identificadores foram explicitamente ocultados. O vídeo v0.1.0 permanece identificado como histórico; não foi gerado vídeo novo.

Ações explícitas de iniciar GPUs pela interface pedem confirmação, com padrão Não, quando o destino efetivo é a carteira do autor. Considera overrides existentes por GPU no assistente. Cancelar preserva a configuração e não inicia o serviço. A carteira do autor continua padrão, como solicitado, e a contribuição opcional continua desativável. Esta confirmação da UI não é uma política universal de autorização: GPUs novas detectadas por um serviço já ativo continuam seguindo a configuração padrão documentada.

Adiciona material para revisão de segurança e métricas agregadas locais. Nenhum resultado externo foi inventado. A análise Microsoft do SRBMiner 3.8.1 permanece pendente; não foi concedida exceção ou restaurada quarentena nesta atualização.

Validação: 387 testes unitários; revisão dos resultados do agente Terra pelo agente principal; verificações de documentação, links locais da página, arquivos públicos e segredos. HashPilot é pré-lançamento; múltiplas GPUs continuam simuladas nos testes. Isso não constitui auditoria independente de segurança.