Federación Dinámica: Túneles de Subgraphs GraphQL Locales en Supergraphs de Producción

No deberías tener que levantar 50 microservicios en tu portátil solo para probar un cambio en un esquema GraphQL. Este artículo desglosa la arquitectura de los túneles de subgraph—cómo integrar sin problemas tu código local en un supergraph en la nube en vivo sin la sobrecarga de ejecutar toda la pila localmente.

---

1. El Cambio de Paradigma: De APIs Monolíticas a Supergraphs Federados

GraphQL surgió como la respuesta estándar a la sobrecarga y subcarga de datos, ofreciendo a los clientes un único endpoint unificado. A medida que las organizaciones escalaron, un servidor GraphQL monolítico se convirtió en un cuello de botella evolutivo. Los equipos chocaban en despliegues, los conflictos de esquema eran frecuentes y la inestabilidad de un solo servicio podía derribar todo el grafo.

Apollo Federation abordó esto a nivel arquitectónico. Al descomponer un esquema monolítico en subgraphs específicos de dominio, desplegables de forma independiente, diferentes equipos de ingeniería pueden gestionar sus respectivas partes del API. Un proceso de composición une esos archivos SDL de subgraph en un supergraph único. En el borde, un gateway o router de alto rendimiento recibe las consultas de los clientes, construye un plan de consulta y envía solicitudes paralelas a los subgraphs subyacentes.

Federation 2—la especificación canónica actual—introdujo un modelo de propiedad compartida más limpio, mejor fusión de tipos y nuevas pistas de composición para detectar errores antes. Los esquemas de subgraph optan por aplicar la directiva @link para indicar su participación. Las directivas específicas de Federation—@key, @shareable, @provides, @requires, @interfaceObject, entre otras—codifican las relaciones entre tipos a través de los límites de servicio. La validación de la composición verifica estos contratos de forma estática y produce un artefacto SDL de supergraph que el router consume en tiempo de ejecución.

El núcleo de Apollo Router es el runtime de referencia para esta arquitectura. Escrito en Rust, se diseña con tres principios: corrección (estricto cumplimiento de las especificaciones GraphQL y Federation), fiabilidad (latencia predecible, huella de memoria y estabilidad) y experimentación segura (banderas de características en tiempo de ejecución y hooks de extensibilidad que no afectan las consultas existentes).

Donde Federation resolvió el problema de escalabilidad organizacional en producción, creó un nuevo cuello de botella en el ciclo de desarrollo.

---

2. El Cuello de Botella en el Desarrollo Local

En una arquitectura federada con diez, treinta o cincuenta subgraphs distintos, la experiencia del desarrollador se degrada rápidamente. Añadir un campo al subgraph Inventory requiere confianza en que la integración será limpia y que las consultas cruzadas entre servicios—como Products, Users e Inventory—siguen resolviéndose correctamente.

Tres válvulas de escape suelen usarse, cada una con costos reales.

Ejecutar toda la pila localmente. Incluso con Docker Compose, el agotamiento de recursos es casi seguro. La limitación de CPU, los kills por OOM y conflictos de puertos se acumulan rápidamente a medida que aumenta el número de servicios. Para la mayoría de los ingenieros, esto deja de ser viable más allá de unos pocos subgraphs.

Mockear los subgraphs faltantes. Un desarrollador puede ejecutar su servicio único localmente y simular los otros cuarenta y nueve. El riesgo es la deriva. Los mocks son instantáneas; staging y producción son objetivos en movimiento. Los errores en los puntos de unión reales entre servicios no se detectan hasta que CI los ejecuta—o después del merge.

Subir a un entorno de staging. Esto mantiene la fidelidad, pero colapsa el ciclo de retroalimentación. Esperar a que un pipeline completo de CI/CD reconstruya y redeploye un contenedor para probar un cambio en el nombre de un campo del esquema es un coste de productividad con impacto desproporcionado en la velocidad de iteración.

El problema subyacente es aislamiento: la portátil del desarrollador está desconectada del grafo en vivo y conectado en la nube. Los túneles de subgraph existen para disolver esa barrera.

---

3. Ingreso Dinámico de Subgraphs: El Patrón de Túneles

El ingreso dinámico de subgraphs es un patrón arquitectónico que permite a un desarrollador ejecutar un solo subgraph localmente mientras un agente de túnel lo registra y enruta tráfico en vivo desde un supergraph de staging en la nube. El desarrollador logra integración completa contra el grafo compuesto real sin ejecutar otros servicios.

