@bacano/sdk 1.0.1 → 1.1.8

package/skills/bacano-web/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: bacano-web
+description: Audita y prepara sitios construidos con @bacano/sdk antes de publicarlos o después de un despliegue. Usar cuando se solicite evaluar una web Bacano, revisar si está lista para producción, investigar errores página por página, validar SEO, rendimiento, seguridad, legal, medición, Content, autenticación o, en tiendas virtuales, catálogo, carrito, checkout, pagos y pedidos.
+---
+
+# Bacano Web
+
+Evaluar el sitio con evidencia del repositorio, del build y, cuando exista, del
+dominio desplegado. No declarar el sitio listo basándose únicamente en una
+revisión visual.
+
+## 1. Confirmar el tipo de sitio
+
+Antes de auditar, confirmar uno de estos alcances:
+
+- **Web informativa**: contenido, formularios y contacto, sin compra completa.
+- **Tienda virtual**: catálogo vendible y flujo de carrito/checkout/pago.
+
+Si el usuario no lo indicó expresamente, preguntar exactamente una pregunta
+corta y esperar: **“¿Esta web será informativa o una tienda virtual?”**
+
+No aplicar la lista transaccional a una web informativa. Si un sitio híbrido
+permite comprar, clasificarlo como tienda virtual.
+
+Después construir primero la matriz arquitectónica definida en
+[references/architecture-runtime.md](references/architecture-runtime.md):
+catálogo estático, estado dinámico de productos, configuración pública, vista
+previa editorial, marketing/analítica y funciones transaccionales. Clasificar
+cada capacidad como `ACTIVA`, `INACTIVA` o `BLOQUEADA` con evidencia del código,
+build y configuración pública. Añadir debajo las capacidades específicas como
+autenticación, formularios, GA4, Meta, Clarity, catálogo publicitario, cupones,
+pagos y entregas.
+
+Una capacidad inactiva no bloquea la salida y sus pruebas son `NO APLICA`, no
+`NO VERIFICADO`. Una capacidad activa y visible debe probarse en proporción a
+su riesgo.
+
+## 2. Leer los contratos aplicables
+
+Leer siempre [references/common.md](references/common.md) y
+[references/architecture-runtime.md](references/architecture-runtime.md).
+Después leer solo:
+
+- [references/informational.md](references/informational.md) para web informativa.
+- [references/storefront.md](references/storefront.md) para tienda virtual.
+
+Si `@bacano/sdk` está disponible, leer sus contratos canónicos aplicables antes
+de proponer cambios. Como mínimo revisar `STOREFRONT_LEGAL.md`,
+`STOREFRONT_MARKETING.md`, `STOREFRONT_PERFORMANCE.md` y
+`STOREFRONT_PREVIEW.md`; añadir
+`AUTHENTICATION.md`, `STOREFRONT_LEADS.md`, `STOREFRONT_CLARITY.md` y
+otros contratos únicamente cuando esas capacidades existan. Leer
+`STOREFRONT_CONSTRUCTION.md` cuando el website permita ocultarse temporalmente.
+
+## 3. Auditar sin alterar el sistema
+
+Por defecto realizar una auditoría de solo lectura. No editar código, cambiar
+configuración externa, publicar, crear cuentas, enviar formularios reales ni
+ejecutar compras/pagos sin autorización explícita.
+
+1. Inspeccionar stack, scripts, rutas, variables públicas esperadas y versión
+   efectiva de `@bacano/sdk`.
+2. Registrar la matriz de capacidades y cuáles son críticas para el
+   lanzamiento actual.
+3. Identificar una sola fuente para Bacano, Content, legal, marketing y auth.
+4. Ejecutar typecheck, lint, pruebas y build usando los comandos del proyecto.
+5. Comparar router, salida del build y sitemap; ninguna ruta pública debe
+   omitirse silenciosamente.
+6. Inspeccionar HTML generado, metadata, JSON-LD, media y enlaces internos.
+7. Si existe un dominio o una aplicación ejecutable, auditar sus rutas reales,
+   la consola y un trace de red con nombres y conteos de operaciones GraphQL.
+8. Probar vistas representativas desktop y mobile.
+9. Retestar individualmente cada hallazgo antes de considerarlo real.
+
+Para una comprobación HTTP inicial puede ejecutarse:
+
+```bash
+node <skill-dir>/scripts/audit-http.mjs https://ejemplo.com --max 500 --preview /vista-previa/
+```
+
+El script no reemplaza pruebas de navegador, accesibilidad, interacción ni
+flujos autenticados.
+
+Si esta skill se leyó directamente dentro de `node_modules` y aún no está
+instalada en el proyecto, ejecutar `pnpm exec bacano-web install` antes de
+continuar. Verificar después con `pnpm exec bacano-web check`.
+
+## 4. Evitar falsos positivos
+
+- Limitar una auditoría masiva a dos navegadores concurrentes y espaciar las
+  rutas. Un `429` provocado por el auditor no es un defecto del storefront.
+- Repetir después de la ventana de rate limit cualquier `429`, recurso
+  cross-origin o fallo transitorio.
+- No reportar `net::ERR_ABORTED` aislado como error si corresponde a beacons
+  cancelados al cerrar o navegar la página.
+- Distinguir “no verificado” de “falló”. Login, pago, correo y webhooks no se
+  consideran aprobados si no se ejecutó el flujo real.
+- No recomendar comodines amplios en CSP para silenciar la consola.
+
+## 5. Entregar un cierre verificable
+
+Usar [references/report.md](references/report.md). Cada control debe quedar como
+`✅ APROBADO`, `⚠️ ADVERTENCIA`, `❌ FALLÓ`, `➖ NO APLICA` o
+`🧪 NO VERIFICADO`, con evidencia concreta. Mantener siempre la palabra del
+estado junto al emoji para que el informe siga siendo buscable y procesable.
+
+Clasificar controles por su efecto en la salida:
+
+1. `P0 · Gate`: bloquea publicación si falla; si no se pudo verificar, el
+   dictamen queda incompleto.
+2. `P1 · Calidad`: requisito profesional que permite salir solo con riesgo
+   explícito y responsable.
+3. `P2 · Mejora`: evolución deseable que nunca cambia por sí sola el dictamen.
+
+No decir “listo para producción” mientras exista un `❌ FALLÓ` P0 o una
+capacidad esencial activa permanezca `🧪 NO VERIFICADO`.

