Usar o REAToolkit em um projeto novo ou existente

Copiar/descompactar o toolkit fora da pasta de distribuição do produto. Fixar a versão e validar o manifesto conforme o processo disponível; o pacote entregue não tem assinatura comercial de produção. Consultar VERSION/BUILD.json e preservar o histórico do próprio projeto.

Mensagem para acompanhar a entrega (substituir os caminhos):

Use o REAToolkit by Mizin em CAMINHO_DO_TOOLKIT para diagnosticar e melhorar a resistência à engenharia reversa deste projeto. Leia primeiro as instruções AGENTS e as regras de versão/deploy do projeto. Preserve originais e trabalho em uso. Identifique tecnologia, artefato realmente entregue, recursos essenciais, obrigações de terceiros e necessidades offline. Consulte a referência REA fixada e registre a versão instalada se ela for analisada. Execute auditorias de código e distribuição separadamente, com relatórios externos, e gere um plano. Implemente melhorias compatíveis em cópia/branch dentro do escopo autorizado; comece por exposição desnecessária e controles no componente correto. Não aplicar proteção genérica de runtime nem modificar contêiner Wire. Preparar distribuição por lista explícita somente após conferir dependências e notices. Repetir testes funcionais, métricas e uma tarefa delimitada de análise antes/depois. Registrar evidências, limites, plano de retorno e risco residual. Respeitar as autorizações de publicação já definidas neste projeto. Entregar achados e mudanças verificáveis, sem valores de segredos e sem declarar bloqueio completo de engenharia reversa.

Incluir proteção contra invasão, acesso indevido, adulteração e perda de dados. Usar security e os controles do plano para avaliar contas/sessões, permissões por recurso, entradas/arquivos, rede/IPC, segredos, dependências, distribuição, registros e recuperação conforme existirem no produto. Priorizar riscos confirmados de dados e acesso; ofuscação não substitui essas correções. Usar contas/dados de teste em ambiente autorizado e preservar funcionalidade, desempenho e continuidade. Não tratar ausência de alertas ou um checklist exportado como evidência de proteção implementada. Quando a implementação estiver autorizada, entregar mudanças concretas e testes delimitados, além do diagnóstico.

Sequência prática

1. init: inventário e checklist da tecnologia.
2. knowledge e security: referência REA e checklist local de segurança correspondentes ao perfil.
3. audit: diagnóstico em leitura de código e pacote, separadamente.
4. plan: propostas e evidências pendentes a partir do relatório.
5. Implementação seletiva no fluxo do produto; o toolkit não a executa automaticamente.
6. stage: cópia de distribuição quando a política de arquivos já estiver revisada.
7. Testes externos no produto e coleta das evidências reais.
8. compat, compare, manifest, sign e verify, conforme o processo definido.
9. Publicação e retorno seguem as regras e autorizações do projeto.

Os comandos são independentes de Codex/REA e não enviam arquivos a serviços externos. Este documento não manda mensagem a outros chats, não instala integração global e não muda projetos sozinho. O scanner pode apontar fontes obrigatórias de terceiros ou dados sintéticos de teste; revisar o contexto e registrar exceções sem apagar o relatório original.

Política de proteção de criações

Objetivo: reduzir exposição de propriedade intelectual, abuso de licenças, acesso indevido, exploração de falhas, adulteração de produtos, vazamentos e perda de dados. Aplicação: projetos novos, produtos em desenvolvimento e produtos já em uso. REA é uma das ferramentas do cenário; as decisões devem continuar úteis quando outra ferramenta for utilizada.

Objetivos e limites

Uma recriação independente a partir de resultados observáveis pode ocorrer sem recuperar o código original. Priorizar também qualidade do produto, manutenção e entrega contínua; proteger o arquivo não elimina esse caminho.

Modelo mínimo de ameaças

Considere: comprador que copia o pacote; pessoa com acesso de administrador ao próprio dispositivo; invasor da conta de cliente; vazamento por colaborador; adulteração do atualizador; analisador que usa REA ou ferramentas convencionais; observador que reproduz o comportamento. Registre ativos, pontos de entrada, fronteiras de confiança e evidência necessária para cada hipótese. Não presuma que o cliente, o relógio local ou uma resposta de rede controlada por ele sejam autoridades confiáveis.

Proteger: fontes editáveis, chaves de assinatura, credenciais de serviços, algoritmos selecionados, direitos de acesso, integridade dos instaladores, dados dos usuários e disponibilidade durante trabalho ao vivo. Manter chaves privadas fora do binário e do repositório. Uma chave pública no aplicativo é esperada; não deve ser classificada como segredo.

Regras de decisão

• Controles de acesso devem existir onde a operação é concedida. A interface pode explicar o acesso; o servidor valida cada operação protegida que controla.
• Ofuscação/antiadulteração complementam a arquitetura. Não substituem autorização, criptografia correta, atualizações nem proteção de dados.
• Usar bibliotecas e primitivas mantidas. Não criar criptografia própria nem embutir uma senha universal para todas as instalações.
• Não bloquear processos de análise do usuário, procurar ferramentas no computador todo, atacar analisadores, inserir prompt injection ou coletar dados pessoais como forma de proteção.
• Toda mudança precisa preservar suporte, acessibilidade, desempenho, recuperação e obrigações de licenças. Código de terceiros que precisa ser fornecido não pode ser ocultado sob este programa.
• Não desligar um show por perda transitória de conectividade. A política de validade offline é explícita e testada; não autoriza uso indefinido por acidente.

Estados de evidência

NOT_TESTED: não houve execução do teste. NOT_SUPPORTED: a plataforma não fornece o mecanismo proposto. INCONCLUSIVE: execução não resolveu a hipótese. FAILED: critério não atendido. PASSED_LOCAL: teste delimitado passou. PASSED_TARGET: teste no produto/host previsto passou. RISK_ACCEPTED: responsável aceitou uma exceção com validade e plano. Não converter nenhum desses estados em aprovação geral automática.

Uma publicação exige: ausência de bloqueadores sem tratamento, cobertura conhecida, testes funcionais e de segurança proporcionais, validação de instalação/retorno e decisão do responsável. O scanner produz um gate auxiliar, nunca esse aceite final. Não usar nota percentual de “segurança contra REA”.

Base técnica: OWASP MASVS, família RESILIENCE, aplicada aqui como orientação de resistência; ela não é certificação de aplicações desktop. O NIST SSDF orienta a integração do trabalho de segurança ao ciclo de desenvolvimento.

Proteção contra invasão segue o guia de segurança de aplicação. Priorizar riscos confirmados de acesso, dados e exposição de credenciais. NO_BLOCKERS_DETECTED na auditoria estática nunca significa que autenticação, isolamento entre clientes ou resistência a invasão foram testados.

Projetos novos

Antes da primeira distribuição

Preencher o inventário e nomear um responsável. Identificar o perfil tecnológico e se haverá uso offline ou em eventos. Descrever o que pode ser público, o que precisa ficar privado e o que já é observável pelo funcionamento normal. Não colocar um algoritmo inteiro no servidor apenas por ser valioso se a latência e a operação exigem execução local; registrar esse compromisso.

