Veredicto: 🟢 GO. Se validó de punta a punta el sistema de control de acceso contra producción, un día antes del evento. Todo funciona. Hay 3 pendientes menores (ninguno bloquea) y 1 gotcha operativo (walk-ins).
Se corrigieron dos supuestos: (1) el escáner sí tiene búsqueda por nombre — el "plan B" ya existía; (2) el correo ya no usa Gmail SMTP, ahora sale por Resend.
| Pendientes de enviar | 0 — 100% enviado (creció a 1,757 y aun así llegó a cero) |
| Workflow WF-EXPOLIVING-SEND | ✓ Activo, 10 ejecuciones recientes, 0 errores |
| Vía de envío | Resend API, remitente info@expoliving.mx (ya no Gmail SMTP) |
| Entregabilidad (DNS) | Revisar SPF de envío OK (send.expoliving.mx → amazonses); DMARC p=none. DKIM de Resend no encontrado, pero DMARC probablemente pasa por alineación SPF. Confirmar "Verified" en Resend + spot-check spam. |
| Estado | Resultado en pantalla |
|---|---|
| OK | ✓ ACCESO PERMITIDO · nombre · Día 25 (verde) |
| DUP | ⚠ YA INGRESÓ EL DÍA 25 · hora del primer ingreso (ámbar) |
| NOTFOUND | ✕ CÓDIGO NO VÁLIDO (rojo) |
Modo offline: ✓ al simular caída de red, el ingreso se encoló ("1 por subir") y se subió solo al reconectar.
Búsqueda por nombre (Plan B): ✓ probada en vivo — "garcia" devolvió 54 resultados con botón "Registrar".
/api/list) es un snapshot que se refresca por lotes aprox. cada 15–20 min, no en vivo. El intake al CRM es instantáneo, pero la puerta ve la lista con retraso. Impacto: solo afecta a walk-ins registrados en la puerta (los ~1,757 pre-registrados ya están). Ver pendiente en el runbook.| Con código de acceso | 100% (0 sin código) |
| Check-ins reales | 0 — arranque limpio |
| Códigos duplicados | 8 — misma persona registrada 2 veces (cosmético, infla conteo) |
| Sin nombre | 1 — código EXPOLW7IRSF |
| Por tipo | 1,739 visitantes · 14 expositores · 1 sin tipo |
El intake dedupea por teléfono/email. El teléfono de prueba 8110000000 colisionó con una entrada existente ("Gerardo C G", email relay, teléfono idéntico — probable registro basura). Resultado: no se creó Persona nueva; se le regeneró el QR y se le añadió una nota.
Los códigos QR son deterministas. Al regenerar el de "Gerardo", salió idéntico al que ya tenía (EXPOVAB44OD) → re-registrarse NO invalida el QR ya emitido. Bueno para la robustez del sistema.
Correo por Resend, no Gmail. El workflow cambió de Gmail SMTP a Resend después del 21 jul. Nota vieja desactualizada corregida en memoria.
Se probó sin ensuciar: notfound y offline usaron un código inexistente (sin efecto en datos reales).
Huella menor: (1) una nota inocua en "Gerardo C G" + QR regenerado idéntico (sin daño); (2) un check-in de prueba en la entrada "PRUEBA Puerta" (EXPOPRUEBAPUERTA) al probar ok/dup.
No se hizo: no se borró "PRUEBA Puerta" (no la creé yo; puede estar en uso por el equipo) → queda como acción para el sábado. No se envió ningún correo nuevo. No se modificó ningún registrante real.
| Acción | Prioridad |
|---|---|
| Confirmar dominio "Verified" en Resend + spot-check spam | Media |
Borrar entrada de prueba "PRUEBA Puerta" (EXPOPRUEBAPUERTA) → resetea contador | Media |
| Decidir política de walk-ins en puerta (por el lag de ~15–20 min) | Alta si habrá walk-ins |
| Limpiar 8 duplicados + 1 sin nombre | Baja |
| Escáner (puerta) | expoliving-acceso.pages.dev |
| Registro público | registro.expoliving.mx |
| CRM (Twenty) | expo-living.crm.demarketing.mx |
| Backend (Worker) | expoliving-checkin-api.miguel-28a.workers.dev — /api/list, /api/checkin, /api/pending, /api/mark-emailed |
| WF intake (n8n) | WF-EXPOLIVING-INTAKE · gFLDByb0ZNu1OxSU (webhook, tiempo real) |
| WF envío (n8n) | WF-EXPOLIVING-SEND · 2mfi60Xidn67RWvN (Resend, cada 10 min) |
| Este runbook | expoliving-runbook.pages.dev |
Las llaves/tokens NO se incluyen aquí (están en la memoria local y en los secretos del worker/n8n).