# Live view do wireframe — companion v1

Este arquivo migrou da `lumo-scope` para a `lumo-mockup` — mora aqui junto do
`wireframe-kit.md`, mas continua sendo acionado durante o processo da
`lumo-scope` (Fase 3 da entrevista, ver `lumo-scope/SKILL.md`). `wireframe-kit.md`
continua sendo a fonte da verdade do HTML — ficha, ícones e regras de
integridade moram lá; o render (Vega-Lite, tema Horus) é dele. Este companion
só serve o arquivo mais recente num navegador local, com live-reload e dois
botões — não introduz vocabulário visual novo, não relaxa nenhuma regra de
integridade do kit.

## Quando oferecer

Só uma vez por rodada: **no início da Fase 3**, antes de desenhar o primeiro
wireframe. Nunca nas Fases 0/1/2. A oferta vai numa mensagem própria, nunca
misturada com uma pergunta de conteúdo. Texto exato:

> "Essa parte fica mais fácil se eu te mostrar ao vivo — abro uma prévia do
> wireframe no seu navegador e você acompanha enquanto eu ajusto ficha por
> ficha, com um botão de aprovar/pedir ajuste. Quer que eu ative? (o documento
> final continua sendo o HTML estático de sempre, isso só evita o vai-e-volta
> de reabrir arquivo)"

Se o analista recusar: **nunca reoferecer** nessa rodada, nem em dashboards
seguintes da mesma sessão. Segue no fluxo atual (arquivo estático, sem
regressão).

## Como usar

`$SKILL_DIR` abaixo é o diretório **absoluto** desta skill na máquina em uso —
aquele de onde você leu este arquivo (`~/.claude/skills/lumo-mockup`,
`~/.agents/skills/lumo-mockup`, `%USERPROFILE%\.claude\skills\lumo-mockup`…).
Caminho de repositório (`llms/…`) não existe fora do repo. O script resolve o
próprio diretório internamente, então basta invocá-lo pelo caminho certo:

```bash
bash "$SKILL_DIR/scripts/wireframe-server.sh" start [<dir-de-wireframes>]
# default do dir: ./escopo/wireframes — imprime a URL (http://127.0.0.1:<porta>/)
bash "$SKILL_DIR/scripts/wireframe-server.sh" stop
```

1. Se aceito, rode `start`, compartilhe a URL impressa e continue escrevendo
   os `.html` normalmente em `escopo/wireframes/<dash>.html` (mesmo processo
   de `wireframe-kit.md`) — o servidor sempre serve o mais recente por mtime.
2. O navegador recarrega sozinho (polling em `/mtime`, ~1.5s) a cada novo
   arquivo escrito. Nada a pedir ao analista.
3. Aprovação continua **por dashboard**, nunca em bloco — os botões só
   registram o gesto; a decisão de "próximo dashboard" ainda é do agente.
4. No **próximo turno**, leia `escopo/eventos-wireframe.jsonl` (uma linha
   JSON por clique: `{ts, file, action: aprovar|ajustar, comment}`) para
   saber se o dashboard foi aprovado ou se veio um pedido de ajuste — trate
   como confirmação/feedback equivalente a um "é isso?" respondido em texto.
5. Ao fechar a Fase 3 (ou se o analista pedir), rode `stop`.

## O que não muda

- Artefato final = o `.html` estático de `wireframe-kit.md`, sem alteração.
- Regras de integridade (banner de dados ilustrativos, ≤9 widgets, sem pizza
  sólida, KPI com o placeholder da escala escolhida, gráfico sem escala numérica
  no eixo etc.)
  continuam vindo só do kit — o companion não adiciona nada ao conteúdo, só
  à forma de visualizar.
- Sem WebSocket, sem auth, bind só em `127.0.0.1` — decisão deliberada: sessão
  curta (uma reunião), ambiente do próprio analista, sem múltiplos tópicos
  sensíveis acumulados.

## Fallback

`node` indisponível **de verdade** (confira nos gerenciadores de versão antes de
concluir isso, ver `pipeline.md` §2 — `which node` falha sob nvm mesmo com Node
instalado), ou o analista recusa a oferta: siga o fluxo atual sem
servidor — gerar o `.html`, pedir aprovação em texto por dashboard. Nenhuma
etapa da Fase 3 depende do companion para funcionar.
