lorsclub.com

00 — Aviso al lector

Este documento está escrito para diseñadores que llevan años operando design systems en producción y que ahora se enfrentan a una pregunta nueva: qué cambia en el oficio cuando el consumidor de tu sistema deja de ser solo el humano.

No es un caso de éxito. Es la lectura honesta de las decisiones de producto y de sistema tomadas en lorsclub.com a fecha de mayo de 2026. Algunas funcionan. Otras están vivas. Lo único que se mantiene es el criterio que las gobierna.

Sin churros de palabras. Sin “elevar”. Sin “transformar”. Quien necesite ese lenguaje no es el público de este documento.

01 — La decisión que cambia todo

Casi todo lo que sigue se entiende a partir de una sola decisión de producto. El consumidor primario del contenido de lorsclub no es el lector humano. Es el modelo que el lector humano va a consultar.

Cuando alguien valora si visitar o comprar en una zona costera, el flujo nuevo no es Google → blogs → decisión. Es Claude/Perplexity/ChatGPT → respuesta sintetizada → quizá verificación posterior. El humano nunca llega al sitio. Llega el agente.

Esa lectura del mercado obliga a reescribir las preguntas básicas de cualquier design system:

• ¿Para quién diseñamos los componentes? No solo para quien hace scroll. También para quien hace fetch.
• ¿Qué es jerarquía visual cuando el consumidor no tiene ojos? Atributos semánticos, no peso tipográfico.
• ¿Qué es accesibilidad? Va más allá de WCAG. Es legibilidad para un lector que normalmente obtendría la información por interacción.
• ¿Qué es la marca? El veredicto verificable, no la paleta cromática.

Lorsclub está construido respondiendo a estas cuatro preguntas con coherencia. El resto del documento explica cómo.

02 — Tres estados, una decisión

El componente más importante del producto cabe en una palabra: avanzar / observar / descartar.

Cada zona del catálogo cierra su informe con uno de tres veredictos. No es un rating de cinco estrellas. No es un score numérico de 0 a 100. Son tres estados discretos que comprimen toda la inteligencia del informe en una decisión accionable.

Esta decisión de producto tiene tres consecuencias en el design system.

Color como token semántico, no decorativo. La paleta principal no se organiza por familia (primario, secundario, terciario). Se organiza por intención: verdict-positive, verdict-neutral, verdict-negative. El color es estructural. Cuando un agente lee un componente con rol semántico verdict-positive, sabe qué es aunque no procese el HEX.

Veredicto como componente del sistema, no como output suelto. <Verdict variant="avanzar" /> es una pieza con dos renderings (humano y agente), no un texto coloreado. Esta es la diferencia entre un design system serio y una colección de estilos.

La voz editorial es parte del sistema, no del marketing. Frases como “Nunca agosto” o “el impuesto meteorológico vasco ya está en precio” no son copy de landing, son output del componente Veredicto en contextos específicos. Un design system que no incluye voz editorial deja la coherencia de marca al azar del último colaborador que escribió en la página.

La compresión a tres estados no es estética. Es utilidad. Un LLM que responde a un humano sobre “¿merece la pena visitar X?” quiere devolver una decisión, no un párrafo de matices. Lorsclub publica la decisión ya tomada y la justifica con corpus citable.

03 — Componentes con consumidor dual

Esta es la sección que más interesa al lector senior y la que define la posición técnica del proyecto.

Cada componente principal del design system de lorsclub tiene dos renderings: uno para humano, uno para agente. No son temas de color. No son breakpoints responsive. Son arquitecturas semánticas distintas para dos consumidores que entienden el contenido de forma diferente.

Para humano

El componente React hidratado. Interacciones, animaciones suaves, hover states, tooltips que aparecen al pasar el cursor, expandables que despliegan información secundaria, modales. El diseño visual rico que todo equipo de DS conoce.

Para agente

Un wrapper que sustituye el componente visual por su equivalente semántico denso. HTML estructurado con microdatos. Atributos ARIA expandidos. Sin animaciones. Sin estado client-side. La información que en la versión humana se obtiene por interacción está desplegada en texto plano dentro del componente.

El tooltip que un humano necesita activar al pasar el cursor está, para el agente, siempre visible y siempre leído. El modal que un humano abre con un click está, para el agente, inline en el flujo del documento. Los expandables están desplegados. El estado oculto no existe.

