getxuui/present

Presentar en xuui

Convierte el trabajo de la conversación actual en un estudio xuui ejecutable y revisable. La entrega es una URL local verificada, una breve explicación de la pregunta de diseño y las diferencias que vale la pena revisar. Después de la entrega, sigue escuchando la revisión de la persona.

Mantente en xuui

xuui es la superficie de presentación para este trabajo. Una vez que un diseño está en xuui, sigue presentándolo allí.

• Cuando otra habilidad o flujo de trabajo también esté en juego, usa su método para elegir direcciones, pero construye las direcciones como variantes de xuui. Nunca construyas su selector, un conmutador dentro de la aplicación o una página de vista previa separada.
• "Muéstralo en la página completa", "en el sitio" o "en contexto" significa un estudio xuui más grande: renderiza la página o el diseño circundante alrededor del diseño, con las mismas variantes.
• Cambia la aplicación real solo cuando la persona pida implementar o enviar una dirección. Mantén el estudio para que la elección siga siendo revisable.

Resuelve qué presentar

Usa la interfaz solicitada, referencia o trabajo reciente como resumen. Presenta una implementación existente fielmente. Cuando el resumen pida alternativas, haz que sus diferencias respondan a la pregunta de diseño; elige el número del resumen y las comparaciones útiles. Pregunta solo cuando la conversación y el espacio de trabajo dejen el tema poco claro.

Encuentra el espacio de trabajo del estudio a partir del proyecto actual: un espacio de trabajo instalado tiene xuui.studies.ts y una dependencia xuui local. Lee el README de esa versión, docs/authoring.md y los tipos exportados, además de un registro cercano. Usa el CLI instalado en lugar de descargar un alpha más reciente en un espacio de trabajo existente. Un checkout de la fuente xuui en su lugar usa examples/studies.ts, src/xuui/model.ts y src/xuui/parameters.ts; lee CONTEXT.md allí. No infieras el espacio de trabajo consumidor subiendo desde un skill instalado.

El alpha presenta componentes React registrados en un espacio de trabajo independiente. Si se necesita un nuevo espacio de trabajo, ejecuta npx --package @getxuui/[email protected] xuui init <directorio>, luego usa su instalación fija. Para trabajo de otro código base, inspecciona sus tokens, interfaz vecina, restricciones responsivas, proveedores y datos. Adapta el componente relevante y las dependencias necesarias sin rediseñarlo silenciosamente. Incluye un envoltorio de contexto cuando el aislamiento distorsionaría la revisión, y divulga datos simulados o comportamiento de backend no disponible.

Enmarca una exploración

Cuando se soliciten alternativas, indica la pregunta de diseño, nombra la variable principal y di qué se mantiene constante. Planea direcciones que respondan a esa pregunta. Inícialas con contenido coincidente, estado significativo, ancho de ventana gráfica y escala. No generes alternativas para una solicitud de presentar un diseño existente fielmente. Deja que el resumen y las comparaciones útiles determinen el número.

Registra el estudio

Coloca el diseño y su adaptador junto al registro del estudio, siguiendo los estudios existentes. Añade el estudio al registro central, o extiende el estudio existente relevante cuando el trabajo explore la misma pregunta.

• Usa los términos del producto estudio, variante, lienzo, capa y guía. Registra un estudio con defineStudy y lista sus variants.
• Dale a cada variante un ID estable y descriptivo único entre todos los estudios registrados. Añade un nuevo ID cuando avances una dirección que deba permanecer revisable. Conserva la implementación anterior; compartir un componente mutable no congela su historial.
• Escribe un nombre, descripción y justificación útiles para cada variante.
• Registra componentes React ordinarios. xuui proporciona navegación, desplazamiento, zoom, inspección, comparación y comentarios; el estudio proporciona el diseño y los proveedores o datos que necesita.
• Limita el CSS del estudio para que no pueda reestilizar el chrome del estudio ni variantes no relacionadas. Dale al diseño dimensiones significativas; un ancho porcentual sin un bloque contenedor dimensionado puede colapsar en el lienzo.
• Añade data-xuui-layer-name donde el DOM por sí solo dé un nombre de capa poco útil.

Expone estados y controles

La barra lateral muestra los controles que declara una variante, y el revisor comenta sobre lo que se renderiza. Elige el tipo de control que coincida con el diseño:

