site-consistency — QA de copy alineada a la oferta

Site Consistency — Offer-Aligned Text Audit

Goal: cada pieza de texto en el sitio cuenta la misma historia — la oferta establecida en la página de inicio — al mismo cliente, con la misma promesa, nombres y términos. Auditar primero; corregir solo lo que el usuario apruebe.

Dos límites estrictos:

1. Auditar antes de corregir. La auditoría es de solo lectura. No se modifica ningún archivo hasta que el usuario apruebe filas específicas de la tabla de auditoría.
2. Solo texto. Esta habilidad cambia palabras — nunca diseño, estilos, componentes, imágenes, rutas o estructura de página. Consulta "Reglas de edición solo texto".

Idiomas

• Habla al usuario en el idioma que use en la conversación. El informe, los encabezados de tabla, las etiquetas de gravedad y la columna de "por qué" están en ese idioma.
• Las citas del texto actual son textuales, en su idioma original.
• El texto propuesto para el sitio se escribe en el idioma del texto que reemplaza, de forma nativa e idiomática (nunca una traducción literal), manteniendo la forma de tratamiento del sitio (p. ej., español "tú"/"usted", alemán "du"/"Sie") y su tono.
• Detecta los idiomas del sitio a partir de <html lang>, la configuración de i18n, los archivos de configuración regional y el texto visible. En sitios multilocale, identifica la configuración regional principal; si no está claro qué configuraciones regionales auditar, pregunta.

Flujo de trabajo

Sigue los pasos en orden. Los pasos 1–6 nunca modifican archivos.

Paso 1 — Reconocimiento

Lee references/text-inventory.md. Establece:

• la pila tecnológica y el enrutamiento (cómo las URL se asignan a archivos),
• dónde vive el texto: componentes/plantillas, archivos i18n, colecciones de contenido Markdown/MDX, metadatos, plantillas de correo electrónico, CMS externo,
• las configuraciones regionales y el idioma principal del sitio,
• los documentos de oferta existentes: docs/offer/offer-brief.md (escrito por la habilidad grand-slam-offer) o cualquier brief/documento de posicionamiento en docs/.

Si la mayor parte del texto vive en un CMS externo y no hay ni una exportación ni una URL para leer el sitio renderizado, informa al usuario qué se puede y qué no se puede auditar antes de continuar.

Paso 2 — Extraer la oferta de la página de inicio

Lee la página de inicio como lo haría un visitante por primera vez: héroe primero, luego cada sección en orden, más <title>, meta descripción, encabezado y pie de página. Completa el Declaración de la oferta:

Campo	Qué responde
Qué se vende	producto/servicio y su formato
Para quién	el cliente/avatar, segmento, mercado
Promesa principal	el resultado que obtiene el cliente (+ plazo, si se indica)
Mecanismo / diferenciador	cómo se entrega, por qué esto en lugar de alternativas
Nombres	ortografía exacta del nombre de la oferta, producto, método y paquetes
Términos clave	precio/paquetes, garantía, escasez/fechas límite, tiempo de entrega — solo los indicados
Conversión principal	la CTA principal y qué sucede después de hacer clic
Voz	tono, forma de tratamiento, posicionamiento (premium, económico, experto, amigable…)

Para cada campo, registra el valor y la fuente (cita + ubicación). Si un campo no está en la página de inicio, escribe "no indicado". Si existe un brief de oferta, compáralo con la página de inicio campo por campo.

En un sitio con varias ofertas distintas (p. ej., servicios separados para diferentes audiencias), registra la oferta general de la página de inicio y enumera las subofertas; cada página de suboferta se verificará con su propia oferta y con la oferta general.

Paso 3 — Puerta de claridad de la oferta

La oferta es clara cuando se cumplen todas estas condiciones:

1. "Qué se vende", "Para quién", "Promesa principal" y "Conversión principal" pueden responderse solo desde la página de inicio.
2. La página de inicio presenta una oferta principal (o un paraguas claro con subofertas) — sin ofertas en competencia.
3. La página de inicio no se contradice a sí misma (dos precios, dos audiencias, dos promesas diferentes).
4. La página de inicio no contradice el brief de oferta, si existe.

