De Stitch o HTML generado a Angular real
Cómo pasamos diseños visuales, prototipos y HTML generado a componentes Angular mantenibles sin perder fidelidad visual.
Un export visual de Stitch o un `code.html` puede servir como maqueta, pero no debería entrar al producto tal cual. Codex ayuda a extraer especificaciones, detectar componentes y convertir el diseño en Angular real, respetando el sistema del proyecto.
Por qué no basta con pegar HTML
Un HTML generado puede verse bien en una captura, pero suele traer estilos duplicados, estructura poco mantenible y decisiones que no calzan con tokens, rutas, accesibilidad ni componentes existentes.
El trabajo correcto es traducir el diseño: primero leerlo como especificación visual, luego mapearlo a componentes Angular y finalmente verificarlo con navegador en desktop y mobile.
Flujo para llevar un diseño a Angular
Auditar el diseño fuente
Antes de tocar código, Codex debe extraer layout, contenedores, grillas, spacing, tipografía, colores, radios, sombras, estados y responsive.
Detectar componentes reales
Separar qué es layout, qué es UI reusable y qué pertenece al feature. En `neges-backffice`, por ejemplo, se mira `shared/ui`; en `umas`, los bloques viven como componentes de secciones; en la tienda, catálogo y checkout tienen UI propia.
Implementar con fidelidad, no con creatividad
El objetivo no es rediseñar. Si el diseño viene de Stitch o de un `code.html`, se conserva jerarquía, densidad, proporciones y comportamiento responsive salvo que el sistema del proyecto obligue a adaptar algo.
Revisar en navegador
Después de implementar, se compara la pantalla contra el diseño fuente, se revisa mobile y se enumeran diferencias restantes de forma explícita.
Qué debe respetar Codex al traducir el diseño
La fidelidad visual importa, pero no puede pasar por encima del sistema existente. Un buen resultado se ve parecido al diseño fuente y además queda organizado como código Angular mantenible.
- Usar componentes reales del proyecto antes de crear nuevos.
- Separar layout, UI reusable y lógica del feature.
- Mantener tokens, utilidades y convenciones de estilos existentes.
- Conservar accesibilidad: botones reales, labels, foco, estados y contraste.
- No copiar `code.html` completo si trae estilos duplicados o estructura difícil de mantener.
- Validar SSR/SEO cuando la pantalla es pública, como catálogo, tienda o help center.
Prompts que usamos para este tipo de trabajo
Quiero que implementes este diseño con alta fidelidad visual.
No empieces escribiendo código.
Primero audita el diseño y extrae: layout, spacing, tipografía, colores, radios, sombras, iconos, estados y responsive.
Lista los componentes detectados y los riesgos de fidelidad.
Después dime qué archivos tocarías en Angular.Convierte el diseño auditado a Angular real.
Usa componentes standalone, tokens y patrones existentes del proyecto.
No pegues el HTML generado tal cual si rompe mantenibilidad.
Mantén fidelidad visual: estructura, spacing, jerarquía, estados y responsive.
Al final valida con navegador en desktop y mobile y lista diferencias restantes.Casos donde esto aplica
Umas
En `umas`, el foco está en páginas institucionales y secciones visuales: hero, actividades, mutual, estatutos y bloques editoriales. El riesgo principal es perder ritmo visual o responsive.
Neges backoffice
En `neges-backffice`, el diseño debe convivir con Bootstrap, `shared/ui`, formularios, tablas, filtros, guards y rutas privadas. La fidelidad visual no puede romper mantenibilidad.
Tienda pública
En la tienda (`neges-store`/shop), Stitch puede definir catálogo, detalle, carrito o checkout. La implementación debe respetar SEO, SSR, datos de producto y estados de compra.
Prototipos `/stitch/login` o `code.html`
Cuando existe una carpeta de prototipo, se usa como referencia visual. Codex debe extraer especificaciones y luego traducirlas al árbol real de Angular, no copiar la maqueta sin criterio.
Cómo verificamos la fidelidad
La verificación final combina revisión visual y técnica: abrir la ruta real, comparar contra el diseño, revisar mobile, validar estados y confirmar que build/typecheck siguen pasando.
npm pkg get scripts
# en backoffice, si existen esos scripts
npm run typecheck
npm run build:prod
# en help center o tienda pública con SSR
npm run build
PORT=4201 npm run serve:ssr
# luego abrir la ruta real y capturar desktop/mobile:
# /login, /catalogo, /checkout, /actividades o /ayuda/blogRecursos relacionados
¿Te fue útil este contenido?
Tu feedback nos ayuda a mejorar la documentación de Neges.
¿No encuentras lo que buscas?
Conversa con nuestro equipo de soporte en español. Respondemos por WhatsApp, correo o ticket en menos de 24 horas hábiles.