Versión: 1.1 (27-sep-2026)
Estado: NORMATIVO
Aprobado por: Carlos Alberto Torres Camargo — 17-sep-2026
Implementación de referencia: NebulaToastService (nebula-ui-kit) y DialogService.confirm
Un aviso se clasifica por lo que EXIGE DEL USUARIO, no por si trae buenas o malas noticias.
Clasificar por éxito y error es lo que lleva a sacar "Banco seleccionado: Bancolombia" cuando el
banco elegido ya se ve en el campo. La pregunta correcta es otra: ¿el usuario tiene que hacer
algo?
Informa y se va. El usuario sigue trabajando; si no lo lee, no pasa nada grave.
Cuándo: se guardó, se anuló, se eliminó · falló una consulta que puede reintentar · falta
elegir el país antes de bajar a departamento.
Reglas duras:
Cómo: inject(NebulaToastService) y publicar. Quien publica no necesita saber dónde está
la zona de toast; la zona lo recoge. Una sección anidada puede avisar igual que una pantalla.
Hay una acción en curso que no debe ejecutarse sin que el usuario diga que sí.
Cuándo: eliminar, anular, desactivar, finalizar · salir con cambios sin guardar · guardar
dejando secciones opcionales vacías.
Reglas duras:
Cómo: DialogService.confirm(...), suscribiéndose al resultado.
No es un aviso: es una pantalla pequeña. El buscador de bancos, el de ciudades, la ventana de
dirección.
Regla dura: un modal no notifica. Si algo falla dentro, sale en toast.
Compite con los campos por el mismo espacio, empuja el contenido al aparecer, y un CRUD anidado
—que no sabe dónde termina su sección— no tiene dónde ponerlo sin estorbar.
AlertStore y la entrada de aviso de app-page-container quedan deprecados. Desde nebula-ui-kit 2.4.0 (27-sep-2026) lib-alert también queda @deprecated por completo: avisa en consola en desarrollo, salió del Storybook del kit y la composición del layout ya no lo pinta. El Storybook del manual lo conserva aparte, en «⛔ Deprecado», marcado y con su reemplazo; el inventario de lo deprecado, con sus usos, está en http://10.120.0.2:8552/propuesto/dist/reglas/deprecado.html. No se retiran
mientras queden pantallas que los usen: retirarlos antes las dejaría sin avisar.
Elegir algo de un buscador no se notifica: lo elegido está en el campo. El aviso solo repetía
en una caja lo que el usuario acababa de hacer.
Guardar no es destructivo y se puede volver a guardar. Confirmar cada guardado entrena al
usuario a pulsar "Sí" sin leer, y cuando llega la confirmación que sí importa —eliminar, anular—
ya no la lee.
Un campo mal diligenciado se dice en el campo. El toast solo entra cuando el usuario no está
mirando dónde ocurrió: por ejemplo, faltan campos en otra pestaña.
No es un toast. Un toast se va solo y deja al usuario ante una pantalla vacía sin saber por qué.
Se pinta como estado de error en el cuerpo de la pantalla: dice qué pasó, se queda mientras el
problema exista y ofrece reintentar.
Cómo se ven el toast, la confirmación y la ventana en el perfil 3.0, y el contrato de DialogService y NebulaToastService: Manual de Diseño 3.0 · Modales y avisos.
Lo imponible lo impone la API: el aviso dentro del formulario está deprecado y el toast es un
servicio, de modo que la regla se aplica sola. Lo que no se puede codificar —cuándo es
confirmación y cuándo toast— vive en el Javadoc de NebulaToastService, donde el desarrollador lo
encuentra al usarlo, y en este documento.
Medido el 17-sep-2026 sobre nebula-erp:
| Plantillas que pintan el aviso dentro del formulario | 66 |
Componentes que extienden AlertStore |
9 |
Llamadas a DialogService.confirm |
más de 50 |
| Confirmaciones de guardado | 0 (eran 6; retiradas) |
Terceros (#275) es la primera pantalla migrada por completo. Las demás quedan como frente
abierto y medido.