1
✅ done(path) — entrega final + fix de console errors
Citação literal
"Quando terminar, chame done com o caminho do arquivo HTML. Isso abre o arquivo na barra de abas do usuário e retorna quaisquer erros de console. Se houver erros, corrija e chame done novamente — o usuário deve sempre terminar em uma visualização que não quebre."
Fluxo completo
- Claude termina design
- Chama
done("Landing Page.html") - Sistema abre preview na aba do usuário + retorna erros de console (se houver)
- Se erros: Claude lê → corrige →
done()de novo → repete até clean - Se clean: Claude chama
fork_verifier_agent()em background - Encerra turno (não espera verificador)
show_to_user — alternativa para previews intermediárias
"IMPORTANTE: Ler um arquivo NÃO o mostra ao usuário. Para prévias durante a tarefa ou arquivos que não sejam HTML, use show_to_user — funciona para qualquer tipo de arquivo (HTML, imagens, texto etc.) e abre o arquivo no painel de prévia do usuário. Para a entrega final de HTML ao fim do turno, use done — ele faz o mesmo e ainda retorna erros de console."
show_to_user(path)
- • Preview intermediário
- • Qualquer tipo de arquivo (HTML, PNG, JPG, .md, .json)
- • NÃO retorna erros de console
- • Use durante iteração
done(path)
- • Entrega final do turno
- • Apenas HTML
- • Retorna erros de console (Claude precisa fix)
- • Trigger automático para fork_verifier_agent
2
🔒 fork_verifier_agent — modo silencioso (após done clean)
Citação literal
"Quando done informar que está limpo, chame fork_verifier_agent. Isso cria um subagente em segundo plano com seu próprio iframe para fazer verificações completas (screenshots, layout, sondagem JS). Em caso de sucesso, ele fica silencioso — só interrompe se algo estiver errado. Não espere por ele; encerre seu turno."
O que o subagente faz no iframe próprio
- •Screenshots em múltiplos viewports (desktop 1440, tablet 768, mobile 375)
- •Layout probe — overflow horizontal, elementos sobrepostos, alignment quebrado, contraste de cor
- •Sondagem JS — console errors, promises rejeitadas, event handlers quebrados
- •data-om-validate — atributos colocados pelo deck_stage para sinalizar pontos de validação
Princípio: contexto isolado = "olhos frescos"
Mesmo conceito do Claude Code: nunca deixar o modelo revisar o próprio trabalho no mesmo contexto. O subagente nasce com contexto vazio, vê o output como se fosse a primeira vez. Por isso pega bugs que o Claude principal não veria.
3
🎯 fork_verifier_agent({task}) — verificação direcionada
Citação literal
"Se o usuário pedir que você verifique algo específico no meio da tarefa ('tire screenshot e confira o espaçamento'), chame fork_verifier_agent({task: '...'}). O verificador vai focar nisso e retornar independentemente. Você não precisa de done para verificações direcionadas — só para a entrega final ao fim do turno."
Exemplos de tasks direcionadas
// Layout/spacing
fork_verifier_agent({
task: "Check spacing consistency between the 3 cards
in mobile viewport (375px). They should use 16px gap."
})
// Acessibilidade
fork_verifier_agent({
task: "Verify color contrast WCAG AA on all text elements,
especially the muted neutral-400 on bg-dark-800."
})
// Funcionalidade
fork_verifier_agent({
task: "Click the CTA button and confirm modal opens.
Then check if Esc closes it."
})
// Visual fidelity
fork_verifier_agent({
task: "Take screenshots in 1440 / 768 / 375 viewports,
compare hero alignment across all three."
})Verificador retorna independentemente. Não polui contexto principal.
4
🚫 NÃO faça self-check (regra explícita)
Citação literal
"Não faça sua própria verificação antes de chamar done; não capture screenshots proativamente para revisar seu trabalho; conte com o verificador para detectar problemas sem poluir seu contexto."
Por que essa regra existe
- •Self-check polui contexto com screenshots e probe results que NÃO importam pro usuário
- •Modelo no mesmo contexto sofre de viés cognitivo — vê o que quis fazer, não o que fez
- •Role separation clean: Claude principal CRIA. Subagente CHECA.
Quando self-check é OK
Quando você pede explicitamente. "Take a screenshot of the current state and tell me what you see" — Claude faz, mas conta como request seu, não auto-iniciativa.
5
🏷️ mentioned-element blocks — como Claude sabe qual elemento
Citação literal
"Quando o usuário comenta, edita inline ou arrasta um elemento na prévia, o anexo inclui um bloco <mentioned-element> — algumas linhas curtas descrevendo o nó vivo do DOM que ele tocou. Use isso para inferir qual elemento do código-fonte editar."
Anatomia do bloco
<mentioned-element>
react: HeroSection > Headline > Emphasis
dom: body > main > section[data-screen-label="01 Hero"] > h1 > span[data-cc-id="cc-7"]
id: cc-7
</mentioned-element>- •
react:cadeia de componentes React do mais externo para o mais interno (vem do dev mode fibers) - •
dom:ancestralidade DOM completa, com data-attrs visíveis - •
id:identificador transitório no nó vivo
Os 2 atributos transitórios (importantes)
| Atributo | Quando aparece | Forma |
|---|---|---|
data-cc-id | Modo Comments / Knobs / Text edit | cc-N (N = número sequencial) |
data-dm-ref | Modo Design | N (apenas número) |
⚠️ "Isso NÃO está no seu código-fonte — é um identificador em tempo de execução." Claude não pode usar data-cc-id como seletor permanente — usa para localizar e depois edita pela posição/identificador real do código.
eval_js_user_view — desambiguação cirúrgica
"Quando o bloco sozinho não for suficiente para localizar a origem no código, use eval_js_user_view na prévia do usuário para desambiguar antes de editar. Chutar e editar é pior do que uma sondagem rápida."
Tool que executa JS arbitrário no preview do usuário. Útil quando o bloco mentioned-element é genérico demais. Você pode pedir: "Use eval_js_user_view to inspect the parent of cc-7 before editing".
6
🔄 Workflow integrado: criar → comentar → editar → done → verificar
Ciclo completo
- Claude cria — write_file com asset, pasta organizada
- show_to_user(path) — preview intermediário sem fechar tarefa
- Você comenta no canvas → mentioned-element block enviado
- Claude lê o bloco (react+dom+id) → localiza fonte
- Se ambíguo → eval_js_user_view para desambiguar
- Claude edita (não o data-cc-id, mas o código-fonte real)
- show_to_user de novo (intermediário)
- Repete 3-7 até estar bom
- done(path) ao final
- Console clean? → fork_verifier_agent silencioso
- Console errors? → fix → done() → repete
- Resumir EXTREMAMENTE BREVE — caveats e próximos passos só
💡 Hack: forçar verificação cirúrgica antes de done
No meio da iteração, peça "check accessibility before we finalize". Claude invoca fork_verifier_agent({task: "WCAG AA audit"}), recebe report estruturado, e aplica correções ANTES do done final. Resultado: produção-ready.
✅ Resumo do Módulo
✓
done(path) — entrega final, retorna console errors. Fix → done de novo.
✓
show_to_user vs done — preview intermediário (qualquer formato) vs entrega final (HTML + console errors).
✓
fork_verifier_agent silencioso — após done clean. Iframe próprio, screenshots, layout, JS, data-om-validate.
✓
fork_verifier_agent({task}) — verificação direcionada mid-task. Não precisa done.
✓
NUNCA self-check — regra do system prompt. Confie no verificador.
✓
mentioned-element blocks — react: + dom: + id: localizam fonte. data-cc-id (Comments) vs data-dm-ref (Design).
✓
eval_js_user_view — desambigua quando o bloco é vago. Sondagem > chute.
Próximo Módulo:
3.4 — ⚡ window.claude.complete (Haiku 4.5 + 1024 tokens) + snip + context management