@
Mejora derivada de la decisión abierta de #64 (que se cerró por el camino simple: campo contact string + VerificationLevel del recurso).
Contexto
Hoy el contacto oficial de un punto es un único contact (string) en resource.ts, gateado por verificationLevel === official. Funciona para "a quién llamar", pero es plano:
- un solo contacto por recurso,
- sin rol (responsable, logística, médico…),
- sin canal preferente (teléfono / WhatsApp / email),
- sin verificación propia (hereda la del recurso).
Propuesta
Elevar el contacto a un sub-modelo reutilizable por cualquier tipo de destinatario/punto:
- Lista de contactos por recurso, cada uno con:
rol, nombre, canal (phone/whatsapp/email), valor, y verificado propio (vinculado a la acreditación del responsable).
- Mostrar el/los contactos destacados en la ficha, marcando el verificado.
- Mantener compatibilidad: el
contact actual se migra como un contacto único.
Valor
Centralizar peticiones es hoy un cuello de botella real (ver el parte de campo citado en #64). Un contacto estructurado y por rol reduce la fricción de "¿a quién llamo y por dónde?".
Notas
@
Mejora derivada de la decisión abierta de #64 (que se cerró por el camino simple: campo
contactstring +VerificationLeveldel recurso).Contexto
Hoy el contacto oficial de un punto es un único
contact(string) enresource.ts, gateado porverificationLevel === official. Funciona para "a quién llamar", pero es plano:Propuesta
Elevar el contacto a un sub-modelo reutilizable por cualquier tipo de destinatario/punto:
rol,nombre,canal(phone/whatsapp/email),valor, yverificadopropio (vinculado a la acreditación del responsable).contactactual se migra como un contacto único.Valor
Centralizar peticiones es hoy un cuello de botella real (ver el parte de campo citado en #64). Un contacto estructurado y por rol reduce la fricción de "¿a quién llamo y por dónde?".
Notas
resourceso tabla/agregado propio en un contextocontacts?@