Multi-repository workspace support / system-level code graph

[devopsInterviews]

Area

gitnexus (CLI / core / indexing / MCP server)

Problem or opportunity

The problem

A lot of companies do not work with one single monorepo. Instead, they have many separate repositories that together form one product, platform, or business domain.

For example:

workspace/
├── frontend-app/
├── users-service/
├── billing-service/
├── notifications-service/
├── shared-auth-library/
├── deployment-configs/
└── test-automation/

Each folder may be a separate Git repository, but from the product/system point of view they are one connected platform.

Today, GitNexus can help analyze and understand a repository through its code graph, files, classes, functions, dependencies, and relationships. But in many engineering teams, the hardest part is not only understanding one repository. The hardest part is understanding how multiple repositories connect to each other.

Teams often need to answer questions like:

Which repository provides this API?
Which other repositories consume it?
Which frontend calls which backend service?
Which service publishes or consumes a queue/topic?
Which repo owns the database/table used by this flow?
If I change this endpoint, what other services may be affected?
Which tests should I run when this feature changes?
Which deployment config routes traffic to this service?
Which documentation or feature description explains this flow?

This is especially important in microservice environments, systems with many small repositories, shared libraries, multiple frontends, infrastructure repositories, and dedicated test automation repositories.

Proposed solution

It would be amazing if GitNexus could support a workspace mode that analyzes multiple separate repositories together and builds one connected system-level graph.

Something like:

gitnexus scan --workspace /path/to/workspace

Or:

gitnexus scan --workspace workspace.yaml

Example workspace.yaml:

workspace:
name: company-platform

repositories:

• name: frontend-app
  path: ./frontend-app
  type: frontend

• name: users-service
  path: ./users-service
  type: backend

• name: billing-service
  path: ./billing-service
  type: backend

• name: notifications-service
  path: ./notifications-service
  type: backend

• name: shared-auth-library
  path: ./shared-auth-library
  type: library

• name: deployment-configs
  path: ./deployment-configs
  type: infra

• name: test-automation
  path: ./test-automation
  type: tests

The output could still be a knowledge graph, but with repository and service boundaries preserved.

What the workspace graph could include

In addition to the current file/function/class/module/dependency nodes, the workspace graph could add higher-level system nodes such as:

Repository
Service
Application
API endpoint
API consumer
Queue/topic
Database/table
Shared package/library
Kubernetes service / deployment / ingress
Docker Compose service
Helm chart / values reference
CI/CD pipeline
Documentation or feature document
Test plan / test suite

And cross-repository edges such as:

REPOSITORY_CONTAINS_SERVICE
SERVICE_EXPOSES_API
SERVICE_CALLS_API
SERVICE_PUBLISHES_TOPIC
SERVICE_CONSUMES_TOPIC
SERVICE_READS_TABLE
SERVICE_WRITES_TABLE
SERVICE_DEPENDS_ON_PACKAGE
FRONTEND_CALLS_BACKEND
DEPLOYMENT_ROUTES_TO_SERVICE
CONFIG_REFERENCES_SERVICE
TEST_COVERS_SERVICE_OR_API
DOC_DESCRIBES_SERVICE_OR_FLOW

This would allow GitNexus to represent not only how code is structured inside one repository, but also how a real product is connected across repositories.

Signals that could be used

Cross-repository links could be detected from common real-world sources, for example:

HTTP route handlers
HTTP clients
OpenAPI / Swagger files
gRPC / protobuf definitions
Kafka / RabbitMQ / NATS topic names
package manifests such as package.json, pom.xml, pyproject.toml, go.mod, etc.
Kubernetes manifests
Helm charts and values files
Docker Compose files
Terraform or other infrastructure files
environment variables and service URLs
CI/CD files
documentation that mentions services, APIs, flows, or features
test files that call APIs or reference services

Even if the first version only supports a few of these sources, it would already be very useful.

Desired user experience

In the graph UI, API, or MCP/query interface, it would be very useful to have:

repositories grouped as part of one workspace
services shown as first-class nodes
clear edges between services and repositories
ability to click an API and see provider + consumers
ability to filter by repo, service, API, queue/topic, database, deployment, or test
ability to see evidence for each connection, such as file path, function, line number, config reference, or manifest reference
ability to ask questions across the whole workspace, not only one repository

Example questions:

Which repositories are involved in the user update flow?

Which services call users-service?

If I change POST /users/{id}, what other repositories may be affected?

Which test suites should be considered for this API change?

Which frontend screens call billing-service?

Which services publish or consume the user.updated event?

Which database tables are touched by this flow?

Which deployment config routes traffic to this service?
Suggested MVP

I know this is probably a large feature, so even a small first version would be valuable.

A possible MVP could be:

Accept a workspace folder or workspace.yaml containing multiple repository paths.
Run the current GitNexus analysis per repository.
Preserve repository names and boundaries in the graph.
Add Repository and Service nodes.
Detect simple cross-repository links from:
package dependencies
HTTP endpoints and HTTP clients
OpenAPI files
Kubernetes / Helm service names
Show cross-repository edges in the graph.
Include cross-repository context in the query/chat/MCP interface.
Add evidence for every cross-repository edge where possible.

Even this would already help teams understand how their real system fits together.

Why this would help many teams

Many engineering teams today work across multiple repositories. Developers often need to change code in one service while understanding the impact on another service, frontend, shared library, deployment config, or test automation repo.

This would be useful for:

onboarding new developers
understanding legacy systems
planning refactors
reviewing pull requests
finding impacted services before changing an API
generating better test plans
helping AI coding assistants understand the real system, not just one repo
reducing the time spent manually searching across many repositories
helping QA understand what should be tested
helping team leads understand ownership and dependencies

GitNexus already helps answer:

How does this repository fit together?

A multi-repository workspace mode would help answer:

How does this whole product or platform fit together?

Alternatives considered

No response

Acceptance criteria

No response

Constraints

No response

Contribution

• I am willing to open a PR for this (may need design discussion first).

[magyargergo]

Thanks for raising this. This is a very valid use case, especially for teams working across multiple smaller repositories rather than one monorepo.

We partially support this today through the existing Groups feature. Groups allow separately indexed repositories to be connected under one logical group, queried together, and used for cross-repo impact analysis. The current implementation already covers part of the requested MVP, including cross-repo querying, cross-repo impact, HTTP route links, package/shared-library dependency detection, gRPC/Thrift/topic detection, manual links through group configuration, and MCP access to grouped repositories.

That said, I would not consider this feature fully implemented yet.

The feature request goes beyond grouped repositories and describes a more complete workspace/system-level graph. That would include a cleaner scan --workspace style UX, first-class Repository/Service/Application/Infra/Test/Docs nodes, richer edge types such as deployment routing, test coverage, documentation relationships, OpenAPI/Kubernetes/Helm/Terraform signal extraction, and a dedicated workspace-level graph/UI experience.

So I think the right way to frame this is:

The MVP is mostly covered by Groups, but the broader workspace/system graph vision remains open as an enhancement.

I would suggest we keep this issue open and use it to track the next layer above Groups: improving the workspace UX, adding richer system-level nodes/edges, expanding infra/config/test/documentation signal extraction, and exposing this more clearly in the UI and MCP/query surfaces.