Comience con las superficies documentadas de Framer
Una decisión del sistema de diseño puede aparecer en varias partes de Framer. Su página oficial de IA indica que el canvas puede refinar la tipografía, los componentes, los breakpoints, el espaciado, el color, los efectos y los layouts. La página también describe componentes de código creados por IA y conexiones con agentes externos. En toda la plataforma, el diseño, el código, la colaboración y la publicación comparten un único entorno de trabajo.
Esas capacidades indican qué se puede editar. Por sí solas, no deciden dónde debe originarse una regla ni cuál prevalece cuando dos capas discrepan. El modelo de responsabilidad y precedencia a continuación es un contrato de trabajo para equipos, no un estándar nativo de Framer.
Capacidad documentada frente a gobernanza recomendada
Framer documenta las superficies editables del proyecto y los flujos de trabajo de los agentes. Esta guía recomienda una matriz de propiedad, un registro de entrega y una secuencia de verificación para gobernar dichas superficies.
Asigne a cada decisión un único lugar autoritativo
Elija la autoridad basándose en el alcance de la decisión. Una regla que deba sobrevivir a un cambio de página, de agente o de herramienta de implementación pertenece a una guía portátil como DESIGN.md. Implemente un valor reutilizable dentro del proyecto de Framer como un estilo compartido. Cuando una decisión defina una unidad recurrente con estructura o comportamiento, coloque esa implementación en un componente.
| Gestiona | No debe gestionar | |
|---|---|---|
| DESIGN.md | Intención portátil, roles semánticos, principios de layout, guía de componentes, motivos, restricciones y excepciones permitidas | IDs de objetos de Framer, observaciones no documentadas o afirmaciones de que un mapeo ha sido probado cuando no es así |
| Estilos compartidos | Valores de color y texto de Framer reutilizables que implementan roles nominados | Correcciones puntuales de página o la justificación de por qué existe un rol |
| Componentes | Estructura recurrente, variantes, estados, propiedades y comportamiento de interacción | Valores globales que deberían provenir de estilos compartidos o excepciones aisladas para una página |
| Breakpoints | Cambios responsivos intencionados en el diseño, tamaño, visibilidad y disposición | Correcciones no explicadas que compensan un componente base débil |
| Código generado | Comportamiento o renderizado personalizado que las capas visuales de Framer no expresan adecuadamente | Un duplicado silencioso de valores de tokens o reglas que ya pertenecen a otro lugar |
| Overrides a nivel de página | Excepciones concretas y nombradas con un motivo y una condición de revisión | Estilo predeterminado, comportamiento reutilizable o una salida conveniente para evitar actualizar la capa de origen |
Un mapeo no es una segunda autoridad. Por ejemplo, DESIGN.md puede especificar que el texto atenuado utiliza un rol semántico de primer plano. Un estilo de texto de Framer puede implementar ese rol bajo un nombre específico del proyecto. La regla escrita posee el significado, mientras que el estilo de Framer posee el valor reutilizable local. El registro de entrega los conecta.
Utilice una regla de precedencia de conflictos
Cuando dos capas discrepen, no acepte simplemente la que se renderice al final. Rastree la decisión hasta su autoridad declarada, verifique si el mapeo downstream está actualizado y clasifique cualquier desviación como una excepción aprobada o un defecto.
- Verifique la decisión autoritativa y su alcance.
- Verifique el mapeo registrado hacia el estilo de Framer, componente, breakpoint o componente de código.
- Verifique si se permitió explícitamente una excepción más restringida.
- Si la autoridad es ambigua, detenga el cambio y asígnela antes de editar más superficies.
- Actualice primero la capa propietaria, luego actualice los mapeos afectados y registre la evidencia observada.
La corrección local puede ocultar la deriva del sistema
Un override a nivel de página puede hacer que una pantalla parezca correcta mientras que los estilos compartidos, los componentes y otros breakpoints sigan estando mal. Trátelo como una excepción solo cuando su alcance y motivo estén registrados.
Copiar este resumen de cambios de rama
Un agente necesita más que una solicitud de diseño. Proporciónele un registro de aceptación breve que nombre la decisión autoritativa, los consumidores previstos, las superficies sin cambios y la evidencia requerida para la revisión.
change_id: nav-muted-text
objective: Align secondary navigation text with the declared muted-text role.
source:
authority: DESIGN.md > Color roles > Muted content
owner: Design systems owner
decision: Secondary navigation labels use the muted foreground role.
targets:
framer_styles:
- Secondary / Navigation
components:
- Site Header
- Footer Navigation
representative_pages:
- Home
- Pricing
breakpoints:
- Desktop
- Smallest supported phone width
allowed_exceptions:
- Active navigation item uses the primary foreground role.
must_remain_unchanged:
- Primary navigation labels
- Button labels
- CMS article body text
- Header spacing and interaction behavior
agent_context:
include:
- Relevant DESIGN.md color-role section
- Target text style
- Site Header and Footer Navigation components
- Home and Pricing pages
exclude:
- Unrelated pages, CMS content, and global layout changes
evidence:
intended_change:
- Before and after capture for each representative page and breakpoint
unrelated_drift:
- Comparison of named unchanged surfaces
unresolved:
- Record any mapping or behavior that could not be inspected
disposition: pass | revise | block
reviewer:
reviewed_at:El registro separa la intención de la observación. Se espera que un objetivo listado bajo framer_styles cambie. Su presencia allí no es evidencia de que el mapeo exista o de que el resultado coincida con la fuente. Complete la sección de evidencia solo después de la inspección.
Las páginas representativas deben ejercer una reutilización real. Elija al menos una página donde el objetivo sea prominente y otra donde aparezca en una composición diferente. Para los breakpoints, cubra la condición responsiva con más probabilidades de cambiar el componente en lugar de verificar cada ancho de lienzo arbitrario.
Delimite el contexto del agente antes de editar
Framer describe el contexto del proyecto, los estilos y activos editables, las conexiones con agentes externos y los cambios realizados por agentes. Más contexto no es automáticamente mejor. Un contexto delimitado facilita ver si el agente siguió la regla prevista y si se coló trabajo no relacionado en la rama.
- 1
Seleccione la decisión de origen
Proporcione la sección relevante de DESIGN.md u otra autoridad declarada. No envíe una librería completa cuando solo un rol de color o una regla de componente están en el alcance.
- 2
Nombre los consumidores de Framer
Identifique los estilos compartidos, componentes, páginas, capas y breakpoints que se espera que implementen la decisión. Marque los mapeos desconocidos como desconocidos en lugar de adivinar sus nombres.
- 3
Establezca los no-objetivos
Enumere las superficies cercanas que el agente no debe rediseñar, renombrar, reestructurar ni cambiar de estilo. Incluya componentes no relacionados que compartan la página.
- 4
Defina la aceptación observable
Describa lo que un revisor debe ver en las páginas representativas y en los breakpoints pequeños. Nombre las superficies no relacionadas que deben permanecer sin cambios.
- 5
Abra un cambio de rama delimitado
Solicite únicamente el cambio nombrado. Si el agente encuentra un mapeo faltante o una autoridad ambigua, exíjale que informe la brecha en lugar de inventar un sistema nuevo.
Trate lo 'desconocido' como un estado de evidencia válido
Es más útil marcar algo como Unknown que inventar un nombre de estilo o asumir el resultado de una importación. Esto indica al revisor qué mapeo debe establecerse antes de que el cambio pueda aprobarse.
Partir de un artefacto de origen completo
Si el traspaso de Framer carece de roles portables y reglas de uso, inspeccione un kit público y su DESIGN.md antes de crear mapeos locales. Mantenga la implementación de Framer separada del artefacto de origen.
Verificar un cambio controlado en una rama
Un lienzo de escritorio con buen aspecto es una evidencia débil. Revise el cambio previsto en cualquier lugar donde se reutilice, inspeccione un breakpoint más pequeño y compruebe que no haya desviaciones en superficies no relacionadas. El objetivo es la trazabilidad, no afirmar que una sola revisión certifica todo el sitio.
- 1
Confirmar el origen y el mapeo
Verifique que el resumen de la rama apunte a la decisión autoritativa actual y a los consumidores de Framer previstos. Si falta alguno de los dos, revise el resumen antes de juzgar el renderizado.
- 2
Inspeccionar la página representativa principal
Compruebe el estilo o componente previsto en la página donde su efecto sea más evidente. Registre qué ha cambiado en lugar de confiar en la memoria.
- 3
Inspeccionar otro consumidor real
Abra una segunda página o composición representativa que utilice el mismo estilo o componente. Una discrepancia suele revelar un valor local desvinculado o un componente duplicado.
- 4
Comprobar la adaptación responsiva
Inspeccione el breakpoint nombrado más pequeño y cualquier breakpoint donde la disposición, la visibilidad o el tamaño cambien intencionadamente. Confirme que la regla base se mantenga, a menos que el resumen permita una adaptación.
- 5
Buscar desviaciones no relacionadas
Compare las superficies enumeradas en
must_remain_unchanged. Compruebe los valores de estilo, la estructura del componente, el diseño, el contenido y las interacciones relevantes para el alcance de la rama. - 6
Asignar una disposición
Apruebe (Pass) cuando los mapeos previstos coincidan y no queden desviaciones dentro del alcance. Solicite una revisión (Revise) para una discrepancia corregible. Bloquee (Block) cuando la autoridad sea ambigua, la evidencia requerida no esté disponible o la rama modifique objetivos no permitidos (non-goals) protegidos.
Qué significa una aprobación
La aprobación (Pass) significa que el cambio delimitado cumplió su contrato declarado en las superficies inspeccionadas. No significa que todo el sitio de Framer sea accesible, responsivo, eficiente o esté listo para publicarse.
Diagnosticar inconsistencias en el orden de propiedad
Cuando una página de Framer parece inconsistente, lanzar otro prompt general a menudo dificulta la interpretación de la evidencia. Recorra las capas en orden de propiedad y deténgase en el primer mapeo no compatible o contradictorio.
- Decisión de origen: ¿Es el rol o la regla prevista explícita, actual y tiene un propietario?
- Contexto seleccionado: ¿Recibió el agente de código la regla, los objetivos, las excepciones y los non-goals relevantes?
- Mapeo de estilo compartido: ¿Utiliza el elemento de destino el estilo de Framer mapeado al rol de origen?
- Uso de componentes: ¿Está la página utilizando el componente compartido y la variante prevista, o una copia desvinculada?
- Adaptación de breakpoint: ¿Cambia un override responsivo intencionadamente el valor o la estructura?
- Código generado: ¿Contiene un componente de código un valor o comportamiento duplicado que entre en conflicto con el origen?
- Override a nivel de página: ¿Existe un valor local que enmascara la implementación compartida?
Corrija la capa propietaria, no el primer síntoma visible. Si un componente utiliza el estilo compartido incorrecto, corrija el mapeo del componente. Si la regla de origen es realmente errónea, cámbiela a través del proceso normal del sistema de diseño del equipo y actualice entonces cada consumidor afectado. No reescriba el origen simplemente para legitimar un valor local accidental.
Consistency check · Ad-hoc colors
The same plan card, built two ways in Ambient Sage.
Pricing
Everything a small team needs to ship a branded UI.
Pricing
Everything a small team needs to ship a branded UI.
Ambient Sage como ejemplo de estado de evidencia
El kit público Ambient Sage sirve como ejemplo porque sus datos de origen son inspeccionables. Su página publicada proporciona un DESIGN.md, design tokens semánticos claros y oscuros, una paleta de 31 colores y roles tipográficos. Se utiliza Plus Jakarta Sans para encabezados y cuerpo, mientras que JetBrains Mono cumple el rol de monoespaciado. El kit también describe superficies de color salvia cálido, tarjetas tonales y un acento amarillo discreto.
Token specimen · real values
Ambient Sage
Live renderAmbient Sage's actual tokens — the same values its exports use.
| Ejemplo de Ambient Sage | Lo que permanece sin resolver | |
|---|---|---|
| Disponible desde el origen | DESIGN.md, design tokens semánticos claros y oscuros, roles tipográficos, guía de espaciado, motivos y exportaciones públicas | Nada en este estado demuestra cómo Framer representa esas decisiones |
| Implementado en Framer | Un equipo podría crear estilos de Framer con nombre y mapeos de componentes a partir de la fuente | Los nombres reales de los estilos, las asociaciones de componentes, el comportamiento del código y las adaptaciones de breakpoints siguen siendo desconocidos hasta que se implementen y registren |
| Observado en páginas | Un revisor podría inspeccionar páginas y breakpoints representativos tras un cambio delimitado en una rama | Ninguna prueba congelada establece el comportamiento de importación, la paridad visual, la integridad responsiva o los resultados de superficies sin cambios |
Un traspaso (handoff) podría mapear el rol de fondo del kit a un estilo de color de Framer, su rol de cuerpo a un estilo de texto que use Plus Jakarta Sans y su guía de tonal-card a un componente de tarjeta reutilizable. Estos son mapeos de ejemplo, no hechos sobre un proyecto de Framer existente. El propietario del proyecto debe elegir los nombres reales y verificar las páginas resultantes.
Sin integración nativa ni declaración de paridad
La evidencia disponible muestra que Framer puede usar referencias como DESIGN.md y que Ambient Sage expone artefactos portátiles. No muestra una importación automática de Identity Forge, la creación automática de estilos ni una paridad probada entre el kit y un proyecto de Framer.
Sepa qué no puede certificar este flujo de trabajo
El mapa de responsabilidades y el registro de la rama mejoran la trazabilidad. No sustituyen la revisión de un especialista ni prueban que el resultado sea bueno. Una implementación coherente puede seguir aplicando una decisión de diseño errónea de manera coherente.
- No certifica la conformidad de accesibilidad, incluyendo el contraste, el comportamiento del teclado, el tratamiento del foco, la semántica o el soporte para tecnologías asistivas.
- No prueba que cada página, estado de contenido, locale o viewport sea responsivo.
- No evalúa la calidad del código generado, el comportamiento en tiempo de ejecución, el rendimiento, la seguridad o la mantenibilidad fuera del cambio declarado.
- No prueba que un artefacto de origen se haya importado automáticamente o se haya reproducido con paridad visual.
- No autoriza la publicación. La rama aún requiere el proceso normal de revisión y lanzamiento del proyecto.
Mantenga pistas de evidencia separadas cuando el riesgo lo requiera. La conformidad con el sistema de diseño cuestiona si la implementación sigue su fuente declarada. La accesibilidad, la resiliencia, el comportamiento y la preparación para producción requieren sus propias comprobaciones.
Haga que una decisión sea trazable hoy mismo
Elija una decisión existente que aparezca en más de una página de Framer, como el texto de navegación atenuado o el color de superficie de una tarjeta. Declare su fuente autoritativa, registre el estilo exacto de Framer o el mapeo del componente, nombre dos páginas representativas y un breakpoint pequeño, y luego pruebe un cambio delimitado en una rama. Amplíe el sistema solo cuando el registro sea lo suficientemente claro como para que otro revisor pueda reproducirlo.
Fuentes
- AI Website Builder for Designers & Teams | Framer: Framer documenta páginas editables creadas por IA y la capacidad de refinar diseños, tipografía, componentes, breakpoints, espaciado, color, efectos y componentes de código dentro del proyecto.
- Framer: AI website builder for professional sites: Framer presenta los agentes, el diseño, el código, la colaboración y la publicación como partes de la misma plataforma de creación de sitios web.
- Web Design Tools in Framer: La descripción general del diseño capturada describe el estilo de capas, cuadrículas, stacks, adaptación de pantalla responsiva, fuentes integradas y superficies de colaboración orientadas a breakpoints.
- Ambient Sage Design Kit: El kit público de Ambient Sage proporciona un DESIGN.md, design tokens semánticos claros y oscuros, tipografía Plus Jakarta Sans, JetBrains Mono y varios formatos de exportación para desarrolladores.
- How to generate a DESIGN.md (and what it is): Identity Forge define DESIGN.md como un resumen de diseño escrito que cubre la intención, los design tokens, la tipografía, el diseño, el tratamiento de componentes, los motivos y las reglas de uso explícitas para los agentes de código.
- AI UI review checklist: test generated interfaces before you ship: La guía de revisión separa la evidencia de tareas, del sistema de diseño, de resiliencia y de accesibilidad, y recomienda probar estados representativos y cambios controlados antes del lanzamiento.
Fuentes
- AI Website Builder for Designers & Teams | Framer: Framer documenta páginas editables creadas por IA y la capacidad de refinar diseños, tipografía, componentes, breakpoints, espaciado, color, efectos y componentes de código dentro del proyecto.
- Framer: AI website builder for professional sites: Framer presenta los agentes, el diseño, el código, la colaboración y la publicación como partes de la misma plataforma de creación de sitios web.
- Web Design Tools in Framer: La descripción general del diseño capturada describe el estilo de capas, cuadrículas, stacks, adaptación de pantalla responsiva, fuentes integradas y superficies de colaboración orientadas a breakpoints.
- Ambient Sage Design Kit: El kit público de Ambient Sage proporciona un DESIGN.md, design tokens semánticos claros y oscuros, tipografía Plus Jakarta Sans, JetBrains Mono y varios formatos de exportación para desarrolladores.
- How to generate a DESIGN.md (and what it is): Identity Forge define DESIGN.md como un resumen de diseño escrito que cubre la intención, los design tokens, la tipografía, el diseño, el tratamiento de componentes, los motivos y las reglas de uso explícitas para los agentes de código.
- AI UI review checklist: test generated interfaces before you ship: La guía de revisión separa la evidencia de tareas, del sistema de diseño, de resiliencia y de accesibilidad, y recomienda probar estados representativos y cambios controlados antes del lanzamiento.