Web personal: diseño fijado con referencias, 1:1

Sitio web personal (Personal Website)

Reglas principales

No te lances directamente al código. Trata el sitio web como un proyecto impulsado por imágenes de referencia en fases:

1. Bloqueo de contenido y estilo
2. Bloqueo de imágenes de referencia
3. Lista de desglose de activos
4. Revisión de generación de activos
5. Replicación de alta fidelidad y QA

El flujo visible para el usuario tiene cuatro puntos de confirmación bloqueantes de forma predeterminada:

1. Confirmar el brief completo de contenido y estilo, incluyendo la forma del sitio, la planificación de secciones, la suficiencia del contenido y la dirección visual ya elegida o proporcionada por el usuario.
2. Confirmar el conjunto de imágenes de referencia después de la revisión de consistencia, ritmo y factibilidad.
3. Antes de generar o buscar nuevos activos, confirmar la lista de desglose de activos.
4. Antes de la implementación del código de la página, confirmar los activos generados/organizados y el brief de ejecución de la réplica.

Después de confirmar el conjunto de imágenes de referencia, no pases directamente a la implementación. Primero, revisa cada imagen de referencia confirmada, genera una lista de desglose de activos para el usuario y espera la confirmación. Una vez confirmada la lista, genera, busca u organiza solo los activos aprobados en la lista. Cuando los activos estén listos, enumera las rutas finales, los resultados de la verificación y un breve brief de ejecución de la réplica; espera a que el usuario acepte, solicite regenerar o modifique el desglose. Solo después de esta confirmación podrás comenzar la replicación de alta fidelidad.

La nota de diseño previa a la construcción (lightweight pre-build design note) anterior se fusiona con la salida de la revisión de activos para formar un breve brief de ejecución de la réplica. No es un punto de confirmación adicional independiente: el usuario confirma simultáneamente los resultados de los activos y el brief de ejecución de la réplica antes del código.

No comprimas las fases posteriores en una construcción frontend normal. Las imágenes de referencia confirmadas no son un moodboard. Antes de escribir código, cada imagen de referencia debe tener un contrato de render (render contract) confirmado, dividido en áreas de responsabilidad del código, escenas fusionadas, medios independientes, activos de identidad/fuente real, anclas visuales, y decisiones finales sobre el origen y el estado.

Condición de parada estricta: No crees ni modifiques archivos HTML, CSS, JS, React, rutas o componentes hasta que la lista de desglose de activos esté confirmada, los activos aprobados se hayan generado u organizado, y se haya aceptado la revisión de activos con el brief de ejecución de la réplica. Decir "Voy a desglosar las imágenes de referencia" solo en un aviso de progreso no cuenta como completado.

Los proyectos impulsados por imágenes de referencia refinadas también requieren una condición de parada estricta basada en evidencia: lee references/evidence-gate.md. Si falta la evidencia en disco requerida, el estado solo puede ser not verified, no pass. Si el usuario solicita saltarse las pausas de confirmación, eso solo significa que el flujo continúa automáticamente después de que se supera el umbral; no significa aprobación automática, reemplazo silencioso de imágenes de referencia, omisión de la revisión ni finalización sin evidencia.

Si el usuario solo tiene información parcial, primero revisa las carencias y sugiere formas menos laboriosas de proporcionar información, en lugar de exigirle que escriba todo manualmente de inmediato. Si el usuario ya tiene contenido, imágenes de referencia y activos confirmados, puedes saltar directamente a la revisión relevante, la revisión de activos o la etapa de replicación, pero aún así debes mantener los mismos límites de confirmación antes del código.

Disciplina de ejecución

Al avanzar entre fases, explica la suposición actual, el siguiente objetivo verificable y cómo verificarlo. Si la solicitud tiene múltiples interpretaciones, primero aclara las opciones y pregunta, luego procede con una dirección específica.

Mantén las modificaciones con moderación:

• No agregues secciones, interacciones, contenido, rutas, tipos de activos o configuraciones que el usuario no haya solicitado o confirmado.
• Al editar un proyecto existente, solo modifica los archivos necesarios dentro del alcance confirmado y respeta el estilo existente del proyecto.
• Solo elimina código, activos o importaciones que se hayan vuelto inútiles después de agregarlos en este flujo de trabajo; menciona el código muerto irrelevante, pero no lo elimines.
• Prioriza el diseño mínimo, la lista de activos, los conjuntos de prompts o los cambios de implementación que permitan que la siguiente fase avance de manera confiable.
• Los pasos múltiples deben tener criterios de éxito lo suficientemente específicos para evitar avanzar por conjeturas.
• Implementa y verifica una sección a la vez; cuando solo se haya verificado una parte de las secciones, no afirmes que varias secciones han pasado.

Idioma y expresión de localización

