Módulo 2.4 — Páginas longas, inputs React & multi-estado

1

📜 Scroll antes do screenshot roadmap

Páginas longas exigem scrollIntoView na seção antes de capturar. Hoje, feito na mão.

O problema

O capture.mjs não rola a página. Nas telas do inemaVOX, foi preciso dirigir o agent-browser na mão, fazendo scrollIntoView por seção antes de cada screenshot.

📊 A solução planejada (backlog nº 1)

Ação scroll / scrollTo

Adicionar ao capture.mjs uma ação de scroll por passo.

scrollIntoView({block})

Rolar até o alvo antes do screenshot. As bboxes (viewport-relative) batem com o shot daquele scroll.

💡

É o item que mais economiza trabalho manual

Por isso é a prioridade nº 1 do backlog. Enquanto não chega, rolar na mão antes de medir/capturar funciona — só dá mais trabalho.

2

⚛️ Inputs controlados por React/Vue parcial

Setar .value mostra o texto mas não dispara o estado — botões ficam disabled.

✗ Não faça

✗ el.value = "768" via eval puro
✗ O React não percebe → botão segue disabled
✗ O screenshot sai com o controle inativo

✓ Faça

✓ setValue dispara input+change
✓ Ideal (roadmap): fill nativo do Playwright
✓ Conferir que o botão habilitou no shot

setValue dispara os eventos (trecho do capture.mjs)

el.value = "768";

el.dispatchEvent(new Event('input',{bubbles:true}));

el.dispatchEvent(new Event('change',{bubbles:true}));

💡

Backlog nº 2: usar o fill nativo

O ideal é o capture.mjs chamar agent-browser fill @ref (fill nativo do Playwright) em vez de setar .value — simula digitação real e dispara o estado de forma confiável.

3

⏱️ Esperar CONDIÇÃO, não tempo fixo roadmap

Hoje o capture usa wait (ms). O ideal é um waitFor de texto/seletor.

Abordagem	wait (ms) — hoje	waitFor — roadmap
Critério	tempo fixo	condição real
Geração lenta	chuta a folga	espera o <img>
Risco	cedo demais / lento	sai na hora certa

💡

Geração demorada: poll por um <img> real

O flux2-klein levou ~2,5 min no POC. Antes do screenshot do resultado, faça poll por um <img> de fato carregado no painel — não confie só no relógio. Trocar wait por waitFor é o backlog nº 3.

4

🔄 Fluxos assíncronos multi-estado feito na mão

Analisar → aprovar → dublar → concluído: capturados como sub-passos nomeados, com poll de conclusão.

O pipeline do inemaVOX

1

Analisar

Dispara o processamento; o status muda. Captura o estado "analisando".

2

Aprovar (waiting_approval)

O fluxo para até a aprovação. Captura o estado de espera e a ação de aprovar.

3

Dublar

Processo longo; poll de conclusão entre as capturas.

4

Concluído

Resultado final, com zoom. Encerra o walkthrough antes da CTA.

⚠️

O poll foi script à mão

No POC, o poll de conclusão (poll-job*.sh) foi feito fora do capture.mjs. Embuti-lo como sub-passos nomeados com poll é o backlog nº 4.

5

⏸️ Estados como waiting_approval

Estados disparados por evento (não por tempo) precisam de um poll de status — não de um wait fixo.

Por que tempo fixo não resolve

Um waiting_approval muda quando alguém aprova — não quando o relógio bate. Esperar X ms pode capturar antes da hora (ou tarde demais).

Poll de status (conceito)

// repetir até o status sair de "waiting_approval"

while (status === "waiting_approval") {

status = readStatus(); // eval no DOM / API

sleep(2000);

} // → então captura o próximo estado

💡

É o que liga este tópico ao waitFor

O waiting_approval é o caso de uso que justifica o waitFor do tópico 3: esperar uma condição (status mudou) em vez de um tempo.

6

⚠️ Armadilhas de captura

Os erros que mais custam tempo — aplique antes de renderizar. Detalhe em gotchas.md.

✗ Armadilhas de captura

✗ Viewport inconsistente → cursor erra o alvo
✗ Refs @eN deslocam após mudança de DOM
✗ eval --json aninhado: data URL em data.result
✗ Screenshot estourando os limites do canvas

✓ Correções

✓ Mesmo viewport para bbox e shot; recapturar tudo
✓ CSS selectors / {tag,text} + re-snapshot
✓ Ler data.result; decodificar base64 se salvar
✓ Viewport 1280×800 → print x320..1600, y148..948

💡

Salvar o resultado gerado

Se o app gera um arquivo (ex.: imagem), pegue o src (data: URL) via eval — que vem em data.result — e decodifique base64 para PNG, ou clique no botão de download.

7

🗺️ O que já funciona vs o que é roadmap

A fronteira honesta da skill: o que o capture.mjs faz hoje e o que ainda exige a mão.

✓ Funciona hoje (v1)

✓ actions.json: fill, click, clickText, setValue, wait
✓ Bboxes via getBoundingClientRect → steps.json
✓ 1 shot por estado + moldura + cursor + zoom + CTA
✓ Páginas longas e multi-estado, dirigindo na mão

⏳ Roadmap / backlog

1. Scroll/scrollIntoView no capture.mjs
2. fill nativo do Playwright para inputs React
3. waitFor (condição) em vez de wait fixo
4. Poll multi-estado embutido · 5. 9:16 · 6. v3 gravação

⚠️

Limites conhecidos (seja honesto com o usuário)

Estado dinâmico vira print estático (movimento real seria v3, gravar a tela). App com login precisa de credenciais de teste. O formato natural é 16:9 — 9:16 exigiria reenquadre.

🎯 Resumo do módulo

✓ Páginas longas: scrollIntoView na mão hoje (scroll = backlog nº 1)
✓ Inputs React: use setValue (dispara input/change); fill nativo é nº 2
✓ Esperar condição (waitFor) > tempo fixo; poll por <img> real (nº 3)
✓ Multi-estado (analisar→aprovar→dublar→concluído) com poll (nº 4)
✓ Aplique os gotchas antes de renderizar; marque sempre o que é roadmap

Continua na Trilha 3

T3

🎬 Composição & Render

Com o steps.json em mãos, a T3 monta o vídeo: moldura, cursor, zoom, narração Kokoro e o render HyperFrames até o MP4.

Ir para a Trilha 3 →

← Módulo 2.3 Trilha 3: Composição & Render →