Imita el comportamiento de otro framework web con una capa de compatibilidad

## Usa las pruebas y el código del framework de referencia como especificación Trata la compatibilidad como un problema de evidencias. Las pruebas y la implementación del framework de destino definen el comportamiento esperado con más fiabilidad que la intuición. Para cada función o corrección de errores: 1. Busca ampliamente en las suites originales de pruebas unitarias y de extremo a extremo, incluidos nombres relacionados, errores, entradas no válidas y casos límite. 2. Lee la implementación correspondiente para entender el orden, los valores predeterminados y el comportamiento ante fallos. 3. Busca incidencias o conversaciones de diseño anteriores cuando el código no aclare si un comportamiento es intencional. 4. Adapta los casos pertinentes antes de implementar el cambio y vincula cada adaptación con su prueba original. 5. Documenta las evidencias en la descripción del cambio. Utiliza un clon superficial local para buscar rápidamente en el código fuente y las pruebas. Recurre a la búsqueda remota de código solo cuando el clon no esté disponible o la cuestión requiera consultar una conversación actual. Si la capa de compatibilidad debe diferir intencionadamente por razones de seguridad, despliegue o plataforma, registra explícitamente esa decisión. Nunca permitas que una divergencia accidental se haga pasar por una función. ## Escribe primero una prueba que falle y corrige juntos todos los puntos de entrada Escribe primero una prueba específica que falle y después implementa el cambio mínimo que satisfaga el contrato verificado. - Ejecuta el archivo de pruebas del subsistema que hayas cambiado y las pruebas acopladas directamente. - Añade entradas de fixture para el comportamiento de integración; reserva los ejemplos para demostraciones dirigidas a usuarios. - Utiliza filtros por nombre de prueba durante las iteraciones. - Deja que CI ejecute la suite completa, a menos que el cambio afecte al enrutamiento compartido, la infraestructura de compilación, los módulos virtuales o los asistentes de prueba comunes. - Cuando cambie la infraestructura compartida, amplía la validación local solo a las superficies transversales afectadas. Asocia la validación con la responsabilidad: los shims necesitan pruebas de shims, el enrutamiento necesita pruebas de orden de rutas, el almacenamiento en caché necesita pruebas de caché y los cambios de compilación o despliegue necesitan pruebas de compilación. El tratamiento de solicitudes suele existir en puntos de entrada independientes para desarrollo, producción, renderizado en servidor y edge. Comprueba todas las implementaciones responsables del mismo comportamiento y corrige las diferencias de paridad en el mismo cambio, en vez de dejar duplicados conocidos pendientes. ## Pasa los datos de la solicitud entre entornos y mantén ligero el código generado Los entornos separados de compilación o renderizado pueden tener grafos y estados de módulos independientes. Nunca des por hecho que establecer el estado de una solicitud en un entorno cambia otro. - Transmite explícitamente el pathname, los parámetros, las cabeceras, las cookies y el resto del contexto de la solicitud a través de los límites entre entornos. - Inicializa el contexto inmediatamente antes del renderizado y límpialo después. - Mantén el estado con ámbito de solicitud y las pequeñas fachadas públicas separados de las implementaciones pesadas. - Verifica tanto el consumo en streaming como el momento de la limpieza. Los módulos de entrada generados solo deben contener imports específicos de la ruta, manifests y conexiones ligeras. Traslada la orquestación de solicitudes, la política de caché, el despacho de métodos, las redirecciones, el tratamiento de errores, la combinación de cabeceras y cualquier otro comportamiento comprobable a módulos tipados normales. Prueba de forma unitaria y directa los asistentes extraídos. Las pruebas del código generado deben verificar la delegación y las conexiones, en vez de comparar grandes cadenas de implementación. Mantén un límite claro de responsabilidad entre el plugin subyacente del bundler y la capa de compatibilidad. El plugin puede ser responsable de las transformaciones, la serialización, las compilaciones para varios entornos, el tratamiento de CSS y el arranque de la hidratación, mientras que la capa de compatibilidad se ocupa del enrutamiento, el ciclo de vida de las solicitudes, la composición del diseño, la navegación, el almacenamiento en caché y los shims de API. ## Normaliza las rutas de archivos y compila con el proceso completo de varios entornos Las rutas del sistema de archivos utilizadas como identificadores de módulo o imports generados necesitan una única política canónica de separadores para todos los sistemas operativos. - En el código fuente, utiliza una abstracción de rutas que preserve la semántica nativa y devuelva identificadores canónicos. - Normaliza solo los valores de origen externo, como los directorios de trabajo del proceso, los módulos resueltos, las rutas reales, la salida de glob y los identificadores comunicados por el bundler. - No normalices repetidamente valores que ya haya producido la capa canónica de rutas. - Mantén separada la limpieza de barras inversas en URL del tratamiento de rutas del sistema de archivos. - Documenta y somete al linter cualquier excepción real que necesite rutas nativas. Las pruebas deben construir las entradas con las API de rutas nativas para que Windows proporcione barras inversas reales. Normaliza solo las salidas esperadas según la forma canónica. Las pruebas multiplataforma construidas enteramente con barras diagonales no pueden detectar una regresión de normalización en Windows. Las compilaciones de producción deben utilizar el proceso completo del builder multientorno del plugin del framework. Una llamada genérica de compilación para un único entorno puede omitir silenciosamente las fases necesarias de server, renderer y client. Cuando la cadena de herramientas cambie de versión principal, da preferencia a las familias actuales de opciones de transformer, dependency optimizer y bundler. Trata los nombres de opciones heredados como objetivos de migración. Los módulos virtuales también requieren un tratamiento explícito de los identificadores con prefijo de raíz, los prefijos null ya resueltos y los imports absolutos cuando no existe una ubicación física del módulo. ## Mantén ligeras las solicitudes comunes y define el comportamiento de la caché Mantén los entornos de ejecución específicos de cada función fuera de la ruta común de las solicitudes. - Condiciona el comportamiento opcional mediante metadatos baratos de la solicitud o la ruta antes de importarlo dinámicamente. - Utiliza imports de solo tipos cuando no sea necesario el código en tiempo de ejecución. - Filtra los hooks del bundler antes de que se ejecuten los handlers de JavaScript, excluyendo dependencias, entornos de ejecución generados, prebundles y objetivos sintácticos imposibles. - Mantén los módulos ligeros de estado y registro separados de las implementaciones de caché, navegación o renderizado. - Reutiliza las claves de caché calculadas y los valores derivados de la solicitud. - Eleva las expresiones y tablas inmutables. - Traslada el análisis determinista y la selección de recursos al momento de la compilación cuando sea posible. No añadas caché hasta que sean explícitas su responsabilidad, su invalidación y la paridad entre entornos de ejecución. Un grafo de módulos más pequeño no supone una mejora si provoca código obsoleto, condiciones diferentes entre entornos o bundles de plataforma dañados. Mantén simples los handlers de almacenamiento y coloca por encima de ellos la política de regeneración incremental. Define por separado el comportamiento stale-while-revalidate, la regeneración single-flight, los metadatos de revalidación y la invalidación por etiquetas. Las entradas caducadas pueden devolverse obsoletas mientras se ejecuta la regeneración; las entradas invalidadas explícitamente deben eliminarse. Haz declarativa la selección del backend, conserva un valor predeterminado seguro y registra los adaptadores opcionales antes de utilizarlos por primera vez. ## Procesa las solicitudes en el mismo orden que el framework de referencia Modela el ciclo de vida de las solicitudes del framework de destino como un contrato ordenado: 1. Las cabeceras de configuración estática se evalúan respecto a la solicitud original. 2. Las redirecciones estáticas se evalúan respecto a la solicitud original. 3. El middleware se ejecuta y puede reescribir, redirigir o modificar cabeceras. 4. Las reescrituras anteriores al sistema de archivos se evalúan respecto al estado posterior al middleware. 5. Se resuelven las rutas estáticas y del sistema de archivos. 6. Se ejecutan las reescrituras posteriores al sistema de archivos. 7. Se resuelven las rutas dinámicas. 8. Se ejecutan las reescrituras de respaldo. No muevas una etapa solo porque la respuesta final parezca equivalente. Las coincidencias condicionales pueden cambiar cuando el middleware modifica la solicitud. Registra las diferencias de paridad conocidas en vez de ocultarlas. Preserva distinciones intencionales, como qué recursos estáticos omiten el middleware y qué archivos públicos pasan por él. Para API en evolución, admite patrones de acceso antiguos y nuevos solo cuando el contrato de compatibilidad exija ambos. Por ejemplo, una promesa ampliada con campos resueltos puede admitir tanto el acceso a parámetros con await como el acceso directo. Las bibliotecas de terceros que utilicen imports de API públicas pueden funcionar mediante alias o normalización de extensiones. Las bibliotecas que dependan de plugins de compilación o API internas requieren una integración explícita; instalarlas e importarlas no es suficiente. ## No eludas el lockfile y fusiona solo con pull requests que pasan las comprobaciones Nunca eludas un lockfile congelado durante una instalación desatendida. Si la resolución de dependencias requiere realmente cambiar el lockfile, detente y pide al usuario que realice o autorice esa operación. Las versiones exactas y los hashes de integridad forman una frontera de la cadena de suministro. Nunca envíes cambios directamente a la rama predeterminada protegida, eludas la protección de ramas ni fuerces una fusión administrativa. Sigue esta secuencia: 1. Crea una rama de función con un alcance específico. 2. Realiza el cambio coherente más pequeño y ejecuta comprobaciones específicas. 3. Haz commit según la convención de mensajes exigida por el repositorio. 4. Envía la rama y abre una pull request. 5. Espera a que se superen todas las comprobaciones obligatorias de formato, tipos, pruebas unitarias y pruebas de extremo a extremo. 6. Corrige los fallos en vez de eludirlos. 7. Fusiona mediante el método aprobado y elimina la rama. Permite que la automatización de publicaciones derive los metadatos del registro de cambios de los commits convencionales. Utiliza mecanismos documentados de anulación solo para una reclasificación retroactiva deliberada; no edites manualmente los artefactos de publicación generados. En refactorizaciones grandes, utiliza pequeños cambios apilados, cada uno de los cuales extraiga un único límite cohesionado, añada pruebas específicas para asistentes y actualice las verificaciones de delegación. La CI para contribuciones no fiables debe ejecutarse sin secretos y con permisos de solo lectura. Los flujos de vista previa que utilicen secretos deben omitir los forks, salvo que un responsable autorizado los active explícitamente mediante un comando protegido por verificación de identidad. Cada ejemplo desplegado necesita estar registrado en la matriz de compilación y disponer de una prueba de humo que verifique la ruta, el estado y el contenido esperados. La publicación o el despliegue solo se completan después de superar las comprobaciones obligatorias y las evidencias posteriores al despliegue.