Sistema de diseño Google Stitch: diagnosticar el drift y verificar el handoff

Google describe el archivo DESIGN.md como una forma portátil de importar y exportar reglas de diseño. En él se pueden plasmar decisiones compartidas sobre roles de color, tipografía, espaciado, principios de maquetación, tratamiento de componentes y restricciones visuales. Esta portabilidad es fundamental: las reglas pueden trasladarse entre proyectos y plataformas en lugar de quedar limitadas a una sola conversación.

El archivo tiene una función más limitada: establece reglas. No demuestra que cada pantalla generada las haya seguido, que un prompt no las haya anulado o que el código exportado las haya preservado. Tampoco certifica la finalización de tareas, la accesibilidad, el comportamiento responsivo, la calidad del código generado o la preparación para producción. Estos aspectos requieren comprobaciones independientes.

Stitch cambia rápidamente y los resultados de búsqueda mezclan documentación del producto, tutoriales y reportes de usuarios. Etiquete cada afirmación del flujo de trabajo según su clase de evidencia. Esto evita que un tutorial optimista o un reporte de fallo aislado se conviertan accidentalmente en un contrato de producto.

Para cualquier capacidad relevante para el handoff, utilice la documentación oficial actual para establecer la disponibilidad y sus propias observaciones registradas para establecer el comportamiento. Mantenga las instrucciones de terceros como provisionales hasta que las haya reproducido. Los informes de la comunidad son ideas para pruebas, no pronósticos.

La consistencia se vuelve costosa cuando varios artefactos parecen autoritativos a la vez. Un sitio de referencia sugiere una escala tipográfica, DESIGN.md nombra otra, una pantalla generada introduce una tercera y alguien corrige manualmente el código exportado. Sin un registro de precedencia, el resultado visible más reciente tiende a prevalecer, incluso cuando no debería.

Para cada conflicto no resuelto, registre los valores en disputa, la capa propietaria, la persona que decide y la evidencia que necesita. No lo resuelva copiando el valor que haya aparecido en la generación más reciente.

Antes de pedir a Stitch que genere más pantallas, anote las decisiones que deben permanecer estables. Utilice un lenguaje observable. "Mantener la cohesión" no es comprobable. "Utilizar la misma estructura de navegación principal en las pantallas de cuenta, facturación y analítica" sí lo es.

• Navegación: estructura, ubicación, estado seleccionado, comportamiento de colapso y variaciones permitidas.
• Iconos: estilo de origen, tratamiento de trazo o relleno, reglas de tamaño y dónde se requieren etiquetas de texto.
• Modo de color: modos permitidos, modo predeterminado, roles semánticos y si una pantalla puede cambiar de forma independiente.
• Tipografía: familia por rol, pesos disponibles, escala, intención de la altura de línea y tratamiento de datos o código.
• Espaciado y diseño: anchos de contenedor, medianiles, ritmo de sección, comportamiento de la cuadrícula y densidad.
• Componentes: tratamientos compartidos de botones, entradas, tarjetas, tablas, feedback y enfoque.
• Excepciones: la pantalla exacta, el estado, el motivo, el aprobador y el límite de cada desviación.

No compruebe solo la pantalla más pulida. Elija un conjunto representativo que incluya la estructura principal, una pantalla de datos densos, un formulario, un estado de error o destructivo y cualquier pantalla con una excepción aprobada. Si el modo móvil o oscuro están dentro del alcance, incluya esos estados explícitamente.

Cuando dos pantallas divergen, busque el primer punto donde la evidencia difiere. Regenerar todas las pantallas inmediatamente puede ocultar la causa e introducir cambios nuevos.

1. 1

   Comprobar si la regla rectora está completa

   Busque la regla pertinente en DESIGN.md. Si solo indica "usar navegación consistente", no define la estructura, los estados ni las excepciones. Revise la regla en su capa responsable antes de corregir las pantallas.

2. 2

   Comparar los prompts y las sugerencias aceptadas

   Registre el prompt original, las instrucciones de seguimiento y cualquier sugerencia automática o manual. Una instrucción específica de la pantalla puede haber anulado la regla compartida. Elimine o limite esa anulación y vuelva a intentar solo el caso afectado.

3. 3

   Comprobar si existe una excepción aprobada

   Una diferencia legítima no es drift cuando su pantalla, estado, motivo y alcance han sido aprobados. Si la excepción no está documentada, deténgase y solicite una decisión de propiedad en lugar de normalizarla a posteriori.

4. 4

   Localizar el primer artefacto divergente

   Compare pantallas representativas de Stitch antes de inspeccionar el código derivado. Si las pantallas coinciden pero la exportación difiere, derive el hallazgo al límite de exportación o implementación. Si las pantallas ya divergen, mantenga la corrección en la etapa anterior (upstream).