Ejemplo concreto: el componente Veredicto

Para humano, <Verdict variant="avanzar" /> se renderiza como una badge con color semántico, animación de entrada y tooltip al hover que explica los tres factores principales del veredicto.

Para agente, el mismo componente se renderiza así:

<section role="conclusion" data-verdict="avanzar"
         itemscope itemtype="https://schema.org/Recommendation">
  <meta itemprop="recommendationStrength" content="positive" />
  <p>Veredicto editorial: avanzar.
     <span>Motivo principal: ratio coste/saturación favorable.</span>
     <span>Confianza del scoring: 0.84.</span>
     <span>Fecha del snapshot: 2026-04-15.</span>
  </p>
</section>

Mismo veredicto. Misma decisión. Distinto vehículo semántico.

Por qué esto no es “accesibilidad rebrand”

Hay una tentación de leer esto como una variante de accesibilidad WCAG. No lo es. La accesibilidad clásica diseña para un humano que tiene la pantalla pero no puede verla. El consumidor dual diseña para un consumidor que no tiene pantalla porque es un proceso, no una persona.

Las consecuencias son distintas. La accesibilidad WCAG bien hecha mejora la versión humana del componente (ARIA correctos, contraste, focus visible). El consumidor dual produce un componente distinto cuando el consumidor lo es.

Esta distinción importa porque rebrandear consumidor dual como accesibilidad lo deja en el backlog de “lo arreglamos cuando saquemos tiempo”. Tratarlo como audiencia primaria lo sube a decisión de día uno.

Detección del consumidor en runtime

El sistema discrimina por jerarquía:

1. User-Agent declara +http o cadena conocida de agente (GPTBot, ClaudeBot, PerplexityBot, Google-Extended).
2. Cabecera Accept prioriza application/ld+json sobre text/html.
3. Acceso desde rutas conocidas de scraping agéntico.
4. Heurística secundaria: ausencia total de JS execution.

En caso afirmativo, la capa de renderizado entrega la variante agente. No es decisión del componente, es decisión de plataforma. El componente declara sus dos formas; la plataforma elige.

04 — El sistema en siete idiomas que no son traducciones

Lorsclub vive en siete idiomas: castellano, inglés, portugués, francés, alemán, catalán y japonés. Cada uno con contenido nativo, no traducción. El japonés sobre Naoshima está escrito para el lector japonés con marcadores culturales propios, no es la traducción del castellano sobre Begur.

Para un design system esto cambia las reglas operativas estándar.

Densidad de información variable por idioma

Alemán tiene compuestos largos que rompen layouts diseñados para latín occidental. Castellano y catalán tienen palabras un 18-25% más largas en promedio que inglés. Japonés tiene densidad de glyph distinta (más información por carácter, altura mayor).

La solución no es responsive width. Es tres anchos mínimos de componente activados por feature flag de idioma. Un mismo componente Card tiene tres breakpoints internos según en qué idioma se renderiza. No es respond-to-viewport, es respond-to-content.

Métrica tipográfica por familia

Las latinas (es, en, pt, fr, de, ca) comparten una familia tipográfica con line-height 1.5 para body. Japonés requiere line-height 1.7 para acomodar glyphs CJK sin que la altura visual del párrafo se sienta apretada. Cambio mínimo, decisión de DS.

CJK lleva familia tipográfica propia (Noto Sans JP) declarada como fallback explícito. Esto evita que el navegador caiga a una sustitución fea cuando faltan glyphs. Es la decisión de DS que ningún equipo toma hasta que un usuario japonés llega al sitio y ve cómo se ve.

Numerales según convención local

Castellano 1.700. Francés 1 700. Inglés 1,700. Japonés 1,700. Alemán 1.700. Cada uno se renderiza correctamente con Intl.NumberFormat parametrizado en el componente, no en string traducido.

La regla operativa: si tu sistema usa cadenas localizadas para números, tu sistema asume que los números son texto. Los números son datos. El DS los renderiza, no los traduce.

Multilingüe vs multimercado

Si el contenido fuera traducción de una fuente única, todo esto sería sobreingeniería. La traducción permite que un mismo layout funcione casi siempre con ajustes menores. El contenido nativo en siete idiomas obliga a que el sistema acomode contenidos genuinamente distintos, no variantes de uno.