Separar desde o início: fonte interna, artefato comercial, fontes/notices de dependências exigidos por licença e evidências internas. Não montar ZIP de entrega copiando o diretório inteiro do desenvolvimento. A lista de entrada do empacotador deve ser explícita, reproduzível e compatível com o instalador.

Primeiro ciclo

1. Criar inventário: node bin/reatoolkit.mjs init --profile PERFIL --out CAMINHO_EXTERNO/projeto.json.
2. Modelar ameaças com o responsável. Definir direitos de uso, política offline, suporte e confiança do atualizador.
3. Executar auditoria do código com --scope source. Revisar candidatos a segredos sem transcrever seu valor em tickets.
4. Implementar autorização, armazenamento de segredos e validação de entrada nos componentes corretos. Definir proteção local apenas para ativos selecionados.
5. Gerar um pacote de teste em diretório separado. Auditar esse diretório com --scope artifact; inspecionar também instaladores/ASAR depois do empacotamento com ferramentas próprias.
6. Gerar manifesto, validar assinatura e testar atualização, downgrade e retorno de falha em ambiente isolado.
7. Executar testes funcionais e o roteiro de resistência no artefato exato. Registrar versão, build, commit e hashes.
8. Responsável decide a publicação. Guardar símbolos/mapas privados, fontes e licença de terceiros exigidas para suporte e conformidade.

Integração ao desenvolvimento

Adicionar o trecho do modelo AGENTS ao arquivo existente somente após revisar suas regras; não substituir instruções atuais. Integrar o exemplo de CI à automação já usada. Verificar códigos de saída e guardar relatórios como artefatos privados, inclusive quando o job falhar. O toolkit não instala hooks, não altera a CI nem modifica arquivos de versão dos adotantes.

Automação deve impedir publicação por bloqueadores, erro de execução ou cobertura incompleta não tratada. A ausência de bloqueadores automatizados apenas permite continuar para testes/aceite. Um risco aceito é registrado separadamente, com dono e prazo; não é escondido alterando o relatório original.

Concluído para adoção inicial

O projeto possui inventário, ameaça principal, distribuição separada de fontes, chave de assinatura fora do cliente quando aplicável, checklist tecnológico, evidências mínimas de licença/atualização e um processo de revisão antes de publicar. Obfuscação sofisticada e análise dinâmica adicional podem entrar depois, com medição de ganho e custo.

Adoção em projetos existentes e em uso

O diagnóstico inicial não muda licenças, clientes, banco de dados, servidor nem comportamento do produto. Versões já entregues continuam sendo uma exposição histórica; uma atualização futura não recolhe cópias anteriores nem revoga um segredo que já vazou.

Fase 1 — referência confiável

Registrar versão/build atuais, commit conhecido, instalador realmente entregue, plataforma, dependências de funcionamento e restrições do show/cliente. Preservar o pacote e fazer uma cópia de trabalho. Quando houver dados mutáveis, criar e validar backup e restauração antes de migração. Não testar engenharia reversa em um processo que está operando um evento.

Auditar o código e o artefato entregável separadamente. Se só existir um executável/instalador, começar pelo inventário e pelo manifesto; declarar análise interna pendente. Inspecionar uma cópia isolada do pacote com ferramentas compatíveis. Não baixar produtos nem enviar binários a serviços externos automaticamente.

Fase 2 — classificação do trabalho

Essas prioridades são critérios operacionais do toolkit. A severidade automática é um candidato de triagem e pode mudar após revisão contextual.

Fase 3 — mudança delimitada

Criar branch/cópia, preencher o plano e definir a versão anterior que continuará utilizável. Não editar binários originais nem aplicar um protetor genérico em toda a coleção. Começar pelo empacotamento e pelas credenciais expostas; depois autorização, atualizador e proteção local.

Para licenças antigas, mapear quem tem direito ao produto, regras de migração, ativação offline, computadores substituídos e suporte. Não converter licença permanente em assinatura nem impor internet contínua sem decisão comercial explícita. Nenhum identificador de máquina deve depender apenas de um componente que muda com atualização comum de hardware.

Fase 4 — provar compatibilidade

Repetir uso normal, licença válida/expirada/revogada, reinstalação, troca de equipamento, falta de internet, recuperação após queda e atualização interrompida. Medir inicialização, CPU/GPU, memória e latência conforme o produto. Para vídeo ao vivo, incluir resolução, codecs, saída real e FPS/latência com o projeto de show apropriado.

Comparar auditorias da mesma árvore e cobertura. Arquivos removidos podem explicar um achado ausente; isso não prova que a credencial foi revogada nem que o binário resiste a análise. Anexar evidência de correção no ponto de origem.

Fase 5 — implantação e retorno

Usar um grupo piloto definido pelo responsável. Definir janela, critérios de parada, pacote anterior validado e migrações reversíveis ou restauração. Monitorar falhas de ativação/atualização e impacto real. Publicar em produção somente no fluxo autorizado do projeto. Conservar as versões anteriores internamente, sem continuar expondo artefatos vulneráveis em links públicos por acidente.

O primeiro piloto recomendado é um produto próprio com boa cobertura funcional e instalação recuperável. Wire exige validação no Arena/Avenue; um aplicativo próprio permite experimentar assinatura/licenciamento no seu runtime, mas também exige testes reais.

Perfis tecnológicos

Todos os perfis recebem as verificações básicas de distribuição e possíveis credenciais. O perfil Electron adiciona busca textual por configurações candidatas. Os demais perfis não decompilam nem inspecionam mitigadores de binários; seus checklists guiam a validação específica.

Web e serviços

JavaScript/CSS/HTML entregues ao navegador são acessíveis ao cliente. Minificação não esconde segredos. Guardar credenciais privilegiadas e decisões de autorização no serviço; validar usuário, recurso e operação em cada chamada protegida. Uma chave pública de um serviço pode ser intencional; verificar os privilégios reais em vez de presumir que toda chave é secreta.

Separar mapas públicos dos mapas internos de suporte. Impedir acesso a fontes privadas, backups e .env no servidor/armazenamento. Validar cache/CDN, URLs de download com validade delimitada, limites por usuário e acesso entre contas. Testar com duas contas e recursos pertencentes a cada uma. Browser headers/CSP são controles de segurança web, não barreiras contra leitura do código entregue.

Evidência necessária: requisições negadas/autorizadas com identidades delimitadas, acesso direto ao recurso estático, isolamento entre clientes, revisão dos bundles e resultado de expiração/revogação no servidor. Base: OWASP Authorization.

Electron

ASAR é empacotamento, não criptografia; a documentação do formato explica o acesso a seus arquivos. Revisar as fronteiras entre renderer, preload e main, com APIs mínimas e validação de remetente e argumentos do IPC. Inspecionar isolamento de contexto, sandbox, integração Node e navegação; a expressão textual encontrada pelo scanner exige confirmação no código realmente executado.

Reduzir fontes e mapas distribuídos, aplicar proteção seletiva onde estável e medir compatibilidade. Assinar o aplicativo conforme a plataforma e validar atualizações no instalador real. Mover código para um módulo nativo pode aumentar trabalho de análise em casos específicos, mas amplia manutenção e não impede decompilação; não é obrigação deste programa. Não carregar proteção que prejudique acessibilidade ou suporte.