• machine para los estados distintos del diseño y los eventos que se mueven entre ellos: vacío, cargando, cargado y error; cerrado y abierto; los pasos de un formulario o flujo. El revisor puede saltar a cualquier estado desde la barra lateral y seguir las transiciones en modo Reproducción, para que cada estado pueda ser juzgado y comentado. Nombra estados y eventos como lo hace el producto. Renderiza desde machine.value y conecta las interacciones reales del diseño a machine.send(event), de modo que hacer clic en modo Reproducción siga la misma máquina.
• state para valores independientes a los que el diseño reacciona, como un toggle de favorito o un conteo de elementos.
• props para parámetros de diseño que vale la pena comparar, como texto, radio o ancho.

Cuando el diseño tenga estados significativos más allá del camino feliz, exponlos con una máquina en lugar de presentar un solo estado. No inventes estados que el diseño no tenga. Expón solo controles que cambien el diseño renderizado y verifica que cada estado se renderice. Consulta el docs/authoring.md instalado para conocer la forma exacta.

Mantén los cambios limitados al estudio solicitado y al registro necesario para presentarlo. Una solicitud de presentación no autoriza rediseñar el estudio en sí mismo.

Hecho significa que el diseño solicitado se renderiza a partir de una variante registrada y sus controles expuestos funcionan.

Ejecuta y verifica

En un espacio de trabajo instalado, usa npx --no-install xuui dev; en un checkout de la fuente, usa sus scripts de paquete. Verifica primero si hay una vista previa existente y reutilízala cuando sirva al espacio de trabajo previsto. Deja los procesos no relacionados en paz. Mantén el servidor local en ejecución para el revisor y usa el origen impreso real.

Abre una URL usando el origen real del servidor y los IDs registrados:

• Variante enfocada: /?study=<id-estudio>&variant=<id-variante>
• Comparación: la misma URL con &view=all

Verifica la identidad de la variante renderizada, en lugar de tratar un HTTP 200 como prueba: los IDs desconocidos recurren a un estudio existente. Inspecciona la interfaz, ejercita interacciones importantes en modo Reproducción y prueba cada control expuesto. Aplica el mismo piso de usabilidad a cada dirección: acceso por teclado, foco visible de control completo, texto legible, movimiento reducido apropiado y contenido, estados y anchos realistas. Ejecuta las comprobaciones relevantes del proyecto e informa fallos o comprobaciones no disponibles con precisión.

Usa almacenamiento de prueba aislado para las comprobaciones de envío. Deja los comentarios borrador reales del revisor y los registros enviados intactos.

Hecho significa que el enlace abre el diseño previsto, las interacciones significativas funcionan y el límite de revisión está claro.

Entrega

Devuelve el enlace enfocado, más un enlace de comparación cuando sea útil. Explica qué juzgar en unas pocas frases y nombra limitaciones materiales como datos simulados. El revisor usa Reproducción para interacciones, C para comentarios y Enviar revisión para la entrega. Termina diciendo que estás escuchando su revisión y que pueden seguir charlando mientras tanto.

Para alternativas, añade una tabla breve de lo que cambió, cuándo encaja cada dirección y su costo principal. Indica el ancho y estado revisados. No elijas silenciosamente un ganador. Cuando te pidan avanzar una elección, verifica el diseño promovido en su contexto de origen y conserva su estudio revisable; preserva las implementaciones antiguas y añade IDs estables para más trabajo comparable.

Escucha retroalimentación

Después de la entrega, espera la revisión sin que te lo pidan.

• Si las herramientas MCP de xuui están disponibles, llama a xuui_wait_for_review con el studyId del estudio. Cada llamada devuelve en 50 segundos. Vuelve a llamarla con los knownReviewIds devueltos hasta que llegue una revisión o la persona te pida que pares.
• Si no están disponibles, el servidor MCP del espacio de trabajo no está conectado. Ofrece conectarlo, siguiendo el docs/mcp.md instalado, y di si el anfitrión necesita un reinicio para cargarlo. Hasta entonces, si tu anfitrión puede ejecutar un comando en segundo plano que te notifique cuando termine, úsalo para esperar un nuevo archivo en .xuui/reviews/. De lo contrario, pide a la persona que te diga cuando haya enviado.

Cuando llegue una revisión, lee el paquete completo, luego acúsala con xuui_acknowledge_review. Un recibo significa que la has leído, no que sus solicitudes estén hechas. Los borradores del navegador no son retroalimentación enviada. Actúa sobre los comentarios: haz cambios como nuevas variantes con nuevos IDs, verifícalos, entrega los nuevos enlaces y vuelve a escuchar.