Vivelebacon/demo-website

Demo website

Una ejecución lleva a un prospecto desde "sí, me gustaría verlo" hasta un rediseño en vivo y una respuesta esperando en Borradores. El usuario pega una URL o un nombre; todo lo demás se descubre, no se pregunta. La dirección creativa está delegada para toda la ejecución: no te detengas para pedir respuestas de entrevistas o aprobaciones.

Construcción de referencia: una vez que hayas entregado una demo con la que estés satisfecho, consérvala como referencia. Lee su BRIEF.md y copia su estructura (site.css, site.js, pages.css, home.css, home.js, lab/) como esqueleto inicial. Nunca copies su diseño: la compuerta de huella digital lo prohíbe.

Reglas fijas para cada demo

• Conservar: el logo, cada fotografía, cada palabra del texto, cada página y el orden de las secciones dentro de cada página. Los errores tipográficos se mantienen. Las etiquetas de navegación se mantienen. Las etiquetas de CTA se mantienen.
• Cambiar: todo lo visual. Diseño, tipografía, uso del color, movimiento, interacción.
• Todas las páginas se rediseñan, no solo la página de inicio. Un archivo HTML por página original, mismos slugs (cleanUrls mantiene /servicios funcionando).
• Adiciones permitidas: solo microcopia de UI mínima (líneas de estado de formularios, un placeholder de entrada, etiquetas aria). Sin nuevo texto de marketing, sin números inventados.
• Las reglas de la casa prevalecen sobre cualquier referencia (edita esta lista a tu gusto): paleta clara con el acento del cliente, marca + foto del dueño + todos los servicios visibles en el héroe, cabecera fija siempre visible, el clic en el logo vuelve al inicio (desplazamiento suave en la página de inicio), sin barra lateral, sin guiones largos visibles en ninguna parte, solo fotos del cliente (sin generación a menos que el usuario lo pida).
• Desplegar en Vercel producción y hacer commit sin preguntar. Los correos electrónicos son solo borradores.

Paso 0 · Identificar al prospecto

1. Si el usuario dio un nombre, no una URL, y tienes un CRM: busca al prospecto allí para obtener el sitio web, la ciudad, el idioma, el buzón desde el que se envió el contacto y el estado de la respuesta. Si el prospecto no está en un CRM, trabaja desde la URL y no preguntes nada; el paso del borrador dirá qué buzón se necesita.
2. Slug: la raíz del dominio, ej. acmecoaching. Carpeta de construcción: demos/<slug>-scrollcraft/. Proyecto de Vercel: <slug>-redesign. URL de la demo: https://<slug>-redesign.vercel.app (con guión, nunca un punto: un subdominio con punto no existe, y un enlace muerto es el error más costoso de este pipeline).
3. Nombre de pila para el correo: de la firma del correo del prospecto, la página about/contacto del sitio o el dominio ("janecoaching" → Jane). Si es realmente desconocido, omítelo ("Bonjour," / "Hola,").

Paso 1 · Capturar todo el sitio web existente

Todo va a <build>/_src/ (activos sin procesar) y <build>/lab/ (notas, capturas).

1. Obtén la página de inicio y lee los enlaces de navegación + pie de página para listar cada página. Obtén cada página.
2. Extrae por página, en orden: secciones, encabezados, párrafos (con tramos en negrita/cursiva), listas, botones y sus destinos, imágenes (URLs de resolución completa; para Squarespace añade ?format=2500w, para Wix elimina la transformación /v1/fill/...), formularios (etiquetas de campos, indicadores de obligatoriedad, etiqueta de envío, mensaje de éxito), video incrustado. Squarespace mantiene las definiciones de formulario en data-block-json / formFields.
3. Descarga el logo (todas las variantes: oscuro, claro, favicon), cada foto, cada textura. Vectoriza un logo geométrico simple a SVG con cv2.findContours + approxPolyDP en su canal alfa; conserva el PNG para marcas complejas.
4. Fichas de marca: color de acento/tinta/fondo de las variables CSS del sitio, caras de encabezado y cuerpo. Elige la fuente de Google más cercana cuando la cara sea Typekit o personalizada.
5. Capturas de pantalla de página completa de cada página en vivo (scripts/full.mjs <live-url> 1440 900 lab/live <pages>) y léelas: esa es la estructura que debes mantener.

