Design Harness

¿Qué hace Design Harness?

Ejecuta un flujo de trabajo de interfaz web reanudable. Mantén al usuario en control de la intención y mantén la producción de diseño separada de la revisión.

Inicio y reanudación

Resuelve <skill-dir> como el directorio que contiene este SKILL.md; no asumas que el directorio de trabajo actual contiene los scripts empaquetados.

1. Ejecuta node <skill-dir>/scripts/preflight.mjs --root <proyecto> antes de hacer preguntas. Lee su informe de capacidades; no instales nada. Trata una ruta de sistema de archivos faltante como un consejo: verifica el inventario de habilidades/plugins cargados del host antes de declarar que Impeccable o Jakub no están disponibles.
2. Ejecuta node <skill-dir>/scripts/state.mjs init --root <proyecto>. Esto actualiza de forma segura un estado heredado porque init es un comando mutante. Si el estado existe, ejecuta el comando de solo lectura status y reanuda en su nextPhase; nunca reinicies fases completadas. Usa migrate explícitamente al verificar o actualizar una ejecución heredada sin reinicializarla.
3. Lee solo la referencia necesaria para la fase actual:
   • descubrimiento/confirmación: references/interview.md
   • contexto/dirección: references/context-contract.md
   • construcción/elecciones de herramientas: references/routing.md
   • selección de fuente opcional: references/optional-tool-registry.json, solo después de que se confirme una condición de activación
   • revisión/QA/entrega: references/review-and-qa.md
4. Avanza el estado después de cada fase completada con node <skill-dir>/scripts/state.mjs advance <fase> --root <proyecto>. Para human-feedback, pasa también --outcome used o --outcome not-used. Para feedback-fixes, pasa --outcome applied o --outcome not-applicable.

Usa esta secuencia monótona fija:

preflight → discovery → confirmation → context → direction → build → internal-review → human-feedback → feedback-fixes → independent-review → fixes → qa → handoff → complete

Almacena solo el estado de la máquina en .design-harness/state.json; los informes y capturas de pantalla pertenecen a .design-harness/reports/. Nunca almacenes transcripciones completas de chat, tokens, cookies, credenciales o datos de entorno no relacionados.

Aplicar la puerta de aprobación

Entrevista de forma adaptativa y resume las respuestas en una tarjeta de confirmación concisa. Incluye producto, audiencia, objetivo principal, contenido, páginas/superficies, cualidades deseadas y no deseadas, referencias positivas y negativas, restricciones, movimiento, estados requeridos, pila, delegación, estados específicos de IA, tolerancia WebGL, política de fuentes externas y cualquier límite de licencia paga. Pregunta solo por detalles faltantes o importantes.

No escribas, edites ni generes código de producción de interfaz de usuario antes de que el usuario apruebe explícitamente la tarjeta de confirmación. Están permitidos: el preflight, las preguntas, la inspección de solo lectura y un borrador en el chat de la tarjeta de confirmación o el contenido de intención propuesto. No crees ni modifiques archivos .md de intención del proyecto hasta la aprobación.

Si faltan referencias, trata las palabras descriptivas como suficientes. Deriva dos o tres direcciones nombradas con ventajas y desventajas concretas y pide al usuario que elija. Genera tableros visuales solo cuando exista una herramienta visual y el usuario se beneficie; nunca hagas que un tablero sea un requisito previo.

Crear contexto aprobado

Después de la confirmación, completa estos archivos a partir de las respuestas del usuario o propuestas que el usuario apruebe explícitamente:

• PRODUCT.md, incluyendo un registro brand o product aprobado
• REFERENCES.md
• DESIGN.md
• ACCEPTANCE.md
• al menos un .impeccable/surfaces/<slug>.md

Copia las estructuras de las plantillas PRODUCT, references, design, acceptance y surface. Marca cada archivo de intención como aprobado solo después de que el usuario apruebe su contenido. Ejecuta node <skill-dir>/scripts/validate-context.mjs --root <proyecto> antes de la construcción.

Mantén las secciones H2 de DESIGN.md exactamente, una vez cada una, en este orden: Overview, Colors, Typography, Elevation, Components, Do’s and Don’ts.

Trata PRODUCT.md y DESIGN.md como protegidos después de la aprobación. Para cualquier cambio posterior, muestra el diff propuesto, solicita la aprobación explícita y luego aplícalo. Nunca racionalices la desviación en silencio.

Registra cada componente, receta, efecto o integración de retroalimentación externo aprobado en REFERENCES.md con su fuente exacta, elemento seleccionado, versión o commit fijado cuando esté disponible, fecha de acceso, propósito previsto, resultado de licencia/términos actual, adaptaciones y alternativas requeridas. "Usar bibliotecas externas" no es aprobación para una fuente específica.

Construir a través de Impeccable