Evidência necessária: tentativa de operação IPC fora da permissão, navegação/conteúdo não confiável, instalação/atualização e inspeção do ASAR. Base: documentação de segurança Electron.

.NET

Assemblies gerenciados costumam manter metadados úteis à análise. Revisar o conteúdo publicado, símbolos, arquivos de configuração e credenciais. Ofuscação seletiva pode alterar reflexão, serialização, bindings e XAML; testar esses caminhos. Single-file, ReadyToRun, trimming e Native AOT têm objetivos de implantação/desempenho e restrições próprias; não tratá-los como proteção garantida.

Escolher ferramentas de inspeção compatíveis e medir o que ainda fica legível. Assinatura de assembly/strong name não substitui a confiança da distribuição nem o Authenticode; a Microsoft distingue identidade de segurança. Guardar símbolos privados por versão para investigar falhas. Validar toda mudança com o aplicativo real e seu atualizador. Antes de Native AOT, revisar suporte e restrições da implantação.

Nativo C/C++/Rust/Qt

Separar símbolos privados, revisar strings/recursos e metadados de compilação, configurar mitigadores suportados pelo compilador/linker e validar o resultado em binários reais. Mitigadores contra exploração de memória não equivalem a proteção de propriedade intelectual. Preservar notices e entrega de código de dependências quando exigidos.

Análise estática e dinâmica deve considerar o formato/plataforma do binário. Evitar proteção invasiva/virtualização antes de medir crash reports, antivírus, depuração de suporte, inicialização e desempenho de renderização. Verificar assinatura do instalador e a cadeia do atualizador separadamente do manifesto do toolkit.

Resolume Wire / Acervo Mizin

Preservar Wire e .cwired. Guardar .wire, recursos editáveis e pacotes internos em acesso administrativo. Entregar ao comprador somente a variante prevista: o ZIP interno de manutenção pode ter fontes; o ZIP comercial sem direito a fontes não deve herdá-las. Arquivos .wired continuam editáveis.

O .cwired restringe edição/acesso normal a recursos pelo editor, conforme Resolume. Isso não é garantia de resistência a engenharia reversa. O campo de licença documenta os termos. Um pulso OSC, valor oculto ou login no instalador não constitui, por si só, autorização forte da execução de uma cópia entregue.

--juicebar requer licença gerada por Juicebar para renderizar sem watermark. Integração do nosso app/servidor com esse mecanismo precisa de confirmação oficial; a documentação consultada não estabelece uma API própria de emissão. Consultar o fluxo oficial de publicação. Não criar promessa comercial de ativação própria sem essa prova.

Não cifrar/modificar o contêiner .cwired depois de compilar: isso pode impedir o loader oficial de abri-lo. Não aplicar ofuscador de EXE em um patch. Testar o compilado exato no Arena/Avenue com recursos, presets, alpha, resolução e projeto real. Validação local no Wire não prova desempenho no host nem no painel físico. A falta de suporte de .cwired em um analisador é NOT_SUPPORTED, nunca aprovação de proteção.

Licença, assinatura, atualização e continuidade

Estas são decisões e requisitos de implementação para cada produto. O toolkit fornece assinatura de manifesto; não fornece servidor de licença, DRM, atualizador pronto nem integração de ativação Wire.

Fronteiras de confiança

flowchart LR
  A[Fontes e CI privados] --> B[Pacote sem segredos]
  K[Chave privada protegida] --> C[Assinatura do manifesto]
  B --> C
  C --> D[Distribuição]
  D --> E[Cliente com chave pública confiável]
  E --> F[Validação e instalação controladas]
  E <--> G[Servidor de autorizações]
  G --> H[Operações e dados protegidos no serviço]

A chave privada não entra em B, D ou E. A chave pública confiável é fixada no instalador/processo por canal anterior à distribuição em análise. Obter manifesto, assinatura e uma chave pública todos do mesmo local adulterável não estabelece a identidade do autor. A validação local pode ser alterada por quem controla o runtime; operações do servidor continuam exigindo sua própria autorização.

Licenciamento nos aplicativos próprios

Definir produto/edição, identificador opaco do direito, funcionalidades, identificador da chave emissora, emissor/destinatário, validade, tolerância de relógio, limite de dispositivos e protocolo de revogação. Assinar bytes definidos por um formato estável usando biblioteca mantida. Não reutilizar o formato de manifesto deste toolkit como token de licença por improviso.

O emissor protege a chave, valida pagamento/direito no banco e aplica transações ao registrar/transferir uma instalação. Tokens de acesso curtos e credenciais de renovação têm escopos distintos. Não confiar em licensed=true enviado pelo cliente nem no campo de licença de um patch. Uma assinatura impede forjar uma autorização sob a chave conhecida; não impede remover uma verificação local de um programa modificado.

O identificador de instalação deve minimizar dados pessoais. Não usar CPF, e-mail em watermark público, número bruto de disco ou inventário completo de hardware por conveniência. Permitir recuperação e troca legítima de computador. Documentar quais dados o produto coleta, sua finalidade e retenção; o toolkit não instala telemetria.

Offline e eventos

Escolher por produto: validade do direito em cache, momento de renovação, período de tolerância e limite de uso desconectado. Revogação imediata exige contato com uma autoridade; uma instalação offline pode continuar até expirar a autorização previamente concedida. Relógio local adulterável e restauração de snapshots precisam fazer parte dos testes.

Para uso ao vivo, fazer a checagem antes da sessão e fornecer avisos em tempo hábil. Uma sessão já autorizada deve seguir a política de continuidade definida mesmo com queda de rede. Não embutir um bypass universal de emergência; prever recuperação controlada pelo suporte. Esse desenho é uma decisão do produto, não uma funcionalidade instalada pelo toolkit.

Atualizações e integridade

O comando manifest descreve exatamente todos os arquivos regulares da pasta, sem exclusões implícitas; não usar sobre a raiz de desenvolvimento com .git. sign assina os bytes do manifesto. verify verifica a assinatura, se fornecida, e compara conteúdo, tamanho e conjunto completo de arquivos. Detecta adições, remoções e mudanças.

Para incorporar isso em um atualizador real, ainda implementar: origem confiável da chave pública; metadados autenticados do produto/canal/versão; política contra downgrade; rotação/revogação de chaves; limites de extração; staging imutável; validação depois da extração; transição atômica; recuperação de falha e controle de permissões. O intervalo entre verificação e uso permite corrida se alguém puder alterar arquivos. O verificador de linha de comando não fecha essa janela nem instala o produto.

Um hash solto ajuda a comparar bytes, mas pode ser substituído junto do arquivo. Assinatura do manifesto não é Authenticode nem assinatura da plataforma. Um pacote validamente assinado também pode conter falha de programação. Preservar cada evidência com seu escopo.

Chaves

