Aggregator de iconos por BC
Generado automáticamente desde el archivo fuente. No editar a mano — vuelve a ejecutar
catalyst-changelog-sync.
Qué cambió
Sección titulada «Qué cambió»- Nuevo fichero emitido por bounded context:
<bc>-icons.providers.ts, exporta<bcCamel>Icons— el set deduplicado y ordenado alfabéticamente de iconoslucide*declarados en<bc>.navigation.ts. Marcado@aurora-catalyst-generated, sobrescrito por completo en cada regen. - Nuevo bootstrap idempotente que modifica
nav-main.tsexactamente una vez por BC: añade unimport { <bcCamel>Icons }y un spread...<bcCamel>Iconsdentro deprovideIcons({...}). Los imports y los iconos chrome del framework existentes no se tocan. - La plantilla scaffold
nav-main.tsse actualiza para declarar solo iconos framework inline (lucideSquareTerminal,lucideChevronRight, …); los iconos BC-específicos viven en el aggregator.
Por qué importa
Sección titulada «Por qué importa»Añadir un NavItem con un icono nuevo requería antes una edición manual de nav-main.ts para registrar el icono en provideIcons. Olvidar la edición producía un <ng-icon> vacío en el sidebar — bug visual silencioso, sin error en runtime. Con el aggregator dueño del registro, cada regen de módulo frontend mantiene el sidebar en sync; los consumidores solo editan nav-main.ts para chrome framework. Cuando provideIcons recibe un argumento no canónico (p.ej. una variable custom), el bootstrap loguea [NAV-MAIN BOOTSTRAP SKIPPED] y emite el aggregator igualmente, así que el wire-up manual sigue siendo posible.