Esto separa al design system multilingüe del design system multimercado. El primero traduce. El segundo respeta el mercado en sus componentes.

05 — Cinco bloques fijos: la anatomía del informe

Cada informe de zona es una pieza editorial de 4.000-6.000 palabras estructurada en cinco bloques fijos. La regularidad no es decorativa: es la condición que hace posible todo lo demás.

Los cinco bloques

1. Veredicto. El componente principal del DS. Tres estados. Encima del fold. Visible sin click.

2. Scoring. Siete ejes cuantitativos: saturación, coste diario, inversión, mejor mes, seguridad, transporte, clima. Cada eje con su número, su tendencia, su nivel de confianza. Renderizado como componente reutilizable, no como ilustración ad-hoc.

3. Tabla de coste 12 meses. Coste diario por mes para una pareja, desglosado por categorías. Cada celda con fecha de captura.

4. Calendario de saturación semana a semana. 52 semanas con nivel de saturación. Es lo que permite responder “¿cuándo ir?” sin caer en temporada alta/baja.

5. Qué falla. Cuatro a siete contras explícitos por zona. No es disclaimer legal, es contenido editorial.

Por qué la regularidad importa

Cuando todos los informes tienen los mismos cinco bloques, tres cosas se vuelven posibles.

Componentes reutilizables. <ScoreChart /> se renderiza idéntico en el informe completo, en /match cuando el matcher sugiere zonas, en /preguntar cuando el RAG cita un score, y en el dashboard interno. Un solo componente, cuatro contextos.

Indexación predecible. El motor de búsqueda interno sabe que el coste de cualquier zona está en el bloque 3 y la saturación en el bloque 4. Esto permite responder preguntas estructuradas sin parsear prosa.

Comparabilidad. Dos zonas se pueden comparar bloque a bloque porque están escritas en el mismo formato. La comparación es función del DS, no de cada informe.

La irregularidad editorial es romántica. La regularidad es operativa.

06 — “Qué falla” como decisión de producto

El bloque 5 de cada informe merece párrafo propio porque condensa la posición de marca.

“Qué falla” es la lista de cuatro a siete contras explícitos de cada zona. No es disclaimer legal. No es advertencia genérica. Es contenido editorial con voz: ruido nocturno por la calle de bares, escasez de aparcamiento agosto, alergia al polen primaveral, dependencia de un único transportista marítimo, agua dura, alérgenos, normativa cambiante.

Es lo que un agente no puede sintetizar desde fuentes optimistas. Booking, TripAdvisor, blogs patrocinados: todos están alineados con el incentivo de que vendas, viajes, pagues. La sección “qué falla” es la que un sintetizador no puede generar honestamente porque su training data no la contiene en proporción suficiente.

Para el design system, “qué falla” exige dos cosas. Una, tono editorial codificado: la voz no se inventa por informe, está pautada y se aplica. Dos, componente que aguanta la lista variable: cuatro a siete items, con peso visual no decorativo (no son nice-to-haves), accesible sin colapsar.

Operativamente: es el activo de marca diferencial. El veredicto se puede copiar. Los scores se pueden estimar. “Qué falla” requiere haber estado en el sitio y haber hablado con quien sabe. Es la pieza que justifica el ticket Pro frente al consumo gratuito de blogs.

07 — El reloj editorial: el sistema que no admite blog congelado

El producto promete públicamente: “si un dato envejece, sale del informe hasta que podamos refrescarlo”. No es retórica. Está implementado.

Diez procesos automáticos mantienen el catálogo vivo. Los tres críticos para la promesa editorial:

Verificación mensual de claims. Cada afirmación cuantitativa del informe (precio, frecuencia, horario, dato regulatorio) se reverifica el primer día de cada mes contra su fuente. Si la fuente cambió o desapareció, el claim se marca como obsoleto y sale del informe hasta refresco. Esto materializa en código la promesa pública.

Snapshot mensual del índice. El primer día de mes a las 06:00 se genera la versión publicable del índice. Es lo que el RAG cita como “snapshot abril 2026 v2.3” en cada respuesta. Sin esta versión datada, las respuestas serían genéricas. Con ella, son referenciables.

Monitoreo semanal de competencia. Los martes se ejecuta una rutina que verifica si Booking, TripAdvisor, Google u otros lanzaron la feature equivalente (saturación + mejor mes + coste). Si lo hacen, lo sabemos el martes, no cuando un cliente nos lo cuenta seis meses después.

