En el sitio
[server name] de mi servidor de hosting de Opus Growth, crea un sitio de evento estático y rápido para
[event name]. Evento:
[what it is, who it is for, which edition, two sentences]. Fecha y hora:
[start and end, time zone]. Lugar: [venue name, full address, transport, parking, accessibility facilities]. Programa:
[for each day the time, session title, speaker and room]. Ponentes: [name, title, organisation, talk title, bio, photo link and permission to publish the photo]. Entradas: [ticket types, prices, whether VAT is included, valid dates, the link on the ticketing platform, refund and transfer terms]. Organizador:
[organisation name],
[email],
[phone]. Política de grabación y fotografías:
[whether talks are recorded and photos taken]. Dominio:
[domain].
Páginas: inicio (una línea con fecha y lugar, cuenta atrás, breve introducción, qué va a pasar, cuatro de los ponentes, un resumen del lugar, FAQ), programa (/program/: pestañas por día y un archivo de calendario .ics), ponentes (/konusmacilar/), entradas (/bilet/: tipos de entrada, qué incluye, reembolsos, FAQ de facturación), lugar (/mekan/: dirección, transporte, accesibilidad, alojamiento), privacidad (/gizlilik/, incluida la opción sobre fotos y grabaciones) y 404.html.
Estilo: cartel de conferencia. Si no se indica
[colour preference], una franja hero amarillo señal, fondo crema, texto negro y bordes negros de 2 píxeles. Una tipografía ancha y en negrita de Fontshare, en mayúsculas, para los títulos (por ejemplo Panchang 700) y una sans redondeada para el cuerpo del texto (por ejemplo Chillax 400 y 500); precarga los tres archivos de la primera pantalla. Las mayúsculas requieren `<html lang="tr">`; de lo contrario, la "i" se convierte en "I". Si un ponente no tiene foto o no hay permiso para publicarla, usa un monograma con sus iniciales; nunca uses la foto de otra persona.
Reglas de interacción (sin librerías, un único `ix.js` con defer, solo en las páginas de inicio, programa y ponentes):
1. La cuenta atrás es correcta incluso con JS desactivado: el HTML contiene el texto "Starts: <time datetime="2027-05-13T09:00:00+03:00">Thursday 13 May 2027, 09.00</time> (Turkey time)" dentro de una caja de altura fija. JS lee las fechas ISO con desfase horario de data-start y data-end con Date.parse y escribe las cajas de día, hora y minuto en esa misma caja. La caja debe tener la misma altura en ambos estados (min-height en CSS y una altura de unidad fija); de lo contrario, la primera pantalla se desplaza. No muestres segundos; actualiza cada minuto y detén la actualización mientras la pestaña esté oculta. Las cajas con números llevan aria-hidden, con una única frase visualmente oculta para lectores de pantalla a su lado, y sin región en vivo (aria-live), porque se leería en voz alta cada minuto. Cuando el evento haya empezado escribe "happening now"; cuando haya terminado, "has ended"; nunca muestres números negativos para una fecha pasada.
2. Pestañas por día: en el HTML cada día es una sección independiente con su propio encabezado (id="gun-1", "gun-2"), con enlaces a esas secciones encima; con JS desactivado se muestran todos los días uno debajo de otro. El contenedor de los enlaces lleva role="group" y un aria-label. JS los convierte en pestañas ARIA (tablist, tab, tabpanel, aria-selected, tabindex, teclas de flecha, Inicio y Fin), selecciona el segundo día cuando la página se abre con #gun-2 y actualiza la URL con history.replaceState al cambiar de pestaña, para poder compartir un día como enlace. Cada sesión es una fila de lista con un `<time datetime>`: hora, título, un enlace al ancla del ponente en la página de ponentes y la sala; las pausas tienen un fondo distinto.
3. Biografía del ponente: en el HTML está dentro de un `<details>` en cada ficha, de modo que es legible con JS desactivado y por los buscadores. JS intercepta el clic en el summary, construye un único `<dialog>`, copia en él el nombre, el cargo, el título de la charla y la biografía con textContent, lo abre con showModal y lleva el foco al botón "Close"; Esc y un clic en el fondo lo cierran y el foco vuelve al summary. Añade aria-haspopup="dialog" al summary. El id de cada ficha es el slug del ponente, que es adonde apuntan los enlaces de la agenda.
4. Llamada a la acción fija para las entradas: un botón "Get tickets" en la cabecera en escritorio y, en móvil, una barra fija en la parte inferior de la pantalla (fecha, precio más bajo y "Get tickets"). La barra es HTML estático en la plantilla del pie de página y es position: fixed desde el primer renderizado; añadirla después con JS provoca un desplazamiento de diseño. En móvil, da al body un padding inferior igual a la altura de la barra para que los últimos enlaces no queden ocultos debajo, añade `env(safe-area-inset-bottom)` y oculta la barra en la página de entradas mediante una clase en el body.
5. Archivo de calendario: `/assets/
[event].ics` descargable desde la página del programa (VCALENDAR con un VEVENT, DTSTART y DTEND en UTC, SUMMARY, LOCATION, URL, saltos de línea CRLF). Da al enlace el atributo download.
Schema: el mismo Event (@id /#event) en las páginas de inicio, programa y entradas: name, description, startDate y endDate con desfase horario, eventStatus EventScheduled, eventAttendanceMode OfflineEventAttendanceMode, location como un Place con una PostalAddress completa, tres imágenes en proporciones 1x1, 4x3 y 16x9, organizer, los ponentes como performer y un array offers (para cada tipo de entrada name, price, priceCurrency "TRY", availability, validFrom, validThrough para las de venta anticipada y la página de venta como url). El resultado enriquecido de evento de Google exige location y startDate y no fusiona @id entre páginas, así que escribe el Event completo en cada página que lo use; en la página del programa añade además cada sesión como subEvent. Si el evento se aplaza o se cancela, establece eventStatus en EventPostponed o EventCancelled en lugar de eliminar la página. Place en la página del lugar y BreadcrumbList en cada página interior. Los patrocinadores, las cifras de asistentes o "agotado" se escriben solo si son ciertos.
Configuración y errores conocidos (cada uno costó puntos en las mediciones de la demo, no omitas ninguno):
1. Si ya hay un sitio activo en el servidor, dímelo primero, porque la configuración inicial sobrescribe index.html y la carpeta assets. Previsualiza scaffold_site con confirm=false y llámalo con confirm=true solo después de que yo lo apruebe. Después lee site_design_guide y site_seo_guide. Antes de escribir código, pon la dirección de diseño (tipografía, colores, cuadrícula, elemento distintivo, lenguaje de movimiento y las librerías que NO se cargarán) en un breve archivo ART.md fuera de assets y muéstramelo.
2. Compila Tailwind, no lo cargues desde el CDN. Instálalo con site_run_command y background=true (`npm i -D tailwindcss@3`) y haz seguimiento con site_command_status. Las rutas content de `tailwind.config.js` deben cubrir todos los archivos HTML, las plantillas de `_src` y cualquier archivo JS que escriba clases. `_src/tw.css` contiene la línea `@import "../assets/app.css";` más las tres líneas `@tailwind`; compílalo en un único archivo con `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Elimina el script cdn.tailwindcss.com y el tailwind.config en línea de todas las páginas y enlaza solo `/assets/site.css`. Recompila después de cada cambio en el HTML.
3. Aloja las fuentes tú mismo. Lee el CSS de la familia de Fontshare que hayas elegido, descarga el woff2 de cada peso por separado con site_fetch en `assets/fonts/` y escribe las reglas @font-face con `font-display: swap` en `assets/app.css`, que es donde design-check busca una fuente personalizada. Comprueba el nombre de font-family en el CSS descargado y confirma que la familia tiene las letras turcas ı, İ, ş y ğ (Tanker no tiene ı). Precarga TODOS los pesos usados en la primera pantalla con `<link rel="preload" as="font" type="font/woff2" crossorigin>`, colocado antes de la línea de la hoja de estilos; si son más de tres archivos, usa menos pesos. En la demo, un único peso del cuerpo sin precargar llevó el LCP móvil a 2,6 segundos y bajó Performance a 97. La mayoría de las fuentes de Fontshare no tienen el símbolo ₺, así que escribe los precios con "TL".
4. Haz que el menú y el pie de página sean HTML estático. No cargues chrome.js, motion.js ni site.config.js en las páginas. Escribe un pequeño `chrome-stamp.mjs` que lea la lista de navegación de site.config.js y estampe `_src/header.tpl` y `_src/footer.tpl` entre los marcadores `<!-- nav:start --><!-- nav:end -->` y `<!-- footer:start --><!-- footer:end -->` en cada página, añadiendo aria-current="page" al enlace activo. Usa marcadores como `
[[NAV]]` en lugar de `{{...}}` y no des a las plantillas la extensión .html; de lo contrario, design-check y seo-check las tratarán como páginas a medio hacer. Construye el menú móvil con un `<details>` sin JS. Mantén el nombre del negocio, la dirección y el teléfono como texto plano en el pie de página, y haz que los enlaces del pie y de las migas de pan midan al menos 44 píxeles de alto.
5. Convierte las imágenes al obtenerlas con site_fetch: escribe la misma imagen como archivos separados con resize="480x", "800x" y "1200x", image_format="webp", quality=60 (site_fetch no recorta, así que pide el original en la proporción que necesites). Da a cada `<img>` srcset, sizes y width y height que coincidan con la proporción real. La imagen que sea el elemento LCP de la página recibe fetchpriority="high" y no es lazy; todas las demás imágenes reciben loading="lazy" decoding="async". Si una imagen llena la primera pantalla móvil, sirve un recorte más pequeño a móvil con `<picture>`.
6. Añade `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a cada página y crea un apple-touch-icon de 180 píxeles a partir del logo con site_fetch y resize="180x180". Sin un enlace de favicon, el navegador solicita /favicon.ico, registra un 404 y Best Practices baja a 96.
7. Reglas del validador HTML: empieza cada documento con un `<!DOCTYPE html>` en mayúsculas; cada espacio en el texto visible de un enlace tel: debe ser ` `, incluido el que sigue a un prefijo como "Call: 0212..."; no uses style=""; da a cada botón un type; pon aria-label solo en landmarks, formularios o elementos interactivos (en un ul o en un div sin rol fue un error); nunca etiquetes dos landmarks con el mismo nombre; no dejes espacios en blanco al final de línea.
8. No saltes niveles de encabezado: en una página de listado, los títulos de tarjeta como h3 justo después del h1 bajaron Accessibility a 98. Cuando reutilices una tarjeta, establece el nivel de encabezado por página (h2 en una página de listado, h3 dentro de una sección h2).
9. Llama data-reveal al atributo de movimiento (design-check solo reconoce el movimiento por ese nombre). JS aplica el estado inicial oculto solo a los bloques que están por debajo de la pantalla cuando se abre la página, y nunca oculta el contenido de la primera pantalla; usa transform, porque desvanecer con opacity reduce la auditoría de contraste. Pon el atributo en el bloque que envuelve un encabezado y su descripción, no solo en el encabezado; en la demo, un encabezado en espera se deslizó sobre el párrafo de debajo. Con prefers-reduced-motion: reduce no se oculta nada y las animaciones están desactivadas.
SEO, AEO y GEO:
1. Usa URLs de estilo directorio con barra final. Rellena el bloque seo de site.config.js y ejecuta `node seo-stamp.mjs`. Escribe el schema específico de cada página en bloques `<script type="application/ld+json">` separados, vinculados al grafo base mediante @id. No anides BreadcrumbList dentro de @graph; mantenlo en su propio bloque, que es la única forma en que seo-check lo detecta.
2. Títulos de como máximo 60 caracteres (seo-check marca como error cualquiera de menos de 25 o más de 65), descripciones de 130 a 158 caracteres, un h1 por página y al menos 150 palabras de contenido principal en cada página. Las páginas de contacto, privacidad y listados tienden a quedarse cortas; añade información específica de la página, no relleno.
3. El primer párrafo de cada página responde directamente a la pregunta de la página. Escribe FAQ específicas de cada página con `<details>` y márcalas como FAQPage. Muestra el publisher y una fecha de "Last updated" en un elemento `<time>`.
4. En robots.txt, escribe tu decisión con su motivo para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot y CCBot, y apunta al sitemap. sitemap.xml lleva fechas lastmod reales. llms.txt contiene un resumen exacto del sitio en dos frases y una lista de las páginas importantes.
5. Nada de invenciones: no escribas reseñas, valoraciones, premios, cifras de clientes, certificados, horarios de apertura, coordenadas ni precios sin preguntarme. Deja fuera del schema por completo cualquier campo que no conozcas.
Controles (en orden; no digas "hecho" hasta que todos pasen):
1. Con site_run_command ejecuta `node chrome-stamp.mjs`, la compilación de Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 errores, 0 advertencias), `node design-check.mjs` (0 errores; justifica cualquier advertencia que quede) y `npx html-validate "**/*.html"` (0 errores).
2. Revisa cada página con site_preview, view="mobile" y view="desktop". site_preview captura la página con el movimiento desactivado (reduced-motion); si falta contenido en esa captura, el estado estático está roto. En las capturas de página completa, los elementos fijos como una barra fija pueden aparecer a mitad de la página y las imágenes lazy más abajo pueden verse en blanco; no los cuentes como errores, pero comprueba sus rutas.
3. Ejecuta core_web_vitals para cada página con strategy="mobile" y strategy="desktop". Criterio de aceptación: en móvil Performance de al menos 95 (objetivo 99 a 100) y Accessibility, Best Practices y SEO en 100; en escritorio las cuatro en 100. Para una página que no llegue, usa resources=true para encontrar el archivo que la retrasa, corrígelo y vuelve a medir. Después ejecuta seo_audit en la página de inicio con strategy="mobile" y runs=2. No debe quedar en la lista de solicitudes de red ninguna dirección ajena a tu propio dominio.
4. Sin desplazamiento horizontal con 360, 390, 768 y 1440 píxeles de ancho, áreas táctiles de al menos 44 píxeles, sin errores en la consola.
Comprobación de interacción: site_preview no puede mostrar el tiempo, las pestañas ni los diálogos. Dime cómo comprobar que la cuenta atrás muestra la fecha correcta con JavaScript desactivado y se convierte en cajas de la misma altura con JS activado, que /program/#gun-2 abre el segundo día y que las pestañas cambian con las teclas de flecha, que la biografía de un ponente se abre en un modal y el foco vuelve tras Esc, que en un teléfono la barra de entradas no tapa los últimos enlaces de la página, que el archivo de calendario llega al calendario del teléfono a la hora correcta y que la Rich Results Test de Google muestra el Event sin errores.
Tras publicar: previsualiza con site_headers la regla `/assets/* Cache-Control: public, max-age=31536000, immutable` y aplícala una vez que yo la apruebe; a partir de entonces, versiona el nombre del archivo siempre que cambien el CSS o el JS (site-v2.css y así sucesivamente). Envía sitemap.xml con gsc_submit_sitemap y revisa la página de inicio con gsc_url_inspect. Al final entrégame: una tabla de puntuaciones por página (página, cuatro puntuaciones móviles, cuatro puntuaciones de escritorio, LCP, CLS), el resultado de cada control y la lista de correcciones que aplicaste.
