En mi servidor de hosting de Opus Growth
[nombre del servidor], crea el informe de impacto de
[año] de
[nombre de la organización] como un sitio que cuenta su historia a medida que se hace scroll. Organización:
[qué hace, dónde, año de fundación]. El mensaje principal del informe:
[una frase]. Las cuatro cifras destacadas:
[cifra, unidad, explicación en una frase]. Datos de los gráficos:
[para cada gráfico, título, periodos y valores]. Presupuesto: [fuentes de ingresos y partidas de gasto, importes y porcentajes]. Capítulos:
[nombres de los capítulos y el texto o las notas de cada uno]. Plan del próximo año:
[elementos]. De dónde provienen las cifras y cuáles son sus límites:
[qué registros, cómo se trataron los datos que faltaban]. Elaborado por y fecha de publicación:
[nombre del editor, fecha]. Contacto:
[correo electrónico],
[teléfono],
[dirección]. Dominio:
[dominio]. Fotos:
[enlaces; sin rostros de niños ni de beneficiarios].
Páginas: informe (/: titular de portada, párrafo de resumen que responde primero, autor y fecha, imagen de portada, navegación de capítulos fija y, en este orden, resumen del año, capítulos, presupuesto, plan del próximo año y preguntas sobre el informe), metodología (/yontem/: la fuente y los límites de cada cifra), organización y contacto (/dernek/ o un nombre que encaje con tu organización), privacidad y KVKK (/gizlilik/) y 404.html. Escribe los gráficos como SVG estático generado a partir de los valores que te di, no con Chart.js ni D3; no redondees los valores y comprueba que los totales cuadran. Muestra el presupuesto como una `<table>` sin ningún ancho mínimo, no como un gráfico.
Estilo: una lectura larga al estilo de una historia de datos de periódico. Fondo en tono papel, una serif de Fontshare para los títulos (por ejemplo Bespoke Serif) y una tipografía de cuerpo legible que admita tabular-nums (por ejemplo Epilogue), con como máximo dos colores de gráfico. En escritorio, una lista de capítulos fija de 220 px a la izquierda; en móvil, una tira de capítulos con scroll horizontal que se queda fija arriba, con una fina línea de progreso de lectura debajo.
Reglas de movimiento (la parte más difícil, síguelas al pie de la letra):
1. Librerías: solo el núcleo de GSAP 3.13 y ScrollTrigger, solo en la página del informe. NO se carga Lenis, porque el scroll nativo es más cómodo para una lectura larga; tampoco se cargan SplitText ni librerías de gráficos. No hay ningún script en las páginas de metodología, organización y privacidad.
2. Gráficos de líneas: cada línea es un `<path pathLength="1">` y está completamente dibujada en el HTML. JS establece strokeDasharray 1 y strokeDashoffset 1 solo en los gráficos que están por debajo de la pantalla al cargar y lleva el offset a 0 con ScrollTrigger scrub (start "top 75%", end "bottom 65%"); los puntos de datos van apareciendo a medida que la línea pasa por ellos. Haz que el texto SVG mida al menos 22 unidades en un viewBox de 600 unidades para que se mantenga por encima de 12 px en móvil, y deja al menos 40 unidades a la derecha para que no se corte la última etiqueta del eje.
3. Cada gráfico es un `<svg role="img" aria-labelledby>` con un title y un desc que enuncia todos los valores en una frase; el figcaption muestra la fuente y enlaza a la nota metodológica, e INMEDIATAMENTE DESPUÉS de la figure un `<details>` con la etiqueta "Ver los datos como tabla" contiene una `<table>` real. Esa tabla es la versión en texto de los datos, tanto para la accesibilidad como para la búsqueda con IA.
4. Contadores: el valor final está escrito en el HTML en formato turco (como 31.540). El número visual va en un span aria-hidden y el mismo valor va en un span sr-only para los lectores de pantalla. JS pone a 0 solo los contadores que están por debajo de la pantalla al cargar y los cuenta hacia arriba con Intl.NumberFormat("tr-TR") cuando entran en pantalla; nunca rebobines un número que ya es visible. Dale al número tabular-nums y un ancho mínimo igual al número de caracteres del valor final (con una clase de Tailwind, no con un atributo style) para que la línea no se mueva mientras cuenta.
5. Navegación de capítulos: los enlaces son anclas que funcionan sin JS. JS usa ScrollTrigger por capítulo para encontrar el activo, pone aria-current="true" en su enlace y desplaza la tira del móvil hacia los lados para que el enlace activo sea visible (la tira, no la página). Pon el comportamiento fijo en la barra lateral (aside) que es hija directa de la cuadrícula que abarca todo el informe, no en el nav interior; en la demo, el sticky en el nav interior nunca se quedaba fijo en móvil.
6. Ningún otro movimiento aparte de la línea de progreso de lectura y las imágenes que aparecen con data-reveal.
Configuración y trampas conocidas (cada una costó puntos o rompió algo en la medición de la demo, no te saltes ninguna):
1. Si ya hay un sitio en producción en el servidor, avísame primero, porque la configuración sobrescribe index.html y la carpeta assets. Previsualiza scaffold_site con confirm=false y llama con confirm=true tras mi aprobación. Después lee site_design_guide y site_seo_guide. Antes de escribir código, pon la dirección de diseño (tipografía, color, cuadrícula, elemento distintivo, lenguaje de movimiento y las librerías que NO se cargarán) en un breve ART.md fuera de assets y muéstramelo.
2. Compila Tailwind, no lo cargues desde el CDN. Instala `npm i -D tailwindcss@3` con site_run_command y background=true, y sigue el proceso con site_command_status. Las rutas content de `tailwind.config.js` deben cubrir todos los archivos HTML, todas las plantillas y todos los archivos JS que escriban clases. `_src/tw.css` contiene una línea `@import "../assets/app.css";` y 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 las páginas y enlaza solo `/assets/site.css`. Recompila tras cada cambio en el HTML.
3. Aloja las fuentes tú mismo. Primero comprueba que la familia de Fontshare que elijas tenga las letras turcas (ş, ğ, ı, İ, ç, ö, ü): en la demo, Tanker no tenía la ı sin punto y Outfit no tenía ş, ğ ni İ, así que esas letras habrían caído a otra fuente en los títulos. Descarga el woff2 de cada peso por separado con site_fetch en `assets/fonts/`, escribe las reglas @font-face con `font-display: swap` en `assets/app.css` (design-check busca ahí la fuente personalizada) y comprueba el nombre de font-family en el CSS que descargaste. Haz preload de las fuentes de títulos y de cuerpo usadas above the fold en cada página con `<link rel="preload" as="font" type="font/woff2" crossorigin>`, antes de la hoja de estilos; no hagas preload de más de dos archivos, porque en la demo hacer preload de un tercer peso alargó el LCP móvil en 0,2 segundos. La mayoría de las fuentes de Fontshare no tienen el signo ₺, así que escribe "TL" para los precios.
4. Haz que el menú y el pie de página sean HTML estático. No cargues chrome.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. Las plantillas no deben terminar en .html y deben usar marcadores como `
[[NAV]]` en lugar de `{{...}}`. Construye el menú móvil sin JS usando `<details>`. Mantén el nombre de la organización, la dirección y el teléfono como texto plano en el pie de página, y haz que cada elemento táctil mida al menos 44x44 px, incluidos los enlaces del pie y de las migas de pan.
5. Convierte las imágenes mientras las descargas con site_fetch: escribe la misma foto con resize="480x", "800x" y "1200x", image_format="webp", quality=65 en archivos separados. site_fetch nunca recorta; cuando una foto de Unsplash necesite otra proporción, descarga la versión recortada añadiendo parámetros como `?w=1600&h=1200&fit=crop` a su URL. Dale a cada `<img>` srcset, sizes y un width y height que coincidan con la proporción real. La imagen principal above the fold lleva fetchpriority="high" y no es lazy; las demás llevan loading="lazy" decoding="async". Si la imagen principal llena la pantalla en móvil, sirve un recorte más pequeño con `<picture>`.
6. Escribe la versión SVG del logo como favicon.svg con site_write_file y añade `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a cada página. Sin favicon el navegador registra un 404 y Best Practices baja a 96.
7. Reglas del validador HTML: empieza con un `<!DOCTYPE html>` en mayúsculas, usa ` ` para los espacios del texto visible de los enlaces tel:, no uses nunca un atributo style="", pon type="button" a cada botón y no pongas un `<details>` dentro de una `<figure>` después de su figcaption.
8. Descarga las librerías de movimiento (GSAP, ScrollTrigger) de jsdelivr a `assets/vendor/` con site_fetch, fija la versión y cárgalas solo en la página del informe. No uses `<script defer>`; pon un pequeño cargador al final de la página que espere al evento load, dos llamadas a requestAnimationFrame y luego a requestIdleCallback, y añada los scripts en orden con async=false. Un script de una línea en `<head>` añade la clase `js` a `<html>` y la clase `anim` salvo que prefers-reduced-motion sea "reduce"; sin `anim` el cargador no descarga nada. Define los estados iniciales ocultos solo bajo `.anim` y añade una animación CSS como red de seguridad que revele todos los elementos ocultos a los 2,5 segundos por si la librería nunca llega. En demos anteriores, las librerías con defer llevaron el LCP móvil a 3,2 segundos; con este cargador las páginas midieron entre 99 y 100. Llama data-reveal al atributo de los elementos que aparecen con el scroll; design-check solo reconoce el movimiento por ese nombre.
SEO, AEO y GEO:
1. Usa URL de estilo directorio con barra final (/yontem/, /dernek/, /gizlilik/). Rellena el bloque seo de site.config.js y ejecuta `node seo-stamp.mjs`. Escribe el schema específico de cada página (página del informe: WebPage con un Report como mainEntity, que incluya headline, datePublished, dateModified, image, author (Person, el editor) y publisher, más FAQPage; metodología: Article; página de la organización: AboutPage con un subtipo adecuado a la organización (por ejemplo NGO); BreadcrumbList en las páginas interiores. Si no hay una oficina que reciba visitas, localBusiness:false en site.config.js) en bloques `<script type="application/ld+json">` separados y enlázalos con el grafo base mediante @id. No anides BreadcrumbList dentro de @graph; mantenlo en su propio bloque, porque es la única forma en que seo-check lo ve.
2. Mantén los títulos en 60 caracteres o menos (seo-check marca como error cualquiera de más de 65), las descripciones entre 120 y 158 caracteres, un solo h1 por página y ningún nivel de encabezado saltado (un h3 justo después del h1 bajó la accesibilidad a 98). Cada página necesita al menos 150 palabras de contenido principal; las páginas de contacto y privacidad suelen quedarse cortas.
3. El primer párrafo de cada página responde directamente a la pregunta de la página. Escribe FAQs específicas de cada página con `<details>` y márcalas como FAQPage. Muestra la organización editora y una fecha de "Última actualización" en `<time>`.
4. En robots.txt, anota y justifica tu decisión 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. Dale a sitemap.xml fechas lastmod reales. llms.txt contiene un resumen exacto del sitio en dos frases, los datos clave y una lista de las páginas importantes.
5. Nada inventado: no escribas reseñas, valoraciones, premios, cifras de clientes, certificados, horarios, coordenadas ni precios sin preguntarme. Deja fuera del schema cualquier campo que no conozcas.
Controles de calidad (en orden; no digas "listo" 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 usando 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 sin movimiento está roto. Las imágenes lazy más abajo pueden salir en blanco en la captura de página completa; no lo cuentes como error, pero comprueba sus rutas.
3. Ejecuta core_web_vitals con strategy="mobile" y strategy="desktop" para cada página. Criterio de aceptación: en móvil, Performance de al menos 95 y Accessibility, Best Practices y SEO en 100; en escritorio, las cuatro de al menos 95. Si una página no llega, encuentra el archivo lento con resources=true, 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 ninguna dirección ajena a tu propio dominio en la lista de peticiones de red.
4. Sin scroll horizontal a 360, 390, 768 y 1440 px, elementos táctiles de al menos 44 px y sin errores en la consola. El sitio también debe verse impecable dentro de un marco de 390x790 y de 1440x898, como en las páginas de prompts.
Comprobación del movimiento: site_preview no puede mostrar el movimiento, así que dime qué mirar en mi propio navegador. En escritorio, los contadores deben contar de cero al valor final cuando entren en pantalla, las líneas de los gráficos deben dibujarse de izquierda a derecha al hacer scroll con los puntos apareciendo uno a uno, y la lista de capítulos de la izquierda debe marcar el capítulo que estás leyendo. En móvil, la tira de capítulos debe quedarse fija arriba y deslizar el capítulo activo a la vista. Con reduce motion activado y con JavaScript desactivado, cada cifra muestra su valor final y cada gráfico está completamente dibujado; las tablas de datos se pueden abrir.
Tras publicar: previsualiza la regla `/assets/* Cache-Control: public, max-age=31536000, immutable` con site_headers y aplícala tras mi aprobación; a partir de entonces, versiona el nombre del archivo cada vez que cambien el CSS o el JS (site-v2.css, etc.). Envía sitemap.xml con gsc_submit_sitemap y revisa la página de inicio con gsc_url_inspect. Por último, dame: una tabla de puntuaciones por página (página, las cuatro puntuaciones móviles, las cuatro de escritorio, LCP, CLS), los resultados de los controles, el resultado de las interacciones que probaste en un navegador y la lista de correcciones que aplicaste.