El flujo de datos en tiempo de consulta es directo.

Un cliente—una aplicación o un desarrollador en Apollo Sandbox—envía una consulta al router del supergraph de staging. El router analiza la operación y construye un plan de consulta. Para campos resueltos por subgraphs en la nube (Users, Reviews), los obtiene de esos clusters de staging como de costumbre. Para cualquier campo propiedad del subgraph en desarrollo (Inventory), enruta la sub-operación a través de un túnel seguro a localhost:4000 en la máquina del desarrollador. El proceso local ejecuta resolvers, accede a bases de datos locales o remotas y devuelve la carga útil por el túnel. El router agrega todos los resultados parciales y devuelve una respuesta unificada al cliente.

Desde la perspectiva del cliente, la respuesta es indistinguible de un supergraph completamente alojado en la nube. Desde la del desarrollador, el proceso local tiene plena capacidad de depuración—puntos de interrupción, inspección de variables, trazas de pila—contra tráfico en vivo y compuesto.

---

4. Arquitectura Central: Tres Componentes

Una implementación completa de túnel de subgraph requiere tres componentes coordinados.

4.1 El Subgraph Local

Este es un servidor GraphQL compatible con Federation que corre en la máquina del desarrollador. Cualquier lenguaje y framework que produzca un SDL válido de subgraph funciona: Node.js con @apollo/subgraph, Python con Strawberry, Go con gqlgen, Kotlin con DGS, etc. La recarga en caliente o equivalente mantiene los cambios en esquema visibles sin reiniciar el proceso.

El servidor debe exponer un puerto HTTP. Ese puerto será el destino al que el túnel proxyará el tráfico.

4.2 El Agente de Túnel Seguro

El agente crea una conexión persistente y autenticada entre la máquina local y un endpoint público de relay, saltándose NAT y firewalls corporativos. Dos opciones de producción son comúnmente usadas.