Haz que la habilidad Impeccable instalada y su contexto aprobado sean la única autoridad de diseño y producción para esta pasada. Carga su habilidad y las referencias de dominio relevantes, luego entrégale los archivos de intención y superficies aprobados. No permitas que repita el descubrimiento o reinterpreta la intención aprobada. Deja que Impeccable genere o actualice .impeccable/design.json; nunca edites ese sidecar manualmente, y nunca aceptes un cambio resultante en PRODUCT.md o DESIGN.md sin el flujo de diff y aprobación protegido.

No cargues ninguna otra habilidad amplia de gusto o sistema de diseño en la misma pasada de producción. Enruta ayudantes específicos solo bajo references/routing.md. Preserva la biblioteca de componentes y pila existentes a menos que el contexto aprobado autorice el cambio. Nunca instales ni copies automáticamente una entrada de registro opcional; explica el uso exacto y acotado y obtén la aprobación primero.

Ejecuta una auto-revisión de Impeccable después de construir y registra los hallazgos; esto es internal-review, no la revisión independiente. Una vez que la interfaz de usuario sea lo suficientemente estable para inspeccionar, ingresa a human-feedback: ofrece el checkpoint de Agentation aprobado cuando sea útil, o registra Not used con --outcome not-used y avanza. Mantén Agentation solo para desarrollo y local/manual por defecto; MCP, webhooks y resolución autónoma requieren aprobación explícita separada. En feedback-fixes, aplica solo las anotaciones de usuario adjudicadas y registra --outcome applied; cuando se omitió la retroalimentación, registra Not applicable con --outcome not-applicable y avanza sin editar. Resuelve las anotaciones del usuario antes de la revisión independiente.

Revisión, correcciones y QA separados

Para independent-review, inicia un subagente/contexto nuevo de solo lectura con la habilidad better-interface actual de Jakub y sus seis habilidades de dominio. Entrégale capturas de pantalla, archivos de implementación relevantes, restricciones de la biblioteca de componentes y los documentos de intención aprobados. Solicita una revisión completa después de la construcción. El revisor debe informar solo los hallazgos y no debe editar ni rediseñar en silencio.

Adjudica cada hallazgo en el contexto raíz contra PRODUCT.md, DESIGN.md, las especificaciones de superficie, los criterios de aceptación y la biblioteca de componentes. Registra aceptar/rechazar/diferir más la justificación. Aplica las correcciones aceptadas por separado a través de la autoridad de producción, luego solicita una revisión rápida enfocada de solo lectura de las áreas cambiadas.

Sigue references/review-and-qa.md. Ejecuta el detector de Impeccable, capturas de pantalla de Playwright en móvil/tableta/escritorio, axe y Lighthouse. Cubre rutas representativas y estados aplicables de carga, vacío, error, texto largo, hover, foco y movimiento reducido. Para fuentes opcionales, también ejercita sus puertas de registro: alternativas semánticas/estáticas, comportamiento sin WebGL, navegadores aprobados, presupuestos de CPU/GPU o bundle móvil y exclusión de producción de herramientas de desarrollo según corresponda. Marca los estados no admitidos o no ejercitados como Not reviewed; nunca los informes como aprobados.

Para interfaces con movimiento de desplazamiento de documento significativo o para preparación de video/demo, inicia la construcción de producción nueva en un puerto local dedicado y ejecuta node <skill-dir>/scripts/verify-motion.mjs --root <proyecto> --base-url <url> --routes /,<otras-rutas> --config .design-harness/qa/motion.config.json después de adaptar la configuración andamiada. El verificador prueba móvil, tableta y escritorio por defecto, aísla cada ruta en un contexto nuevo, requiere una respuesta de ruta exitosa, raíz de contenido configurada, cadena de URL/redireccionamiento observada esperada y desplazamiento de documento medible, y no simula solicitudes de aplicación ni permite redireccionamientos a menos que la configuración explícita del proyecto declare cada excepción. Conserva su proveniencia de Playwright/navegador de esquema-versión 4 y hashes de captura de pantalla/mock con la entrega. Trata los umbrales de primer fotograma/sonda de inicio y ritmo de fotogramas como evidencia solo para esa máquina y navegador, nunca como una garantía universal de 60 FPS.

Usa node <skill-dir>/scripts/scaffold-qa.mjs --root <proyecto> para previsualizar un andamio de QA genérico y agrega --apply después de que la tarjeta de confirmación autorice el plan de QA. Pregunta nuevamente solo cuando los archivos existentes serían reemplazados. Nunca instala dependencias.

Entrega

Indica Ready solo cuando los criterios de aceptación aprobados se cumplan y no quede ningún hallazgo bloqueante o brecha de QA inexplicada; de lo contrario, indica Not ready. Enumera los archivos cambiados, las capturas de pantalla, los hallazgos de revisión y disposiciones, las comprobaciones automatizadas y los resultados, los estados no admitidos, las brechas restantes y cada fuente externa realmente utilizada con su proveniencia fijada y resultado de licencia. Avanza hacia handoff, luego ejecuta node <skill-dir>/scripts/state.mjs complete --root <proyecto> solo cuando el flujo de trabajo esté genuinamente completo.