Produção: provisionar a chave em ambiente apropriado, limitar seu acesso à função de assinatura, manter recuperação protegida, registrar responsável e ensaiar rotação. Nunca gerar chave de produção durante um teste de usuário ou colocar chave de exemplo no cliente. O toolkit aceita Ed25519 PEM; chave cifrada usa REA_SIGNING_PASSPHRASE no processo de assinatura, sem passar segredo em argumento CLI. Provisionamento por ambiente é apenas compatibilidade da ferramenta; um cofre/HSM e sua integração exigem adaptação própria.

Os testes automatizados geram chaves efêmeras em pasta temporária e as removem. Nenhuma chave fornecida na entrega deve ser tratada como identidade confiável de produção.

Roteiro de validação de resistência

Executar somente em produtos próprios ou explicitamente autorizados, em cópia isolada. O toolkit não lança REA, decompiladores, depuradores ou o produto. Os testes abaixo são um procedimento de validação para o responsável técnico executar e registrar.

Comparação reproduzível

Escolher uma tarefa delimitada, orçamento de tempo, experiência do operador e conjunto de ferramentas. Usar a mesma tarefa e limites antes/depois; registrar versões das ferramentas e os caminhos realmente analisados. Alterar o produto não significa aumentar resistência até que a hipótese seja medida.

Registrar por tarefa: pacote e SHA-256, versão/build/commit, sistema, ferramenta e versão, configuração relevante, tempo até o objetivo ou fim do orçamento, evidências e limitações. Não divulgar passos sensíveis nem segredos em relatórios públicos. Se a ferramenta não suporta o formato, procurar uma abordagem compatível na cópia isolada ou registrar NOT_SUPPORTED.

Matriz mínima

Evidência sem exagero

Não usar “demorou mais” sem medições comparáveis. Uma tarefa não concluída em 30 minutos significa apenas isso; não significa que nunca será concluída. Diferenças de modelo, prompt, ferramenta, orçamento e conhecimento prévio são fatores de comparação. Nomes ofuscados não provam que a lógica ficou inacessível. Arquivo cifrado que é decifrado no cliente continua sujeito a observação do runtime.

Para Wire: anotar quando a ferramenta rejeita o .cwired; isso mede compatibilidade do analisador. Guardar separadamente a execução do compilado no Arena/Avenue, presets, alpha, slices e desempenho. Para câmera, GPU, painel e rede, um simulador não equivale ao dispositivo físico.

Gate de aceite

Responsável verifica que cada hipótese crítica tem evidência, falha tratada ou exceção válida. Anexar resultados funcionais, plano de retorno e riscos residuais. O aceite identifica o artefato exato e seu hash. A próxima compilação ou mudança relevante pode exigir repetir os testes afetados. A ferramenta não emite certificado de resistência ao REA.

Referência das ferramentas

Executar com Node.js 22+. Não há instalação npm, chamada de rede, plugin global, hook instalado nem execução de binários do alvo. Fontes, chaves e relatórios são acessados somente nos caminhos fornecidos. O operador continua responsável por usar uma cópia isolada se o material puder ser hostil.

Auditoria

node .\bin\reatoolkit.mjs audit --root "D:\Produto\src" --profile electron --scope source --out "C:\Auditorias\Produto-src-001"
node .\bin\reatoolkit.mjs audit --root "D:\Produto\pacote" --profile electron --scope artifact --out "C:\Auditorias\Produto-pacote-001"

source ignora diretórios .git, node_modules, .venv e venv; não é varredura do histórico Git nem da cadeia de dependências. artifact ignora conteúdo do diretório .git depois de apontar sua presença como achado. Links simbólicos/junctions não são seguidos; tornam a cobertura incompleta. Diretórios de saída precisam ser novos e externos ao alvo. O toolkit não modifica ou remove arquivos analisados.

Limites padrão: 20.000 arquivos; 2 MiB de conteúdo por texto; ZIP de entrada até 32 MiB; até 1.000 entradas ZIP; expansão total até 16 MiB; até 2 MiB por entrada; relação de expansão até 100 para entradas maiores que 64 KiB. Os limites evitam trabalho descontrolado e não garantem uma sandbox. Conteúdos criptografados, ZIP64, multipartes, métodos não suportados, aninhamento e contêineres opacos são marcados para revisão. O parser não grava entradas ZIP no disco e verifica tamanho/CRC dos conteúdos que lê.

Texto UTF-8 e UTF-16LE com BOM são considerados. Outros encodings, valores calculados, codificados, cifrados, fragmentados ou em formatos binários podem escapar das heurísticas. .key pode ser um formato legítimo sem segredo: triagem humana obrigatória. Arquivos .env de exemplo são tratados de forma diferente, mas ainda podem conter um segredo real detectável. Extensão .js/.mjs não é proibida no pacote porque pode ser necessária ao funcionamento do produto. Arquivos de código aberto exigidos por licença podem justificar um achado de fonte.

Nenhuma regra confirma validade de uma credencial. Relatórios guardam regra, caminho, linha e recomendação; não guardam o valor nem um trecho da linha. Caminhos/metadados ainda podem conter informação interna. Não publicar relatórios sem revisão. Uma falha de leitura/parse pode encerrar com erro; não interpretar relatório ausente como auditoria aprovada.

Saída audit: 0 sem bloqueadores detectados na cobertura descrita; 2 achados críticos/altos; 3 cobertura incompleta sem bloqueador alto. 1 erro operacional/argumentos. securityApproval continua NOT_GRANTED em todos os casos. Severidades médias/revisão ainda exigem decisão humana.

Manifesto, assinatura e verificação

node .\bin\reatoolkit.mjs manifest --root "D:\Produto\pacote" --out "C:\Auditorias\produto.manifest.json"
node .\bin\reatoolkit.mjs sign --manifest "C:\Auditorias\produto.manifest.json" --private-key "CAMINHO_PRIVADO\assinatura.pem" --out "C:\Auditorias\produto.signature.json"
node .\bin\reatoolkit.mjs verify --root "D:\Produto\pacote" --manifest "C:\Auditorias\produto.manifest.json" --signature "C:\Auditorias\produto.signature.json" --public-key "CANAL_CONFIAVEL\publica.pem"

manifest inclui todos os arquivos regulares, inclusive ocultos, sem exclusões; links e arquivos especiais provocam erro. O manifesto fica fora da pasta descrita. A geração usa SHA-256 por streaming. O pacote deve estar parado/imutável; as verificações de arquivo não garantem um snapshot atômico do diretório.

sign aceita somente chave Ed25519 PEM existente; a frase de chave cifrada vem de REA_SIGNING_PASSPHRASE, se necessária. Nunca usar uma chave pública obtida do pacote suspeito como única raiz de confiança. O envelope assina os bytes exatos do manifesto; reformatar JSON depois de assinar invalida a assinatura.

verify exige assinatura e chave pública juntas ou nenhuma das duas. Sem assinatura, informa INTEGRITY_ONLY_NOT_AUTHENTICATED. Com assinatura válida e conteúdo correspondente: AUTHENTICATED_AND_MATCHED. Arquivo extra, faltante ou alterado: MISMATCH, saída 2. Assinatura inválida, caminho perigoso, duplicação ou erro: saída 1. Não há instalação, política antidowngrade ou verificação Authenticode.

Comparar

node .\bin\reatoolkit.mjs compare --before "C:\Auditorias\Produto-antes\audit.json" --after "C:\Auditorias\Produto-depois\audit.json" --out "C:\Auditorias\Produto-comparacao.json"