5. 5

   Cambiar una variable controlada por el responsable

   Aplique un cambio de regla puntual, como el modo de color predeterminado o el tratamiento de selección de navegación. No agrupe revisiones de tipografía, espaciado y componentes en la misma prueba.

6. 6

   Asignar una disposición

   Aprobado (Pass) cuando el cambio previsto aparece donde se esperaba sin drift material no relacionado. Revisar (Revise) cuando la regla rectora o el prompt estén incompletos. Bloqueado (Block) cuando la propiedad, la evidencia o la paridad derivadada sigan sin resolverse.

Un cambio controlado comprueba si una regla declarada llega a los lugares donde debería. Es más limitado que una revisión visual general. Elija una regla con un resultado observable, nombre las pantallas y la superficie de exportación afectadas y capture tanto los efectos previstos como los no previstos.

Controlled change

Project:
Observed date:
Reviewer:

Governing layer:
Rule identifier:
Current rule:
Proposed rule:
Reason for change:
Owner and approver:

Representative screens:
- Screen / state:
  Expected change:
  Actual observation:
  Evidence reference:
- Screen / state:
  Expected change:
  Actual observation:
  Evidence reference:

Approved exceptions:
- Screen / state:
  Exception and reason:
  Expected to remain unchanged: yes / no

Exported artifact:
Artifact and version:
Expected change:
Actual observation:
Evidence reference:

Unrelated drift:
- Navigation:
- Icons:
- Color mode:
- Typography:
- Spacing and layout:
- Component treatment:

Unresolved conflicts:
Owner:
Next evidence required:

Disposition: pass / revise / block
Disposition reason:

"No se observó drift no relacionado" es válido solo para las pantallas y el artefacto nombrados. No significa que todo el proyecto sea consistente. Siempre que su flujo de trabajo lo permita, adjunte referencias a capturas de pantalla, versiones de pantalla, texto de prompts, revisiones de DESIGN.md y commits o archivos exportados.

Este registro de entrada muestra cómo incorporar una fuente delimitada al proceso sin inventar resultados de Stitch. Ambient Sage es un kit de Identity Forge gratuito y publicado. Su tipografía documentada utiliza Plus Jakarta Sans para los roles de cuerpo y encabezado en los pesos 400, 500, 600 y 700, además de JetBrains Mono para el rol mono en los pesos 400, 500 y 700. La escala publicada es compact-product.

Artifact intake: Ambient Sage

Source state
- Public kit page: documented
- Kit access: free and published
- Typography roles: documented
- Body and heading family: Plus Jakarta Sans
- Body and heading weights: 400, 500, 600, 700
- Mono family: JetBrains Mono
- Mono weights: 400, 500, 700
- Typography scale: compact-product
- DESIGN.md: available
- Semantic light and dark tokens: available
- Delivery formats: shadcn, Tailwind, CSS, and DTCG

Stitch evidence state
- DESIGN.md imported into Stitch: not tested
- Import warnings or transformations: not tested
- Generated-screen adherence: not tested
- Navigation consistency: not tested
- Icon consistency: not tested
- Light and dark mode behavior: not tested
- Typography and spacing parity: not tested
- Exported-artifact parity: not tested
- Controlled-change result: not tested

Handoff disposition
- Status: block pending evidence
- Reason: the source artifact is documented, but no Stitch-specific behavior or source-to-export parity has been observed
- Next action: import through the currently documented Stitch workflow, capture any transformation, then run one controlled change across representative screens and the chosen export

Entregue conjuntamente el DESIGN.md rector, los tokens legibles por máquina o artefactos de implementación, el registro de excepciones, el registro de cambios controlados y el código exportado. Asigne a cada elemento una versión o una referencia de evidencia estable. El desarrollador debe poder rastrear un valor visible hasta un rol semántico o una regla escrita y ver qué diferencias fueron aprobadas.

• Indicar la revisión de DESIGN.md y el artefacto de tokens utilizado para la generación.
• Listar las pantallas representativas y sus estados registrados.
• Incluir las excepciones aprobadas exactas y los conflictos no resueltos.
• Registrar el método de exportación y la versión del artefacto resultante.
• Separar la paridad verificada de las áreas que no fueron probadas.
• Derivar las correcciones posteriores hacia la regla responsable cuando representen decisiones de diseño compartidas.

Si un desarrollador cambia un color compartido, un valor de espaciado o el tratamiento de un componente solo en el código exportado, trátelo como drift derivado hasta que la fuente rectora acepte el cambio. Si es un detalle de implementación sin consecuencias para el sistema de diseño, manténgalo en el código y explique por qué no es necesario trasladarlo a la etapa anterior.

