getxuui/present

Apresentar no xuui

Transforme o trabalho na conversa atual em um estudo xuui executável e revisável. A entrega é uma URL local verificada, uma breve explicação da questão de design e as diferenças que valem a pena revisar. Após a entrega, continue ouvindo a revisão da pessoa.

Permaneça no xuui

xuui é a superfície de apresentação para este trabalho. Uma vez que um design está no xuui, continue apresentando-o lá.

• Quando outra skill ou fluxo de trabalho também estiver em jogo, use seu método para escolher direções, mas construa as direções como variantes xuui. Nunca construa seu seletor, um alternador dentro da aplicação ou uma página de pré-visualização separada.
• "Mostre na página inteira", "no site" ou "no contexto" significa um estudo xuui maior: renderize a página ou layout ao redor do design, com as mesmas variantes.
• Altere a aplicação real apenas quando a pessoa pedir para implementar ou enviar uma direção. Mantenha o estudo, para que a escolha permaneça revisável.

Resolver o que apresentar

Use a interface solicitada, referência ou trabalho recente como briefing. Apresente uma implementação existente fielmente. Quando o briefing pedir alternativas, faça suas diferenças responderem à questão de design; escolha o número a partir do briefing e as comparações úteis. Pergunte apenas quando a conversa e o workspace deixarem o assunto pouco claro.

Encontre o workspace de estudo a partir do projeto atual: um workspace instalado tem xuui.studies.ts e uma dependência local xuui. Leia o README dessa versão, docs/authoring.md e os tipos exportados, além de um registro próximo. Use o CLI instalado em vez de baixar uma alpha mais recente em um workspace existente. Um checkout do código-fonte xuui, por sua vez, usa examples/studies.ts, src/xuui/model.ts e src/xuui/parameters.ts; leia CONTEXT.md lá. Não infira o workspace consumidor subindo a partir de uma skill instalada.

A alpha apresenta componentes React registrados em um workspace independente. Se um novo workspace for necessário, execute npx --package @getxuui/[email protected] xuui init <diretório>, depois use sua instalação fixada. Para trabalho de outra base de código, inspecione seus tokens, interface vizinha, restrições responsivas, provedores e dados. Adapte o componente relevante e as dependências necessárias sem redesenhar silenciosamente. Inclua um wrapper de contexto quando o isolamento distorcer a revisão, e divulgue dados simulados ou comportamento de backend indisponível.

Enquadrar uma exploração

Quando alternativas forem solicitadas, declare a questão de design, nomeie a variável primária e diga o que permanece constante. Planeje direções que respondam a essa questão. Comece-as com conteúdo correspondente, estado significativo, largura de viewport e escala. Não gere alternativas para uma solicitação de apresentar fielmente um design existente. Deixe o briefing e as comparações úteis determinarem o número.

Registrar o estudo

Coloque o design e seu adaptador ao lado do registro do estudo, seguindo os estudos existentes. Adicione o estudo ao registro central, ou estenda o estudo existente relevante quando o trabalho explorar a mesma questão.

• Use os termos do produto estudo, variante, tela, camada e guia. Registre um estudo com defineStudy e liste suas variants.
• Dê a cada variante um ID estável e descritivo, único em todos os estudos registrados. Adicione um novo ID ao avançar uma direção que deve permanecer revisável. Preserve a implementação anterior; compartilhar um componente mutável não congela seu histórico.
• Escreva um nome, descrição e justificativa úteis para cada variante.
• Registre componentes React comuns. xuui fornece navegação, panorâmica, zoom, inspeção, comparação e comentários; o estudo fornece o design e os provedores ou dados de que necessita.
• Escolha o CSS do estudo para que não possa reestilizar o chrome do estúdio ou variantes não relacionadas. Dê ao design dimensões significativas; uma largura percentual sem um bloco contentor dimensionado pode colapsar na tela.
• Adicione data-xuui-layer-name onde o DOM sozinho dá um nome de camada inútil.

Expor estados e controles

A barra lateral mostra os controles que uma variante declara, e o revisor comenta sobre o que é renderizado. Escolha o tipo de controle que corresponde ao design:

• machine para os estados distintos do design e os eventos que transitam entre eles: vazio, carregando, carregado e erro; fechado e aberto; as etapas de um formulário ou fluxo. O revisor pode pular para qualquer estado pela barra lateral e seguir as transições no modo Play, para que cada estado possa ser julgado e comentado. Nomeie estados e eventos como o produto faz. Renderize a partir de machine.value e conecte as interações reais do design a machine.send(event), para que clicar no modo Play siga a mesma máquina.
• state para valores independentes aos quais o design reage, como um alternador de favorito ou uma contagem de itens.
• props para parâmetros de design que valem a pena comparar, como texto, raio ou largura.

Quando o design tiver estados significativos além do caminho feliz, exponha-os com uma máquina em vez de apresentar um estado. Não invente estados que o design não tem. Exponha apenas controles que alteram o design renderizado e verifique se cada estado renderiza. Consulte o docs/authoring.md instalado para a forma exata.

Mantenha as alterações no estudo solicitado e no registro necessário para apresentá-lo. Uma solicitação de apresentação não autoriza redesenhar o próprio estúdio.

Pronto significa que o design solicitado renderiza a partir de uma variante registrada e seus controles expostos funcionam.

Executar e verificar

Em um workspace instalado, use npx --no-install xuui dev; em um checkout de código-fonte, use seus scripts de pacote. Verifique se há uma pré-visualização existente primeiro e reutilize-a quando ela servir ao workspace pretendido. Deixe processos não relacionados em paz. Mantenha o servidor local em execução para o revisor e use a origem impressa real.

Abra uma URL usando a origem real do servidor e os IDs registrados:

• Variante focada: /?study=<id-do-estudo>&variant=<id-da-variante>
• Comparação: a mesma URL com &view=all

Verifique a identidade da variante renderizada, em vez de tratar um HTTP 200 como prova: IDs desconhecidos recaem em um estudo existente. Inspecione a interface, exercite interações importantes no modo Play e teste cada controle exposto. Aplique o mesmo piso de usabilidade a cada direção: acesso por teclado, foco visível de controle inteiro, texto legível, movimento reduzido apropriado e conteúdo, estados e larguras realistas. Execute verificações relevantes do projeto e relate falhas ou verificações indisponíveis com precisão.

Use armazenamento de teste isolado para verificações de submissão. Deixe os rascunhos de comentários reais do revisor e os registros submetidos intactos.

Pronto significa que o link abre o design pretendido, interações significativas funcionam e o limite da revisão está claro.

Entregar

Retorne o link focado, mais um link de comparação quando útil. Explique o que julgar em algumas frases e nomeie limitações materiais, como dados simulados. O revisor usa Play para interações, C para comentários e Submit review para a entrega. Termine dizendo que está ouvindo a revisão e que podem continuar conversando enquanto isso.

Para alternativas, adicione uma pequena tabela do que mudou, quando cada direção se encaixa e seu custo principal. Informe a largura e o estado revisados. Não escolha silenciosamente um vencedor. Quando solicitado a avançar uma escolha, verifique o design promovido em seu contexto de origem e retenha seu estudo revisável; preserve implementações antigas e adicione IDs estáveis para trabalhos comparáveis futuros.

Ouvir feedback

Após a entrega, aguarde a revisão sem ser perguntado.

• Se as ferramentas MCP do xuui estiverem disponíveis, chame xuui_wait_for_review com o studyId do estudo. Cada chamada retorna em até 50 segundos. Chame novamente com os knownReviewIds retornados até que uma revisão chegue ou a pessoa peça para parar.
• Se não estiverem disponíveis, o servidor MCP do workspace não está conectado. Ofereça-se para conectá-lo, seguindo o docs/mcp.md instalado, e diga se o host precisa de reinicialização para carregá-lo. Até lá, se seu host puder executar um comando em segundo plano que o notifique quando terminar, use um para aguardar um novo arquivo em .xuui/reviews/. Caso contrário, peça à pessoa que lhe avise quando enviar.

Quando uma revisão chegar, leia o pacote completo e, em seguida, confirme com xuui_acknowledge_review. Um recibo significa que você leu, não que seus pedidos estão concluídos. Rascunhos do navegador não são feedback submetido. Aja sobre os comentários: faça alterações como novas variantes com novos IDs, verifique-as, entregue os novos links e ouça novamente.