package/skills/bacano-web/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Bacano Web"
+  short_description: "Audita sitios Bacano antes de producción"
+  default_prompt: "Usa $bacano-web para evaluar si este sitio Bacano está listo para producción."

package/skills/bacano-web/references/architecture-runtime.md

@@ -0,0 +1,109 @@
+# Arquitectura SDK y tráfico runtime
+
+Usar este control en toda web construida con `@bacano/sdk`. Clasificar primero
+estas seis capacidades, antes de evaluar si su implementación es correcta:
+
+| Capacidad | Estado permitido |
+| --- | --- |
+| Catálogo estático | `ACTIVA`, `INACTIVA` o `BLOQUEADA` |
+| Precio y disponibilidad dinámicos | `ACTIVA`, `INACTIVA` o `BLOQUEADA` |
+| Configuración pública del website | `ACTIVA`, `INACTIVA` o `BLOQUEADA` |
+| Vista previa editorial | `ACTIVA`, `INACTIVA` o `BLOQUEADA` |
+| Marketing y analítica | `ACTIVA`, `INACTIVA` o `BLOQUEADA` |
+| Funciones transaccionales | `ACTIVA`, `INACTIVA` o `BLOQUEADA` |
+
+`INACTIVA` significa que la capacidad está apagada intencionalmente y no hace
+parte del lanzamiento. `BLOQUEADA` significa que el sitio pretende usarla, pero
+falta contrato, configuración o una dependencia necesaria. El resultado de una
+prueba se informa aparte como aprobado, fallido o no verificado.
+
+## Static First
+
+Contrastar siempre con `STOREFRONT_PERFORMANCE.md`.
+
+- Inventariar qué datos nacen en build/servidor y cuáles cambian en runtime.
+- Verificar que catálogo, Content, metadata, rutas, sitemap y JSON-LD se
+  materialicen estáticamente cuando corresponda.
+- Inspeccionar el HTML exportado directamente. No aceptar una página que solo
+  obtiene contenido después de hidratar.
+- Confirmar un único `BacanoProvider` y un único `BacanoClient` por árbol de
+  ejecución. No crear clientes por módulo, hook, ruta o vista previa.
+- Si `public-config` se obtuvo en servidor o build, derivar el contexto con
+  `getWebsiteContextFromPublicConfig()` y entregarlo como `initialContext`.
+- No resolver repetidamente el website ni descargar en el navegador productos
+  completos que ya están en el snapshot.
+- Actualizar en runtime solo datos volátiles mediante el contrato oficial:
+  precio, disponibilidad y `maxPurchasableQuantity`.
+- Agrupar IDs, eliminar duplicados y usar caché/debounce razonables. Respetar el
+  máximo documentado por solicitud y conservar el snapshot si falla el refresh.
+- Filtros o paginación dinámicos pueden consultar estructura únicamente cuando
+  el diseño publicado lo requiere. Deben usar el SDK y no repetir la descarga
+  inicial sin una interacción que lo justifique.
+- No aceptar GraphQL directo, endpoints internos, clientes paralelos ni reglas
+  locales que reconstruyan catálogo, inventario o precios.
+
+## Trace real del navegador
+
+Cuando exista una aplicación ejecutable o un dominio, capturar la red en un
+contexto limpio y registrar por fase:
+
+1. carga inicial directa;
+2. navegación interna;
+3. filtro, orden o paginación;
+4. apertura de un detalle representativo.
+
+Para cada operación GraphQL registrar `operationName`, cantidad, fase,
+iniciador, código HTTP y tipo de datos solicitado. Comparar payloads para
+detectar la misma operación con las mismas variables. Una repetición sin nueva
+interacción, invalidación o cambio de datos es un duplicado; una revalidación
+documentada no lo es.
+
+El informe debe indicar:
+
+- número de instancias del cliente;
+- cantidad y nombres de operaciones en la carga inicial;
+- operaciones duplicadas y causa;
+- datos provenientes del HTML/snapshot;
+- datos actualizados en runtime;
+- conclusión explícita sobre Static First.
+
+Si no hay navegador disponible, marcar el trace `🧪 NO VERIFICADO`; no inferir
+la ausencia de tráfico solo desde el código.
+
+## Vista previa editorial
+
+Contrastar siempre con `STOREFRONT_PREVIEW.md`. Si está activa, validar:
+
+- una única ruta pública, preferiblemente `/vista-previa/`;
+- `BacanoPreviewShell` desde `@bacano/sdk/react/preview`;
+- el mismo provider y cliente global del storefront;
+- una allowlist finita de rutas editoriales;
+- exclusión de checkout, pagos, cuenta, pedidos y demás rutas transaccionales;
+- los mismos componentes y mappers usados en producción;
+- `noindex, nofollow` y ausencia total del sitemap;
+- carrito, popups, chat y elementos comerciales globales ocultos;
+- ausencia de scripts y requests efectivos de GA4, Meta, Clarity u otros
+  proveedores al cargar directamente preview;
+- cero eventos de marketing durante navegación, refresh y errores de preview;
+- estados SDK `idle`, `loading`, `ready` y `error`;
+- resultados visuales `missing` y `unsupported` definidos por el storefront;
+- reintento, refresh forzado, caché y navegación interna;
+- contenido publicado únicamente, mientras el SDK no soporte borradores.
+
+Activar preview no puede volver dinámica toda la web pública.
+
+## Verificaciones automatizables
+
+Automatizar cuando sea razonable:
+
+- HTML estático con contenido y enlaces reales;
+- conteo de providers/clientes mediante pruebas de integración;
+- inventario de requests GraphQL sin duplicados;
+- batching, caché y error del estado vivo;
+- `noindex, nofollow` y exclusión del sitemap;
+- ausencia de marketing en preview;
+- allowlist y bloqueo de rutas transaccionales;
+- estados, refresh y caché de preview.
+
+No reemplazar un contrato faltante con GraphQL o API directa. Registrarlo como
+brecha del SDK, con evidencia y prueba de aceptación propuesta.