Exige o mesmo nome de pasta alvo, perfil e escopo. O operador precisa confirmar que é o mesmo produto e a mesma versão do scanner. A identidade do achado usa regra/caminho/linha/motivo; deslocar linhas pode aparecer como remoção e introdução. noLongerObserved não significa corrigido. Comparar cobertura e revisar manualmente. O comando não suprime findings nem aceita riscos automaticamente.

Relatórios novos incluem fingerprint do código do scanner e versão Node. A comparação sinaliza troca de engine/Node, ausência dessa identidade, redução do inventário, mudança de exclusões ou cobertura incompleta. Remover uma fonte do pacote pode reduzir legitimamente o inventário; a sinalização pede revisão, sem desfazer a redução nem afirmar que houve uma melhoria de segurança.

Conhecimento e plano

node .\bin\reatoolkit.mjs knowledge --profile electron --out "C:\Auditorias\referencia-rea.json"
node .\bin\reatoolkit.mjs plan --report "C:\Auditorias\Produto-antes\audit.json" --out "C:\Auditorias\Produto-plano-001"

knowledge lê somente a base local versionada; all seleciona todos os perfis. plan valida o formato do relatório e gera plan.json/plan.md, com propostas P0–P3, referências e controles NOT_TESTED. Nenhum deles executa REA ou aplica hardening. Relatório de entrada não é autenticado pelo plano. Novos arquivos/pastas não sobrescrevem saídas anteriores.

stage e compat são documentados com seus modelos em camadas e compatibilidade. stage usa os códigos 0, 2, 3 do gate estático; todos mantêm STAGED_NOT_APPROVED. compat retorna 0 para consistência na evidência declarada e 2 para bloqueio; erros de entrada/operação retornam 1. Não substituir o gate do projeto por um código de saída isolado.

Checklist de segurança de aplicação

node .\bin\reatoolkit.mjs security --profile electron --out "C:\Auditorias\Produto-security.json"

Exporta o catálogo local filtrado por perfil. Sucesso (0) significa que o arquivo foi criado; não é aprovação nem teste de segurança. Perfil inválido, saída existente ou erro operacional retornam 1. O comando não aceita alvo, URL, senha ou opção de execução. Cada controle tem condição, verificação, compatibilidade e fontes; todos ficam TO_ASSESS/NOT_TESTED. O mesmo catálogo é incluído nas saídas novas de init e plan. Ver escopo e limites.

Versionamento e changelog automáticos

Formato obrigatório: vX.Y.Z (build XXXX). A versão não é escolhida pelo operador. Commits: tipo: descrição, com feat, fix, improve, perf, refactor ou break. Escopos e outros tipos não pertencem a este contrato.

O script lê commits desde a última tag de release registrada. Um commit break ou corpo com BREAKING CHANGE incrementa X e zera Y/Z. Na ausência disso, feat incrementa Y e zera Z. Nos demais casos incrementa Z. Cada novo empacotamento incrementa build em um; o número é formatado com pelo menos quatro dígitos. Sem versão anterior, a origem de cálculo é 0.0.0 e o contador é zero, ambos internos, nunca um release manual.

node .\scripts\release.mjs --dry-run
node .\scripts\release.mjs --build

--dry-run apenas calcula e mostra origem/resultado; cria uma trava temporária em .git e a remove. --build exige árvore limpa, valida os commits, executa os testes e, após sucesso, atualiza VERSION, version.json e CHANGELOG.md. Cada item do changelog registra o SHA completo de origem. As quatro seções são mantidas mesmo quando vazias; um feat com BREAKING CHANGE também aparece na seção de incompatibilidades.

O script faz commit estruturado somente desses três arquivos e cria tag anotada vX.Y.Z-buildXXXX. Em seguida copia os arquivos rastreados para uma pasta nova em releases/, inclui BUILD.json e gera ZIP, manifesto e recibo com hashes. Não faz push, publicação, assinatura de produção, deploy ou alteração em outros projetos. Git precisa ter identidade configurada no repositório. Não usar git add ..

Nova compilação sem commits funcionais recebe patch +1 e build +1, conforme a regra geral de incremento; o changelog registra o commit de origem. Não reempacotar para corrigir o mesmo número: gerar novo build. Uma falha depois do commit/tag de versão pode deixar release incompleto; conservar o registro, diagnosticar e gerar novo build. Não apagar a tag nem reutilizar o número para esconder uma tentativa. Falha de teste anterior ao empacotamento não cria versão.

A trava evita empacotamentos simultâneos pelo script. Um encerramento abrupto pode deixar a trava em .git/reatoolkit-release.lock; verificar que não há operação ativa antes de removê-la manualmente. Publicação e cópia dos arquivos são etapas posteriores, e precisam validar os recibos. O Git local é rastreabilidade, não identidade criptográfica comercial: as tags/commits desta entrega não são assinados por uma chave de produção.

Na adoção em outro projeto, integrar ao mecanismo existente. Não substituir sua automação nem alterar sua versão para “acompanhar o toolkit”. O projeto adotante segue seu próprio histórico, build e aprovação. Esta entrega inclui histórico Git local e um bundle externo para recuperar os commits citados quando o pacote ZIP estiver separado do repositório.

O empacotador também registra as estatísticas lidas do TAP em BUILD.json e preserva o arquivo .tests.tap externo. Contagem ausente, testes ignorados/cancelados, pendências ou falhas impedem a conclusão do gate de testes. Os recibos de QA usam essas estatísticas, sem um número manual fixado no script de validação.

Programa de adoção

Ordem de trabalho

1. Inventariar produtos e escolher um piloto recuperável. Identificar os que já têm fontes/credenciais na distribuição e os que operam eventos críticos.
2. Fazer diagnóstico em leitura do piloto, preservando a versão realmente entregue. Definir prioridades e metas observáveis.
3. Corrigir empacotamento e autorização antes de mecanismos de ofuscação. Aplicar proteção seletiva compatível com a tecnologia e o suporte.
4. Provar compatibilidade, continuidade e retorno. Comparar tarefas delimitadas de análise com o mesmo orçamento.
5. Integrar o gate à CI do piloto e expandir por grupos tecnológicos, um produto por vez.

Responsabilidades

Uma pessoa pode acumular papéis; a revisão deve continuar explícita. Não atribuir tarefas a outras pessoas nem contatá-las automaticamente.

Indicadores úteis

Cobertura de inventário; produtos com separação fonte/distribuição; achados confirmados resolvidos; credenciais expostas efetivamente revogadas; releases com assinatura verificada; hipóteses críticas testadas; tempo comparável até uma tarefa de análise; falhas legítimas de ativação/atualização; regressão de desempenho e tempo de recuperação.

Não somar esses indicadores em uma porcentagem de proteção contra engenharia reversa. Registrar a versão dos dados e pendências. Falta de evidência permanece visível.

Backlog após esta entrega