Clara → continúa. El Declaración de la oferta es el punto de referencia; va al principio del informe para que el usuario pueda corregirlo.

No clara → detente y pregunta al usuario sobre la oferta antes de auditar cualquier otra cosa. Nunca adivines la oferta para superar esta puerta.

• Usa la herramienta AskUserQuestion si está disponible (máximo 4 preguntas por ronda), con opciones basadas en los candidatos que realmente encontraste en el sitio y espacio para una respuesta personalizada. De lo contrario, pregunta en el chat.
• Pregunta solo sobre los campos que faltan o están en conflicto, p. ej., "La página de inicio vende tanto X como Y — ¿cuál es la oferta principal?", "¿El cliente principal es A (héroe) o B (sección de servicios)?", "El brief dice una garantía de 30 días, la página de inicio 14 días — ¿cuál es la actual?". Para múltiples ofertas, confirma la jerarquía (oferta principal vs. subofertas).
• Registra las respuestas en el Declaración de la oferta con la fuente "confirmado por el usuario". El texto poco claro o contradictorio de la página de inicio se convierte en hallazgos — la página de inicio se audita contra la oferta confirmada como cualquier otra página.

Paso 4 — Inventario de páginas y texto

Enumera todo lo que un visitante puede leer (detalles en references/text-inventory.md):

• cada ruta/página, incluyendo rutas dinámicas y colecciones de contenido,
• texto compartido: encabezado, navegación, pie de página, banners, modales/ventanas emergentes, formularios (etiquetas, marcadores de posición, validación, mensajes de éxito/error), estados 404/500 y vacíos,
• texto que los visitantes ven indirectamente: <title>, meta descripción, etiquetas Open Graph/Twitter, campos de texto JSON-LD, alt, aria-label, nombre/descripción del manifiesto web,
• correos electrónicos transaccionales y notificaciones, si sus plantillas están en el repositorio.

Asigna a cada página su rol narrativo (consulta references/consistency-checklist.md) — el rol decide qué significa "consistente" para esa página.

Sitios grandes: audita cada página principal por completo. Para grandes colecciones del mismo tipo (p. ej., más de 20 publicaciones de blog o productos), audita la plantilla compartida más el título, la descripción, la introducción y la CTA de cada elemento; di exactamente en el informe qué se cubrió de esta manera y ofrece una pasada completa. Si la herramienta Agente está disponible, puedes dividir el inventario entre subagentes — dale a cada uno el Declaración de la oferta confirmado, la lista de verificación y su lista de páginas, luego fusiona sus hallazgos en una sola tabla.

Paso 5 — Auditoría

Lee references/consistency-checklist.md. Verifica cada unidad de texto contra el Declaración de la oferta en todas las dimensiones (D1–D10), en el contexto del rol de su página. Para cada hallazgo, registra: ubicación, cita textual, dimensión, gravedad, por qué es un problema (vinculado a un campo específico del Declaración de la oferta), tipo de corrección y el texto propuesto.

• Construye primero la matriz de hechos (cada mención de precio, garantía, plazos, plazas, tiempo de entrega, nombres — lado a lado) para que las contradicciones entre páginas se detecten sistemáticamente, no por casualidad.
• El texto propuesto sigue las Reglas de edición solo texto y nunca inventa hechos. Un hecho faltante se convierte en un marcador de posición en el idioma del sitio (p. ej., [TO FILL IN: …], español [POR COMPLETAR: …]).
• Hechos en conflicto donde la verdad no está establecida → tipo de corrección Decisión: enumera las opciones, no elijas una.
• Problemas que el texto no puede resolver (imagen que muestra un producto diferente, sección o botón CTA faltante, página que no debería existir, destino de enlace incorrecto, slug de URL) van a "Fuera del alcance del texto" — se informan, nunca los corrige esta habilidad.

Paso 6 — Informe de auditoría, luego detente

