Este plan convierte el estado actual de libs/shared/ui/src/lib/modals en una transición revisable. La meta propuesta es conservar una sola base visual para selección, abrirla mediante una fachada genérica y obtener datos del servicio dueño de cada API. Los servicios específicos que solo duplican configuración del selector se retirarán después de migrar sus consumidores.
INVENTARIO_MODALES_Y_SELECTORES.md y añadir consumidores que aparezcan al buscar imports en todo el monorepo.conceptos-facturacion con invoice-concept-modal, servicios de importación genérica, plan de cuentas y formatos contables.DialogService, cuáles se usan como componente embebido y cuáles ejecutan una operación de archivo.Salida: matriz de consumidores y dueño de cada endpoint; todavía no retirar código.
SelectDialogComponent existente en libs/shared/ui/src/lib/select-dialog.No crear un servicio API monolítico. El servicio genérico de diálogo no conoce recursos ni endpoints.
shared/uiPor dominio funcional y de menor riesgo primero:
libs/data-access/src/<funcionalidad>/ propietario del endpoint.HttpClient directo y URL fija a HttpService + API_CONFIG.libs/domain/src/lib/<dominio>/; dejar DTO de transporte exclusivo junto a su cliente API.index.ts públicos y exportaciones a los barriles raíz de cada librería.shared/ui/src/lib/modals.Migrar en grupos pequeños, verificando la selección y paginación para cada grupo:
Para cada uno, el componente consumidor inyecta el servicio del feature y entrega un datasource al modal base. Si la configuración del selector se comparte legítimamente, puede vivir en una pequeña factory tipada por catálogo; la petición HTTP sigue perteneciendo al data-access del recurso.
No tratar estos flujos como selectores simples:
ConfirmReasonModalComponent: mantenerlo enfocado en captura de razón; mover su estado de datos al consumidor si no requiere API.DiferidoDialogComponent, CuentaDeduccionDialogComponent, FormatoContableDialogComponent: asociar UI y lógica a accounting/invoicing según ownership funcional, reutilizando controles/base visual común.ImportarAsientoDialogComponent y ImportarGeneralDialogComponent: separar UI de carga/preview de los servicios de importación y contratos de backend. La importación contable pertenece a data-access/feature accounting; la base de carga genérica puede vivir en shared UI.AccountingAccountPopupComponent: mantenerlo como pieza visual de detalle o convertir su contenido en una variante del selector, sin inyectar endpoint concreto en el selector genérico.Después de migrar todos los consumidores de un wrapper:
@deprecated indicando el reemplazo.libs/shared/ui/src/index.ts cuando no existan imports.libs/data-access/<feature>.libs/domain, DTO específico junto al data-access.HttpClient local fuera del patrón aprobado.loadPage/datasource a la base común.La migración de un recurso está completa cuando hay un único servicio propietario de su fuente API, un único contrato público para los modelos compartidos, un único componente base de selección, consumidores actualizados y ningún import activo del wrapper antiguo. Los modales de flujo especializado pueden conservar componentes propios si reutilizan el shell/controles y mantienen sus APIs fuera de shared/ui.