• Auditoria real de um produto piloto e implementação dos achados aprovados.
• Integração do verificador no instalador/atualizador de um aplicativo próprio, com metadados de canal/versão e política antidowngrade.
• Implementação de serviço de licenciamento e política offline específica, quando pertinente.
• Conexão com cofre/HSM de assinatura e rotação de chaves de produção.
• Inspeção específica de PE/.NET/ASAR e ensaio de ferramentas de proteção, após escolher o produto e medir o custo.
• Confirmação oficial de eventual integração comercial com Juicebar mantendo .cwired.

Esses itens não estão implementados no toolkit inicial e não bloqueiam o uso das ferramentas de diagnóstico já entregues. Não há alteração automática de todos os projetos do computador.

Fontes primárias e decisões

Consultadas em 2026-10-24. Links e funcionalidades podem mudar; a adoção em produto deve verificar a versão da tecnologia em uso. Estes documentos são orientação técnica e não conferem certificação nem autorização de integração comercial.

Decisões locais

O toolkit é independente de qualquer ferramenta de ataque e funciona sem rede. Prefere diagnósticos em leitura e implantação gradual. Não executa proteção genérica no computador, não modifica hosts/antivírus e não tenta interferir em análises de terceiros. Não modifica os arquivos originais nem transforma plugins Wire em DLL.

As limitações Wire/Acervo e os cuidados com QA real preservam decisões de trabalhos anteriores do usuário; nenhum estado de um produto anterior foi revalidado por esta entrega. Checklists de .NET e nativo são requisitos de revisão, não alegações de que o scanner mede mitigadores dessas plataformas.

Não foi escolhida uma ferramenta comercial de ofuscação nesta etapa. A escolha depende do runtime, orçamento, manutenção, licença, regressão e ensaio com o produto. Não é necessário contratar assinatura ou comprar créditos para utilizar este toolkit.

A referência detalhada do REA agora usa fontes por commit em 11 — funcionamento do REA. knowledge/rea.json registra o fuso, a data da consulta e o horário UTC do commit, evitando confundir revisão de documentação com teste de uma instalação local.

O guia de segurança contra invasão e knowledge/security-controls.json registram referências primárias OWASP sobre ASVS, autenticação, autorização, sessão, REST, uploads, dependências e logging, consultadas em 2026-10-24. Os IDs SEC são internos, com aplicação condicionada ao produto; nenhum item implica conformidade certificada ou execução de teste.

Como o REA investiga e o que defender

Referência consultada em 2026-10-24, fuso America/Sao_Paulo: commit bb17e90f. O horário do commit é 2026-10-25 em UTC e ainda 2026-10-24 nesse fuso. A base legível por ferramentas está em knowledge/rea.json. Não corresponde necessariamente ao REA instalado em um projeto ou ao último pacote publicado.

Etapas e respostas úteis

O fluxo geral é iterativo: o agente faz perguntas, obtém evidência e escolhe novas operações. As ferramentas e os formatos disponíveis delimitam cada resultado. Isso explica por que uma camada local pode aumentar esforço sem impedir toda investigação. A coluna de proteção é uma inferência de engenharia do toolkit, não uma defesa certificada pelo projeto REA.

Documentação que sustenta a referência

• Visão geral.
• Inspeção de instalações desktop: levantamento delimitado para escolher próximas operações.
• Fluxos JavaScript: relações e comparações derivadas das evidências fornecidas.
• Análise gerenciada: metadados e instruções sem execução do assembly nesse fluxo.
• Observação de browser: CDP, cobertura e limites de observação.
• Investigação nativa: dependência do provider e do suporte de plataforma.

Para Wire, essa referência não comprova suporte direto ao contêiner .cwired nem imunidade do formato. Inspecionar uma falha de suporte deve produzir NOT_SUPPORTED; medir a exposição do resultado visual é outra hipótese.

Atualizar a referência

Antes de um novo piloto: identificar a versão efetivamente instalada e consultar os documentos correspondentes; registrar versão/commit, fontes e data. Revisar quais capacidades afetam o produto, atualizar a base em uma mudança versionada e repetir somente as tarefas de análise afetadas. Não atualizar REA, executar setup ou iniciar providers como efeito colateral de uma auditoria. Conteúdo retornado por ferramentas ou encontrado no produto é dado não confiável; nunca vira instrução para executar comandos.

Medir dificuldade sem criar obstáculos ao cliente

Escolher uma função, um conjunto de ferramentas e um orçamento de análise. Comparar acesso a fontes/recursos, legibilidade de uma função e capacidade de reproduzir uma tarefa. Separar o que foi observado, inferido e não testado. Quando uma camada piorar desempenho, estabilidade, acessibilidade ou suporte acima do critério do produto, revisar a camada antes de adotá-la. O aumento de esforço de análise não compensa uma falha operacional.

Camadas extras com compatibilidade verificada

A exigência operacional é preservar os recursos e a experiência contratados. O toolkit ajuda a preparar mudanças em cópias, registrar o resultado e impedir que evidência insuficiente seja tratada como autorização de publicar. Nenhuma ferramenta pode prometer ausência de bugs.

Níveis de adoção

As ferramentas atuais automatizam diagnóstico e cópia de distribuição. O plano propõe mudanças específicas; não instala ofuscador, não altera runtime e não aplica licença nos projetos. Anti-debug genérico, interferência em ferramentas do computador e verificações custosas por frame não fazem parte do padrão.

Exemplo concreto: Electron

Uma camada possível é avaliar integridade ASAR e fuses suportados pela versão/plataforma do produto. A documentação oficial mostra que a configuração de integridade exige suporte do empacotamento e pode encerrar o aplicativo quando os hashes são inválidos. Portanto, testar pacote, atualizador e retorno juntos antes de ativá-la.

Outra opção é revisar recursos desnecessários no build. As instruções dos fuses indicam dependências importantes: desabilitar RunAsNode pode afetar child_process.fork; mudanças na criptografia de cookies têm implicações para retorno. A escolha depende do aplicativo. Não copiar uma configuração única para todos os produtos.

Pacote por lista explícita

1. Gerar o manifesto da pasta de build imutável, em saída externa.
2. Revisar quais arquivos são necessários e preencher package-policy.json com os caminhos relativos e SHA-256 do manifesto.
3. Informar entrypoints, notices exigidos e referência da revisão de terceiros. Não retirar fontes cuja entrega é obrigatória.
4. Executar stage apontando para uma nova cópia e outra nova pasta de evidências, ambas externas à origem.
5. Testar a cópia completa. O comando não descobre dependências; omitir uma DLL/recurso necessário pode impedir o funcionamento.
6. Somente depois de testes e decisão do responsável, incorporar o processo ao empacotamento do produto.

node .\bin\reatoolkit.mjs stage --root "D:\Produto\build" --policy "C:\Auditorias\package-policy.json" --out "C:\Auditorias\candidato-001" --evidence "C:\Auditorias\evidencias-001"

files é uma lista exata, sem globs nem inclusão recursiva implícita. Cada hash é verificado antes e depois da cópia. Links, caminhos não portáveis, arquivos ausentes e mudanças de conteúdo são recusados. Materiais privados óbvios e fontes/símbolos de um pacote closed exigem revisão antes da preparação. open e internal permitem fontes, mas a auditoria continua apontando-as; exceções precisam ser justificadas e não são suprimidas automaticamente.