Las indicaciones visibles para el usuario deben coincidir con el idioma principal del usuario. Cuando el usuario haga preguntas en chino, usa chino para los avisos de progreso, transiciones de fase, solicitudes de confirmación y etiquetas de opciones, por ejemplo, 第一步 / 内容与风格锁定, 接下来进入第二步. Cuando el usuario haga preguntas en inglés, usa inglés, por ejemplo, Step One / Content and style lock, Next I will move to Step Two. Si la conversación mezcla chino e inglés, prioriza la preferencia explícita más reciente del usuario o el idioma de la última solicitud sustancial.

Los avisos para el usuario, las transiciones de fase, las solicitudes de confirmación y las etiquetas de opciones se usan en chino de forma predeterminada; los nombres de archivos, comandos, nombres de campos y términos técnicos necesarios se mantienen en inglés para no alterar el contrato de ejecución.

Los nombres de las fases también deben traducirse por completo. Para los usuarios de chino, escribe 第五步 / 高保真复刻与 QA, no Step Five / Build and QA u otras etiquetas mixtas.

Habilidades complementarias integradas

Este skill incluye referencias complementarias integradas, por lo que el flujo de trabajo no depende de que el usuario instale otros skills adicionales:

• references/imagegen-frontend-web.md: utilizado para el contrato estricto de generación de imágenes de referencia de sitios web personales en el segundo paso.
• references/visual-quality-gate.md: utilizado para la revisión de significado real, jerarquía, espacio en blanco, recorte, superposición, autoría y contexto fresco en el segundo y quinto paso.
• references/evidence-gate.md y scripts/verify_identity_run.py: utilizados para hashes de referencia no sobrescribibles, evidencia de capturas de pantalla sección por sección, atribución topológica y verificación de finalización determinista.
• references/reference-asset-splitter.md y references/split-patterns.md: utilizados para el veredicto de activos de tres ejes y ejemplos de corrección de errores reales en el tercer paso.
• references/frontend-app-builder.md: utilizado para la implementación de alta fidelidad y QA después de la revisión de activos.

En la fase de generación de imágenes de referencia del sitio web personal, ya sea que esté instalado el modulo independiente imagegen-frontend-web o no, se debe leer references/imagegen-frontend-web.md. Cuando el objetivo es refinado, profesional, distintivo o de nivel Awwwards, también se debe leer references/visual-quality-gate.md en el segundo y quinto paso. Estos archivos integrados son contratos estrictos de este flujo de trabajo; los skills independientes pueden complementar un vocabulario creativo más amplio, pero no pueden sobrescribir el brief confirmado, la huella de estilo (style fingerprint), el contrato de significado, el umbral de calidad visual, el presupuesto de activos y las reglas de factibilidad.

En la fase de veredicto de activos, si reference-asset-splitter está instalado, úsalo; de lo contrario, usa la versión integrada; ambas deben mantener el mismo clasificador y ejemplos. El brief confirmado por el usuario y los límites de fase estrictos de este skill tienen prioridad sobre las reglas predeterminadas de las habilidades complementarias. En el quinto paso, aún se debe priorizar el uso de la versión instalada de frontend-app-builder, y la copia integrada se utiliza como respaldo.

Si el skill complementario no está instalado, no te detengas, no pretendas que la invocación @skill esté disponible y no le pidas al usuario que lo instale para continuar. Lee la referencia complementaria integrada en este paquete y considérala como el contrato de ejecución mínimo local.

Solo discute la instalación por separado de un skill complementario cuando el usuario quiera explícitamente componentes instalables de forma independiente. En la ruta normal, instalar el skill identity-skill debería ser suficiente.

Si no hay ninguna herramienta de generación de imágenes, escribe prompts reproducibles para que el usuario los pegue en GPT web Image 2 u otra herramienta de imágenes, o pídele al usuario que proporcione sus propias imágenes de referencia. Si el usuario omite por completo las imágenes de referencia, trata la construcción como de fidelidad más baja y explica claramente que el QA visual solo puede basarse en el brief de texto, no en imágenes de referencia aceptadas.

Protocolo de aviso de fase

Al final de cada fase visible para el usuario, proporciona un aviso de progreso claro:

• Progreso actual: 第一步 / nombre de la fase
• Completado: el resultado específico que acabas de generar.
• Todavía falta o hay riesgo: solo enumera los puntos de bloqueo que realmente afectan el progreso.
• Qué puede hacer el usuario ahora: confirmar, modificar una parte nombrada, proporcionar información faltante o elegir opciones.
• Próximo paso: explica el nombre de la siguiente fase y lo que sucederá.

No dejes al usuario en un punto muerto implícito. Si el flujo continúa sin una confirmación bloqueante, explica claramente que continuará y por qué.

Primer paso: Bloqueo de contenido y estilo

Primero, determina qué ruta de contenido se aplica. No obligues al usuario a repetir manualmente información que ya se puede leer de los archivos, enlaces, currículums, perfiles, notas, muestras de escritura, documentos de proyecto, capturas de pantalla o sitios web existentes.

Rutas de entrada de información

Utiliza una de las siguientes rutas:

• Ruta de información suficiente: El usuario ha proporcionado currículum, CV, LinkedIn, página de inicio personal, portafolio, enlaces de proyectos, documentos de Notion/Markdown, biografía breve, kit de prensa, páginas de redes sociales, archivos de escritura o materiales similares. Lee el contenido accesible, extrae hechos confirmados, unidades de contenido utilizables para secciones, enlaces, activos y carencias. Solo haz preguntas complementarias que afecten la dirección del sitio.
• Ruta de brief breve: El usuario ha dado un objetivo o identidad, pero con poco material de apoyo. Primero invita al usuario a proporcionar una entrada menos laboriosa, como un currículum, una presentación existente, enlaces de proyectos, enlaces de escritura, fotos, sitios web de referencia o capturas de pantalla. Si el usuario no quiere proporcionar archivos, usa las preguntas guía a continuación.
• Ruta desde cero: El usuario no tiene materiales o quiere empezar desde cero. Formula las preguntas guía de una sola vez, no como una entrevista larga pregunta por pregunta.
• Ruta de demostración rápida: El usuario enfatiza explícitamente la velocidad o un prototipo tosco. Puedes usar contenido mock ligero, pero todos los hechos inventados, proyectos, citas, métricas, enlaces o detalles de la biografía deben marcarse como contenido provisional que debe reemplazarse antes de la versión final.

La ruta de preguntas guía debe recopilarse de forma compacta:

• Objetivo: currículum, búsqueda de empleo, portafolio, creador/marca personal, consultor, presentación de fundador/ejecutivo, página de charlas/medios, u otro propósito.
• Audiencia: quién visitará, qué quieres que hagan después de verlo.
• Posicionamiento: etiquetas de identidad, frase que se pueda recordar, límites de tono.
• Material de prueba: experiencia, proyectos, escritos, productos, clientes, cobertura mediática, charlas, premios u otra evidencia.
• Detalles del proyecto: preguntas de contexto para cada proyecto importante, tu rol/acciones, resultados, enlaces/medios, y qué quieres que la gente recuerde.
• Activos y límites: foto de perfil, logotipo, capturas de pantalla, documentos, enlaces, contenido no disponible o sensible, y lo que no se puede generar o exagerar.
• Preferencias del usuario: densidad de información del sitio, preferencia por una o varias páginas, referencias que te gusten, estilos que no te gusten, disposición para el mantenimiento posterior.

Documento de contenido y forma del sitio

Para sitios web personales refinados, sitios de marca personal, portafolios, nivel Awwwards o cualquier escenario donde la calidad del diseño sea importante, genera un documento de contenido y forma del sitio antes de pasar a las imágenes. Para demostraciones rápidas, mantén la misma estructura pero escríbelo más corto.

El documento debe incluir:

• Cobertura de información: qué archivos, enlaces, notas o respuestas del usuario se utilizaron.
• Hechos confirmados: escribe solo hechos proporcionados por el usuario o respaldados por fuentes.
• Borrador de contenido no confirmado: marca claramente el texto propuesto por el agente, ejemplos, marcadores de posición, afirmaciones inferidas o enlaces faltantes.
• Objetivo y audiencia del sitio: qué debe lograr este sitio web y para quién.
• Puntos de memoria del visitante: una a tres cosas que el visitante debe recordar.
• Recomendación de forma del sitio: página única, currículum de una página, página de inicio más estudio de caso, portafolio de varias páginas, centro de creador, página de aterrizaje de consultor u otra forma.
• Razón de la recomendación: por qué esta forma se adapta a los objetivos del usuario, la cantidad de contenido, la profundidad de la prueba y la disposición al mantenimiento.
• Alternativas opcionales: estructuras más ligeras o más completas que son viables pero no la recomendación principal.
• Planificación de secciones: propósito de cada sección, contenido requerido, unidades de contenido, enlaces/activos y estado (ready, needs detail, placeholder o cut).
• Riesgo de suficiencia del contenido: secciones vacías, genéricas, falsas, abarrotadas, sin respaldo o que no merecen conservarse.

La forma del sitio debe recomendarse según los objetivos del usuario y la densidad de información; no asumas por defecto cinco o seis secciones. Para currículums o búsqueda de empleo, generalmente solo se necesita una página única o una o dos páginas. Un portafolio profundo puede necesitar rutas de estudio de caso. Los sitios de creadores, fundadores o consultores solo necesitan una narrativa más sólida o una ruta de conversión si el contenido lo respalda.

Todo el contenido utilizado para las imágenes de referencia debe provenir de lo que el usuario haya proporcionado o haya aprobado explícitamente. El agente puede proponer contenido para llenar vacíos, pero ese contenido es solo un borrador, no un hecho confirmado. No trates el contenido propuesto por el agente como confirmado solo porque esté bien escrito o se vea bien.

Antes de la confirmación del segundo paso, fija la estrategia de fuente de evidencia para cada persona, empresa, producto, trabajo, publicación o proyecto identificable. Recopila los activos del usuario o activos oficiales disponibles lo antes posible, de modo que las imágenes de referencia se compongan directamente alrededor de la evidencia real; no confirmes primero una composición más fuerte de marcador de posición generada y luego planees reemplazarla con activos oficiales de diferente peso visual, proporción o sujeto después del bloqueo.