package/skills/bacano-web/references/common.md

@@ -0,0 +1,92 @@
+# Controles comunes
+
+Aplicar `P0` solo a capacidades publicadas o comprometidas para el lanzamiento.
+Usar `P1` para calidad profesional y `P2` para evolución. No convertir una
+función apagada en un bloqueo artificial.
+
+## Repositorio y arquitectura
+
+- Confirmar rama, estado de Git, lockfile y versión instalada del SDK.
+- Identificar framework, modo estático/híbrido/SSR, hosting y dominio canónico.
+- Verificar un único cliente/provider de Bacano y ausencia de GraphQL directo.
+- Si el sitio admite modo construcción, verificar `BacanoWebsiteGate` por fuera
+  de auth y marketing, fallback estático `<noscript>`, actualización en runtime
+  y vista previa temporal.
+- Confirmar que fallos de Content, marketing o servicios externos degradan sin
+  vaciar la página ni bloquear navegación.
+- Ejecutar los controles definidos por el proyecto: instalación reproducible,
+  typecheck, lint, pruebas, E2E disponibles y build de producción.
+
+## Rutas y contenido
+
+- Inventariar rutas desde sitemap, export estático y router; no depender de una
+  muestra manual arbitraria.
+- Comparar rutas declaradas, páginas generadas y URLs del sitemap. Explicar
+  cualquier diferencia y fallar si el build omite contenido público de forma
+  silenciosa.
+- Verificar HTTP, errores de consola, excepciones, recursos fallidos, enlaces
+  internos, 404, redirecciones y canonical.
+- Comprobar que preview, callbacks, cuenta, checkout y respuestas de pago no se
+  indexen cuando corresponda.
+- Validar estados vacío, loading, error y ausencia de Content opcional.
+
+## SEO y compartición
+
+- Título, descripción, canonical, robots, Open Graph y Twitter por ruta.
+- `robots.txt`, sitemap con URLs canónicas y ausencia de rutas privadas.
+- Jerarquía de encabezados, idioma, texto alternativo, enlaces internos y
+  JSON-LD coherente con el contenido visible.
+- Confirmar 404 real, canonical único, ausencia de slugs/URLs duplicadas y
+  redirección consistente entre `www`, dominio raíz y HTTP/HTTPS.
+- Usar `hreflang` solo cuando existan versiones regionales o de idioma reales.
+- Favicon, iconos, manifest y vista previa al compartir.
+
+## Rendimiento y media
+
+- HTML inicial útil; no publicar únicamente skeletons.
+- Imágenes con dimensiones, `srcset`, `sizes`, formatos optimizados y lazy load
+  bajo el pliegue. No construir transformaciones de Storage manualmente.
+- Revisar desktop y mobile, DPR 1/2, CLS, LCP, fuentes y JavaScript inicial.
+  Tratar una medición sintética aislada como diagnóstico, no como verdad de
+  campo; repetir y distinguir regresión sostenida de ruido.
+- Confirmar caché y CORS/CORP de media pública sin proxies locales.
+
+## Accesibilidad y experiencia
+
+- Navegación por teclado, foco visible, landmarks, labels, contraste y zoom.
+- Formularios con errores específicos, estados de envío y prevención de doble
+  envío. No usar solo color para comunicar estado.
+- Probar anchos móviles, tablet y escritorio sin scroll interno accidental.
+
+## Legal y privacidad
+
+- Consumir términos, envíos, cambios/devoluciones, privacidad y cookies desde
+  `publicConfig.legal`, manejando documentos nulos.
+- No duplicar documentos legales en Content o en constantes del storefront.
+- Mostrar el aviso informativo solo si Bacano lo activa y no presentarlo como
+  gestor de consentimiento.
+- No exponer PII, tokens, secretos ni identificadores internos en URL, HTML,
+  logs, eventos o almacenamiento inseguro.
+- Detectar placeholders visibles, texto de ejemplo y datos legales incompletos.
+  Un documento publicado con marcadores como `[RAZÓN SOCIAL]` es un `P0`.
+
+## Seguridad y terceros
+
+- HTTPS, HSTS cuando aplique, `X-Content-Type-Options`, `Referrer-Policy`,
+  `Permissions-Policy` y CSP efectiva.
+- Construir CSP solo con proveedores realmente activos. Revisar la matriz
+  canónica de `STOREFRONT_MARKETING.md`.
+- No usar `unsafe-eval`, comodines arbitrarios ni secretos públicos.
+- Confirmar que CSP no bloquee Clerk, pagos, GA4, Meta o Clarity habilitados.
+- Confirmar que la pantalla de construcción no se presente como seguridad ni
+  permita que contenido privado forme parte del export estático.
+
+## Operación
+
+- Validar dominio canónico, redirects, DNS, SSL, variables de producción y
+  rollback.
+- Confirmar monitoreo de errores y logs sin datos personales.
+- Registrar fecha, ambiente, versión/commit y qué pruebas requieren cuentas o
+  acciones externas para completarse.
+- Verificar que el equipo conoce qué cambios requieren rebuild/despliegue y que
+  existe un mecanismo reproducible para ejecutarlo y revertirlo.

