Cambia un monorepo TypeScript full stack y prueba sus funciones de LLM por su significado

## Ejecuta solo los comandos y comprobaciones por paquete que usa CI Antes de ejecutar nada, identifica los comandos documentados del repositorio para desarrollo, compilación, análisis estático, formato, pruebas, pruebas de integración y evaluación. Usa el comando específico del paquete correspondiente al espacio de trabajo afectado, en lugar de sustituirlo por una herramienta que abarque toda la raíz. - Ejecuta una sola prueba mediante la ruta o el filtro de nombre admitidos. - Ejecuta las evaluaciones de IA desde la raíz del repositorio mediante el comando de evaluación específico del paquete de IA. - Usa la compilación o la comprobación de tipos de la aplicación que esté alineada con CI; no ejecutes una comprobación de tipos no admitida en la raíz que revele deuda técnica no relacionada del monorepositorio. - Instala las dependencias antes de las pruebas o las compilaciones solo si aún no están instaladas en el espacio de trabajo. - No inicies servidores de desarrollo ni compilaciones completas salvo que la tarea lo solicite expresamente. La validación debe ajustarse al paquete modificado y a las comprobaciones que usa CI. ## Prueba lo que hace el código, no cómo está escrito Revisa la guía de pruebas del repositorio antes de crear o modificar pruebas. Para corregir fallos del núcleo, aplica el ciclo rojo-verde-refactorización cuando resulte práctico: primero reproduce el fallo, después realiza la corrección mínima y, por último, mejora la estructura sin cambiar el comportamiento. Coloca las pruebas unitarias junto a los archivos fuente. Sitúa las pruebas de integración, de extremo a extremo y de evaluación de IA en sus árboles de pruebas designados. Usa la implementación real del registro salvo que la prueba se dirija específicamente a un límite del registrador. Prefiere pruebas que detecten una regresión de comportamiento significativa. Evita las aserciones de poco valor que solo reformulen detalles privados de implementación. Los cambios en los prompts o en el comportamiento del modelo deben contar con evaluaciones semánticas o pruebas de contratos estructurados, además de las pruebas de código habituales. ## Instala las dependencias en el espacio de trabajo que las usa Instala cada dependencia en el espacio de trabajo que la utiliza, no en la raíz del monorepositorio. Al añadir un nuevo paquete de espacio de trabajo, actualiza todos los manifiestos de compilación de contenedores, tanto de producción como locales, que copien los metadatos del paquete antes de instalar las dependencias. Mantén sincronizadas las variables de entorno entre el archivo de entorno de ejemplo, el módulo de validación en tiempo de ejecución y la configuración de compilación del monorepositorio. Aplica a las variables expuestas al código del navegador el prefijo de variables públicas establecido por el repositorio. Cuando el comportamiento de un framework dependa de la versión o no esté claro, lee antes de modificar el código la documentación incluida con la dependencia instalada. No confíes en la memoria ni en documentación correspondiente a otra versión instalada. ## Importa desde el archivo que define cada cosa e infiere los tipos de los esquemas Usa una comprobación estricta de null e infiere los tipos de TypeScript a partir de los esquemas de validación, en lugar de duplicar interfaces. No exportes un tipo que solo se use dentro del archivo donde se define. - Mantén todas las importaciones al principio del archivo; no añadas importaciones dinámicas a mitad del archivo. - Importa desde la fuente original en lugar de crear cadenas de reexportación o archivos agregadores. - Importa funciones auxiliares individuales en lugar de toda una biblioteca de utilidades. - Usa el alias configurado de la raíz del proyecto para las importaciones internas de la aplicación. - Coloca las funciones auxiliares al final del archivo. - Mantén un solo recurso por archivo de ruta de API. Una responsabilidad directa facilita comprender las dependencias, la eliminación de código no utilizado y el impacto de los cambios. ## Extrae funciones auxiliares solo cuando aclaren el código De forma predeterminada, escribe la lógica directamente y colócala junto a su lugar de uso. Las expresiones pequeñas duplicadas suelen ser más claras que una función auxiliar prematura. No extraigas una función que solo cambie el nombre de los parámetros y los reenvíe. Extrae una función auxiliar cuando dé nombre a un concepto de dominio significativo, facilite la lectura del flujo de control circundante o mantenga coherente un comportamiento sensible a la corrección entre varios flujos. Centraliza pronto la lógica duplicada sustancial cuando sus copias deban permanecer sincronizadas para evitar fallos. Evita las expresiones ternarias grandes o anidadas. Prefiere un flujo de control directo, una función auxiliar específica o una tabla de consulta. Añade comentarios para explicar por qué existe una decisión, no para describir lo que hace un código que ya se explica por sí mismo. Prefiere el cambio legible más sencillo. Conserva la compatibilidad con versiones anteriores solo cuando el requisito lo exija; de lo contrario, actualiza directamente los puntos de llamada coordinados en vez de añadir una ruta de migración sin uso. ## No dejes datos personales en niveles de registro amplios No repitas los campos de contexto del registrador que ya se hayan adjuntado en un nivel superior de la cadena de llamadas. Incluye los campos que permitan identificar a una persona, como remitente, destinatario o asunto del mensaje, únicamente en el nivel de seguimiento más restringido del repositorio. Una excepción documentada explícitamente puede permitir el identificador propio del usuario autenticado en niveles más amplios, pero no extiendas esa excepción a datos de terceros. Mantén las pruebas sobre el registrador real para que sigan ejercitando los filtros de privacidad, la propagación del contexto y el formato. Antes de añadir un registro, identifica su público, el plazo de conservación, la sensibilidad y si el contexto existente ya aporta el valor. ## Deriva el estado de la interfaz de los datos y usa los componentes compartidos No reflejes mediante un efecto las propiedades obtenidas ni los datos del servidor en el estado local. Prefiere valores derivados para las vistas de solo lectura y un estado de edición explícito para los borradores controlados por el usuario. Usa la biblioteca de componentes aprobada por el repositorio antes de crear un elemento básico personalizado. Representa el contenido asíncrono mediante el contenedor compartido de carga y errores para mantener coherentes los estados de carga, fallo y éxito. Coloca los componentes de página específicos de una ruta junto a su archivo de entrada, sin añadir directorios de componentes anidados. Sitúa los componentes compartidos entre páginas en el directorio de componentes compartidos de la aplicación. ## Haz los cambios de datos con acciones de servidor y esquemas de validación compartidos Elige el middleware de ruta según el nivel de acceso: tratamiento público de errores, acceso de usuario autenticado o acceso limitado a una cuenta. Exporta los tipos de respuesta derivándolos de la función de datos, en lugar de duplicar interfaces de respuesta. Para las mutaciones web, usa acciones del servidor a través de la capa de acciones seguras del repositorio. Reserva las rutas de API POST para integraciones que necesiten un contrato HTTP externo estable, como los clientes nativos. Define los esquemas de validación de las mutaciones en los módulos de validación designados e infiere de ellos los tipos de entrada. Usa la caché de cliente establecida para las lecturas e invalida la clave afectada después de cada mutación. Construye formularios con la biblioteca de formularios y el hook de acción aprobados, y canaliza los fallos mediante el formateador compartido de errores de acciones. Usa abstracciones de proveedor para la lógica normal de la aplicación. Comprueba un tipo concreto de proveedor únicamente en un verdadero límite de integración. Evita las transacciones dinámicas de base de datos basadas en callbacks cuando el repositorio las prohíba. ## Prueba las funciones de LLM por su significado, no con listas de palabras clave Corrige los modos generales de fallo del modelo, no la redacción de un único caso de evaluación. No añadas listas negras de palabras clave o frases a los prompts, las evaluaciones o las pruebas solo para detectar la redacción actual del modelo; las comprobaciones textuales son especialmente frágiles entre idiomas. Comprueba los resultados semánticos con un criterio evaluador o un contrato estructurado, por ejemplo, si el modelo evita aclaraciones innecesarias o afirmaciones de estado sin fundamento. Nunca condiciones la inyección de contexto ni el comportamiento de una herramienta a coincidencias improvisadas con el texto del usuario. Usa estados estructurados, metadatos o eventos explícitos. Haz que la descripción de cada herramienta sea autosuficiente e incluya su propósito, el significado de sus parámetros, pautas de selección, requisitos previos y restricciones de seguridad específicas. Conserva en el prompt del sistema solo las políticas transversales de identidad, confirmación, seguridad y formato; coloca las instrucciones de cada herramienta en su descripción. ## Revisa el diff e informa qué comprobaciones se ejecutaron Antes de informar de la finalización, examina las diferencias de los cambios y ejecuta el conjunto mínimo de comprobaciones alineadas con CI que demuestre el comportamiento afectado. Amplía el alcance a pruebas de integración o evaluación cuando el contrato cruce esos límites. Confirma que: - cada dependencia y variable de entorno pertenece al espacio de trabajo correcto; - las pruebas cubren el comportamiento y los archivos de prueba nuevos pueden descubrirse; - las importaciones, los tipos derivados de esquemas, las funciones auxiliares y las abstracciones siguen las convenciones del repositorio; - los registros no amplían la exposición de datos personales; - el estado de la interfaz, las mutaciones, la validación, la invalidación de caché y los estados de carga siguen los patrones establecidos; - el comportamiento de LLM se prueba por su semántica y no mediante una redacción frágil; - no se ha ejecutado sin autorización ninguna comprobación no admitida que abarque la raíz, ningún servidor de desarrollo ni ninguna compilación completa. Indica qué comprobaciones se ejecutaron y cuáles de mayor alcance quedaron fuera de forma deliberada.