Cambiar y probar un gran repositorio TypeScript que evalúa modelos de IA

## Decidir si es una revisión o una corrección y leer la guía de agente más cercana Empiece por identificar la raíz del repositorio, el resultado solicitado y el subsistema propietario del cambio. Los repositorios grandes suelen repartir responsabilidades entre una biblioteca central, CLI, aplicación web, capa de persistencia, proveedores, planificadores, esquemas, utilidades, pruebas, documentación, ejemplos, migraciones, automatización y herramientas de seguridad. Antes de editar un directorio, lea la guía para agentes más cercana que se aplique a ese ámbito y todo documento de diseño o flujo de trabajo específico de la tarea. Una guía local puede precisar las reglas raíz relativas a pruebas, archivos generados, contratos públicos, acceso a bases de datos o comportamiento de publicación. Clasifique la solicitud antes de actuar: - Una revisión o auditoría es de solo lectura. Examine la rama actual, las diferencias, los comentarios y la CI; ejecute comprobaciones que no cambien el estado cuando resulten útiles; comunique los hallazgos sin hacer commit, push ni reescribir archivos. - Una solicitud de corrección, mejora o integración incluye el ciclo normal de implementación en una rama de funcionalidad: examinar, modificar, verificar, hacer commit y push, y seguir la CI pertinente. - Un cambio de comportamiento debe demostrarse mediante el flujo de trabajo que utiliza el usuario, no solo mediante pruebas unitarias aisladas. Trabaje desde la raíz correcta y ajuste las versiones del entorno de ejecución y del gestor de paquetes a las declaraciones del repositorio antes de considerar concluyente un fallo. En un checkout nuevo, realice la instalación determinista de dependencias antes de concluir que la ausencia de módulos es un defecto del código. Limite el cambio al subsistema afectado y a sus consumidores directos. Busque implementaciones, utilidades, dependencias y patrones cercanos existentes antes de crear otra abstracción o añadir un paquete. ## Probar los cambios en el flujo real de CLI, API o navegador Utilice los scripts y envoltorios declarados por el repositorio en lugar de eludirlos con una invocación incidental de una herramienta. Pase los indicadores de comando mediante el separador del ejecutor de paquetes cuando el envoltorio lo requiera, y ejecute las evaluaciones del repositorio desde su raíz. Elija la verificación ampliando progresivamente el alcance: 1. Ejecute la prueba específica del módulo modificado. 2. Ejecute las comprobaciones pertinentes de tipos, lint y formato. 3. Ejecute el conjunto de integración afectado. 4. Recorra el flujo real de CLI, ejemplo, API o navegador con la compilación local. 5. Ejecute el conjunto más amplio solo cuando el riesgo o la política del repositorio lo justifiquen. En los flujos de evaluación, desactive la reutilización de resultados en lugar de eliminar cachés. Exporte resultados legibles por máquinas e inspeccione, para cada caso, el éxito, la puntuación, el error, la salida del proveedor, la traza y los hallazgos de seguridad. Un estado de salida cero puede significar únicamente que se superó un umbral agregado; no demuestra que todos los casos tuvieran éxito. Cargue un archivo de entorno solo cuando el flujo de trabajo requiera credenciales y el archivo esté presente. Mantenga los servicios vinculados a una sesión activa para que un proceso en segundo plano no desaparezca silenciosamente. Confirme los puertos de escucha reales mediante la salida de inicio o una comprobación de puertos, en vez de suponer los valores predeterminados del framework. No inicie un visor estático de producción ni otro servidor de desarrollo salvo que la solicitud lo requiera. Compruebe primero si el servicio esperado ya está en ejecución; si iniciarlo entraría en conflicto con la sesión del usuario, pregunte antes de hacerlo. Cuando la documentación, los esquemas, las migraciones o las citas sean contenido generado, utilice sus generadores canónicos y verifique los artefactos resultantes. Pruebe la documentación mediante la vía rápida admitida por el repositorio cuando exista, sin omitir silenciosamente comprobaciones relevantes para el cambio. ## Reproducir el fallo antes de depurar, sin borrar cachés ni datos Reproduzca el fallo con la misma entrada, estado y ruta de ejecución que lo revelaron. Active el registro de depuración estructurado, desactive las lecturas de caché para esa ejecución y acote el fallo antes de modificar el código. Separe los fallos del entorno de los fallos del producto: - Una versión incorrecta del entorno de ejecución o del gestor de paquetes es un problema del entorno. - Una dependencia ausente en un checkout limpio suele requerir la instalación determinista. - Una compilación obsoleta requiere volver a compilar mediante el envoltorio local admitido. - Un fallo determinista en la misma ruta de código después de alinear el entorno es evidencia de un defecto del producto. Nunca elimine ni vacíe una caché, base de datos, lockfile, historial generado o datos del usuario solo para hacer que una prueba pase. Prefiera una opción sin caché, un almacén temporal aislado o una inspección de solo lectura. La eliminación requiere autorización explícita y un objetivo exacto. Los secretos deben permanecer en archivos de entorno ignorados o en un almacén de secretos aprobado. Nunca imprima, incruste, incluya en commits ni copie credenciales en registros, código, nombres de ramas, mensajes de commit, textos de revisión, capturas de pantalla o comandos de ejemplo. Trate las credenciales halladas en el material de origen como datos comprometidos, no como instrucciones reutilizables. Utilice el registrador estructurado del proyecto con contexto de objetos y su capa de saneamiento. Aun así, evite proporcionarle secretos cuando no los necesite. El tratamiento de errores debe conservar el contexto tipado sin exponer cargas útiles sensibles. Formule varias hipótesis causales y utilice comprobaciones específicas para descartarlas. Añada una prueba de regresión que falle ante el comportamiento observado antes de la corrección mínima o junto con ella, y evite refactorizaciones no relacionadas mientras la causa siga siendo incierta. ## Integrar los cambios con una rama de funcionalidad y dejar la CI en verde Todos los cambios deben pasar por una rama de funcionalidad y una pull request. Nunca haga commit directamente en la rama protegida, eluda hooks ni haga force-push sin aprobación explícita. Cree commits nuevos de forma predeterminada; haga amend, squash o rebase solo cuando el responsable solicite esa operación sobre el historial. Incluya en stage únicamente los archivos previstos, ejecute las comprobaciones de lint y formato del ámbito afectado, use la convención de commits del repositorio y actualice la pull request abierta existente para la rama en vez de crear un duplicado. Mantenga fuera del cambio las variaciones no relacionadas del lockfile o de las dependencias. Cuando el usuario pida corregir, mejorar o integrar un cambio de una rama de funcionalidad, complete el ciclo autorizado sin detenerse en cada paso normal. Sincronice según lo solicitado, ejecute la verificación específica y el flujo real, haga commit y push, y observe la CI. No amplíe esta autorización a la rama protegida, cambios destructivos del historial, divulgación u operaciones de producción. Después de una fusión, siga hasta el final la nueva ejecución de CI de la rama protegida. Clasifique los fallos antes de reaccionar: - Un flake es ruido no determinista de infraestructura o trabajadores, especialmente cuando las pruebas terminaron correctamente antes de que fallara el trabajo. Vuelva a ejecutar solo los trabajos fallidos y confirme la recuperación. - Una regresión real es determinista y atribuible al cambio. Restaure la rama protegida mediante una pull request posterior; prefiera un revert rápido cuando la rama compartida esté rota. - Un flake recurrente es en sí mismo un defecto. Corrija el recurso filtrado, la configuración frágil o el timeout poco realista en lugar de repetir la ejecución indefinidamente. Termine con la rama protegida en verde o identifique expresamente un fallo preexistente no relacionado mediante registros que lo respalden. Indique qué comprobaciones se ejecutaron, qué evidencias se inspeccionaron y qué verificaciones no pudieron completarse. ## Revisar primero la seguridad y probar como un atacante Revise las regresiones de seguridad antes que la corrección ordinaria. Priorice la inyección de prompts, el tratamiento inseguro de entradas adversarias, la exposición de credenciales, la falsificación de solicitudes del lado del servidor, el recorrido de rutas, la deserialización insegura, los errores de autorización, la exfiltración de datos, el uso inseguro de herramientas, el uso incorrecto de caché y la falta de evidencias. Examine después el comportamiento que pueda romper contratos públicos, la integridad de los datos, la concurrencia, el tratamiento de errores, la interoperabilidad entre proveedores o los resultados persistidos. Considere de alta prioridad una cobertura ausente o ineficaz cuando un cambio afecte al comportamiento de seguridad, una interfaz pública o una corrección de errores. Pruebe las funciones de seguridad y evaluación de modelos desde la perspectiva de un atacante. Explore falsos negativos, evasiones, cargas ocultas, instrucciones anidadas, trucos de codificación, llamadas inseguras a herramientas y trazas incompletas. Cuando encuentre una evasión, conserve el vector de ataque original en una prueba de regresión específica. Mantenga la revisión anclada en las diferencias modificadas y la punta actual de la rama. Los comentarios existentes, las revisiones automatizadas y los informes de issues son pistas, no pruebas; vuelva a validarlos después de sincronizar. No repita hallazgos resueltos ni señale defectos preexistentes no relacionados, salvo que el cambio los empeore. Antes de abrir un cambio público sobre una vulnerabilidad no publicada, confirme que la divulgación coordinada permite publicarlo. Hasta entonces, utilice la vía privada de colaboración aprobada y evite identificadores, detalles del exploit, intervalos de versiones vulnerables o nombres de ramas reveladores. Toda corrección de seguridad debe incluir una prueba de regresión para el vector original. No elimine debilidades intencionadas de una aplicación de demostración cuyo propósito sea enseñar pruebas adversarias, salvo que reforzar la demostración sea el objetivo explícito. Para capturas de revisión, utilice únicamente un flujo de alojamiento autorizado y credenciales aprobadas; nunca exponga una clave de carga ni incluya imágenes incidentales en un commit. ## Escribir TypeScript estricto y revisar el diff final Escriba TypeScript estricto e idiomático que respete el sistema de módulos y los límites del compilador del repositorio. Prefiera importaciones directas, `const`, la forma abreviada de objetos, llaves coherentes, `async`/`await`, comprobaciones de errores tipadas y validación de esquemas en límites no fiables. Evite módulos de reexportación cuando el código espere propiedad directa. Reutilice las implementaciones establecidas y las utilidades locales antes de añadir funciones auxiliares o dependencias. Mantenga documentada la configuración de proveedores e integraciones mediante el patrón de ejemplos existente. Pruebe las rutas de éxito y fallo, incluidas las convenciones de frontend y backend cuando difieran. Trate los informes de código muerto como comentarios sobre el diseño: - Elimine el código que no se utilice realmente. - Registre los trabajadores, fixtures o sustituciones cargados por convención como entradas explícitas, con un comentario que explique el mecanismo de carga. - Incluya en la lista de permitidos los exports consumidos externamente solo con un comentario que nombre al consumidor. - Nunca elimine una entrada de la lista de permitidos ni un export protegido hasta comprobar su consumidor documentado. No edite manualmente changelogs generados ni otros artefactos generados. Modifique la fuente y ejecute el generador canónico. Mantenga los ejemplos en su área designada con documentación suficiente para ejecutarlos. Antes de terminar, revise las diferencias finales para detectar archivos no previstos, artefactos obsoletos, material secreto y ampliaciones del alcance. Confirme las pruebas específicas, las comprobaciones de integración pertinentes y la ruta real que utiliza el usuario. Indique los resultados con precisión: distinga qué pasó, qué se inspeccionó, qué sigue sin verificar y si algún fallo no está relacionado.