Clientes
Un solo registro de cliente para cada vertical. Forma parte del vertical de negocio. Leyenda: ✅ hecho · 🟡 en curso · ⬜ pendiente.
Lista
✅ Pacientes
Un solo registro de cliente para cada vertical.
✅ Contactos
Personas propiedad de la compañía sobre la tabla contacts portada; CRUD de /v1/contacts probado en vivo.
✅ Segmentos
Grupos nombrados con membresía explícita y listas contadas; otras compañías no ven nada.
✅ Derivaciones
Quién envió a cada cliente, sin la restricción de uno-por-paciente de la tabla dental; el ciclo cliente-a-cliente está cerrado.
✅ Resolución de identidad
Atribución del correo del checkout a orders.customer_id con una cola de sugerencias pendientes cuando no hay coincidencia; el enlace de /v1/identity-suggestions actualiza orden + facturas atómicamente (V08_10).
Evidencia
Un solo registro de cliente a nivel de negocio, escrito de verdad: el resolutor geo-referencial cerró la regla nombre-a-id, las inserciones pasan por el grafo del cliente y las actualizaciones sincronizan correos y direcciones — probado en vivo. Los pacientes dentales se vinculan mediante patients.customer_id. Contactos, segmentos (customer_groups + miembros) y referidos (generalizados de la tabla dental) tienen rutas probadas en vivo. La resolución de identidad está entregada en el checkout: un correo del carrito que nombra exactamente un cliente atribuye la orden (y su factura AR) al enviarla, un correo sin coincidencia acuña una fila pendiente en identity_suggestions (V08_10, idempotente por orden), y la cola de revisión detrás de /v1/identity-suggestions vincula orden + facturas atómicamente o descarta — probado en vivo de extremo a extremo. Pendiente: auto-sugerencia del lado del paciente y revisión de fusión para registros duplicados.