Systems & Cross-repository reviews
A pull request pins one repository. Your change does not stop there. SourceAnt records the services, components, queues and datastores that work together, then uses that map to review a change against everything it reaches, and names the repositories it could not read rather than skipping them.
Every engineer and every agent included, never per seat · Your own model keys
The review
Every review tool reads the diff in front of it. When the contract you just changed is consumed by a service in another repository, the diff is the half of the story that cannot tell you so. SourceAnt starts from the changed files, walks the graph to whatever they reach, and reads there too.
Starting from the changed files, the review walks the graph to the services, queues and datastores on the other end. Approved links are stated. Pending ones are raised as a question, never as a fact.
In each repository it reaches, it searches for the code that touches what you changed, and quotes it with the repository and the revision it came from. You can open the file it names.
A repository it failed to reach is named in the review, with the reason. A reviewer that quietly skips half your system is worse than one that admits the gap.
Read from the manifests your repositories already publish, through the API. Nothing is cloned, nothing is executed, and no model guesses. Every edge names the file it came from, and nothing is approved without a person.
A sibling repository is read at the revision it was last indexed, because a pull request pins only its own. Where that revision is old, the review says so rather than presenting it as current.
How it knows
A review can only reach as far as the graph behind it. Every other architecture map is a snapshot someone took once. This one is a loop: read the source of truth, propose the difference, wait for you, and admit when it has aged.
package.json, composer.json, go.mod, requirements.txt and pyproject.toml, fetched through the GitHub API. A manifest that will not parse proposes nothing rather than failing the whole system.
A dependency is proposed where one repository declares a name another publishes itself under. Every proposal names the manifest it came from, so you can check it by opening one file.
Proposals arrive pending and stay pending. Nothing here approves itself. Send persist: false first if you want to see the proposal without touching the graph at all.
A part believed out of date is marked stale rather than deleted. The record says it is unsure instead of going quietly wrong, which is the failure every architecture diagram has.
Evidence, not assertion
A relationship you cannot check is a rumour. Each one carries where it came from, how sure it is, and whether anyone has signed it off.
billing-api depends_on shared-auth pending
A bare name is not proof the dependency resolves to you. A public registry can carry the same name, which is how dependency confusion works, so an unowned name is proposed with lower confidence rather than asserted.
Bounded on purpose
A traversal returns a subgraph you can inspect or give to a model. It tells you when it had to stop rather than quietly returning half a graph.
| Field | Default | Range |
|---|---|---|
| depth | 2 | 1 to 3 |
| direction | both | outbound, inbound, both |
| minimum_confidence | 0.0 | 0 to 1 |
| include_stale | false | on or off |
| entity_limit | 50 | up to 50 |
| relationship_limit | 100 | up to 100 |
Read the graph directly with /api/topology/search and /api/topology/traverse, or let an agent pull the same subgraph through a context pack over MCP.
Why not a catalog
Developer portals ask a person to register each service and then trust the entry forever. The entry does not rot loudly. It just stops matching the code, and nobody finds out until an incident.
Questions
What it reads, how far it goes, and what it does when it cannot get there.
What Systems makes possible. It is a review that does not stop at the repository the pull request was opened in. It starts from the changed files, follows the connections in your system to the services, queues and datastores on the other end, and reads the code there. A normal review sees one diff. This one sees what the diff reaches.
Yes. Multi-repo code review, cross-repo review and polyrepo review all name the same problem: the change is in one repository and the consequence is in another. We say cross-repository review because the reach is the point, not how many repositories you happen to have.
Reviewing each one separately gives you a verdict per repository and nobody looking at what runs between them. That is where the breakages are: one side changed a contract the other side still expects. A cross-repository review reads both sides in one pass, and quotes the code it read on the far side with the repository and revision it came from.
It reads your code and works out what belongs together. Some joins are obvious, like one repository depending on another. Others only the code implies. You can add more custom connections and SourceAnt shows you suggestions after looking at your system.
Yes. A monorepo counts as one repository, so a change inside it is already reviewed against the rest of it. Systems matter more in a multi-repo or polyrepo setup, where the other side of a change sits in a different repository. They also help a monorepo that talks to something outside its own tree, such as a service, a queue or a datastore. You can add those as parts even though they have no code to read.
No. The review crosses whether the link is approved or not. Approval changes how it may talk about it. An approved link is stated as fact, with where the change could break the other side. A pending one is raised as a question, and carries no suggestion.
It is named in the review, with the reason. It is never skipped quietly. A reviewer that silently skips half your system looks the same as one that read everything and found nothing. The usual causes: the repository was never read, it is connected but not in the same system, or the app is not installed on it.
A sibling repository is read at the revision it was last indexed, because a pull request pins only its own. Where that revision is old, the review says so rather than presenting it as current.
Setting it up is covered step by step in the cross-repository review guide.
Graph snapshots are portable, streamed, and validated on the way in, and an interrupted write is recovered rather than left half applied.
Over MCP the scope is the authenticated principal. Over HTTP it is a workspace claim on the token, and a token without one is refused.
A part is whatever your architecture calls a part: a service, a queue, a datastore, a job. SourceAnt does not impose a kind list on you.
Point it at repositories you already have, approve the first proposal, then open a change on one of them and see what the review reaches on the other.