Guía de adopción
Cómo migra cada app a la versión vigente, sin big-bang y con prueba en navegador por paso.
La regla: una app por vez, un módulo por vez, prueba en navegador antes de commitear.
Subir el paquete (las 4 apps)
"@fesa/components": "git+ssh://[email protected]/AdanSerrano/fesa-components.git#v0.5.2"Cambia también transpilePackages y el @source de Tailwind al nombre nuevo, purga el lock
(bun pm cache rm + borrar las líneas @fesa/ del bun.lock + rm -rf node_modules/@fesa) y
reinstala. Imports: @fesa/datatable → @fesa/components/datatable (y /server). El API de la
tabla no cambió: si compila, se comporta igual.
fesa.com.pa — formularios ✅ (hecho en v0.5.2)
Reemplazado components/ui/form-fields/ (~17.000 LOC) por imports de @fesa/components/forms.
El barrel exporta los mismos nombres; el grueso del cambio es la ruta del import. Validar el
módulo form-demo completo en navegador.
Fesa ID — motion + hooks + email
Borrar sus copias de use-in-view, animated-*, back-to-top y adoptar el layout de email
inyectando su marca (brandName="Fesa ID").
FesaStore — seguridad + utils
Adoptar ./security (su WAF es el donor: cambio de import) y las utilidades que donó
(serialize, date-range, slug).
tracking y transfer — ui + email + storage
Los satélites ganan todo lo que hoy no tienen: primitivas mantenidas, design system de email y el adapter R2 que transfer ya usa (versión unificada).
Qué NO migrar todavía
El cluster de auth (better-auth), el motor de importación, realtime SSE y audit-log están planificados pero no extraídos — el orden y las decisiones pendientes están en el AUDIT-2026.md del repo.