Recomendación de estilo

Una vez que el contenido y la forma del sitio estén lo suficientemente claros, recomienda un máximo de tres direcciones visuales basadas en el contenido, las preferencias del usuario, la audiencia, el propósito del sitio y las referencias existentes. El usuario puede elegir una, mezclar múltiples opciones o proporcionar su propia dirección visual/referencia.

Las opciones de estilo deben ser conceptos visuales, no solo etiquetas de posicionamiento. No des solo opciones como "Currículum de estudiante internacional premium", "Investigador de productos Fintech", "Portafolio de IA + Finanzas" que solo diferencian a la audiencia o la narrativa profesional. Estas etiquetas pueden explicar por qué es adecuado, pero las opciones en sí mismas deben permitir que el usuario imagine cómo se ve la página antes de generar imágenes.

Cada opción de estilo debe cubrir brevemente:

• Nombre del concepto visual: una etiqueta corta que describa la atmósfera de la imagen, no solo el rol personal.
• Empatía y coincidencia de posicionamiento.
• Dirección de color: 3-5 colores específicos o roles de color, con hex si es necesario.
• Carácter tipográfico: carácter y contraste de peso para display/body.
• Composición del pliegue superior (above the fold): cómo aparecen el nombre, el titular, la foto/perfil, CTA, pistas de prueba.
• Densidad del diseño y ritmo de las secciones: moderación de una página, ritmo editorial, bloques de prueba estilo bento, profundidad de estudio de caso u otro ritmo específico.
• Manejo de imágenes o activos: recorte de foto de perfil, capturas de pantalla de proyectos, tarjetas de documentos, visualización de datos, fotografía editorial, fondo abstracto o gráficos renderizados por código.
• Sensación de UI chrome y navegación: densidad del encabezado, marca denominativa, forma de CTA, bordes, esquinas redondeadas, estilo de iconos y estado activo.
• Carácter de los efectos de movimiento.
• Qué verá el usuario: describe la impresión visual de la pantalla en una oración.
• Por qué es adecuado para esta persona y esta forma de sitio.
• Principales riesgos o compensaciones.

Si una opción de estilo no se puede describir como una imagen de sitio web visible, reescríbela antes de mostrarla al usuario. Si el objetivo del usuario es el posicionamiento profesional, traduce ese posicionamiento en decisiones visuales, no dejes que el título de la opción cargue con toda la expresión.

Cuando sea necesario, utiliza este formato compacto de opción de estilo:

Opción A — Editorial Resume / Sensación de papel tinta
Colores: blanco cálido #F7F3EC, negro tinta #171717, gris azulado #6B7280, azul de énfasis #2563EB.
Tipografía: serif display contenido + sans body limpio; profesional pero no decorativo.
Pliegue: nombre y frase de posicionamiento alineados a la izquierda, sobre un amplio espacio en blanco con sensación de papel; a la derecha, una foto de perfil o fotografía estilo LinkedIn recortada con suavidad; dos enlaces de prueba debajo.
Ritmo: flujo de currículum de una página, secciones tranquilas, pruebas de proyecto en tarjetas pequeñas.
Impresión visual: como un CV editorial refinado de un candidato internacional, no una landing page de startup.
Riesgo: si el usuario quiere una marca personal más fuerte, puede parecer de poca distinción.

No generes imágenes de referencia hasta que el usuario haya confirmado el brief completo de contenido y estilo. Si el usuario ha elegido una opción de estilo y no se ha opuesto al documento de contenido, solo considera esa respuesta como la primera confirmación bloqueante si tu mensaje deja claro que "esto bloqueará tanto el contenido como el estilo".

Utiliza esta forma de aviso de cierre del primer paso:

Progreso actual: Primer paso / Bloqueo de contenido y estilo
He preparado: Resumen de la fuente de información, hechos confirmados, recomendación de forma del sitio, planificación de secciones, riesgos de contenido y opciones de estilo.
Por favor, confirma o modifica:
1. Forma del sitio y planificación de secciones
2. Todo el contenido marcado como no confirmado
3. Dirección visual: elige una opción, mezcla varias opciones, modifica colores/diseño, o proporciona tus propias referencias
Después de la confirmación, pasaré al segundo paso para generar o preparar imágenes de referencia para cada sección.

Segundo paso: Bloqueo de imágenes de referencia

Usa imágenes de referencia a nivel de sección como fuente de verdad visual.

Los prompts de las imágenes de referencia deben basarse en el brief de contenido y estilo confirmado: contenido aprobado, forma del sitio aprobada, dirección visual elegida o proporcionada por el usuario, reglas globales de chrome y unidades de contenido específicas de cada sección. Cuando el usuario espera un sitio web personal de alta calidad, no generes imágenes de referencia basadas en un brief superficial o contenido propuesto por el agente no aprobado.