O resultado fica STAGED_NOT_APPROVED, com auditoria e manifesto externos. Falha/interrupção preserva o que já foi criado; stage-start.json sem stage-result.json indica preparação incompleta. Não instalar essa cópia automaticamente. O comando não criptografa, recompila nem muda .cwired.

Gate de compatibilidade

Definir os testes do produto e os limites antes da alteração. Usar compat-policy.json e um arquivo de execução baseado em compat-run.json. Os modelos contêm campos a preencher; não são evidências prontas.

Executar os testes no produto antes/depois, fora do toolkit, em ambientes comparáveis. Registrar hashes do pacote e das evidências, IDs de ambiente/suite/revisão, estado de cada teste e valores medidos. O toolkit avalia os JSONs declarados; não executa os testes nem confirma a autenticidade dos logs referenciados pelos hashes.

node .\bin\reatoolkit.mjs compat --baseline "C:\Auditorias\antes.json" --candidate "C:\Auditorias\depois.json" --policy "C:\Auditorias\compat-policy.json" --out "C:\Auditorias\compat-001.json"

O gate bloqueia: projeto/ambiente/suite/revisão divergentes; reutilização do mesmo runId; teste obrigatório não aprovado no nível exigido; teste anterior removido ou regredido; teste com falha/pendência; métrica removida, ausente, sem orçamento ou com unidade diferente; regressão acima do limite. Números indisponíveis não podem ser preenchidos com zero. Base zero diferente do candidato exige revisão para evitar divisão percentual inválida.

Resultado positivo: NO_REGRESSION_IN_DECLARED_EVIDENCE. Isso não concede aprovação de segurança nem garante ausência de falhas. O gate não verifica rede, frame, câmera, instalação ou playback. Se a política não configura métricas, performanceGate permanece NOT_CONFIGURED. Uma política para eventos deve incluir as medições de desempenho relevantes e evidência no host real.

Critérios por produto

Escolher, conforme aplicável: instalação, inicialização, recursos principais, plugins, leitura de projetos anteriores, salvamento/reabertura, atualização interrompida, restauração, operação offline, troca legítima de máquina, CPU/GPU, memória, FPS e latência. Preservar mecanismos privados de suporte e symbols/maps associados ao build. Alteração de proteção precisa ser desativável por um novo build controlado ou ter retorno ensaiado; não criar um bypass universal no cliente.

Proteção contra invasão, acesso indevido e perda de dados

O programa de proteção passa a cobrir propriedade intelectual, integridade, acesso aos recursos, dados e continuidade operacional. Essas frentes se complementam. Ofuscar código pode aumentar o esforço de análise; permissões incorretas, credenciais expostas ou um parser inseguro ainda precisam de correção no componente responsável.

Base: OWASP ASVS para requisitos de aplicações web/serviços e guias primários citados abaixo. O catálogo usa IDs próprios SEC-001 a SEC-013; não representa uma verificação completa do ASVS, auditoria profissional ou certificação.

Ordem de implantação por produto

1. Inventariar entradas, serviços, dados, usuários privilegiados e dependências. Identificar que partes realmente existem; um plugin Wire local não deve herdar, por suposição, um servidor ou um sistema de contas.
2. Tratar exposição confirmada de credenciais, permissões de acesso e dados. Planejar rotação e migração para não interromper consumidores legítimos.
3. Corrigir fronteiras de entrada: arquivos, parâmetros, IPC, chamadas externas e operações de banco/processo.
4. Revisar distribuição, atualizações, dependências e ambiente operacional.
5. Testar detecção, disponibilidade e restauração. Aplicar medidas adicionais de resistência à engenharia reversa com os mesmos critérios de compatibilidade.

Não aplicar todas as configurações de segurança disponíveis por padrão. Escolher medidas que reduzam um risco concreto, documentando seus efeitos no programa e o retorno à versão anterior. Um bloqueio agressivo de login, limite de upload baixo ou atualização de dependências pode afetar o uso legítimo; testar esses efeitos antes de implantar.

Contas, permissões e sessões

Quando há contas, reforçar acesso privilegiado, recuperação de senha e tentativas automatizadas conforme a orientação de autenticação. O direito de usar uma função precisa ser conferido pela autoridade que a executa, incluindo recursos estáticos privados. Testar conta A, conta B e administrador com dados sintéticos. Ocultar um botão não demonstra que a operação correspondente é negada. Autorização.

Revisar validade, renovação e invalidação das sessões. Exercitar logout, expiração e eventos de recuperação no componente responsável. A política offline do produto deve continuar explícita; uma sessão de uso ao vivo e um token de serviço podem ter requisitos diferentes. Gestão de sessão.

Não entregar senha universal ou chave privada para “resolver” autenticação local. Não coletar senhas do usuário para auditar um provedor. Usar contas de teste e os mecanismos oficiais de autorização.

Entradas e execução

Descrever quais entradas podem vir de terceiros: URLs, consultas, JSON, arquivos, projetos antigos, plugins, IPC e recursos de mídia. Validar tipos, tamanhos e caminhos; trabalhar com APIs parametrizadas e execução com privilégios mínimos. Limites e erros devem permitir recuperação. Autorização deve continuar presente depois da validação do formato de entrada.

Para uploads e extração, verificar conteúdo, destino, acesso posterior e limites de expansão. Uma extensão ou MIME declarado não prova que um arquivo é adequado. Não executar o arquivo para decidir se ele é seguro. Guia de upload. Produtos com vídeo, câmera ou plugins exigem testes com arquivos legítimos representativos e manutenção dos codecs/parsers utilizados.

O toolkit não testa SQL injection, XSS, SSRF, execução remota ou vulnerabilidades de parsers automaticamente. Essas hipóteses precisam de revisão e testes delimitados na cópia/ambiente de teste autorizado. Um scanner de distribuição não substitui esse trabalho.

Rede, serviço e máquina local

Quando existe HTTP/API, revisar transporte, validação de certificados, métodos permitidos e limites de consumo. CORS e endereço local não concedem identidade nem permissão. Serviços locais e IPC também precisam de fronteiras de confiança. Aplicar os controles relevantes ao protocolo e à tecnologia. Guia REST.

Registrar portas/interligações realmente necessárias e o alcance esperado. Mudanças de bind, firewall, proxy ou certificados devem preservar integrações e redes de eventos e passar pelos testes do produto. O toolkit não modifica esses componentes nem abre conexões de teste.

Para host/infraestrutura, atribuir responsabilidades por atualizações, contas administrativas, acesso ao banco/armazenamento e publicação. Um .cwired não configura a segurança do Arena, do sistema operacional ou do Acervo; esses componentes têm seu próprio escopo de diagnóstico.

Dependências e distribuição

Manter inventário de versões, origens e componentes usados, incluindo dependências transitivas e runtimes. Verificar avisos e avaliar o caminho vulnerável no contexto antes de priorizar uma mudança. Não aplicar atualização em massa em um produto em uso. Gestão de dependências vulneráveis.

Repositório, CI e chaves de publicação precisam de acesso controlado. A assinatura do pacote ajuda a conferir sua origem quando a raiz de confiança está protegida; não prova ausência de vulnerabilidades. Preservar notices e fontes exigidas por licença, sem misturar segredos no pacote.