package/skills/bacano-web/references/informational.md

@@ -0,0 +1,39 @@
+# Checklist de web informativa
+
+Aplicar además de los controles comunes.
+
+## Contenido y navegación
+
+- Home, páginas institucionales, servicios, blog, contacto y legales cargan
+  contenido real y conservan rutas estables.
+- Menú, footer, breadcrumbs y enlaces de Content no apuntan a borradores o 404.
+- Preview usa `@bacano/sdk/react/preview`, muestra solo contenido publicado,
+  permanece `noindex` y no dispara marketing.
+
+## Formularios y contacto
+
+- Distinguir formularios informativos/PQRS de capturas comerciales.
+- Newsletter, cupón o interés comercial usan
+  `client.marketing.captureLead()` y el texto vigente de autorización.
+- Formularios generales tienen destino, antispam/rate limit, idempotencia y
+  mensaje de recepción sin promesas falsas.
+- WhatsApp, teléfono y email emiten `contact` con ubicación canónica cuando
+  marketing está activo.
+
+## Medición
+
+- Una sola fuente de `page_view` para navegación inicial y SPA.
+- Medir contacto, formularios y navegación relevante sin inventar ecommerce.
+- GA4, Meta y Clarity cargan solo en dominio canónico y nunca en preview/local.
+- No exigir catálogo, carrito, checkout, métodos de entrega, pagos ni eventos
+  ecommerce a esta clase de sitio.
+
+## Cierre mínimo
+
+- Probar cada formulario sin crear registros duplicados.
+- Verificar entrega o persistencia real cuando el formulario sea esencial.
+- Comprobar páginas principales y legales en desktop/mobile.
+- Validar indexación, performance y consola en todas las rutas publicadas.
+- Marcar autenticación, leads o medición como `➖ NO APLICA` cuando estén
+  realmente apagados; si están visibles, aplicar sus contratos y pruebas de
+  cierre.

