# Speed Live — preparação local da investigação do filtro

## Estado: núcleo executor local preparado; sem instalação, conexão ou autorização concedida

Objetivo exclusivo: descobrir o contrato do botão **Aplicar filtro** em `https://speedlivem.painelr.top/users/manage`. Nenhuma pesquisa remota, alteração de credenciais, importação ou mudança da árvore foi autorizada nesta etapa.

### Evidências disponíveis

- O proprietário informa que Username = Alaer5566 retorna visualmente somente o revendedor ID 98783. Essa informação não identifica a requisição responsável pelo resultado.
- A autenticação existente usa GET `/login`, POST `/login` com `username`, `password`, `csrf`, jar efêmero e evidência JSON protegida em GET `/api/users`. Os nomes do formulário **de login** não comprovam os nomes do formulário **de filtro**.
- O código existente usa `/api/users` e `/api/users/{página}`; não comprova parâmetros de filtro nem endpoint individual.
- A página `/users/manage`, seu formulário e os scripts do filtro não estão disponíveis como evidência estrutural real neste projeto.

## Resultado técnico atual

| Questão | Resultado |
| --- | --- |
| Endpoint real do filtro | Não identificado |
| Método GET ou POST | Não identificado |
| Nome do parâmetro Username | Não identificado; o rótulo visual não comprova `name` |
| Filtro no servidor ou local | Não identificado |
| Pesquisa individual | Comportamento visual informado pelo proprietário; reprodução programática não comprovada |
| Identidade e árvore MASTER | Resultado individual não comprova vínculo; nenhuma mudança na validação existente |
| HTML no username | O filtro não comprova login puro; a resposta ainda pode conter HTML |

## Procedimento preparado para eventual confirmação posterior

1. Antes de qualquer conexão, preparar/instalar separadamente o controle específico da investigação, com finalidade própria (nome proposto: `speed_live_filter_inspection`, não instalado), ADMIN proprietário, referência/origem/preview exatos, impressão das credenciais criptografadas, prazo máximo de cinco minutos e consumo durável atômico. A trava deve impedir simultaneidade com outras finalidades e tentativas sem encerramento. Não reaproveitar grants existentes.
2. Reutilizar as credenciais AES-GCM cadastradas e o contrato de autenticação existente, sem alterar a sessão/importação atual: GET login → POST login → GET users primeira página apenas como evidência estrutural, sem sanitizar usernames nem agregar a lista.
3. Na mesma sessão privada, permitir exclusivamente GET `/users/manage`, mantendo origem fixa, redirects manuais, HTTP 200 obrigatório e interrupção sem repetição. Não buscar dashboard, lines, novas páginas ou recursos de terceiros.
4. Ler o HTML somente em memória limitada, sem persistir corpo, e analisar DOM inerte; nunca executar scripts. Identificar o formulário associado ao botão, método explícito ou padrão HTML, `action`, nomes/tipos de controles e associações. Não coletar valores, hidden values, textos de usuários ou atributos livres.
5. O núcleo mínimo detecta somente presença de scripts inline/externos e handlers; não analisa o código nem identifica endpoints JavaScript. Essa dependência retorna `script_analysis_required`; uma análise estática posterior exige extensão específica sem executar scripts. Ações observadas são dados não confiáveis, nunca autorização para uma requisição.
6. Caso dependa de script externo, registrar apenas a dependência como pendência. Uma futura leitura exige caminho estático exato identificado, mesma origem, sem query/fragmento/credenciais, limite de recursos e autorização que inclua esses GETs. Não seguir URLs automaticamente nem ler todos os scripts.
7. Distinguir contrato observado de hipótese: `action`/`method` comprovam apenas submissão HTML declarada, não o comportamento efetivo de um handler JavaScript. Um endpoint só será identificado quando houver associação inequívoca com o botão e campo; código dinâmico/ambíguo mantém o resultado desconhecido.
8. Não clicar nem enviar o filtro nesta inspeção. POST de filtro desconhecido permanece proibido: o contrato comprovado deve demonstrar leitura e receber confirmação específica antes de execução posterior. Nenhuma chamada pode ser inventada a partir de `/api/users`.
9. Encerrar a autorização e gravar somente etapa/código sanitizados. Erro de encerramento conserva o bloqueio durável, sem renovação, repetição ou desbloqueio automático.

### Limites a preservar no mecanismo futuro