En esta fase, lee siempre references/imagegen-frontend-web.md. Si el modulo independiente imagegen-frontend-web está disponible, úsalo para complementar una dirección artística más amplia bajo el contrato estricto del sitio web personal integrado. El conjunto de imágenes de referencia debe lograr una imagen horizontal por cada sección confirmada, una composición fuerte, un mundo unificado de marca personal y una topología de imagen que realmente se pueda implementar.

Si el usuario prefiere GPT web Image 2, escribe prompts que pueda copiar y pegar, en lugar de generar imágenes directamente.

Plan de generación de imágenes de referencia

Antes de generar cualquier sección, prepara un plan conciso de generación de imágenes de referencia. Pertenece al artefacto interno del segundo paso y no agrega una nueva puerta de confirmación para el usuario. Si ya existe un directorio de proyecto, escríbelo en el documento de restauración o en un pequeño docs/reference-production-plan.md; si no, mantenlo en la salida de trabajo del segundo paso.

Primero, fija la huella de estilo (style fingerprint) compartida para todo el conjunto:

• Roles de color precisos y valores hex.
• Roles tipográficos para display/body/label/nav y tamaños de fuente relativos.
• Geometría global de chrome, lenguaje de bordes/esquinas redondeadas/sombras y familia de CTA.
• Textura, luz, paleta de fotos, lenguaje de ilustraciones/iconos.
• Rango de densidad, ritmo de espaciado, relación de aspecto del lienzo y como máximo un motivo característico (signature motif) opcional.
• Constantes que no pueden variar, y una o dos dimensiones que pueden variar por sección.

Luego, asigna un contrato de render (render contract) para cada sección:

• C0 code-only: tipografía, diseño y geometría simple, sin necesidad de activos raster.
• C1 integrated-scene: la UI del código se superpone a una escena fusionada; la escena puede ser full-bleed o una isla visual con bordes.
• C2 independent-media: carcasa de código más una a tres fotos, capturas de pantalla, portadas o maquetas de productos con significado independiente.
• C3 scene-plus-identity: una escena fusionada, más una foto de perfil, logotipo o imagen de producto oficial de fuente real o para reemplazar después.

Cada contrato de render debe especificar: contenido del que se encarga el código, material compartido de todo el sitio permitido, límites de la escena fusionada, ranuras de medios independientes, activos de identidad/fuente real, elementos prohibidos de fusionar, comportamiento responsivo, zona de seguridad de texto, presupuesto de activos y atribución topológica (section-specific o estructura compartida nombrada con justificación). Para objetivos de alta calidad, también se deben completar los campos de significado de references/visual-quality-gate.md: información de tres segundos, evidencia personal, acciones de diseño de autoría, jerarquía de enfoque, ruta de lectura, mapa de espacios en blanco, significado gráfico semántico, lista de superposiciones, área de exclusión cerrada y carga útil del pliegue superior. C0 code-only significa 0 activos raster exclusivos de la sección; si una textura de papel o una línea de escaneo pertenece a la huella de estilo bloqueada, se puede reutilizar uno o dos materiales de todo el sitio declarados explícitamente. Pero no significa que una sección con contenido insuficiente y solo texto grande que llena la altura esté completa: además del texto grande, debe haber una segunda decisión de diseño basada en el contenido; de lo contrario, acorta, fusiona o rediseña esa sección. Cada material compartido se genera solo una vez y se cuenta una vez para todo el sitio. Por defecto, cada sección tiene un punto focal visual principal, como máximo una escena fusionada y no más de tres unidades raster exclusivas de la sección; solo se puede superar si el usuario aprueba explícitamente la dirección de pared de evidencia densa (dense evidence-wall).

Primero, genera la sección ancla que mejor define la identidad, generalmente Hero. Las secciones posteriores se generan en el mismo lote; cuando la herramienta de imágenes admita entrada de referencia, debes usar el ancla como guía visual; de lo contrario, reutiliza la misma huella de estilo palabra por palabra. No se agregan puertas de confirmación adicionales entre el ancla y las imágenes posteriores.

Salida predeterminada:

• Una imagen de referencia horizontal por sección.
• No uses collage vertical de página completa.
• No uses tableros de múltiples secciones pequeños y difíciles de leer.
• Todas las secciones mantienen una visión de mundo de marca personal consistente.
• Las imágenes de referencia deben parecer capturas de pantalla de sitios web reales, no carteles.
• El texto y los controles de los que se encarga el código deben poder separarse limpiamente del material raster.
• Las escenas fusionadas estáticas se mantienen como una unidad visual completa; no debe haber sombras, reflejos ni oclusiones que crucen los límites entre las ranuras de medios independientes.

Antes de presentar el conjunto de imágenes de referencia al usuario para su confirmación, realiza una revisión en cuatro partes:

1. Revisión del significado visual: ejecuta todos los umbrales estrictos de references/visual-quality-gate.md, incluyendo transmisión en tres segundos, un solo primer punto focal, lista de elementos intencionados, especificidad personal, composición completa, límites superior e inferior de densidad, espacio en blanco significativo, significado gráfico semántico, integridad de recorte, seguridad de superposición y carga útil responsiva del pliegue superior. Una sección, incluso si es bonita o factible, falla si la idea, la evidencia o la composición son débiles.
2. Revisión de consistencia: compara cada imagen con la huella de estilo precisa, verificando navegación global, roles de fuente, paleta de colores, espaciado, lenguaje de cajas, tono de imagen, motivo y lógica móvil. Debe ser evidente que todas pertenecen al mismo sitio web.
3. Revisión de ritmo: enumera el esqueleto de composición de cada sección y verifica el sobre de variación (variation envelope). Se puede variar la tarea, la escala, la alineación, el recorte o la densidad de la sección con moderación, pero no obligues a cada pantalla a convertirse en un concepto visual completamente nuevo. Ejecuta la prueba de bloque gris (grey-block test): después de convertir las fotos en bloques grises, al menos la mitad de las secciones aún deben mantener un diseño a través de la tipografía, el diseño, el color y la estructura.
4. Revisión de factibilidad: compara cada imagen con su contrato de render. Si el texto del código y el material raster no se pueden separar, los activos independientes comparten sombras/reflejos duros, los activos de identidad se fusionan en la escena generada, la reordenación responsiva requiere mover píxeles dentro de una sola imagen, se supera el presupuesto de activos sin aprobación o aparecen islas de imagen no planificadas, esa sección falla.

Cuando la topología de la imagen de referencia falle, usa redesign-required: mantén la huella de estilo de todo el sitio, solo regenera la sección fallida y luego preséntala al usuario para su confirmación. No fuerces una imagen de referencia no factible en el tercer paso mediante cortes frágiles o una implementación de baja fidelidad como solución.

Después de confirmar el conjunto de imágenes de referencia aprobado, cópialo en un nuevo directorio no sobrescribible, por ejemplo, references/locked/v1/, y escribe el SHA-256 de cada imagen en docs/identity-evidence.json. No sobrescribas archivos bloqueados; la regeneración o reestructuración debe crear una nueva versión y volver a ejecutar las revisiones del segundo paso afectadas.

Cuando la calidad del diseño sea importante, o el usuario solicite orientación sobre el gusto, lee simultáneamente references/taste-calibration.md y references/visual-quality-gate.md. Las muestras de gusto (taste samples) se encargan de calibrar el mundo visual opcional, mientras que el umbral de calidad se encarga de juzgar si ese mundo está realmente expresado y el diseño está completo.

Usa esta forma de aviso de cierre del segundo paso:

Progreso actual: Segundo paso / Bloqueo de imágenes de referencia
He preparado: Huella de estilo de todo el sitio, significado y contrato de render de cada sección, imágenes de referencia, y revisión de significado visual/consistencia/ritmo/factibilidad.
Por favor, confirma o modifica:
1. Aceptar estas imágenes como objetivo de construcción
2. Especificar qué secciones regenerar
3. Ajustar la dirección visual antes de construir
Después de confirmar las imágenes, pasaré al tercer paso para producir formalmente la lista de desglose de activos: qué se queda en el código, qué es una escena fusionada, qué son medios independientes, qué debe ser de fuente real, qué necesita blocked, replace-later o redesign-required. Esperaré tu confirmación antes de generar o buscar nuevos activos.

Tercer paso: Lista de desglose de activos

Después de confirmar el conjunto de imágenes de referencia, primero revisa las imágenes aceptadas, no generes activos ni escribas código. Esta fase produce una lista de desglose de activos para que el usuario la vea y se detiene para esperar la confirmación.

Antes de producir la lista, si reference-asset-splitter está instalado, léelo junto con references/split-patterns.md; de lo contrario, lee los archivos integrados references/reference-asset-splitter.md y references/split-patterns.md. Ejecuta el clasificador de tres ejes en orden: granularidad de límites, medio de renderizado y nivel de imagen. No comprimas las tres cosas en una frase como "se ve complejo".

Usa una prioridad de conflicto fija: identidad real/activos de fuente; contenido semántico vivo y accesibilidad; reordenación de interacción/sustitución/actualización/responsiva independiente; lista blanca de código (code whitelist) y señales raster; relaciones de fusión; presupuesto de activos; y, por último, preferencias estéticas. La complejidad visual por sí sola no puede forzar un desglose detallado ni demostrar que el código puede replicar con alta fidelidad.

El objetivo es la practicidad, no la sobrespecificación: dile al usuario qué partes visibles deben permanecer en el código, cuáles necesitan activos generados o recopilados por separado, cuáles necesitan activos transparentes/de primer plano, cuáles son de fondo, qué activos reales no se pueden falsificar y qué juicios, si se equivocan, afectarán el efecto de la réplica final.

Esta fase crea o actualiza un artefacto de restauración visible. Los formatos aceptables incluyen:

• docs/restoration-plan.md, que combina el mapa de imágenes de referencia, el manifiesto de activos y el breve brief de ejecución de la réplica posterior.
• docs/reference-to-build-map.md más docs/asset-manifest.md.
• Si el repositorio ya tiene una convención de documentos, también se puede usar un documento equivalente dentro del proyecto.