package/skills/bacano-web/references/report.md

@@ -0,0 +1,70 @@
+# Formato del informe
+
+## Contexto
+
+- Tipo: web informativa o tienda virtual.
+- Repositorio, rama y commit.
+- Ambiente y dominio.
+- Framework, hosting y versión efectiva de `@bacano/sdk`.
+- Fecha de revisión.
+
+## Alcance detectado
+
+Antes del dictamen incluir una tabla corta:
+
+| Capacidad | Estado | ¿Bloquea este lanzamiento? | Evidencia |
+| --- | --- | --- | --- |
+| Catálogo estático, estado vivo, public-config, preview, marketing, transacciones | ACTIVA/INACTIVA/BLOQUEADA | Sí/No | configuración, código o prueba |
+
+No exigir pruebas a una capacidad `INACTIVA`. Una capacidad `BLOQUEADA` debe
+explicar la dependencia ausente y su impacto.
+
+## Resultado ejecutivo
+
+Indicar una sola conclusión:
+
+- `🟢 LISTO`: sin fallos P0 y con flujos esenciales verificados.
+- `🟡 LISTO CON ADVERTENCIAS`: sin bloqueos P0, con riesgos P1 aceptables.
+- `🔴 NO LISTO`: existe al menos un `❌ FALLÓ` P0 confirmado.
+- `🟠 INCOMPLETO`: falta verificar al menos un P0 activo y no hay evidencia
+  suficiente para declararlo fallido.
+
+No usar `NO LISTO` únicamente porque una función apagada no se probó. Si
+coexisten un fallo P0 y pruebas pendientes, prevalece `🔴 NO LISTO`.
+
+## Evidencia
+
+| Prioridad | Estado                                                                    | Área | Control | Evidencia                | Acción |
+| --------- | ------------------------------------------------------------------------- | ---- | ------- | ------------------------ | ------ |
+| P0/P1/P2  | ✅ APROBADO / ⚠️ ADVERTENCIA / ❌ FALLÓ / ➖ NO APLICA / 🧪 NO VERIFICADO | ...  | ...     | comando, URL o resultado | ...    |
+
+Usar siempre emoji y palabra. Los emojis solos no son suficientemente claros
+ni procesables.
+
+## Pruebas ejecutadas
+
+Listar comandos y sus resultados, rutas auditadas, navegadores/viewports y
+flujos externos realmente ejecutados. Separar pruebas locales de producción.
+
+## Arquitectura SDK y tráfico runtime
+
+Incluir siempre esta sección:
+
+| Control | Resultado | Evidencia |
+| --- | --- | --- |
+| Instancias de `BacanoClient` y `BacanoProvider` | cantidad | archivos o prueba |
+| Operaciones GraphQL en carga inicial | cantidad y nombres | trace/HAR |
+| Operaciones duplicadas | cantidad, nombres y causa | variables y fase |
+| Datos estáticos | inventario | HTML, snapshot o build |
+| Datos actualizados en runtime | inventario | requests observados |
+| Static First | cumple/no cumple/no verificado | conclusión |
+| Preview | cumple/no cumple/no aplica/no verificado | conclusión |
+
+Para cada incumplimiento indicar severidad, efecto y recomendación. No afirmar
+que no hubo requests cuando no se capturó un trace real.
+
+## Riesgos y próximos pasos
+
+Ordenar por severidad. Cada hallazgo debe incluir alcance, causa confirmada o
+hipótesis explícita, corrección propuesta y prueba de cierre. No mezclar
+mejoras opcionales con bloqueos de salida.