Paso 2 · Diseñar con scroll-craft

Carga tu skill de investigación de diseño si tienes una, luego scroll-craft (https://github.com/nateherkai/scroll-craft) y sigue scroll-craft de principio a fin con estas modificaciones:

• El brief es autoredactado bajo delegación creativa explícita (la instrucción permanente del usuario es esta skill). Escribe BRIEF.md con: las reglas fijas anteriores, la evidencia del Paso 1, los ocho temas redactados, una gramática nombrada con restricciones reales, la curva de sensación, el pico único, la frase para contarle a alguien, el movimiento característico, la tabla de puntuación y un plan breve para cada página interna.
• Ejecuta la compuerta de huella digital contra tu espacio de trabajo de scroll-craft FINGERPRINTS.md (4 de 6 contra cada fila). Lee la línea "Lo que la próxima construcción debe evitar" de cada fila reciente. El movimiento característico debe venir de esta marca (su geometría de logo, su eslogan, su propia foto), no de la última construcción.
• La estructura está fijada por el cliente, por lo que la gramática y los dispositivos cambian cómo se comportan las mismas secciones, nunca qué secciones existen.
• Motor vanilla (scrollcraft.js/.css copiados sin modificar), HTML plano multipágina, JS local para escenas a medida.

Paso 3 · Construir

• Compartidos: site.css (fichas, cabecera, menú, pie de página, botones, marcos, entradas), site.js (monta el motor, estado de la cabecera, menú, logo al inicio, entradas, formulario), pages.css para páginas internas, home.css/home.js para las escenas a medida de la página de inicio.
• Está bien generar la estructura de las páginas internas con un script de una sola ejecución; después los archivos HTML son la fuente. Indícalo en BRIEF.md.
• Formularios de contacto: transferencia mailto: a la dirección del cliente con method="post", validación y una línea de estado que diga claramente que se abre la aplicación de correo y no se envía nada hasta que el usuario presione enviar. Nunca finjas un éxito.
• Tiendas y herramientas de reserva: enlaza a las páginas de productos/reservas existentes del cliente.

Errores que ya han costado una ronda

• Nunca establezcas position en un elemento [data-sc-stage]. El motor lo hace sticky; position: relative en tu CSS mata silenciosamente cada pin.
• El pico debe mantener el mayor data-sc-span en la página. Si el héroe crece, haz crecer el pico con él.
• Héroe en capas a partir de una foto: traza cada silueta con una ruta de borde DP (primero un degradado grueso, luego refina en el fino), reconstruye cada placa debajo de la siguiente silueta (cielo: degradado vertical ajustado; niebla lejana: color plano por columna; pendientes texturizadas: mosaico espejo ~110px), limpia las motas oscuras sobrantes encima de las líneas trazadas, luego mira la posición final del desplazamiento: las costuras solo se muestran al final del recorrido.
• Recortes de personas: rembg u2net_human_seg, erosiona la máscara ~2px y descontamina los colores del borde, o la pared original se mostrará como un halo. Recorta donde un plano de primer plano o una banda base oculta el corte.
• Cualquier cosa con white-space: nowrap dentro de una cuadrícula rompe los diseños de teléfonos; deja que los botones se envuelvan por debajo de 520px y usa minmax(0, 1fr).
• Los bloques decorativos inclinados desbordan la ventana gráfica en teléfonos: overflow-x: clip en su sección.
• Una imagen reemplazada conserva sus bytes antiguos en teléfonos durante una semana (encabezado de caché /assets): el nuevo arte obtiene un nuevo nombre de archivo (-v2).
• .prose p { margin: 0 } vence a .prose > * + *; escribe la regla de espaciado como .prose > * { margin: 0 } .prose > * + * { margin-top }.

Paso 4 · Verificar

Sirve localmente (node <scroll-craft>/scripts/serve.mjs --root . --port 4610) y usa scripts/snap.mjs / scripts/full.mjs de esta skill. Ambos resuelven playwright-core desde la carpeta en la que los ejecutes o cualquier carpeta padre, por lo que un npm i playwright-core en la raíz del proyecto cubre todas las construcciones debajo de ella.

• Escritorio 1440x900 en varias posiciones dentro de cada acto fijado, teléfono 390x844 y 360x640, movimiento reducido. Lee cada hoja; corrige y vuelve a tomar.
• Capturas de página completa de cada página interna a 1440 y 390: sin desbordamiento, sin texto recortado, sin celdas de cuadrícula vacías.
• Arnés scroll-craft: sin desplazamiento muerto, sin errores de consola, sin solicitudes fallidas.
• Contraste de texto sobre imágenes medido en píxeles compuestos (oculta el texto, lee los píxeles debajo de él); cuerpo 4.5:1, grande 3:1.
• Funcional: la interacción característica de principio a fin, mensajes de validación de formularios, menú abrir/Escape/foco, logo al inicio, anclas desde los servicios del héroe.
• Busca en la construcción guiones largos y en (U+2014, U+2013): cero visibles.

Paso 5 · Publicar

1. vercel.json: cleanUrls, buildCommand: null, outputDirectory: ".", caché de 7 días en /assets. .vercelignore: lab/ _src/ node_modules/ BRIEF.md.
2. vercel link --yes --project <slug>-redesign luego vercel deploy --prod --yes.
3. Prueba de humo la URL exacta que enviarás: cada página 200, activos clave 200, lab/ y BRIEF.md 404, una carga de navegador en vivo sin errores de consola.
4. Repositorio Git en la construcción (git init -b main), haz commit con -F <archivo> (nunca un here-string de PowerShell), gh repo create <usuario-github>/<slug>-redesign --private --source . --push, vercel git connect --yes. Ediciones posteriores: haz commit y push a main, lo que redepliega. Mantén el repositorio de la demo privado: contiene el logo, las fotos y el texto del prospecto.
5. Añade la fila de huella digital a tu espacio de trabajo FINGERPRINTS.md (las seis dimensiones, mundo, puerto, paleta, tipo, lo que comparte, lo que la próxima construcción debe evitar).

Paso 6 · Redactar la respuesta

python scripts/draft_demo_reply.py <correo-prospecto> --mailbox <alias> --url https://<slug>-redesign.vercel.app --first-name <Nombre>

Verifica que las URLs responden, encuentra el último correo del prospecto en el buzón de contacto, renderiza la plantilla "aquí está la demo" en el idioma del contacto (--lang fr|en) con la firma de ese buzón, guarda un borrador con hilo en la carpeta Borradores de ese buzón y lo lee de vuelta. Nunca envía. Ejecútalo con --dry-run primero si algo sobre el hilo parece inusual. Los buzones se configuran en .env (ver .env.example).

Cuando el prospecto haya respondido desde otra dirección distinta a la que escribiste (un buzón personal en lugar de info@), pásalo con --to <su-dirección>: la respuesta se busca desde ese remitente y el borrador va a esa dirección. Algunos servidores IMAP solo coinciden con una búsqueda FROM en la dirección completa; un fragmento de dominio no devuelve nada.

Con un CRM conectado (DEMO_CRM_DIR, ver el README), <correo-prospecto> puede ser cualquier cosa que el CRM resuelva, el buzón y el idioma provienen del contacto, y el script registra la respuesta del prospecto y la URL de la demo.

Muestra el texto del borrador en el mensaje final. Dile al usuario que avise cuando se envíe para que la demo pueda marcarse como enviada.

Informe final (breve)

URL en vivo (la exacta) · páginas reconstruidas · la idea de diseño en dos líneas · el movimiento característico en una · las pocas adiciones de microcopia · lo que se verificó y lo que no (teléfono real, Safari) · el borrador (buzón, hilo, texto completo) · ruta local de la carpeta de construcción.