El artefacto debe aterrizar antes de la generación de activos y de la edición del código de la página. Debe enumerar cada imagen de referencia confirmada y cada sección/página. Simplemente resumir en el chat, ocultar el razonamiento o usar una línea de aviso de progreso no cumple con el requisito.

La lista de desglose de activos para el usuario debe ser más corta que el artefacto interno. Cada sección incluye:

• Elementos gestionados por código: texto, navegación, botones, diseño, formas simples, etiquetas y efectos de movimiento que deben ser editables.
• Material compartido de todo el sitio: opcionalmente, papel, grano, líneas de escaneo u otros materiales de huella digital que se generan una vez y se reutilizan, o ninguno.
• Activos de escena fusionada: fondo completo o escena fusionada con bordes, texturas, mapas, escenas fotográficas, mundos de escritorio, collages de tarjetas, o ninguno.
• Activos de medios independientes: foto de perfil, maquetas de productos, capturas de pantalla, fotos, portadas, ilustraciones independientes, o ninguno.
• Activos reales existentes: fotos, logotipos, capturas de pantalla de productos, activos oficiales proporcionados por el usuario, o archivos fuente para copiar.
• Activos generables: imágenes de ambiente que se pueden generar de forma segura, decoraciones, maquetas de productos abstractas, fondos o sustitutos.
• Blocked, replace-later o redesign-required: personas reales, marcas oficiales/logotipos/imágenes de productos, capturas de pantalla faltantes con afirmaciones, o topología de imagen de referencia que no se puede dividir fielmente.
• Por qué es importante: qué riesgo de fidelidad de réplica causaría un error en el juicio de los límites del activo.

Reglas de límites de activos

Al preparar la lista de desglose de activos en el tercer paso y la revisión de generación de activos en el cuarto paso, usa las siguientes reglas.

Una vez que existen las imágenes de referencia y antes de escribir código, ejecuta los tres ejes de juicio por separado:

1. Límites: solo la interacción independiente, sustitución/actualización, semántica independiente o reordenación responsiva justifican un desglose detallado. Después de eliminar los nodos de código y los nodos independientes forzados, fusiona los objetos raster estáticos que tengan superposición, sombras/reflejos que crucen objetos, textura continua, perspectiva, luz o relaciones de material. Un mismo grupo de fusión (fusion group) es, por defecto, un solo activo, sin importar cuántas tarjetas se puedan contar dentro.
2. Medio: solo el texto vivo (live text), el diseño DOM, los colores sólidos, los bordes/esquinas redondeados/sombras normales, los degradados CSS simples, los iconos estándar, las cuadrículas/puntos básicos y la geometría SVG simple pueden ser nativos del código (code-native). Las fotos, las texturas irregulares, las pinceladas a mano/ pinceles, las ilustraciones complejas, las maquetas densas de UI/productos, las texturas naturales, el 3D, la luz/reflejos reales o los efectos raster compartidos deben ser imágenes. Cuando se necesite tanto comportamiento vivo como fidelidad raster, usa híbrido: la imagen se encarga de lo visual, el código se encarga de la carcasa, el texto y la interacción.
3. Nivel: integrated-scene es una imagen visual fusionada vinculada a una sección, que puede ser full-bleed o solo ocupar el lado derecho del Hero; independent-media son fotos, capturas de pantalla, portadas, maquetas, fotos de perfil o ilustraciones independientes que se pueden reemplazar de forma independiente. La transparencia o no determina la clasificación.

Por defecto, cada sección tiene como máximo una escena fusionada, y el número total de unidades raster no supera las tres. Las ranuras de medios independientes son activos separados, y los grupos de fusión estática se mantienen como una sola imagen. Todo el texto final, la navegación, los botones, los formularios, los datos fácticos y las interacciones permanecen en el código. Se permite un fondo artístico de pantalla completa, pero no está permitido hornear todo el contenido del que se encarga el código en una captura de pantalla de pantalla completa.

Cuando el texto vivo no se pueda separar del material, los elementos interactivos compartan sombras/oclusión duras con otra capa, los activos de identidad real se fusionen irreversiblemente en la escena generada, la versión móvil requiera mover píxeles de forma independiente dentro de una sola imagen, o la reorganización dependa de costuras de píxeles frágiles, usa redesign-required, no fuerces un desglose. Mantén la huella de estilo y devuelve solo esa sección al segundo paso para regenerarla.

Cada imagen de referencia confirmada debe tener un mapa de referencia a construcción (reference-to-build map) registrado en el artefacto de restauración visible:

Referencia: 01-hero.png
Capa de código: nav, título, subtítulo, grupo CTA, marco de retrato, etiquetas de prueba
Escena fusionada: hero-finance-desk.png, 16:9, full-bleed, se permite máscara oscura
Medios independientes: portrait.png, 24% de ancho a la derecha; product-card-mock.png, 22% de ancho en el centro inferior
Debe preservar: atmósfera de escritorio oscuro/foto financiera, proporción del título grande a la izquierda, tarjeta de foto a la derecha, CTA verde, espaciado del encabezado superior
Desviación permitida: las etiquetas de gráfico en la imagen generada se reemplazarán con el texto confirmado renderizado por código
Disparador de riesgo: las marcas de empresa reales no confirmadas o la foto de perfil del usuario deben confirmarse primero

