Haz cambios en un monorepo full stack sin romper los paquetes compartidos

## Ubica cada cambio en el módulo responsable Antes de editar, crea un mapa del workspace. Distingue entre aplicaciones de producto, paquetes de UI reutilizables, lógica empresarial compartida, esquemas y migraciones de datos, paquetes de tipos, presets de configuración, documentación, recursos de despliegue y arneses de prueba. Coloca el comportamiento específico de una funcionalidad en la aplicación o el módulo responsable de ella. Coloca la lógica de dominio reutilizable y los tipos compartidos en paquetes con consumidores explícitos. Mantén la infraestructura y los elementos auxiliares del despliegue separados del código fuente de runtime. Ubica las pruebas unitarias junto a la lógica estable que ejercitan, mientras que las especificaciones de flujos de navegador deben estar en el área end-to-end de la aplicación. No dupliques lógica compartida dentro de una aplicación solo para evitar modificar un paquete. Respeta la dirección de las dependencias y verifica todos los consumidores posteriores cuando cambie un paquete compartido. ## Recompila los paquetes precompilados y evita cachés viejas Identifica los paquetes que se precompilan y se copian en los assets públicos de una aplicación. Una aplicación en ejecución puede importar el resultado de distribución del paquete en lugar de su código fuente, por lo que editar únicamente el código fuente puede no producir un cambio observable. Después de cambiar un paquete precompilado o cualquier dependencia que afecte a su bundle: 1. elimina únicamente los resultados de distribución conocidos del paquete y los artefactos copiados; 2. omite la caché del sistema de build para el grafo de dependencias afectado; 3. vuelve a compilar el paquete mediante su tarea oficial del workspace; 4. actualiza o desactiva la caché del navegador; 5. reinicia el servidor de desarrollo solo si el asset recompilado sigue sin cargarse. Nunca edites manualmente bundles copiados ni artefactos generados. Considera la invalidación de caché como parte del procedimiento de verificación, no como prueba de que el cambio en el código fuente ha fallado. ## Sigue las reglas compartidas de lint y de tipos Usa los presets compartidos del repositorio para lint, formato y compilación en lugar de overrides locales. Sigue las reglas establecidas de sangría, ancho de línea, comillas, punto y coma y agrupación de imports. Nombra los componentes y sus carpetas de forma coherente, usa lower camel case para funciones y variables, y reserva upper snake case para constantes reales. Coloca los mocks en la ubicación designada para que la resolución y el orden de los imports permanezcan estables. Prefiere tipos inferidos cuando sigan siendo claros, usa los tipos de dominio compartidos y evita vías de escape sin tipado. Trata las props de los componentes como inmutables. Mantén los componentes enfocados, limita los efectos, conserva correctas las dependencias de los hooks y justifica la memoización por una necesidad medida, no por costumbre. ## Separa la lógica del servidor y crea las claves de caché con una sola fábrica Mantén separadas la composición de rutas, la lógica de servicios y los módulos de funcionalidades. Las acciones del servidor deben llamar a servicios y devolver un único formato coherente de éxito o error. Los proveedores de contexto deben fallar de forma clara cuando se usen fuera de su provider y deben limpiar los efectos mediante snapshots estables en lugar de referencias mutables. Usa memoización limitada a la solicitud para el trabajo duplicado dentro de una misma solicitud. Para trabajos costosos entre solicitudes, usa la abstracción de caché compartida aprobada o una caché distribuida explícita. No introduzcas una API de caché inestable del framework cuando el repositorio la haya rechazado. Crea todas las claves de caché mediante la factoría de claves canónica. La clave debe incluir todas las dimensiones que puedan cambiar el resultado, para evitar que usuarios, tenants, entornos, locales o modos de funcionalidad compartan entradas incompatibles. ## Pasa los textos por traducción y separa la zona horaria del idioma Canaliza todo el texto visible para el usuario a través de la función de traducción y sigue la convención establecida de claves en minúsculas separadas por puntos. Mantén un archivo del locale de origen como única fuente de traducciones escrita manualmente. Nunca edites a mano los archivos de locale generados; ejecuta el generador de localización y el validador de claves después de cambiar el texto de origen. Representa las fechas y horas visibles para el usuario mediante los helpers compartidos. Obtén el locale de visualización de la fuente de verdad del idioma de la aplicación, nunca de un valor predeterminado implícito del navegador. Trata el locale y la zona horaria como elementos independientes: el locale controla el formato, mientras que la zona horaria controla el instante representado. Nunca deduzcas la zona horaria a partir del locale. Conserva la semántica existente de los valores almacenados, salvo que el producto defina una fuente de verdad para la zona horaria. Mantén el almacenamiento, las API, las exportaciones, las integraciones y los logs en formatos estables y no localizados, como una representación UTC o ISO explícita. ## No mezcles los datos de cada organización y mantén rápidas las consultas Limita todas las operaciones de datos según la frontera de tenant del repositorio, como la organización y el entorno. Aplica de forma coherente los filtros de eliminación lógica para que los registros inactivos o eliminados no vuelvan a aparecer mediante rutas de consulta alternativas. Para obtener recuentos, usa una consulta de recuento con filtros en lugar de argumentos de paginación basados en offset. Ejecuta simultáneamente las consultas independientes de recuento y datos. Prefiere la paginación por cursor para conjuntos de datos grandes e incluye campos de propiedad indexados cuando filtres por tiempo. Revisa los cambios de esquema y migración junto con todas las rutas de consulta afectadas. El aislamiento de datos es una invariante transversal: la ausencia de un predicado de tenant no es un problema menor de rendimiento, sino un posible fallo de los límites de datos. ## Elige las pruebas según el riesgo para el usuario, no por la cobertura Optimiza la confianza, no un porcentaje de cobertura: - Usa pruebas end-to-end en el navegador para recorridos críticos del usuario, regresiones de la UI y comportamiento de componentes. - Usa pruebas unitarias para lógica pura y estable, como validadores, transformadores, evaluadores, cálculos y casos límite. - Usa comprobaciones manuales en staging para determinar si una release está lista, con un ciclo de corrección de errores, backport y repetición de pruebas para los hallazgos críticos. Mantén las pruebas de navegador enfocadas, bien nombradas y explícitas respecto a las suites lentas. Simula los límites de red y almacenamiento mediante helpers compartidos. No añadas snapshots frágiles de componentes, aserciones de markup, pruebas de detalles de implementación, trucos de temporización, flujos desmesurados ni pruebas de poco valor creadas únicamente para aumentar la cobertura. Ejecuta la suite unitaria estándar antes de la revisión, la cobertura cuando cambien flujos críticos y la suite end-to-end directamente afectada cuando exista riesgo para un recorrido. ## Mantén al día la documentación y los ejemplos de componentes Respeta el contrato de archivos, los campos de metadata, las reglas de encabezados y los componentes aprobados de pasos o avisos del sistema de documentación. Marca el contenido de edición restringida con el aviso estándar en lugar de inventar una insignia o redacción nueva. Mantén los ejemplos de componentes junto al componente e impórtalos mediante su punto de entrada público. Organiza los controles en los grupos estándar del repositorio. Incluye el estado predeterminado, el estado desactivado cuando esté disponible, el estado con icono cuando esté disponible, todas las variantes y los casos límite relevantes. Antes de crear o revisar una UI, carga el contexto de diseño de la superficie afectada. La guía de diseño compartida complementa las convenciones del código y sigue siendo la fuente de verdad para tokens, componentes, movimiento y calidad visual. ## Da a los flujos de CI solo los permisos que necesitan Concede a los tokens de automatización únicamente los permisos necesarios para cada workflow. Inicia los jobs Linux alojados con el paso de refuerzo del runner aprobado, de modo que el comportamiento de red y procesos quede limitado antes de ejecutar el código del proyecto. Mantén los locks de dependencias como fuente autorizada y ejecuta los comandos del workspace mediante el package manager seleccionado por el repositorio. Evita comandos puntuales de instalación o build que omitan el grafo de tareas, el entorno compartido o los metadatos de caché. Al cambiar un workflow, verifica los triggers de eventos, los permisos, la exposición de secrets, las claves de caché, los artefactos y la propagación de fallos. Un paso posterior en verde no debe ocultar el fallo de un requisito previo. ## Entrega un pull request con resultados de pruebas y capturas Antes de finalizar, elimina el código muerto y los imports sin usar, ejecuta el comando de lint autorizado y realiza el conjunto mínimo de pruebas que demuestre el cambio, además de cualquier flujo más amplio directamente afectado. Mantén los commits enfocados y coherentes con la convención de commits del repositorio. Una pull request debe exponer el problema, resumir la solución, enlazar el issue o la especificación que la rige e identificar las migraciones o los cambios de entorno. Adjunta pruebas visuales para el trabajo de UI y pega los resultados de los comandos relevantes de lint, test, build y migración. Los revisores deben poder determinar qué cambió, por qué corresponde a ese módulo, cómo se actualizaron los resultados generados y qué riesgos se verificaron, sin tener que reconstruir el trabajo a partir del diff.