package/skills/bacano-web/references/storefront.md

@@ -0,0 +1,116 @@
+# Checklist de tienda virtual
+
+Aplicar además de los controles comunes.
+
+## P0 · Publicación y cobertura del catálogo
+
+- Generar rutas, HTML, metadata, sitemap y JSON-LD desde un único
+  `getStaticCatalogBootstrap()`; no consultar un producto por ruta durante el
+  mismo build.
+- Comparar `bootstrap.total`, productos únicos del snapshot, rutas de producto
+  generadas, URLs de producto del sitemap y páginas del export. Toda diferencia
+  debe ser intencional y explicable; el límite configurado no puede truncar el
+  catálogo silenciosamente.
+- Hacer fallar el build de producción si el snapshot está vacío, incompleto o
+  no corresponde al website esperado. Los placeholders solo sirven en local.
+- Usar `/producto/{slug}` como ruta canónica cuando el proyecto adopte ese
+  contrato; la variante publicitaria usa `?variant={product_variant_id}` sin
+  alterar canonical.
+- Precio, SKU, stock, variante seleccionada, JSON-LD, carrito, WhatsApp y
+  eventos deben referirse a la misma variante.
+- El HTML inicial debe contener producto, precio y enlaces reales sin depender
+  de JavaScript. Después de hidratar, refrescar únicamente estado volátil por
+  lotes con `getProductLiveState()` y respetar `maxPurchasableQuantity`.
+- Si el refresh vivo falla, conservar el snapshot sin vaciar ni bloquear la
+  página. Al mismo tiempo, checkout debe revalidar autoritativamente precio y
+  stock ante concurrencia.
+- Verificar el comportamiento cuando una variante queda agotada, cambia de
+  precio o limita cantidad entre build y compra.
+- Definir cómo se dispara un rebuild al publicar, retirar, renombrar o cambiar
+  imágenes/descripción. El refresh vivo no reemplaza esa actualización
+  editorial del snapshot.
+- Recomendaciones y relacionados no bloquean el contenido principal.
+
+## P0 · SEO comercial
+
+- Cada producto público tiene título, descripción, canonical, Open Graph,
+  imagen compartible y JSON-LD `Product` coherente con la variante visible.
+- Sitemap contiene cada slug canónico una sola vez y excluye UUID, query de
+  variante, preview, checkout, cuenta, pedido y respuesta de pago.
+- La ruta elegida desde feed, anuncio, tarjeta, relacionado y carrito resuelve
+  el mismo producto; URLs antiguas importantes redirigen o se documentan.
+- Producto retirado responde 404/410 o se reconstruye dentro del SLA definido;
+  nunca queda comprable solo por existir en un export viejo.
+
+## Carrito y checkout
+
+- Carrito invitado persiste y sincroniza sin duplicar líneas.
+- Probar alta, baja, cambios de cantidad, límites de stock, cupón, envío gratis,
+  impuestos, moneda y redondeo.
+- Probar solo los modos activos entre COUNTER, PICKUP y SHIPPING; propia y
+  transportadora cuando apliquen, incluyendo contraentrega y pagos parciales.
+- Verificar errores accionables, idempotencia y doble clic/reintento.
+- Nunca inventar reglas de ventas o estados en el storefront.
+
+## Pagos y pedidos
+
+- Ejecutar al menos un happy path real o sandbox por cada método crítico
+  publicado. Probar pago inmediato, transferencia, Wompi y contraentrega solo
+  si están activos; los estados alternos de cada proveedor quedan en su matriz
+  de riesgo.
+- La página de respuesta no emite `purchase`; Bacano lo hace desde hechos
+  autoritativos. Repetir webhook/conciliación no duplica conversiones.
+- Pedido, pago, entrega y desembolso permanecen conceptos separados.
+- Probar consulta pública segura y cuenta autenticada sin filtrar pedidos de
+  otra persona, website o canal.
+
+## Autenticación
+
+- Clerk posee registro, inicio de sesión, recuperación, verificación y sesión.
+- Una aplicación Clerk por website; solo publishable key en navegador.
+- Un `BacanoProvider` recibe `getAccessToken`; no se captura ni guarda el token.
+- Si las cuentas están activas o se anuncian, probar registro/inicio y el flujo
+  principal autenticado; recuperación, verificación, perfil, direcciones y
+  pedidos se clasifican según lo publicado. Clerk no rompe checkout invitado.
+- Si las cuentas están apagadas, todas estas pruebas son `➖ NO APLICA`.
+
+## Marketing y catálogos publicitarios
+
+- Instrumentar únicamente con `useMarketing().track()` después del éxito.
+- `product_variant_id` es `itemId`; `order_id` es `transaction_id`.
+- Auditar `view_item_list`, `select_item`, `view_item`, carrito, checkout y
+  contactos; conversiones autoritativas nunca salen del navegador.
+- Primera y última fuente no directa sobreviven navegación interna y quedan
+  congeladas en el pedido.
+- Feeds Meta/Google usan la misma variante, ruta, precio y disponibilidad que
+  la landing. Probar URLs del feed y productos omitidos.
+- GA4, Meta, Clarity, leads y feeds se auditan únicamente si están activos.
+  Cada proveedor activo debe demostrar al menos una recepción real antes de
+  declarar esa capacidad lista, sin convertir su caída en bloqueo de compra.
+
+## P1 · Calidad profesional
+
+- Media responsive con dimensiones, `srcset`, `sizes`, carga prioritaria solo
+  para LCP y lazy loading bajo el pliegue; sin transformaciones manuales.
+- Catálogo, filtros y carrito conservan contenido útil durante errores
+  transitorios y no producen saltos de layout evitables.
+- JSON-LD, feed publicitario y estado vivo no contradicen precio, moneda,
+  disponibilidad ni variante mostrados.
+- La generación es reproducible con lockfile y deja evidencia de conteos,
+  snapshot, duración y artefacto.
+
+## P2 · Evolución
+
+- Datos de campo de Core Web Vitals, pruebas sintéticas periódicas, monitoreo de
+  enlaces rotos y alertas de divergencia entre feed, sitemap y catálogo.
+- Matrices exhaustivas de estados no críticos, navegadores adicionales y
+  automatización de rebuild según el hosting.
+
+## Cierre transaccional
+
+- Ejecutar al menos una compra real o sandbox por método crítico activo.
+- Confirmar pedido en Bacano, estado económico, inventario, envío y correo.
+- Confirmar GA4/Meta del embudo y conversión sin duplicados.
+- Si un flujo activo esencial no se ejecutó, marcarlo `🧪 NO VERIFICADO`, no
+  `APROBADO`; el dictamen es `🟠 INCOMPLETO` salvo que exista además un fallo
+  probado.