Cada sección debe cubrir todas las áreas significativas: rol semántico, desencadenantes de límites, resultado de la lista blanca de código, señales raster, grupo de fusión, propietario (code o asset), ubicación (integrated-scene, independent-media o ninguno), alcance de reutilización (global o section), procedencia, modo responsivo, decisión/estado (ready, generate, find/copy, code-native, replace-later, blocked o redesign-required), fuente/acción y ruta final. Si no hay una imagen exclusiva de la sección, explica claramente por qué y enumera por separado el material compartido reutilizado.

Registra el manifiesto de activos (activo, rol, desencadenante de límite, señal raster, grupo de fusión, ubicación, alcance de reutilización, procedencia, cuadro de referencia, relación de aspecto, tamaño relativo, modo responsivo, estado, ruta final), de modo que durante la replicación se pueda colocar cada activo en un contenedor de relación de aspecto fija, en lugar de que el tamaño original de la imagen impulse el diseño.

Usa esta forma de aviso de cierre del tercer paso:

Progreso actual: Tercer paso / Lista de desglose de activos
He preparado: Mapa de referencia a construcción, lista de decisiones de activos y manifiesto de activos preliminar.
Por favor, confirma o modifica:
1. Qué elementos se mantienen como nativos del código
2. Qué escenas fusionadas y medios independientes se deben generar, copiar o marcar como replace-later
3. Qué fotos de perfil, logotipos, capturas de pantalla de productos o activos oficiales reales no se pueden generar
4. Las suposiciones de interacción o sustitución que realmente son ambiguas en la lista
Después de la confirmación, pasaré al cuarto paso para generar u organizar solo los activos aprobados. Todavía no editaré el código de la página. Cuando sea útil, puedo procesar lotes de activos aprobados en paralelo; si prefieres un orden secuencial, dímelo directamente.

Cuarto paso: Revisión de generación de activos

Después de confirmar la lista de desglose de activos, solo genera, copia, busca u organiza los activos aprobados. Luego, muestra al usuario los resultados de los activos y un breve brief de ejecución de la réplica. No comiences la implementación del código de la página hasta que el usuario acepte la revisión de activos.

La revisión de activos debe incluir:

• La ruta final de cada activo listo (ready).
• A qué sección y a qué elemento visible corresponde cada activo.
• Fuente: generado, proporcionado por el usuario, oficial/copiado, nativo del código (code-native) o para reemplazar después (replace-later).
• Resultado de la verificación: accepted, needs regeneration, weak but usable with named deviation, blocked o replace-later placeholder.
• Notas del prompt/fuente necesarias para reproducir el activo.

Cada activo de imagen tiene solo dos fuentes legales:

1. Activos reales ya recopilados en la ingesta del primer paso, como fotos de usuario, logotipos, capturas de pantalla de productos o archivos multimedia. En el cuarto paso, no le pidas al usuario que proporcione nuevos activos de forma temporal, a menos que el usuario elija hacerlo; para el contenido que aún no se haya proporcionado en esta etapa, genera un sustituto (stand-in), usa un marcador de posición nativo del código, márcalo como replace-later o, si puede causar confusión, márcalo como blocked.
2. Nueva generación de imágenes: debe anclarse al área de referencia correspondiente. Antes de escribir cualquier prompt de generación, vuelve a abrir la imagen de referencia confirmada y transcribe el área objetivo en una lista visual: tipo de escena (collage de tarjetas de papel / escena fotográfica / ilustración plana / maqueta de UI / campo de textura), cada objeto principal y su posición aproximada, valores hex de la paleta de colores, luz, textura, diseño de espacio en blanco. El prompt de generación debe escribirse a partir de esta transcripción — mismo tipo de escena, misma lista de objetos, misma composición y paleta de colores — nunca a partir del nombre del activo o un resumen de una línea de la lista de desglose. Si la herramienta de generación admite la entrada de imágenes, adjunta el área de referencia como referencia visual. Un prompt que solo escriba categorías de contenido ("el creador está sentado en un escritorio con un cuaderno y tarjetas") sin la transcripción es un defecto: equivale a autorizar que el modelo invente una escena diferente. Para el texto de marcador de posición dentro del activo, solicita "barras y garabatos de marcador de posición abstractos e ilegibles" – no uses la palabra "greeked", ya que los modelos de generación podrían interpretarlo literalmente como texto en griego.

La imagen de referencia confirmada es el objetivo de construcción y la línea de base de QA, no una fuente de activos. No recortes, captures de pantalla, rebanaes ni extraigas áreas de la imagen de referencia en la construcción; el recorte hereda baja resolución, texto horneado y bordes rotos. No hay un estado extract en el manifiesto. Cuando un área de referencia necesite un activo, regenera esa área con una descripción visual.

...

[truncado por límite de traducción]