Add deterministic cross-repository dependency graphing for Go workspaces

[vvenegasv]

What problem does this solve?

What Problem Does This Solve?

cross-repo-intelligence currently links separately indexed projects when it can match service-level signals such as routes, channels, HTTP calls, async calls, gRPC, GraphQL, or tRPC. However, it does not infer code-level dependencies between repositories that are part of the same Go workspace.

This is a problem for workspaces made of many sibling Git repositories, each with its own go.mod, tied together by a parent or ancestor go.work. In these setups, the real dependency signal is often a Go import:

import "bitbucket.org/org/lib-b/pkg/client"

combined with another repository's module declaration:

module bitbucket.org/org/lib-b

Today, if these repositories are indexed as separate projects, the graph may show zero cross-repo edges even though the code clearly depends on another local workspace module. Re-running cross-repo-intelligence with target_projects: ["*"] does not help if no route/channel/RPC literals are available to match.

The result is that valid Go workspace dependencies remain invisible unless the whole workspace is indexed as one large project, which loses repository boundaries and produces intra-project IMPORTS instead of explicit cross-project relationships.

Proposed solution

Proposed Solution

Add deterministic Go workspace/module dependency inference to the cross-repo indexing flow.

At a high level, the tool should:

1. Keep indexing each Git repository as its own project.
2. During a cross-repo dependency pass, discover the relevant go.work file from each indexed project root, following Go's GOWORK=auto behavior: search from the project root upward through ancestor directories.
3. Optionally allow callers to provide an explicit go_work_path override for unusual layouts.
4. Parse go.work use directives to find local module directories.
5. Read each referenced module's go.mod and extract its module path.
6. Build a mapping from Go module path to indexed project.
7. Use actual extracted Go imports as evidence.
8. If an import path matches another indexed module path by prefix, create a cross-project dependency edge.

Example:

app-a imports bitbucket.org/org/lib-b/pkg/client
lib-b declares module bitbucket.org/org/lib-b

The graph should create a relationship such as:

app-a -> lib-b

Potential edge types could be:

CROSS_IMPORTS
CROSS_DEPENDS_ON

or a single cross-repo edge with metadata:

{
  "language": "go",
  "module": "bitbucket.org/org/lib-b",
  "import": "bitbucket.org/org/lib-b/pkg/client",
  "evidence": "source_import",
  "go_work": "/workspace/go.work"
}

Important: go.mod require should not create a strong dependency edge by itself. It should be used as supporting module metadata, not as proof of an active dependency. The edge should be based on actual imports found in source code, to avoid graphing stale or unused dependencies.

Alternatives considered

No response

Confirmations

• I searched existing issues and this is not a duplicate.

[DeusData]

Thanks for the detailed proposal. I have triaged this as a 0.9.2-rc enhancement because it is useful cross-repo graph work, but it needs design around deterministic go.work/go.mod module-to-project resolution before we add cross-repository dependency edges. The important constraint is avoiding speculative links when multiple local modules can match the same import prefix.