HAILO×AurenPROYECTO 48
Actividad · Tema 3.2 · El Proyecto de 48 Horas

Un CRM con agente
de dirección,
entregado en 48 horas.

Grupo Auren es una casa de bodas y eventos en San Pedro Garza García. Entre el 26 y el 27 de agosto de 2026 HAILO reconstruyó su CRM, le abrió un espacio de operaciones y puso a Emilia, su agente de dirección, a contestar con la base completa. Esto es el proyecto real, contado por los siete dominios de desempeño.

GobernanzaAlcance CronogramaFinanzas InteresadosRecursos Riesgo
AutorGonzalo Estrada Garza
EquipoIndividual
ClienteGrupo Auren
Ventana26 — 27 ago 2026
Emilia — consola de operación Live
Agente EMILIAHerramientas 36 Cerebro Hermes + DeepSeekCorre en VPS · pm2
El encargo
Un proyecto real,
no un plan hipotético.
Lo que pide la actividad
Ejecutar de verdad
Un mini-proyecto tangible, completado antes de la presentación, con bitácora de siete dominios y evidencia verificable.
Lo que elegí
Proyecto propio: un cliente real
Auren ya había firmado con HAILO. El CRM y el agente de dirección eran la primera entrega comprometida y tenían que quedar vivos en dos días.
Por qué son 48 horas
El repositorio lo demuestra
Del primer commit del 26 de agosto a las 12:12 al último del 27 a las 17:30. Cada hora de este documento sale de ahí.
Commits
0
En la ventana de dos días
Horas de ventana
0
12:12 del día 1 → 17:30 del día 2
Rutas en producción
0
Escritorio e iPhone, sin errores de consola
Herramientas de Emilia
0
De 10 el día 1 a 36 el día 2
La evidencia
Del diagnóstico al sistema vivo.
Recórrelo.

A la izquierda, lo que se le propuso a Auren el 12 de agosto. A la derecha, lo que quedó en producción el 27. Cada punto del menú pinta una pantalla real, no un mock.

diagnostico.auren.hailo.mx Captura real
Los agentes
Tres que trabajaron.
Uno de ellos construyó a los otros.

Pica ▶ y mira lo que hace cada uno. Los que hablan muestran su conversación; el que construye, su bitácora de commits.

Las 48 horas
Hora por hora,
sacado del repositorio.

Cada barra empieza donde terminó el commit anterior y termina en el suyo. La línea punteada es la entrega que se planeó; la sólida, la que ocurrió. Pica una barra para ver qué pasó ahí.

Pica una barra ↗
Actividad

Lo que dice el reloj

Tres lecturas

›El día 1 cerró dos horas tarde
Se planeó terminar a las 18:00 con Emilia conectada. El QA en producción encontró 15 excepciones por visita en /leads y empujó el cierre a las 20:12.
›El día 2 se fue en Emilia
Ocho de las trece actividades del día son de ella: salir de la base, Google por persona, artefactos, rutinas. Era el corazón del encargo.
›Tres actividades no estaban en el plan
El QA en producción, el organigrama de Agentes y el área segura del iPhone. Suman 3 h 05 min: exactamente el retraso sobre la entrega planeada.
›Un socio en el mismo repositorio
Erik dejó el CRM base el 25 y volvió el 27 con la ficha de Emilio. Ningún conflicto: git fetch antes de tocar, push al terminar.
La bitácora
Siete dominios,
una decisión real en cada uno.

No son respuestas de manual. Cada tarjeta abre la decisión que se tomó, por qué, y la evidencia que la respalda.

Los checkpoints
Tres entregas,
en el orden que pide la actividad.
El riesgo que se materializó
Cero filas.
Cero errores.
26 de agosto · 18:30
Emilia estaba conectada
y no veía a nadie.

La vista de contactos traía la seguridad por fila horneada: resolvía el rol con la sesión del usuario. Con la llave de servicio del agente no hay sesión, así que el rol era nulo y la base devolvía vacío. Sin error, sin aviso. El peor tipo de falla: la que parece que funciona.

emilia › buscar_lead("Garza")
→ v_contactos … rol_actual() = null
→ 0 filas · status 200
emilia › buscar_lead("Garza") · v_leads_activos
→ 1 fila · teléfono enmascarado ✓
¿Cómo se detectó?
Probándola de verdad, no leyendo el código: una pregunta con un nombre conocido regresó «no encuentro a nadie».
¿Cómo se resolvió en el momento?
El esquema ya tenía vistas pensadas para el agente (leads activos, pendientes, cotizaciones, histórico). Emilia se movió a esas esa misma tarde.
¿Qué cambió después?
El día 2 se crearon 16 vistas planas exclusivas para ella y una función que suma en Postgres: Emilia lee toda la base y nunca suma de cabeza.
¿Qué regla quedó?
Un resultado vacío se trata como error hasta demostrar lo contrario. Y todo se prueba en producción, con navegador, antes de decir «listo».
Pregunta de cierre
Si lo repitiéramos, ¿qué dominio cambiaríamos primero?
La respuesta
Recursos. Y por una razón muy concreta.

Lo único que no quedó vivo al cerrar el día 2 no fue código: fueron tres llaves que no eran nuestras. Las credenciales de WhatsApp del cliente, el permiso de Google del dueño para que Emilia lea su agenda, y una llave de inferencia a nombre de Auren en lugar de la de HAILO. Cada una bloqueó una función terminada.

Se piden el día cero, antes de escribir la primera línea, con una lista de accesos como primer entregable del cliente. El código se escribe en 48 horas; una llave ajena puede tardar una semana.

Lo que me llevo

Cuatro aprendizajes

›Los dominios no van en fila
El riesgo de las cero filas fue a la vez un problema de recursos (la llave equivocada), de cronograma (dos horas) y de alcance (16 vistas nuevas). Se tocan solos.
›El silencio también es un error
Un 200 con cero filas engaña más que un 500. Lo que no se prueba contra datos reales no está probado.
›El commit es la bitácora
Cada mensaje dice en español qué cambió y por qué. Esta página se reconstruyó desde ahí sin inventar una hora.
›Hay scope creep bueno
El organigrama de Agentes no estaba en el plan y es la pantalla que el cliente más entiende. Se acepta cuando cabe en el margen, y se anota.