- TLS nativo, origem fixa, cookies efêmeros e credenciais somente no servidor; risco residual de DNS rebinding explicitado novamente antes de execução.
- Dez segundos por requisição incluindo corpo, 45 segundos por sessão, cinco MB acumulados e nunca além da expiração original.
- Quatro requisições no máximo no escopo inicial: três da autenticação/evidência e uma da página de gerenciamento. Scripts externos não estão incluídos.
- Nenhum endpoint público ou botão de concessão; identidade ADMIN revalidada no servidor e execução manual no preview hospedado.

## Relatório sanitizado futuro

Projeção fechada: versão, horário do servidor, etapa, HTTP, tipo de resposta, existência/ambiguidade do formulário, método, caminho same-origin sem query, nomes dos controles relevantes, handler identificado, classificação `servidor`/`local`/`indeterminado`, contrato `comprovado`/`incompleto` e código de limitação.

Não retornar trechos HTML/JS, valores dos controles, CSRF, cookies, headers, URLs com valores de query, credenciais, mensagens/stack do fornecedor ou dados da lista. Nomes e caminhos também precisam ser validados, limitados e redigidos se contiverem dados pessoais ou segmentos dinâmicos. Não alegar contrato real usando fixtures fictícias.

## Pendências

Núcleo preparado em `speed-live-filter-inspection.server.ts`, DTO fechado e SQL de revisão em `speed-live-filter-inspection.sql.ts`. Não há RPC, botão, adaptador real ou migração instalada. A sessão existente não foi ampliada: um wrapper isolado reutiliza os três pedidos de autenticação e espelha cookies apenas em memória privada para o quarto GET fixo. Nenhum HTML/JS ou valor sai no relatório.

O parser reconhece declarativamente somente associação inequívoca do botão `Aplicar filtro`, rótulo `Username`, controle `name=username`, método GET/POST e caminhos estáticos `/users/manage` ou `/api/users`. Outros nomes/caminhos são redigidos como desconhecidos para impedir vazamento; não são presumidos inválidos no fornecedor. Scripts, base URL, ambiguidade e contratos desconhecidos impedem comprovação. Mesmo um formulário reconhecido não comprova filtro remoto, username exato, resposta filtrada ou árvore MASTER.

### Autorização exata necessária antes da inspeção

Após autorização separada para instalar o SQL preparado e ligar uma chamada manual ADMIN no preview privado:

- Uma autorização privilegiada com finalidade `speed_live_filter_inspection`, versão `speed-live-filter-inspection@2026-10-21.prepare-v1`, proprietário ADMIN autenticado, servidor `painelfoda-reference`, origem `https://speedlivem.painelr.top` e preview `https://id-preview--c65ba1a8-a777-44c6-a277-b5b4bfc21f87.lovable.app`.
- Impressão SHA-256 do ciphertext AES-GCM atual, referência da aprovação explícita, validade máxima cinco minutos; sem concessão por navegador ou renovação automática.
- Permissão exclusiva para **GET /login → POST /login → GET /api/users primeira página → GET /users/manage**, máximo quatro pedidos. Sem executar filtro, scripts externos, dashboard, outras páginas ou `/api/lines`.
- Aceitação explícita do risco residual DNS rebinding: origem fixa, HTTPS/TLS e redirects bloqueados são preservados, mas `fetch` nativo não fixa DNS ao IP efetivamente conectado. O transporte universal permanece bloqueado.
- Consumo durável antes da rede, encerramento/auditoria atômicos; falha de encerramento mantém o bloqueio. Aprovação não autoriza cadastro ou filtro posterior.

O SQL preparado inclui correção indispensável de isolamento de finalidade nas rotinas nativas antigas; sem isso uma autorização de inspeção poderia ser selecionada pelo teste antigo. Isso **não foi aplicado**. Antes de instalar, conferir esquema/ACLs atuais e exclusão recíproca nas rotinas de sondagem existentes; testes isolados não comprovam o estado hospedado.

Busca individual e cadastro não implementados: dependem de contrato remoto, correspondência exata e prova independente da árvore MASTER. Nenhuma cobrança automática.

Alternativa sem conexão pelo GESTOR: o proprietário pode fornecer um resumo sanitizado da requisição já observada ao aplicar o filtro (caminho, método, nomes dos parâmetros sem valores, tipo/estrutura da resposta). Não enviar HAR, HTML completo, headers, cookies ou tokens. Isso pode eliminar a necessidade da inspeção autenticada.

Testes mínimos desta preparação usam somente respostas fictícias e PGlite isolado; não comprovam o contrato real. Nenhuma conexão real, concessão, alteração de banco/credenciais/árvore, uso de VPS, alteração FLOW/DNS CONTROL ou publicação.