Modifica un proxy inverso en Rust sin romper el bucle de eventos ni la seguridad

## Respeta las capas de bibliotecas del proxy y la dirección de dependencias Trata el repositorio como un sistema por capas con una dirección de dependencias explícita: - Una biblioteca del plano de control se encarga del análisis de configuración, los esquemas de comandos, el estado compartido, las utilidades de registro y los canales entre procesos. - Una biblioteca de protocolo y ejecución se encarga del bucle de eventos de un solo hilo, el enrutamiento, los sockets, los búferes, las métricas, TLS, HTTP y el manejo del protocolo de proxy. - Un crate binario se encarga del supervisor, los procesos de trabajo, la CLI, la carga de configuración, la reconfiguración en caliente, las actualizaciones y el servidor de comandos. - Los crates de pruebas de integración y simulación determinista dependen de las bibliotecas de ejecución, pero no deben filtrar sus dependencias asíncronas o exclusivas de pruebas al código de producción. - Los objetivos de fuzzing pueden residir fuera del espacio de trabajo principal cuando sus requisitos de cadena de herramientas sean distintos. Conserva la dirección de las dependencias desde el código de ejecución hacia el plano de control. Mantén cada proceso de trabajo en un solo hilo, evita los mutex compartidos en el bucle de eventos y mantén las bibliotecas de producción libres de entornos de ejecución asíncronos salvo que la arquitectura se rediseñe deliberadamente. ## Compila con la toolchain fijada y prueba las combinaciones de funcionalidades Antes de modificar el código, identifica la cadena de herramientas de Rust fijada y los generadores de código necesarios. Si la generación de esquemas es un requisito previo estricto, instala o verifica el generador antes de interpretar los fallos de compilación. Usa dependencias bloqueadas para las compilaciones y pruebas normales. Ejecuta el formateador con la cadena de herramientas exigida por la configuración del repositorio, ejecuta el análisis estático denegando las advertencias y prueba todo el espacio de trabajo antes de las tareas orientadas a la publicación. Usa conjuntos de pruebas específicos durante la iteración y después vuelve a las compuertas del espacio de trabajo afectado. Trata los indicadores de funcionalidad como celdas de compatibilidad explícitas: - Mantén documentadas las opciones predeterminadas de asignador de memoria y criptografía. - Prueba por separado cada proveedor de criptografía compatible, incluidos los modos orientados al cumplimiento normativo. - Nunca habilites los mecanismos de inyección para pruebas en compilaciones de producción. - Mantén como opciones voluntarias el registro de depuración o seguimiento, la tolerancia del analizador, SIMD, la E/S sin copia y las funciones de telemetría cuando cambien el comportamiento, el tamaño o la observabilidad. No declares que un cambio está limpio porque haya pasado una sola compilación predeterminada. Confirma las combinaciones de funcionalidades afectadas directamente por el cambio. ## Gestiona errores y registros sin panics y no edites a mano el código generado Usa errores estructurados en las bibliotecas y añade contexto amplio solo en los límites de los ejecutables. Una entrada controlada por la red debe convertirse en un error de protocolo, una acción de conexión, una métrica y un registro contextual; nunca debe activar `unwrap`, `expect`, `panic` ni una rama inalcanzable en la ruta de publicación. Sigue las convenciones de propiedad del código cercano. Prefiere conversiones que revelen la intención al convertir cadenas o bytes prestados en valores con propiedad, y usa la clonación ordinaria cuando el tipo ya sea un valor clonable con propiedad. Los módulos de protocolo deben usar sus macros establecidas de registro contextual y etiquetas de búsqueda estables. Conserva la envolvente canónica de sesión, solicitud y backend para que los operadores puedan correlacionar los fallos. Usa los niveles de depuración o seguimiento para los cierres inactivos esperados y el estado ruidoso; reserva los niveles de advertencia y error para fallos reales del protocolo o rupturas de invariantes. Mantén las métricas públicas en la capa central de métricas y actualiza la referencia de configuración dirigida a los usuarios cuando añadas una o cambies su nombre. Trata el desbordamiento inferior de un indicador como un error de corrección. Nunca edites manualmente las vinculaciones de protocolo generadas. Edita el esquema de origen y vuelve a generarlas mediante la compilación. El código inseguro nuevo en una ruta crítica requiere una explicación cercana de la invariante y una prueba específica. ## Evita que las escrituras de socket y los búferes bloqueen el bucle de eventos Para la E/S activada por flancos, no basta con poner en cola bytes desde una ruta de lectura: señala explícitamente que hay una escritura pendiente. Omitir esa señal crea sesiones que se bloquean solo en determinados límites de trama o de búfer. Mantén estructuralmente simétricas las implementaciones de escritura escalar y vectorizada en sockets, incluidos el comportamiento de reintento y el de escritura parcial. En frontends cifrados, evita un cierre dúplex completo que pueda emitir un restablecimiento y truncar los bytes ya encolados; cierra el lado de escritura y deja que el cierre del par siga la ruta de lectura normal. Mantén un búfer suficientemente grande para la trama máxima del protocolo más su cabecera. Valida esa configuración al iniciar, en lugar de permitir que un búfer pequeño bloquee el código de entramado. Mantén separado el estado de conexión a nivel de cable del estado de flujo que posee el búfer, y relaciónalos mediante identificadores estables con reglas verificadas de ciclo de vida. La negociación del protocolo del frontend y las indicaciones de capacidad del backend son conceptos distintos; no uses uno como compuerta accidental del otro. Los controles contra inundaciones deben cubrir tormentas de restablecimientos, cadenas de continuación, tramas de control repetidas y abuso de prioridades. La reconfiguración en caliente multiproceso debe validar los comandos en el supervisor antes de distribuirlos a los procesos de trabajo de un solo hilo. ## Prueba por capas con fuzzing y simulaciones reproducibles Usa cinco capas de pruebas complementarias: pruebas unitarias junto a los módulos, pruebas de integración a nivel de proceso, objetivos de fuzzing, simulación determinista para máquinas de estados sin E/S y protecciones contra regresiones de contratos estructurales como la disposición de los registros. Para analizadores y funciones no triviales de máquinas de estados, codifica precondiciones, poscondiciones y aserciones positivas y negativas en las compilaciones de depuración. Los puntos de entrada públicos de las máquinas de estados deben terminar con una comprobación completa de invariantes. Las aserciones describen imposibilidades internas; una entrada de red adversaria debe seguir devolviendo un resultado de protocolo seguro. Ejecuta las simulaciones deterministas con una fuente aleatoria que use una semilla, tiempo virtual, cargas adversarias e inyección de fallos. Registra las semillas para poder reproducir cada fallo. Limita los indicadores y dependencias de ejecución exclusivos de simulación al crate de simulación. Las pruebas de integración deben asignar los puertos dinámicamente, leer respuestas TCP completas en lugar de un solo segmento y usar plazos explícitos o condiciones de reintento hasta el cumplimiento en lugar de pausas arbitrarias. Una prueba ignorada necesita una dependencia concreta del entorno o una razón registrada; nunca uses la omisión para ocultar una regresión. Para cambios de actualización, análisis, compresión o entramado, ejecuta el conjunto específico de pruebas de integración y los objetivos de fuzzing correspondientes, además de las pruebas generales. ## Cambia TLS, parsers y framing con cuidado y con pruebas de regresión Haz cambios conservadores y respaldados por pruebas en la configuración de TLS, la negociación del protocolo, la vinculación de nombres, la carga de certificados, la normalización del analizador y las cabeceras, el control de flujo, el entramado de comandos, el paso de descriptores, las métricas y los registros. Rechaza el entramado ambiguo de mensajes en lugar de reenviar una representación que difiera del entramado aplicado realmente. Conserva el orden de las pseudocabeceras, la conciliación de la longitud del contenido, las defensas contra el contrabando de solicitudes y la semántica correcta de restablecimiento o cierre ordenado. En los canales de comandos, valida los prefijos de longitud, los mensajes parciales, la transferencia de descriptores de archivo, la reproducción del estado y los límites de los búferes. Para el manejo del protocolo de proxy, cubre las cabeceras parciales y sobredimensionadas, además del tráfico de comprobación de estado. No expongas secretos ni valores sensibles mediante registros o métricas. Mantén correctos los contadores e indicadores en todas las rutas de error y apagado. Cuando modifiques el bucle de eventos o el código de seguridad, añade cobertura de regresión específica para la invariante exacta y después ejecuta las pruebas de protocolo adyacentes. No mezcles refactorizaciones sin relación en el mismo cambio. ## Indica en los pull requests el impacto en protocolo y seguridad Lee la nota canónica sobre ciclo de vida o arquitectura antes de modificar un subsistema de protocolo complejo. Trata los documentos antiguos como indicios y contrasta sus referencias a archivos con el código actual. Usa ramas de alcance limitado y mensajes de commit convencionales que identifiquen el subsistema afectado. Sigue la política de firmas y aprobación del repositorio. Cuando una tarea autorice la publicación, envía la rama con los commits e informa de la ejecución de CI resultante; de lo contrario, detente en el límite autorizado localmente. Basa los cambios en la rama predeterminada actual, salvo que se indique explícitamente una rama de integración activa. Las solicitudes de integración deben describir el impacto en el protocolo o la seguridad, los comandos ejecutados, las pruebas añadidas y los cambios de documentación. Respeta las compuertas de propiedad y licencia de colaboradores. Actualiza los registros de cambios y las referencias de configuración cuando cambie un comportamiento visible para usuarios u operadores, incluidas las claves de configuración, las métricas, los indicadores de línea de comandos y los requisitos de actualización. Antes de la entrega, revisa el diff para detectar archivos generados, filtraciones accidentales de funcionalidades, pruebas ausentes, referencias obsoletas y ediciones sin relación. ## Publica solo con aprobación y prueba antes las actualizaciones en caliente Trata el despliegue como un paso autorizado por separado. Primero construye el artefacto de publicación con dependencias bloqueadas o congeladas; después valida la configuración y ejecuta las compuertas de preparación afectadas en un entorno equivalente al de preproducción. Los paquetes del contenedor y del sistema operativo deben instalar los mismos requisitos previos de compilación usados localmente, incluidos los generadores de esquemas y las bibliotecas de la plataforma. Fija la cadena de herramientas y mantén las dependencias exclusivas de pruebas fuera de los artefactos de producción. Para las regresiones del bucle de eventos o del ciclo de vida de los procesos de trabajo, reproduce el problema con un solo proceso de trabajo, el reinicio automático deshabilitado y las trazas de llamadas habilitadas. Así, el primer fallo permanece visible en vez de quedar oculto por la recuperación del supervisor. Las actualizaciones en caliente deben conservar las invariantes de transferencia de escuchas y sesiones. Prueba explícitamente las rutas de actualización antes de la publicación. No consideres un reinicio ordinario correcto como prueba de que la transferencia de descriptores o la reproducción funcionan. No despliegues en producción, alteres credenciales ni realices una recuperación destructiva sin autorización explícita y una ruta de reversión. Informa de lo que se compiló, las compuertas que se superaron, lo que sigue sin verificar y el límite exacto donde se detuvo el trabajo.