Lo que esto significa para el design system

Un design system editorial sin reloj declarado es un blog congelado disfrazado. Las consecuencias son visibles a corto plazo: el componente Score muestra A+ basándose en un dato de hace nueve meses. El componente Verdict dice “avanzar” cuando la zona cambió de regulación turística. El componente Cost muestra €74 cuando el precio real es €92.

Los componentes están bien. El sistema está roto.

La decisión de DS consecuente: cada componente que renderiza un dato lleva metadata de cuándo se capturó ese dato. Esa metadata es visible para el agente y opcionalmente visible para el humano (en un tooltip, en el detalle expandido, en la versión PDF descargable).

Componentes sin trazabilidad temporal son componentes que envejecen mal. En productos editoriales con IA, envejecen rápido.

08 — Cómo se produce un informe nuevo

Un informe nuevo no nace de la página en blanco. Se compone de dos capas que ocurren en orden inverso al de lectura. La capa cuantitativa ejecuta el sistema. Después, la capa editorial ejecuta Joan.

Primero, el sistema produce datos

Para cada zona candidata se ingestan y normalizan datos oficiales de pernoctaciones y ocupación hotelera, climatología histórica de cinco años, frecuencia y capacidad de cruceros, eventos locales, datos del Registro de la Propiedad, conectividad de transporte, certificaciones de calidad costera.

Cada dato se almacena con cuatro campos obligatorios: el dato en sí, su fuente (URL primaria o field-YYYY-MM-DD si es captura manual), la fecha exacta de captura, el nivel de confianza de 0 a 1. El tipo se llama AgenticSeoClaim y es la unidad atómica que el sistema usa para serializar cada afirmación pública.

Esta capa produce los siete scores cuantitativos, la tabla de coste 12 meses precomputada, el calendario de saturación 52 semanas, y una lista priorizada de candidatos a “qué falla” extraídos por análisis estadístico (outliers, picos, rupturas).

Después, el humano escribe

Sobre esa base, Joan escribe el veredicto con criterio (no es función directa de los scores: los pondera con conocimiento de zona), la prosa del bloque “qué falla” convirtiendo outliers estadísticos en contras editoriales con voz, la narrativa que cose el informe, y el metadata editorial (ángulo, ejemplos comparativos, citas literales).

Por qué este orden y no el inverso

El error del 90% de productos editoriales con IA es generar prosa primero y validar datos después. Lorsclub invierte el orden. La pipeline garantiza la verdad cuantitativa antes de que el humano escriba una sola palabra.

Cuando Joan escribe el veredicto, ya sabe que el coste diario de Begur en mayo es €74 con muestra capturada el día 14. El veredicto no se contradice con los datos porque los datos preceden al veredicto.

La regla operativa: si no puedes producir el dato antes que el texto, no produzcas el texto. Vale también fuera del contenido. Si no puedes producir el token antes que el componente, no diseñes el componente. Si no puedes producir la regla antes que la variante, no diseñes la variante.

09 — Cómo un agente pregunta y lorsclub responde

/preguntar es la superficie más visible de la capa agéntica del producto. Para entenderla desde el oficio de DS hay que separar dos cosas.

El componente público

Visualmente, /preguntar es un input grande con eyebrow “Beta · RAG geoespacial”. El usuario escribe una pregunta en lenguaje natural. La respuesta llega en segundos con citas inline al formato [zona:fuente] y una lista de zonas relacionadas.

El componente conversacional es uno solo. El consumidor puede ser un humano que escribe la pregunta, o un agente externo (Claude, Perplexity) que hace POST al endpoint detrás del componente. El componente declara la misma información en los dos casos, lo que cambia es el vehículo.

El comportamiento que importa

El sistema responde solo desde el corpus publicado. No alucina zonas. Si no tiene evidencia suficiente, lo dice. Cada respuesta cita la fuente y el snapshot del índice usado.

Esto se logra con tres decisiones de producto que un Design System Architect reconoce inmediatamente como decisiones del sistema, no del modelo.

Corpus controlado, no scrapeado. Cada fragmento indexado tiene origen declarado en una lista cerrada (datos oficiales nacionales, certificaciones, captura editorial, blog interno). Un sintetizador no inventa fuentes nuevas porque el sistema no le permite traerlas.

