Cambia y revisa una pasarela de integración multiprotocolo sin romper los controles de acceso

## Busca las instrucciones más cercanas y, si las fuentes chocan, confía en el código en ejecución Comienza con las directrices generales del repositorio y localiza después las instrucciones específicas del dominio más cercanas a los archivos que se van a cambiar. Las pruebas, los plugins, los gráficos de despliegue, la documentación, los servidores de protocolos y los entornos de ejecución sensibles al rendimiento pueden tener flujos distintos. No apliques las reglas de un área a otra sin pruebas que lo justifiquen. Distingue las directrices para quienes contribuyen código de las instrucciones de ejecución para usuarios finales. El material escrito para un modelo o cliente que utiliza el sistema desplegado no rige automáticamente a los agentes que modifican el código fuente. Traza el mapa del sistema antes de editar: - Puntos de entrada de la aplicación y configuración del entorno. - Esquemas de validación, modelos de persistencia y migraciones. - Servicios de negocio, rutas, middleware y transportes de protocolos. - Autenticación, autorización, plugins y límites de federación. - Pruebas, documentación, recursos de despliegue e interfaces administrativas. Cuando las fuentes discrepen, da prioridad al código activo en ejecución y a la configuración canónica; después, a los objetivos de compilación y dependencias compatibles; luego, a los ejemplos de entorno; y, por último, a la documentación o los comentarios. Confirma la implementación actual antes de repetir recuentos numéricos o límites operativos que puedan quedar obsoletos. Inspecciona primero las rutas de código fuente activas. Ignora los espacios de trabajo temporales, registros, resultados de cobertura, artefactos generados y carpetas de tareas aplazadas, salvo que la solicitud los incluya expresamente. ## Pasa las comprobaciones del proyecto y la detección de secretos tras cada cambio Utiliza el ejecutor de tareas admitido por el repositorio y la cadena de herramientas con versiones fijadas, en lugar de invocar las herramientas subyacentes con opciones improvisadas. Valida el entorno de desarrollo frente al ejemplo canónico, ejecuta los pasos requeridos de preparación o generación de interfaces y elige el servidor local o modo de prueba que corresponda a la tarea. Después de cambiar el código: 1. Ejecuta las comprobaciones de formato, lint, tipos, seguridad y documentación que cubran directamente el lenguaje y los archivos modificados. 2. Usa comprobaciones focalizadas durante la iteración y, antes de proponer la finalización, ejecuta la puerta de calidad agregada exigida por el repositorio. 3. Para un lenguaje de sistemas secundario o un entorno de alto rendimiento, ejecuta su comprobación de formato, el linter tratando las advertencias como errores y las pruebas del crate o paquete. 4. Vuelve a generar los recursos administrativos o de cliente cuando cambien sus fuentes. 5. Incluye pruebas de comportamiento para cada cambio visible desde el exterior. Utiliza la detección de secretos como puerta de control. Ante un falso positivo verificado, emplea la supresión en línea autorizada por el proyecto solo cuando no pueda alterar el comportamiento de una prueba o ejemplo. En los demás casos, vuelve a generar y audita la línea base aprobada. Nunca suprimas una credencial real ni coloques secretos en la configuración confirmada en el repositorio. Da preferencia a ampliar el lenguaje, la compilación y la automatización existentes. Añade una dependencia o una cadena de herramientas nueva únicamente cuando exista un requisito concreto que el proyecto no pueda satisfacer de forma segura con sus medios actuales. ## Comprueba por separado qué puede ver y qué puede hacer cada identidad, y deniega las rutas sin regla Mantén dos capas de seguridad independientes en cada ruta protegida: - El filtrado de alcance determina qué recursos puede ver una identidad. - La autorización basada en roles determina qué acciones puede realizar esa identidad. Superar una capa nunca sustituye a la otra. Considera el alcance público de la plataforma como visibilidad dentro de ella, no como permiso de acceso anónimo desde Internet. Normaliza cada clase de token mediante una única función de política canónica. En los tokens autocontenidos o heredados de API, la ausencia de alcance de equipo o un alcance vacío debe cerrarse de forma segura, limitando la visibilidad a lo público; el bypass administrativo exige tanto un estado explícito de bypass como la condición de administrador verificada. Para las identidades respaldadas por sesión, la pertenencia y el estado de administrador persistidos en el servidor son la autoridad, mientras que las declaraciones del token solo pueden reducir el acceso. Una intersección vacía debe cerrarse de forma segura. Las identidades aprovisionadas mediante un inicio de sesión externo de confianza también deben usar el estado de autorización local persistido, en vez de confiar en declaraciones externas de privilegios. Aplica estas invariantes: - Autentica antes de establecer una sesión de transporte o reenviar un mensaje y, después, aplica la autorización de la acción antes de procesarla. - Deniega de forma predeterminada las rutas protegidas que no tengan un mapeo de autorización explícito. - Deriva la propiedad, el equipo y la identidad de sesión del estado autenticado del servidor; nunca confíes en campos de propiedad proporcionados por el cliente. - Nunca aceptes credenciales entrantes del cliente mediante parámetros de consulta de URL. - Mantén deshabilitados de forma predeterminada los transportes de alto riesgo y el enrutamiento entre dominios sin restricciones. - Exige una lista explícita de dominios permitidos para el tráfico entre pasarelas; una lista vacía bloquea todos los destinos. - Exige que las pasarelas que se comunican confíen en el mismo emisor y propaga solo las credenciales necesarias para la autorización remota. En un intercambio delegado de tokens, nunca reenvíes al servicio posterior el token entrante del usuario. Intercámbialo mediante un servidor de autorización de confianza y reenvía únicamente el token obtenido. Trata el destino configurado para el intercambio como un límite de SSRF y salida: valídalo al guardar la configuración, restringe sus cambios a identidades privilegiadas, registra un identificador de correlación y nunca anotes en registros los tokens entrantes sin procesar ni los tokens intercambiados. Los cambios sensibles para la seguridad deben incluir pruebas de regresión para acceso no autenticado, alcance incorrecto, permisos insuficientes, funciones deshabilitadas, destinos no permitidos y otras rutas de denegación. ## Separa las escrituras de trazas y auditoría de la transacción principal Comprende el límite transaccional previsto antes de modificar el código de persistencia. Los datos de la solicitud, los registros de observabilidad y los registros de auditoría pueden usar deliberadamente sesiones y garantías de atomicidad diferentes. Las escrituras de observabilidad de mejor esfuerzo pueden utilizar sesiones independientes de corta duración que confirman de inmediato. Esto conserva trazas y eventos cuando falla la solicitud principal, pero también implica que la telemetría no es atómica con la solicitud y puede mostrar estados parciales o en curso. Las operaciones de consulta deben seguir usando sesiones con el alcance de la solicitud para aplicar los filtros de visibilidad y autorización. El registro de auditoría también puede ser propietario de su sesión y aislar sus fallos. No pases la sesión ya confirmada de la solicitud a un escritor de auditoría independiente solo por comodidad; una segunda confirmación o reversión puede dejar inactiva la transacción compartida y revelar un error después de que el recurso principal ya se haya persistido. Si un registro de auditoría debe ser atómico con la escritura principal, trátalo como un cambio de diseño explícito que requiere revisión, nuevas semánticas de fallo y pruebas. El seguimiento independiente puede crear varias sesiones de base de datos por solicitud. Mide la concurrencia, vigila las señales de agotamiento del pool y dimensiona este para la base de datos y la carga reales, en vez de copiar afirmaciones fijas de capacidad. No clasifiques como defecto aislado una estrategia deliberada de persistencia síncrona dentro de manejadores asíncronos sin pruebas que lo sustenten. Convertir puntos de llamada individuales puede crear semánticas mezcladas; propón en su lugar una migración coordinada del controlador y las transacciones. ## Consulta el head actual antes de añadir una migración de base de datos Antes de crear una migración, consulta el head actual. El padre de la nueva revisión debe hacer referencia a ese head verificado; nunca lo adivines ni copies un identificador de padre desde un archivo antiguo. Después de crearla, comprueba que el historial siga teniendo exactamente un único head previsto. Escribe pasos de migración idempotentes cuando las instalaciones puedan diferir. Inspecciona el esquema actual antes de modificarlo, omite de forma segura una operación cuando falte una tabla opcional y evita añadir una columna u objeto que ya exista. Mantén coherentes las rutas de creación de una base de datos nueva y de actualización. Si una reversión depende de la configuración de ejecución, hazla hermética: 1. Durante la actualización, guarda cada valor de configuración necesario en metadatos propiedad de la migración y asociados a la revisión. 2. Durante la reversión, lee la instantánea guardada en vez del entorno actual. 3. Usa la configuración activa únicamente como alternativa de compatibilidad documentada para bases de datos actualizadas antes de que existieran las instantáneas. 4. Retira la instantánea cuando termine la reversión. Una migración que lea la configuración solo para sembrar datos durante la actualización no necesita una instantánea para la reversión, salvo que esta última también dependa de ese valor. Vuelve a verificar el head después de editar y ejecuta las pruebas pertinentes de migración y aplicación. Si la base de datos de destino está atrasada, lleva la base controlada de desarrollo o pruebas hasta el head esperado antes de generar una nueva revisión. Nunca realices esa actualización correctiva en producción sin autorización explícita y un plan revisado. ## Confirma los resultados reales y pide permiso antes de hacer push Revisa el diff final frente a la solicitud original, las directrices de dominio más cercanas y las invariantes de seguridad anteriores. Confirma los resultados reales de lint, tipos, análisis de seguridad, pruebas, migraciones, recursos generados y documentación cuando correspondan. No afirmes que algo funciona solo por haberlo inspeccionado. Usa la convención de commits, la política de firmas, los enlaces a issues y la plantilla de pull request exigidos por el repositorio. No hagas push ni force-push, no modifiques la rama de otra persona ni cambies el estado externo del proyecto hasta recibir autorización explícita. En revisiones públicas y comentarios de issues: - Empieza por lo que funciona antes de plantear preocupaciones. - Separa los hallazgos bloqueantes, las sugerencias y las notas menores. - Explica el riesgo y ofrece preguntas u opciones, en lugar de dar órdenes innecesarias. - Sé directo sin resultar duro ni robótico. No añadas atribuciones internas del asistente, comentarios operativos ocultos, credenciales ni estimaciones especulativas de esfuerzo a los diffs del producto o mensajes públicos. Crea archivos o documentación nuevos solo cuando el cambio realmente los requiera. Al clasificar trabajo, distingue una solicitud que espera información de quien la reportó, un bloqueo por dependencias y un elemento aceptado pero aplazado. Marca un issue como resuelto solo después de que se haya integrado el cambio que lo corrige, no por haberlo implementado únicamente en local. Antes de finalizar, comprueba que los valores sensibles sigan fuera del control de versiones, que las rutas de denegación de seguridad tengan pruebas, que se haya respetado la prioridad de las fuentes canónicas y que ningún contenido temporal no relacionado haya entrado en el diff.