Apruebe el handoff del sistema de diseño cuando la regla rectora y el propietario estén claros, las pantallas representativas muestren el resultado esperado, las excepciones aprobadas se mantengan delimitadas, el artefacto exportado preserve el cambio verificado y no aparezca ninguna desviación material no relacionada en el alcance.

Seleccione revise cuando la evidencia indique que una regla en DESIGN.md está incompleta, que hay un override de prompt demasiado amplio o que existe una excepción mal definida que el propietario actual puede corregir. Seleccione block cuando las fuentes entren en conflicto sin un propietario asignado, no se haya observado el comportamiento específico de Stitch, el artefacto exportado infrinja una regla rectora o el registro de evidencia sea insuficiente para reproducir la decisión.

En un proyecto nuevo, complete el registro de autoridad de cuatro capas antes de generar otra pantalla. En un proyecto existente, identifique una inconsistencia visible, diríjala a su capa propietaria y ejecute la hoja de trabajo de cambios controlados antes de aceptar o regenerar el resto.

• El formato DESIGN.md de Stitch ya es de código abierto para que pueda utilizarse en diversas plataformas: Google define DESIGN.md como un formato portátil para importar y exportar reglas de diseño entre proyectos y plataformas.
• Presentación del "vibe design" con Stitch: Google describe el flujo de trabajo actual de Stitch como una combinación de un lienzo nativo de IA, un agente de diseño, soporte para DESIGN.md, iteración y superficies de entrega para desarrolladores.
• De la idea a la aplicación: Presentamos Stitch, una nueva forma de diseñar interfaces de usuario: El artículo de lanzamiento de Google documenta la generación a partir de texto o imágenes, el refinamiento interactivo, la transferencia a Figma y la exportación de código frontend.
• Sistema de diseño o guía de diseño en un proyecto de Stitch: Un hilo de la comunidad reporta iconos, navegación y modos de color inconsistentes en las pantallas generadas. Una respuesta etiquetada por Google recomienda prompts más explícitos y la protección de elementos seleccionados.
• Cómo usar Google Stitch para crear un sistema de diseño web en minutos: Este tutorial de terceros describe la extracción de URL, la generación de prototipos multipágina, la iteración y la exportación, pero sus afirmaciones no constituyen un contrato de producto oficial.
• Kit de diseño Ambient Sage: El kit público de Ambient Sage ofrece un ejemplo de diseño delimitado por la fuente que incluye un archivo DESIGN.md, artefactos de entrega legibles por máquina, roles tipográficos documentados y un sistema visual compacto orientado al producto.
• Lista de verificación de revisión de UI con IA: pruebe las interfaces generadas antes del lanzamiento: La lista de verificación de revisión publicada por Identity Forge separa la conformidad con el sistema de diseño de la preparación general y utiliza estados representativos, cambios controlados, registros de evidencia y disposiciones explícitas.

• Stitch's DESIGN.md format is now open-source so you can use it across platforms: Google define DESIGN.md como un formato portátil para importar y exportar reglas de diseño entre proyectos y plataformas.
• Introducing "vibe design" with Stitch: Google describe el flujo de trabajo actual de Stitch como una combinación de un lienzo nativo de IA, un agente de diseño, soporte para DESIGN.md, iteración y superficies de entrega para desarrolladores.
• From idea to app: Introducing Stitch, a new way to design UIs: El artículo de lanzamiento de Google documenta la generación a partir de texto o imágenes, el refinamiento interactivo, la transferencia a Figma y la exportación de código frontend.
• Design system or design guideline on Stitch project: Un hilo de la comunidad reporta iconos, navegación y modos de color inconsistentes en las pantallas generadas. Una respuesta etiquetada por Google recomienda prompts más explícitos y la protección de elementos seleccionados.
• How to Use Google Stitch to Build a Website Design System in Minutes: Este tutorial de terceros describe la extracción de URL, la generación de prototipos multipágina, la iteración y la exportación, pero sus afirmaciones no constituyen un contrato de producto oficial.
• Ambient Sage Design Kit: El kit público de Ambient Sage ofrece un ejemplo de diseño delimitado por la fuente que incluye el archivo DESIGN.md, artefactos de entrega legibles por máquina, roles tipográficos documentados y un sistema visual compacto orientado al producto.
• AI UI review checklist: test generated interfaces before you ship: La lista de verificación de revisión publicada por Identity Forge separa la conformidad con el sistema de diseño de la preparación general y utiliza estados representativos, cambios controlados, registros de evidencia y disposiciones explícitas.