Detecção, recuperação e continuidade

Definir eventos úteis de acesso/falha/administração, destino dos registros, acesso e retenção. Excluir senhas, tokens e dados desnecessários; limitar volume e custo no caminho crítico. Guia de logging. Planejar a resposta a eventos no processo do produto; o toolkit não instala telemetria, monitor ou notificações.

Manter backup/restauração verificados do que o produto realmente persiste. Ensaiar retorno de atualização e recuperação de configurações/projetos. Um incidente pode exigir contenção, revogação e correção na origem; retirar um arquivo de um ZIP não recolhe cópias nem revoga uma credencial já divulgada. Preservar evidências sem copiar segredos para tickets. Usar o modelo de incidente.

Utilizar o novo checklist

node .\bin\reatoolkit.mjs security --profile web --out "C:\Auditorias\Produto-seguranca.json"

O catálogo local também entra automaticamente nos resultados novos de init e plan. Cada item tem condição de aplicação, objetivo, verificação e impacto de compatibilidade. Todos começam TO_ASSESS e NOT_TESTED; nenhuma ausência de achados altera esses estados. Controles que não se aplicam precisam de justificativa contextual registrada pelo responsável, sem inventar um resultado de teste.

O comando não lê o produto, não recebe URL/credenciais, não faz varredura de rede, não testa login, não consulta banco de CVEs e não aplica configurações. Serve para orientar a implementação e a coleta de evidências. Um projeto com plugin e serviço deve avaliar separadamente os perfis desses componentes.

Usar a matriz de acesso e os controles aplicáveis como hipóteses no fluxo de testes. Os resultados reais podem integrar os critérios de compat, junto dos testes funcionais. JSONs preenchidos manualmente continuam evidências declaradas, sem autenticação automática pelo toolkit.

Resultado esperado

Cada risco relevante tem responsável, medida concreta no componente apropriado, teste de negação e de uso permitido, impacto medido e retorno ensaiado. O registro distingue proteção implementada, proposta, não aplicável e não testada. Nenhum projeto em produção é declarado protegido contra invasão apenas por adotar o toolkit.

Site, pacote único e publicação

Site: https://realtoolkit.pages.dev. Repositório público: https://github.com/samirbridi/reatoolkit. Licença MIT aprovada pelo titular para o toolkit; fontes de terceiros conservam suas próprias condições.

Para quem vai utilizar

Baixar o ZIP completo no site. Extrair em uma pasta própria. Abrir LEIA-PRIMEIRO.html, que contém a documentação e o índice sem depender de um servidor. As ferramentas ficam em REAToolkit/; para executá-las, usar Node.js 22 ou superior. O arquivo CONTEXTO-PARA-IA.md reúne o direcionamento para outro projeto/assistente.

MANIFEST.json descreve os arquivos da pasta REAToolkit, ficando fora dela para permitir a verificação do conjunto completo. Exemplo na pasta externa extraída:

node REAToolkit/bin/reatoolkit.mjs verify --root REAToolkit --manifest MANIFEST.json

O hash SHA-256 do ZIP é publicado na página e em downloads/latest.json. O manifesto não está assinado por uma chave comercial de produção. Ele confere conteúdo; sozinho, não estabelece a identidade do autor. Os scripts e exemplos não são executados ao abrir o guia.

HISTORICO.bundle, quando presente, preserva os commits e tags que deram origem à distribuição. Pode ser inspecionado com Git: git bundle verify HISTORICO.bundle. É evidência de histórico, não assinatura comercial.

Para o mantenedor

1. Revisar e integrar mudanças. Preservar os commits estruturados; não editar números de versão manualmente.
2. Confirmar a árvore limpa, a configuração do site, a licença e o acesso Cloudflare.
3. Executar npm run release no checkout canônico. O processo chama a automação de versão, testes, empacotamento, site e deploy em sequência; falha interrompe a sequência.
4. Conferir o resultado do Cloudflare e validar no endereço público: página, documentação, download/hash, versão e changelog.
5. Sincronizar fontes e tags com o GitHub usando a autenticação do mantenedor; manter o histórico com os commits de origem.

npm run release:build gera o release sem publicar. npm run site:build prepara o site a partir de um release já existente e aprovado para distribuição. npm run preview serve os arquivos gerados em http://127.0.0.1:4177; não é publicação. Para desenvolvimento antes do release final, node scripts/build-site.mjs --preview usa os artefatos locais disponíveis, identificados como prévia quando ainda não públicos.

O site é estático: nenhuma chave GitHub/Cloudflare entra em HTML, JS, ZIP ou configuração pública. Tokens de CI, quando usados, ficam nos mecanismos de segredo da infraestrutura. O script de deploy não modifica outros projetos Cloudflare. O projeto atual usa Direct Upload; a publicação automática do release é feita pelo comando do mantenedor, não por toda edição ou Pull Request da comunidade.

O que atualiza junto

VERSION, version.json e CHANGELOG.md derivam dos commits. O empacotamento produz snapshot, ZIP técnico, manifesto, TAP de testes, recibo, bundle Git e ZIP completo de distribuição. O gerador do site lê os recibos para preencher versão, tamanho, hash e downloads; renderiza a documentação e o changelog; mantém os pacotes públicos anteriores disponíveis quando presentes no catálogo local.

Versões anteriores à licença/distribuição pública ficam no histórico sem download público. O site é montado em uma pasta nova e a pasta anterior é preservada em work/, evitando que arquivos de uma prévia interna permaneçam na publicação. Não copiar o diretório de trabalho inteiro para o Cloudflare.

Ao publicar a partir de outra máquina, recuperar primeiro os releases públicos anteriores do arquivo de manutenção, conferir seus recibos/hashes e colocá-los em releases/. Sem esses arquivos, o histórico textual permanece, mas o gerador não inventa links de download. O comando de release não baixa históricos de fontes não verificadas automaticamente.

Contribuições

O formulário da página prepara um título e uma descrição para uma Issue do repositório configurado. O visitante revisa e envia no GitHub, usando sua conta. O site não recebe uploads, não guarda o formulário e não envia nada enquanto o visitante apenas digita. Código deve ser proposto por Pull Request. Vulnerabilidades sensíveis seguem SECURITY.md.

Os arquivos de CI do projeto executam a suíte em contribuições, com leitura de conteúdo e sem chaves de produção. Isso depende de as fontes estarem sincronizadas e de GitHub Actions estar habilitado. A publicação continua em um processo separado e revisado. Não criar um mecanismo que publique automaticamente código de um Pull Request externo com credenciais de Cloudflare.

Enquanto a gravação no GitHub não estiver liberada, o código completo permanece disponível no ZIP e sugestões de correção podem ser registradas em Issues. A opção githubCodePublished deve ser ativada em site/config.json somente depois de verificar as fontes no repositório; ela habilita os links para código e propostas por Pull Request.

Fontes primárias: Cloudflare Direct Upload, GitHub Issues e GitHub Releases. A configuração da CLI foi verificada nesta implantação; o fluxo é identificado como Pages, preservando o endereço pages.dev.