Cuotas que convierten consultas en relación. Anónimo: 5 cada 30 días. Con email: 20. Suscriptor Pro: 100.000. La cuota anónima corta es deliberada: suficiente para descubrir, insuficiente para uso operativo. La cuota se convierte en email, el email se convierte en suscripción.

Citación al snapshot mensual. Cada respuesta incluye fecha de la versión del índice utilizada. Cuando un agente cita lorsclub, cita también con qué versión del dato responde. Esto vuelve la respuesta verificable y auditable.

Para un DS lead que opera contenido y producto, la lección operativa: la confiabilidad de una superficie conversacional no la pone el modelo, la pone el sistema que lo rodea. Modelo intercambiable, sistema permanente.

10 — La defensa contra el sintetizador

Hay datos que un LLM no puede inventar: precios capturados en una muestra concreta de establecimientos en una fecha concreta, coordenadas GPS de aparcamientos sin indexar, horarios verificados en campo, conversaciones con autoridades locales sobre permisos de construcción.

El producto formaliza esto con un tipo de datos del sistema (AgenticSeoClaim) que cada afirmación pública lleva como envoltorio. Estructura:

• El dato en sí.
• La fuente primaria con URL o referencia a captura de campo.
• La fecha exacta de captura.
• El nivel de confianza de 0 a 1.
• Notas internas opcionales (no se publican).

Cuando un agente externo consume el feed o llama al RAG, recibe el dato junto con su trazabilidad completa. Cuando un competidor que use solo síntesis LLM intente generar el equivalente, no puede producir el campo de fecha de captura ni el de fuente con la misma especificidad sin haber estado en el sitio.

El homepage lo dice con voz editorial: “un modelo de lenguaje no fue a la cala. Nosotros sí.” El footer lo refuerza como compromiso permanente: “Editorially independent · No affiliate pipes.”

Para un Design System Architect, esto es la pregunta más interesante del proyecto: ¿qué pieza de tu sistema no es replicable por un LLM con tu producto público como referencia?. Si no tienes esa pieza, eres infraestructura para el sintetizador, no defensa contra él.

11 — Una arquitectura técnica al servicio de una arquitectura comercial

El detalle estratégico más subrayable del producto no está en el contenido. Está en cómo el sistema dirige cada audiencia a su propia versión.

El problema

Lorsclub vende a cinco audiencias con disposición a pagar muy distinta.

• Viajero precompra: €9-29 por informe único.
• Planificador / escapador: €29/mes recurrente.
• Comprador de segunda residencia: ticket variable vía leads cualificados.
• Agencia inmobiliaria: €99-199/mes en modo SaaS.
• Family office o gestora: €399-999/mes en white-label.

Mostrar los cinco precios en la misma página rompe a cada uno. El viajero descarta €999 como caro. La gestora descarta €29 como amateur. La agencia ignora el informe único.

La solución del sistema

Cada audiencia entra por su propia puerta y nunca ve la oferta diseñada para otra persona. El homepage muestra Pro €29. La página /agencias muestra SaaS €99-199. La página /wl (no pública) muestra white-label €399-999.

Operativamente, esto es routing por subdominio gestionado por el sistema. Cada zona puede vivir en su propio subdominio (begur.lorsclub.com) o servir como tenant para una gestora (gestora.lorsclub.com).

Lo que esto significa para el design system

La gestora que contrata white-label tiene su propio subdominio con su logo, sus colores aplicados sobre los tokens del DS, y su propio recorte del catálogo. Los componentes del DS reciben configuración de tenant en runtime y aplican branding sobre los mismos tokens base.

Esto exige que el DS esté tokenizado en serio: cada decisión visual delegable a la marca del tenant debe ser un token, no un valor hardcoded. Color primario, color del veredicto, tipografía display, logotipo, microcopy del CTA principal: todo token. La consecuencia es que el sistema se diseña dos veces, una para lorsclub y otra para cualquier tenant futuro que paga por la versión privada.

Un sistema sin tokens semánticos no puede sostener white-label sin reescribir componentes. Un sistema con tokens semánticos lo sostiene cambiando configuración.

Es el patrón “una arquitectura técnica que hace viable una arquitectura comercial”. Pocas decisiones de DS rentan tanto a medio plazo.

