--- title: "Systems: el mapa que hay detrás de la revisión entre repositorios · SourceAnt" description: "Agrupa repositorios en un sistema, y una revisión puede seguir un cambio en todos los repositorios a los que llega. El mapa que hay detrás de la revisión entre repositorios en bases de código multi-repositorio y polirepositorio." url: "https://sourceant.ai/es/systems/" --- Revisiones de sistemas y entre repositorios # Revise un cambio frente a cada repositorio al que llega. Una pull request fija un repositorio. Tu cambio no termina ahí. SourceAnt registra los servicios, componentes, colas y almacenes de datos que trabajan juntos, y luego usa ese mapa para revisar un cambio frente a todo lo que alcanza, y nombra los repositorios que no pudo leer en lugar de omitirlos. [Empezar gratis](https://app.sourceant.ai/) [Explorar el producto](https://sourceant.ai/es/systems/#reach) Todos los ingenieros y todos los agentes incluidos, nunca por puesto · Tus propias claves de modelo Arquitectura del sistema ![Lienzo del sistema de SourceAnt que muestra servicios, almacenes de datos y relaciones propuestas](https://sourceant.ai/_astro/systems-canvas-dark.DL1-amif_wKPPF.webp) La revisión ## Una pull request fija un repositorio. Tu cambio no termina ahí. Toda herramienta de revisión lee el diff que tiene delante. Cuando el contrato que acabas de cambiar lo consume un servicio de otro repositorio, el diff es la mitad de la historia que no puede decírtelo. SourceAnt parte de los archivos modificados, recorre el grafo hasta todo lo que alcanzan y también lee allí. ### Qué alcanza el cambio Partiendo de los archivos modificados, la revisión recorre el grafo hasta los servicios, colas y almacenes de datos del otro extremo. Los enlaces aprobados se afirman. Los pendientes se plantean como pregunta, nunca como hecho. ### El código que leyó allí En cada repositorio que alcanza, busca el código que toca lo que cambiaste y lo cita con el repositorio y la revisión de donde proviene. Puedes abrir el archivo que nombra. ### Lo que no pudo leer Un repositorio al que no logró llegar se nombra en la revisión, con el motivo. Un revisor que se salta en silencio la mitad de tu sistema es peor que uno que admite la laguna. ### De dónde vinieron los enlaces Leídos de los manifiestos que tus repositorios ya publican, a través de la API. No se clona nada, no se ejecuta nada y ningún modelo adivina. Cada arista nombra el archivo del que proviene, y nada se aprueba sin una persona. Un repositorio hermano se lee en la revisión en la que se indexó por última vez, porque una solicitud de incorporación de cambios fija solo la suya. Donde esa revisión es antigua, la revisión lo indica en lugar de presentarla como actual. Cómo lo sabe ## El mapa que recorre la revisión y cómo se mantiene honesto Una revisión solo puede llegar tan lejos como el grafo que tiene detrás. Cualquier otro mapa de arquitectura es una instantánea que alguien tomó una vez. Este es un bucle: leer la fuente de verdad, proponer la diferencia, esperarte y admitir cuándo ha quedado desactualizado. 1. 01 ### Lee lo que tus repositorios ya publican package.json, composer.json, go.mod, requirements.txt y pyproject.toml, obtenidos a través de la API de GitHub. Un manifiesto que no se puede analizar no propone nada en lugar de hacer fallar todo el sistema. 2. 02 ### Propone, y solo donde puede señalar un archivo Se propone una dependencia cuando un repositorio declara un nombre bajo el que otro se publica. Cada propuesta nombra el manifiesto del que proviene, así que puedes comprobarla abriendo un archivo. 3. 03 ### Tú lo apruebas Las propuestas llegan pendientes y siguen pendientes. Nada aquí se aprueba a sí mismo. Envía primero persist: false si quieres ver la propuesta sin tocar el grafo en absoluto. 4. 04 ### Te avisa cuando ha dejado de ser cierto Una parte que se cree desactualizada se marca como obsoleta en lugar de eliminarse. El registro dice que no está seguro en vez de equivocarse en silencio, que es el fallo que tiene todo diagrama de arquitectura. Evidencia, no afirmación ## Cada arista muestra su trabajo Una relación que no puedes comprobar es un rumor. Cada una indica de dónde proviene, cuán segura es y si alguien la ha validado. `billing-api` depends\_on `shared-auth` pendiente Estado propuesta, aprobada o retirada. Dónde se sitúa la parte, elegido por tu equipo y no por el analizador. Confianza 0 a 1. Una parte que alguien declaró es 1. Una inferida es menor, y se registra el motivo. Obsoleta Se cree desactualizada. Se conserva y se marca en lugar de eliminarse, para que puedas ver qué envejeció y decidir. Evidencia El archivo, el manifiesto, la revisión. Además del nombre exacto que se declaró y qué ecosistema lo emitió. confianza 0.6 Un nombre sin más no es prueba de que la dependencia se resuelva a ti. Un registro público puede llevar el mismo nombre, que es como funciona la confusión de dependencias, así que un nombre sin propietario se propone con menor confianza en lugar de afirmarse. Delimitado a propósito ## Una respuesta lo bastante pequeña para actuar sobre ella Un recorrido devuelve un subgrafo que puedes inspeccionar o dar a un modelo. Te dice cuándo tuvo que detenerse en lugar de devolver en silencio medio grafo. | Campo | Predeterminado | Rango | | --- | --- | --- | | profundidad | 2 | 1 a 3 | | dirección | ambos | saliente, entrante, ambos | | minimum\_confidence | 0.0 | 0 a 1 | | include\_stale | false | activado o desactivado | | entity\_limit | 50 | hasta 50 | | relationship\_limit | 100 | hasta 100 | Lee el grafo directamente con `/api/topology/search` y `/api/topology/traverse`, o deja que un agente extraiga el mismo subgrafo mediante un paquete de contexto a través de MCP. Por qué no un catálogo ## Un catálogo es una copia que alguien escribió. Esto se lee del código. Los portales para desarrolladores piden a una persona que registre cada servicio y luego confían en esa entrada para siempre. La entrada no se corrompe de forma evidente. Simplemente deja de coincidir con el código y nadie lo descubre hasta que ocurre un incidente. Un catálogo registrado - Alguien escribe el servicio una vez - La exactitud depende de quién lo recordó - La desviación es silenciosa - No hay registro de por qué se cree una entrada SourceAnt Systems - Se lee de los manifiestos en cada pasada - La exactitud conlleva un número por el que puedes filtrar - La desviación se marca como obsoleta - Cada arista nombra el archivo que la respalda Preguntas ## Revisión entre repositorios, resuelta Qué lee, hasta dónde llega y qué hace cuando no puede llegar. ### ¿Qué es una revisión entre repositorios? Lo que Systems hace posible. Es una revisión que no se detiene en el repositorio donde se abrió el pull request. Parte de los archivos modificados, sigue las conexiones de tu sistema hasta los servicios, colas y almacenes de datos del otro extremo, y lee el código allí. Una revisión normal ve un diff. Esta ve hasta dónde llega el diff. ### ¿Es lo mismo que la revisión de código multi-repositorio? Sí. La revisión de código multi-repositorio, la revisión entre repositorios y la revisión polirepositorio nombran el mismo problema: el cambio está en un repositorio y la consecuencia está en otro. Decimos revisión entre repositorios porque el alcance es lo importante, no cuántos repositorios tengas. ### ¿En qué se diferencia de revisar cada repositorio por separado? Revisar cada uno por separado te da un veredicto por repositorio y nadie observa lo que ocurre entre ellos. Ahí es donde están las roturas: un lado cambió un contrato que el otro lado todavía espera. Una revisión entre repositorios lee ambos lados en una sola pasada y cita el código que leyó en el otro lado, junto con el repositorio y la revisión de donde proviene. ### ¿Cómo sabe qué repositorios están relacionados? Lee tu código y determina qué encaja junto. Algunas conexiones son obvias, como cuando un repositorio depende de otro. Otras solo las implica el código. Puedes añadir más conexiones personalizadas y SourceAnt te muestra sugerencias tras examinar tu sistema. ### ¿Funciona en un monorepositorio? Sí. Un monorepositorio cuenta como un único repositorio, así que un cambio dentro de él ya se revisa frente al resto. Los sistemas importan más en una configuración de varios repositorios o polyrepo, donde el otro lado de un cambio está en un repositorio distinto. También ayudan en un monorepositorio que se comunica con algo fuera de su propio árbol, como un servicio, una cola o un almacén de datos. Puedes añadirlos como partes aunque no tengan código que leer. ### ¿Hay que aprobar un enlace antes de que una revisión lo atraviese? No. La revisión lo atraviesa tanto si el enlace está aprobado como si no. La aprobación cambia cómo puede hablar de él. Un enlace aprobado se afirma como hecho, indicando dónde podría el cambio romper el otro lado. Uno pendiente se plantea como pregunta y no lleva ninguna sugerencia. ### ¿Qué ocurre con un repositorio que no puede leer? Se nombra en la revisión, con el motivo. Nunca se omite en silencio. Un revisor que se salta en silencio la mitad de tu sistema parece lo mismo que uno que lo leyó todo y no encontró nada. Las causas habituales: el repositorio nunca se leyó, está conectado pero no en el mismo sistema, o la aplicación no está instalada en él. ### ¿Qué tan actualizado está el código que lee en el otro repositorio? Un repositorio hermano se lee en la revisión en la que se indexó por última vez, porque una solicitud de incorporación de cambios fija solo la suya. Donde esa revisión es antigua, la revisión lo indica en lugar de presentarla como actual. La configuración se explica paso a paso en [la guía de revisión entre repositorios](https://sourceant.ai/es/docs/cross-repository-reviews). ### Tuyo para llevártelo Las instantáneas del grafo son portátiles, se transmiten en streaming y se validan a la entrada, y una escritura interrumpida se recupera en lugar de quedar aplicada a medias. ### Con alcance, y solo su propio alcance A través de MCP, el alcance es el principal autenticado. A través de HTTP, es una declaración de espacio de trabajo en el token, y un token sin ella se rechaza. ### Tu vocabulario, no el nuestro Una parte es lo que tu arquitectura llame parte: un servicio, una cola, un almacén de datos, una tarea. SourceAnt no te impone una lista de tipos. ## Conecta dos repositorios y lee una sola revisión Apúntalo a repositorios que ya tengas, aprueba la primera propuesta, luego abre un cambio en uno de ellos y observa hasta dónde llega la revisión en el otro. [Empezar gratis](https://app.sourceant.ai/) [Leer la documentación](https://sourceant.ai/es/documentation)