ngrok abre un stream multiplexado HTTP/2 hacia la infraestructura de relay de ngrok y presenta una URL pública estable (ej. https://dev-inventory.ngrok.app). Las solicitudes HTTP entrantes a esa URL se proxyan por el túnel al puerto local designado. La autenticación en el nivel del túnel—ngrok soporta OAuth 2.0, OpenID Connect y mTLS—debe configurarse siempre que se exponga un servidor de desarrollo con acceso a datos o credenciales reales.

Cloudflare Tunnel (cloudflared) funciona bajo el mismo principio. Un daemon cloudflared establece conexiones salientes a la red de borde de Cloudflare. El tráfico que llega a un hostname configurado en Cloudflare se enruta de regreso a través de esas conexiones al origen local. Como la conexión es solo saliente, no se requieren reglas de firewall entrantes.

Ambas herramientas soportan interfaces de inspección estilo webhook que permiten a los desarrolladores ver las solicitudes y respuestas HTTP en bruto que fluyen por el túnel—útil para depurar detalles del protocolo de subgraph.

4.3 El Router en la Nube Dinámico

Esta pieza es la más compleja arquitectónicamente. El router en la nube debe conocer la URL del túnel y sustituirla por la URL interna del staging del subgraph objetivo.

En configuración estática, el SDL del supergraph codifica la URL de enrutamiento de cada subgraph en una directiva join__Graph. El router lee esas URLs al inicio y envía las sub-operaciones en consecuencia. Para que funcione un túnel, una de dos cosas debe suceder: actualizar la composición para incluir la URL del túnel en el subgraph, o extender el router para sobrescribir la URL en tiempo de solicitud sin recomponer.

Ambos enfoques son válidos según el caso de uso. Sus ventajas y desventajas se exploran en las próximas secciones.

---

5. Implementación Paso a Paso

El siguiente es el proceso canónico en cuatro pasos para conectar un subgraph local en un supergraph de staging.

Paso 1: Iniciar el Subgraph Local

npm run dev --port 4000
# → Servidor en http://localhost:4000/graphql

Confirma que el servidor devuelve un SDL válido del subgraph inspeccionando el endpoint o usando un IDE GraphQL.

Paso 2: Abrir el Túnel Inverso

ngrok http 4000
# → Reenvía  https://dev-inventory.ngrok.app -e9 a localhost:4000

La URL pública ya está activa. Cualquier POST HTTP a https://dev-inventory.ngrok.app/graphql llega a tu resolutor local.

Paso 3: Sobrescribir la URL de enrutamiento del subgraph

Con el CLI Rover, un archivo de configuración supergraph.yaml puede mezclar fuentes de subgraphs. Se puede usar una referencia a un grafo de staging existente para obtener todos los demás subgraphs del registro, sobrescribiendo la entrada inventory con la URL del túnel:

federation_version: =2.12.0
subgraphs:
  products:
    routing_url: http://products.staging.svc.cluster.local
    schema:
      graphref: my-supergraph@staging
      subgraph: products
  users:
    routing_url: http://users.staging.svc.cluster.local
    schema:
      graphref: my-supergraph@staging
      subgraph: users
  inventory:
    routing_url: https://dev-inventory.ngrok.app/graphql
    schema:
      subgraph_url: https://dev-inventory.ngrok.app/graphql

La función de espejo de subgraph de Rover (introducida en una versión reciente) puede heredar URLs de enrutamiento y esquemas de un grafo de estudio existente, facilitando crear un supergraph local sin mantener toda la configuración desde cero—solo la sobrescritura del subgraph en desarrollo.

Ejecutar rover dev inicia un router local que consulta los subgraphs mezclados, brindando un entorno híbrido local/remoto sin tocar el clúster de staging compartido.

Paso 4: Validación de Extremo a Extremo

Apunta tu frontend o Apollo Sandbox al endpoint del router local (por defecto http://localhost:4000). Ejecuta cualquier consulta que cruce límites de subgraph. La terminal del desarrollador debe recibir la sub-operación para el subgraph tunelado localmente. El router arma todos los resultados parciales y devuelve la respuesta unificada.

---

6. Entornos Compartidos: Ingreso Dinámico Basado en Encabezados

El método anterior tiene un fallo operativo crítico si se aplica al router de staging en la nube compartido en lugar de a uno local: actualizar la URL del subgraph en staging para apuntar a la portátil del desarrollador A significa que las solicitudes del desarrollador B—y las pruebas automatizadas—también se enrutan a la máquina del desarrollador A. Cuando el desarrollador A cierra su portátil, todo el entorno de staging compartido se rompe.

El ingreso dinámico basado en encabezados resuelve esto manteniendo el enrutamiento por desarrollador completamente dentro de la solicitud individual, no en la configuración global del router.

El Mecanismo

Un desarrollador añade un encabezado personalizado a sus solicitudes:

x-dev-routing: inventory=https://dev-inventory.ngrok.app

El router inspecciona este encabezado y, solo para esa solicitud específica, sobrescribe la URL de salida del subgraph inventory durante la ejecución. Todas las demás solicitudes continúan enrutándose al clúster de staging interno.

Implementación con Scripts Rhai

Apollo Router soporta scripts Rhai para manipulación en memoria de encabezados, cookies y contexto del router. Los hooks de Rhai se integran en el ciclo de vida de manejo de solicitudes del router a través de puntos de entrada nombrados: router_service, supergraph_service, execution_service, y subgraph_service. El hook subgraph_service se llama una vez por solicitud de subgraph dentro de un plan—si un plan se ramifica en tres subgraphs, el hook se dispara tres veces, cada una con el nombre del subgraph destino.

Un script Rhai que implementa la sobrescritura de enrutamiento basada en encabezados:

fn subgraph_service(service, subgraph) {
    let request_callback = |request| {
        let routing_header = request.headers["x-dev-routing"];
        if routing_header != () {
            // Parsear pares "subgraphName=https://tunnel-url"
            let parts = routing_header.split("=");
            if parts.len() == 2 && parts[0].trim() == subgraph {
                request.subgraph.uri = parts[1].trim();
            }
        }
    };
    service.map_request(request_callback);
}

Los benchmarks publicados por Apollo muestran una sobrecarga de script Rhai de aproximadamente 100 µs en p95, siendo una opción adecuada para este caso. Para lógica que no puede expresarse en Rhai—como análisis complejo de JWT, llamadas a servicios externos o búsquedas en bases de datos—un coprocesador externo que comunique con el router vía HTTP es la alternativa soportada, aunque su sobrecarga promedia alrededor de 350 µs por etapa y escala con la ramificación del subgraph.

Los coprocesadores requieren un plan Enterprise de GraphOS. Los scripts Rhai se ejecutan en todos los niveles del router, incluido el binario de Apollo Router Core de código abierto.

Propiedades de Aislamiento

Con enrutamiento basado en encabezados, múltiples desarrolladores pueden tunelizar diferentes subgraphs en el mismo router de staging simultáneamente. Cada solicitud lleva su propio encabezado de enrutamiento; el script Rhai aplica sobrescrituras solo a las solicitudes coincidentes. Desde la perspectiva del router de staging, el grafo siempre está compuesto y disponible. Un desarrollador desconectado solo afecta sus propias solicitudes.

---

7. Ecosistema: Herramientas que Soportan estos Flujos de Trabajo

Apollo GraphOS y CLI Rover

Rover es la herramienta de línea de comandos de Apollo para gestionar esquemas federados. rover dev inicia una instancia de router local—descargada automáticamente en la primera ejecución—que obtiene los esquemas de subgraph desde un grafo de GraphOS Studio y los une con uno o más subgraphs en ejecución local. El puerto predeterminado del router es 4000.

El formato supergraph.yaml que soportan rover supergraph compose y rover dev admite tres tipos de fuentes de esquema simultáneamente: archivos .graphql locales, URLs de introspección de subgraph en vivo y referencias a grafos publicados en GraphOS Studio. Una sola configuración puede mezclar los tres, justo lo que necesita un flujo de trabajo de túnel.

Las versiones recientes de Rover añadieron espejo de subgraphs, que heredan URLs de enrutamiento y esquemas de un grafo de Studio existente sin requerir un supergraph.yaml manual. Solo el subgraph en local sobrescrito necesita una entrada explícita.

La versión LTS actual de Apollo Router es v2.10, lanzada en diciembre de 2025, compatible con Federation v2.12. Router v1.x dejó de soportarse el 31 de marzo de 2026. Los equipos en v1.x deberían haber migrado ya; no se requieren cambios en los subgraphs para los que ya usan Federation v2.

GraphQL Hive

GraphQL Hive, mantenido por The Guild, es una alternativa open-source, licenciada bajo MIT, a Apollo GraphOS. Ofrece un registro de esquemas, validación de composición, análisis de uso y sus propias opciones de gateway (Hive Gateway en JavaScript y Hive Router en Rust). El registro publica supergraphs compuestos en un CDN de alta disponibilidad respaldado por Cloudflare, desde donde los gateways consultan actualizaciones.

Hive soporta entornos de esquema ramificados (development, staging, production) y promoción de esquemas entre estos sin volver a publicar los subgraphs. Los equipos pueden publicar una URL de túnel como routing_url para un subgraph en el entorno de desarrollo, dejando intactos staging y producción.

El 12 de marzo de 2025, Hive migró de Tokens de Acceso por objetivo a Tokens de Acceso a nivel de organización, que pueden limitarse a proyectos, objetivos o nombres de servicio específicos. Las herramientas que usaban --registry.accessToken ahora también requieren un argumento --target con el slug o UUID.

Hive Gateway y Hive Router

Hive Gateway (Node.js) y Hive Router (Rust) consultan ambos el CDN de Hive para obtener el artefacto del supergraph compuesto. Como soportan la composición estándar de Federation, las URLs de túnel de subgraph funcionan igual: publicar una URL de túnel como la URL de enrutamiento para un subgraph en desarrollo, y el gateway enruta en consecuencia.

---

8. Consideraciones de Seguridad y Operaciones

Autenticación del Túnel

Exponer un servidor de desarrollo local a internet mediante una URL pública es intrínsecamente riesgoso. Un actor malicioso que descubra la URL podría enviar operaciones GraphQL arbitrarias al proceso local, que generalmente corre con credenciales de desarrollador y acceso a variables de entorno, bases de datos o secretos.

Aplicar autenticación en el nivel del túnel, no solo en la aplicación. Tanto ngrok como cloudflared soportan OAuth 2.0 y mTLS en el relay. El router en la nube debe configurarse para incluir un secreto compartido o certificado cliente en las solicitudes, que el agente local valida antes de pasar el tráfico.

Nunca expongas una URL de túnel que llegue a un proceso local con acceso de escritura a bases de datos de producción o staging sin mTLS o verificación de credenciales equivalente.

Inspección y Exposición del Esquema

Cuando un subgraph local se tuneliza en un supergraph de staging, las políticas de esquema y operación del supergraph aplican en el borde del router. Sin embargo, si la introspección del subgraph local está habilitada sin restricciones, un solicitante que conozca la URL del túnel puede inspeccionar el esquema fuera de los controles de acceso del supergraph.

Apollo Router v1.0 y posteriores vienen con la introspección deshabilitada por defecto en modo no-dev. Verifica que la configuración de introspección del subgraph local coincida con la postura de seguridad adecuada.

Nulabilidad y Fallos Parciales

Los entornos de desarrollo local son inherentemente volátiles. Un desarrollador puede poner un breakpoint, reiniciar el servidor a mitad de una solicitud o introducir un error de compilación que detenga el proceso. Cualquiera de estas condiciones provocará que el túnel se agote o devuelva un error en la solicitud en curso.

Diseñar esquemas federados con nulabilidad en mente limita el impacto de estos fallos. Cuando un túnel de subgraph no responde, el router puede devolver null para esa rama del entidad en lugar de propagar un error que anule toda la respuesta de operación. La documentación de Apollo sobre nulabilidad en graphs federados recomienda evaluar la nulabilidad de las entidades referenciadas caso por caso, considerando SLAs internos—no hay una respuesta universal, pero preferir nullable en joins entre servicios da más flexibilidad para una degradación elegante.

La directiva @semanticNonNull, introducida en la especificación de nulabilidad y ahora soportada experimentalmente por Apollo Kotlin y otros frameworks, ofrece una alternativa más expresiva. Las fields anotadas con @semanticNonNull indican que null solo aparece en presencia de un elemento en el array de errores, no como valor válido de negocio. Esta distinción permite a los clientes generar propiedades no nulas en código tipado, manejando aún el caso de fallo si un subgraph tunelado se desconecta.

El soporte del router para @defer también es relevante. Cuando un túnel de subgraph local introduce latencia—quizá porque el desarrollador está paso a paso en un depurador—el cliente puede usar @defer para recibir las partes no diferidas de la respuesta inmediatamente y esperar el resultado local de forma asíncrona.

Trazabilidad Distribuida a Través del Túnel

Depurar la ejecución de planes de consulta complejos se vuelve mucho más difícil sin visibilidad de trazas de extremo a extremo. Cuando una consulta se ramifica a subgraphs en la nube y a un subgraph tunelado localmente, la traza debe abarcar todos.

Apollo Router sigue la especificación W3C Trace Context para generación y propagación de IDs de traza. Las cabeceras traceparent y tracestate se incluyen automáticamente en las solicitudes a los subgraphs. Si el subgraph local está instrumentado con OpenTelemetry—usando @opentelemetry/instrumentation-graphql y un exportador OTLP apuntando a un colector local o compartido—sus spans aparecerán como hijos del span del router en la traza distribuida.

La telemetría del router se configura en router.yaml bajo la clave telemetry. Habilitar trace_context: true en propagation asegura que las cabeceras W3C se reenvían:

telemetry:
  exporters:
    tracing:
      propagation:
        trace_context: true
      otlp:
        enabled: true
        endpoint: "http://localhost:4317"

El waterfall de trazas—mostrando el plan de consulta del router, spans de obtención paralela de subgraphs y spans de resolutor del subgraph local—es la herramienta de depuración más valiosa para análisis N+1 federado en un flujo de trabajo de túnel.

---

9. Madurez Operacional: Qué Estandarizar en Equipos

Para equipos que avanzan desde experimentación individual hacia una práctica compartida de túneles, varias normas operativas reducen fricciones y previenen incidentes.

Automatización del ciclo de vida del túnel. Las URLs de túnel cambian en cada reinicio de ngrok a menos que se configure un dominio reservado (los tiers pagos de ngrok soportan subdominios personalizados estables). Añade el registro de URLs de túnel al script de inicio de desarrollo en lugar de hacerlo manualmente.

Coprocesador vs. Rhai para sobrescritura de enrutamiento. Los scripts Rhai corren directamente en el proceso del router y no requieren infraestructura adicional. Para la mayoría, el patrón de análisis de encabezados descrito arriba funciona bien con Rhai. Los coprocesadores son adecuados cuando la decisión de enrutamiento requiere estado externo—por ejemplo, una tabla de búsqueda que mapea identificadores de desarrollador a sus URLs de túnel actuales en un almacén compartido.

Aislamiento del router de staging. Aplica el patrón de enrutamiento basado en encabezados al router de staging compartido, no a la sustitución global de URLs de subgraph. La sustitución global solo es apropiada para ramas de características de corta duración donde el desarrollador controla todo el entorno de staging.

Validación de composición de esquemas en CI. Incluso con un túnel local, los cambios en esquema deben pasar validación de composición antes del merge. rover subgraph check o hive schema:check detectarán cambios rotos contra la composición actual del registro antes de que la PR se integre.

Revisión de seguridad para el alcance del túnel. Define y documenta qué subgraphs pueden tunelizarse. Los subgraphs con acceso de escritura a datos cercanos a producción deben requerir autenticación elevada en el nivel del túnel y pueden necesitar revisión antes de ser expuestos públicamente, incluso temporalmente.

---

10. Conclusión

La promesa de la federación GraphQL era la autonomía del equipo—propiedad independiente, despliegue independiente, iteración independiente. Las limitaciones físicas del hardware del desarrollador amenazaban con vaciar esa promesa haciendo que las pruebas locales realistas fueran imprácticas.

El túnel de subgraph la restablece. Al enrutar el tráfico de un subgraph específico a través de un túnel seguro hacia la portátil del desarrollador, dejando los demás en la nube, el patrón ofrece acceso completo, depurable y en alta fidelidad al grafo en vivo sin cargarlo localmente.

Las herramientas han madurado mucho. rover dev con espejo de subgraphs, el scripting Rhai de Apollo Router y los registros de esquemas ramificados de Hive proveen los bloques de construcción para un flujo de trabajo de producción. La base estable actual es Apollo Router v2.x con Federation v2.12 (la versión LTS de diciembre de 2025), con Router v1.x en fin de soporte desde marzo de 2026.

El enrutamiento por solicitud basado en encabezados es donde el patrón se vuelve verdaderamente a escala de equipo: múltiples desarrolladores tunelizando diferentes subgraphs simultáneamente en el mismo router compartido, cada uno en completo aislamiento del otro. Esa es la práctica que vale la pena estandarizar.

---

Cambios Recientes

Cambio	Razón
Eliminados keywords y hook line del cuerpo del artículo	Metadatos del borrador, no contenido editorial
Reescrita la descripción del diagrama en la sección 3	Original confundió el DNS de staging del Router con el relay del túnel—se aclaró el flujo de datos
Actualizada la descripción del comando rover dev para reflejar comportamiento actual	rover dev inicia un router local; no modifica el clúster de staging en la nube. Se añadió contexto de espejo de subgraphs en Rover
Actualizado ejemplo de supergraph.yaml a federation_version: =2.12.0	La versión LTS actual de Federation a diciembre de 2025; la original usaba una versión no especificada
Añadido contexto de la versión Apollo Router v2.10 / Federation v2.12 (diciembre 2025); fecha de fin de soporte v1.x (marzo 31 2026)	Fuente en blog de Apollo, diciembre 2025
Script Rhai reescrito para coincidir con API documentada	La lógica original plausible, pero no documentada; ajustada a la firma de subgraph_service y acceso a encabezados según API oficial
Añadidas cifras de rendimiento de coprocesadores (~100 µs / ~350 µs)	Fuente en blog de Apollo sobre extensibilidad y benchmarks
Coprocesadores requieren plan Enterprise de GraphOS	Documentación oficial de Apollo Router
Se eliminó sección de WunderGraph	WunderGraph cambió su oferta a un nuevo producto; la descripción original no reflejaba la posición actual
Se reescribió sección de GraphQL Hive	Añadidos detalles de Hive Gateway v2 y Hive Router (Rust), migración de tokens en marzo 2025, y entrega vía CDN/Cloudflare desde docs oficiales
Discusión sobre @semanticNonNull en la sección 8	Relevante para manejo de fallos en túneles; confirmada como experimental en Apollo Kotlin 4 (agosto 2024) y otros frameworks
Se amplió la sección de trazabilidad con ejemplo de router.yaml	Basado en documentación oficial de Apollo Router; propagación de cabeceras W3C confirmada
Se añadió sección 9 (Madurez Operacional)	Aborda normas de equipo para ciclo de vida del túnel, aislamiento en staging y validación en CI