12 — Lo que no se construyó

Una de las razones por las que el producto llegó a vendible es que descartó decisiones que parecían obvias. Para un Design System Architect senior, esta sección suele ser la más útil del documento: lo que define el sistema es tanto lo que incluye como lo que rechaza.

El patrón: cada “no” preserva la línea editorial. Es la aplicación del “you are what you say no to” de Tony Fadell.

Para un DS, cada “no” se traduce en componentes que no se construyen. Sin afiliados no hay componente de tracking de comisión visible. Sin top-10 no hay componente de ranking ordenado. Sin reservas integradas no hay componente de calendar picker con disponibilidad live. Cada “no” simplifica el sistema. Cada “sí” añade superficie a mantener.

13 — Voz editorial como parte del design system

La decisión más infrecuente del proyecto y la más interesante para un DS senior: la voz editorial es parte del sistema, no del marketing.

Frases del producto vivo. Cada una está pautada en algún lugar del sistema:

• “Criterio antes de visitar, antes de firmar.”
• “Avanzar · observar · descartar.”
• “Nunca agosto.”
• “El impuesto meteorológico vasco ya está en precio.”
• “Un modelo de lenguaje no fue a la cala. Nosotros sí.”
• “No publicamos una zona hasta que cada eje tiene fuente primaria y timestamp.”
• “Si un dato envejece, sale del informe hasta que podamos refrescarlo.”
• “Comisiones aceptadas: por diseño, no por casualidad.”
• “Vendemos informes. Es lo único que vendemos.”
• “Editorially independent · No affiliate pipes.”
• “El archivo, no el ambiente.”
• “Beta · RAG geoespacial.”

Tres registros conviven: periodista (datos), curator (veredicto), disidente (anti-cliché). La densidad por línea es alta. El cliché está prohibido.

Por qué esto es DS y no marketing

Si la voz solo vive en el cerebro del fundador, cada colaborador que escriba en el producto va a degradarla. Si vive en el sistema como pauta operativa, la voz sobrevive a cambios de equipo. Esto incluye:

• Vocabulario aprobado por contexto.
• Vocabulario prohibido (cero AI-slop, cero adjetivos vacíos).
• Estructura preferida por componente (titular, cuerpo, microcopy CTA).
• Tono por sección (informativo en scoring, filoso en “qué falla”, funcional en pricing).

Operativamente: si tu DS no incluye una guía de voz vinculante, tu producto editorial no es un sistema. Es la suma de las voces de quien escribió cada página.

14 — Lo que un DS Architect senior se lleva de aquí

Cinco decisiones aplicables a tu propio sistema, ordenadas por dificultad creciente.

1. Pipeline antes que prosa (fácil)

Si tu producto combina datos y opinión, garantiza primero los datos. La regla: si no puedes producir el dato antes que el texto, no produzcas el texto. Vale para informes, comparativas, dashboards, reviews, casos de estudio, libros blancos. El error universal del 90% de productos editoriales con IA es invertir el orden.

2. Reloj editorial declarado (fácil)

Si tu sistema renderiza datos que envejecen, cada componente que renderiza un dato lleva metadata de cuándo se capturó. Sin esto, tu producto es un blog congelado disfrazado. Con esto, tu producto es un sistema vivo. La diferencia se nota en 6-12 meses.

3. Color como token semántico (medio)

Si tu producto codifica decisiones (estados, riesgos, veredictos, alertas), tu paleta principal no se organiza por familia decorativa sino por intención semántica. Esto vuelve los componentes legibles para agentes y reduce ambigüedad para humanos. Es la misma decisión que tomaría un buen DS para banca o sanidad, aplicada al campo editorial.

4. Tokenización para multimercado, no solo multilengua (medio-difícil)

Si tu producto sirve mercados culturalmente distintos con contenido nativo (no traducción), tu sistema acomoda métricas tipográficas distintas, densidades de información distintas, anchos mínimos distintos. Las variantes no son responsive width, son respond-to-content. La traducción permite un mismo layout; el contenido nativo no.

5. Componentes con consumidor dual (difícil)

Si tu producto tiene tráfico orgánico de agentes (todo SaaS B2B, todo producto editorial, todo dashboard público en 2026), tus componentes principales tienen dos renderings: humano hidratado y agente semántico denso. El design system ya no termina en pantalla, termina en el dato semántico que el agente consume.

