Revisiones de sistemas y entre repositorios
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.
Todos los ingenieros y todos los agentes incluidos, nunca por puesto · Tus propias claves de modelo
La revisión
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í.
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.
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.
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.
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
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.
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.
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.
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.
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
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
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
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
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.
Preguntas
Qué lee, hasta dónde llega y qué hace cuando no puede llegar.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.