Presenta el informe exactamente como en "Formato de salida". El informe siempre termina con la tabla de hallazgos. Lo único permitido después de la tabla es la pregunta de aprobación. Luego detente y espera — no modifiques ningún archivo en este turno.

Pregunta de aprobación (usa AskUserQuestion si está disponible):

• Aplicar todo
• Aplicar solo Críticos y Mayores
• Aplicar filas seleccionadas (el usuario enumera los # y puede editar cualquier propuesta)
• No aplicar — solo auditoría

Cada fila de Decisión que el usuario quiera aplicar necesita una respuesta; pregunta por estas en la misma ronda cuando sea posible.

Paso 7 — Aplicar correcciones aprobadas

• Aplica solo las filas aprobadas, con las ediciones del usuario, siguiendo las Reglas de edición solo texto.
• Antes de cambiar una cadena, verifica dónde más se renderiza (clave i18n compartida, componente compartido, parcial de Markdown reutilizado). Si el nuevo texto no encaja en uno de esos contextos, detente y pregunta.
• Si una corrección aprobada resulta requerir un cambio que no sea de texto, o no se puede aplicar según lo aprobado, sáltala e infórmalo. No improvises una corrección diferente.
• Texto almacenado en un CMS externo: no intentes editarlo; prepara una lista de copiar y pegar (entrada/campo del CMS | texto actual | texto nuevo).

Paso 8 — Verificar e informar

• Vuelve a leer cada pasaje modificado con el texto que lo rodea — debe leerse de forma natural en contexto.
• Busca restos de las variantes antiguas (nombres antiguos, términos antiguos, promesa antigua) dentro del alcance aprobado.
• Valida los archivos modificados: parseo JSON/YAML, los archivos de configuración regional mantienen las mismas claves, las variables de interpolación están intactas. Ejecuta el lint/typecheck/build del proyecto si está disponible y es rápido.
• Multilocale: enumera las otras configuraciones regionales cuyas cadenas necesitan una actualización correspondiente, a menos que el usuario haya aprobado actualizarlas también.
• Termina con la tabla resumen: # | Dónde | Estado (Aplicado / Saltado — razón / Necesita actualización CMS) | Cambio (breve). No hagas commit a menos que te lo pidan.

Reglas de edición solo texto

Permitido:

• contenido de cadenas visibles para el usuario: nodos de texto en JSX/plantillas, literales de cadena renderizados para los usuarios, valores i18n, prosa Markdown/MDX, campos de texto de frontmatter (título, descripción), archivos de contenido CMS en el repositorio,
• atributos de texto y metadatos: alt, title, aria-label, placeholder, <title>, meta descripción, texto OG/Twitter, valores de texto JSON-LD, nombre/descripción del manifiesto,
• mensajes de formularios, sistema y plantillas de correo electrónico,
• reescribir, acortar o eliminar oraciones dentro de un elemento de texto existente.

No permitido (informar bajo "Fuera del alcance del texto" en su lugar):

• agregar, eliminar, reordenar o rediseñar elementos, secciones o componentes; cambiar marcado, clases, CSS o props que no sean de texto,
• vaciar un elemento — un elemento vacío es un cambio de diseño; reescríbelo en su lugar,
• claves i18n, nombres de variables, nombres de archivos, rutas, slugs de URL, anclas (los slugs son texto pero cambiarlos rompe enlaces y SEO),
• destinos de enlace (href) — solo el texto del enlace puede cambiar,
• imágenes, iconos, video y otros medios,
• lógica de código, condiciones, obtención de datos.

Al editar:

• Preserva la interpolación y la sintaxis: {name}, {{count}}, %s, :attribute, plural/selección ICU, entidades HTML, etiquetas en línea dentro de cadenas (<strong>, <br>, <0>…</0>), formato Markdown y escape (comillas en JSX/JSON, apóstrofos en cadenas PHP).
• Mantén la longitud cercana a la original (aproximadamente ±30%) porque el diseño no cambia. Si una corrección necesita mucho más texto, dímelo en la propuesta.
• Respeta las convenciones tipográficas del sitio (comillas, guiones, espacios de no separación).

Reglas obligatorias

• R1. Auditoría de solo lectura. Sin ediciones ni escrituras de archivos (incluidos los archivos de informe, a menos que el usuario lo solicite) antes de la aprobación explícita. La aprobación cubre solo las filas aprobadas.
• R2. Solo texto. Todo lo que esté fuera de las Reglas de edición solo texto se informa, nunca se cambia.
• R3. Punto de referencia primero. Nunca auditar contra una oferta adivinada: el Declaración de la oferta está claro desde la página de inicio o ha sido confirmado por el usuario.
• R4. Evidencia. Cada hallazgo cita el texto actual textualmente y proporciona una ubicación precisa (file:line o clave i18n).
• R5. La tabla siempre va al final. Cada informe de auditoría termina con la tabla de hallazgos, también cuando no hay hallazgos — entonces termina con una tabla de cobertura (Página | Rol | Veredicto).
• R6. Sin hechos inventados. Las propuestas nunca agregan números, resultados, testimonios, garantías o términos que el usuario no haya proporcionado o que el sitio no indique ya de manera consistente. Conflicto → Decisión. Faltante → marcador de posición.
• R7. Consistencia, no uniformidad. No pegues la promesa del héroe en todas partes ni fuerces un discurso de ventas en cada página. Señala solo el texto que contradice, diluye, se desvía o distrae de la oferta, dado el rol de la página. Las páginas legales nunca se reescriben por narrativa — solo se señalan sus conflictos de hechos con el texto de marketing, con una recomendación de que un abogado revise el texto legal.
• R8. Alinear con la oferta, no rediseñarla. Esta habilidad alinea el sitio con la oferta confirmada. Si la oferta en sí misma es débil (promesa vaga, sin pruebas, liderada por precio), dilo en una línea del resumen y sugiere la habilidad grand-slam-offer; no reconstruyas la oferta aquí.
• R9. Idioma. Comunicación en el idioma de la conversación; texto del sitio propuesto en el idioma del texto que reemplaza.

Formato de salida

Informe de auditoría

Secciones en este orden, escritas en el idioma de la conversación:

1. Oferta de referencia — el Declaración de la oferta (tabla compacta) + su fuente (página de inicio / brief de oferta / confirmado por el usuario).
2. Alcance — páginas y fuentes de texto auditadas (recuento + lista o agrupación), configuraciones regionales, lo que se cubrió mediante muestreo, lo que está fuera del repositorio y no se auditó.
3. Resumen — recuento de hallazgos por gravedad; los 2–3 problemas narrativos más grandes, una oración cada uno; opcionalmente una línea sobre la oferta en sí (R8).
4. Reescrituras completas (solo si es necesario) — propuestas de más de ~40 palabras, completas, etiquetadas con el número de hallazgo.
5. Fuera del alcance del texto (solo si los hay) — viñetas cortas; esta habilidad no los corregirá.
6. Tabla de hallazgos — el último elemento del informe.

Tabla de hallazgos — encabezados traducidos al idioma de la conversación:

#	Dónde	Gravedad	Cómo está hoy	Por qué no debería ser así	Corrección propuesta

• # — ID estable utilizado para la aprobación.
• Dónde — página · sección · file:line o clave i18n.
• Gravedad — Crítico / Mayor / Menor (consulta la lista de verificación).
• Cómo está hoy — cita textual del fragmento relevante; acorta con "…" más allá de ~25 palabras.
• Por qué no debería ser así — el conflicto concreto con el punto de referencia, p. ej., "página de inicio: para clínicas dentales; aquí: para cualquier negocio".
• Corrección propuesta — el texto nuevo exacto en el idioma del sitio, "ver Reescritura completa #N", o DECISIÓN: A) … / B) ….

Ordena por gravedad, luego por el orden de página del inventario.

Por ejemplo, en una conversación en español, los tres encabezados principales se convierten en "Cómo está hoy", "Por qué no debería ser así", "Corrección propuesta".

Filas de ejemplo (sitio en español, conversación en español):

#	Dónde	Gravedad	Cómo está hoy	Por qué no debería ser así	Corrección propuesta

…

[truncado para traducción]