Esta última decisión es la que separa al DS adaptado a la era agéntica del DS que está en deuda con ella.

15 — Anexo técnico

Para quien quiera verificar las afirmaciones del documento contra el código.

Stack

Cron jobs operativos

10 jobs definidos en workers/cron/wrangler.toml. Los tres críticos para la promesa editorial son claims-refresh-monthly, lors-index-monthly y competition-monitor-weekly. El resto cubren refresh de media, segmentación de newsletter, regeneración de productos digitales y procesamiento de secuencias de email.

Schemas JSON-LD: 31 tipos

• Navegación: WebSite, WebPage, BreadcrumbList, CollectionPage, AboutPage, ProfilePage, SearchAction, EntryPoint.
• Identidad: Organization, Person.
• Editorial: Article, NewsArticle, CreativeWork, SpeakableSpecification.
• Q&A: FAQPage, Question, Answer.
• Producto y oferta: Product, Offer, Course, Service.
• Reseñas: Review, Rating.
• Listas: ItemList, ListItem, HowTo, HowToStep.
• Territorio: TouristDestination, GeoCoordinates.
• Datos: Dataset, DataCatalog, DataDownload.

Dataset, DataCatalog y DataDownload en particular son raros en sitios editoriales. Son la firma de que lorsclub se ofrece a sí mismo como dataset citable.

El RAG en detalle

Endpoint POST /api/zones-ask. Acepta query en lenguaje natural y, opcionalmente, geometría (lat/lng/radius). Si hay geometría se acota por radio mediante PostGIS ST_DWithin; si no, la query es puramente semántica.

Pipeline:

1. Quota check (5 anón / 20 email / 100k Pro en ventana de 30 días).
2. Embedding de la query con Voyage-3.
3. Búsqueda SQL única que combina distancia coseno pgvector, proximidad geográfica si aplica, filtros de fuente y locale.
4. Compresión a contexto.
5. Generación con system prompt versionado que prohíbe inventar y obliga a citar.
6. Respuesta JSON con answer, citations, zones, latency.

Defensas anti-abuse: cuota deliberadamente corta para anónimos (5/30d), ventana móvil, rate-limit adicional vía KV, Turnstile, system prompt que rechaza cifras inventadas.

Cronología de pivot leída desde las migraciones SQL

Las 39 migraciones de Supabase funcionan como diario de campo. Cinco fases.

1. Base editorial (14 marzo 2026): zonas, leads, blog, newsletter.
2. B2B inicial (18-23 marzo): formulario buying intent, índice mensual para agencias.
3. Editorial endurecido (1-3 abril): zonas promoted, reglas de validación.
4. Cerebro digital (19-26 abril): PostGIS + pgvector, vector store, surface /preguntar.
5. White-label (6 mayo): tenants, branded shell, tiers €399/€999.

Seis semanas del primer formulario B2B al primer producto B2B vendible. Cuatro semanas de los leads al RAG. El pivot cambió de tesis dos veces en 60 días sin romper el stack.

Verificación reproducible

# Inventario público
curl -s https://lorsclub.com/sitemap.xml | grep -c '<loc>'     # → 1683
cat apps/web/src/generated/zone-slugs.json | jq '.slugs | length'  # → 546

# Posicionamiento público
curl -s -A "Mozilla/5.0" https://lorsclub.com | \
  grep -oE '<title>[^<]+</title>|name="description" content="[^"]+"'

# Inventario de schemas
grep -rE '"@type":\s*"[A-Z][a-zA-Z]+"' apps/web/src/lib/seo.ts | \
  grep -oE '"@type":\s*"[A-Z][a-zA-Z]+"' | sort -u | wc -l    # → 31

# Migraciones
ls supabase/migrations | wc -l                                  # → 39

# Idiomas con landing nativa
ls apps/web/src/i18n/locales | wc -l                            # → 7

# Cron jobs activos
grep -E '"[0-9 *,/-]+"' workers/cron/wrangler.toml | wc -l      # → 10

# Tests
pnpm test --reporter=summary                                    # → 284

URLs públicas verificables:

• Sitemap: https://lorsclub.com/sitemap.xml
• Metodología: https://lorsclub.com/metodologia
• RAG público: https://lorsclub.com/preguntar
• Newsletter: https://lorsclub.com/newsletter