Cross-repo intelligence

Workspaces unlock three classes of insight that simply don't exist in single-repo mode. All three are pure analysis — no extra LLM calls — and they're refreshed on every workspace update.

Co-change pairs

When backend/api/routes.py and frontend/src/api/client.ts always change together, repowise records that as a high-strength co-change pair. There's no import edge between them, but the git history is unambiguous: they're coupled.

The result lives in .repowise-workspace/cross_repo_edges.json and surfaces in two places:

• Workspace dashboard — /w/<id>/co-changes, ranked by strength.
• get_context and get_risk MCP tools — when you query a file, its cross-repo co-change partners come back alongside its in-repo ones.

API contract extraction

Repowise scans every workspace repo for:

• HTTP route handlers — Express, FastAPI, Spring, ASP.NET, Laravel, Gin / Echo / Chi (Go).
• gRPC service definitions — .proto files (services + RPCs).
• Message topics — Kafka, RabbitMQ, Redis pub/sub, NATS publishers and subscribers.

It then matches providers with consumers across repos. If the backend exposes POST /api/users and the frontend calls fetch('/api/users', { method: 'POST' }), that's one contract link.

Visible at /w/<id>/contracts, filterable by type and repo.

Package dependency mapping

Repowise reads each repo's manifest:

• package.json (npm / pnpm / yarn workspaces)
• pyproject.toml (Poetry, PEP 621)
• go.mod
• pom.xml (Maven)
• Cargo.toml

When one repo depends on another as a published or workspace package, it shows up as an explicit dependency edge — and changes to the upstream package surface as risk signals on consumers.

Why it matters

The most expensive bugs come from implicit coupling — the kind where a refactor in one service silently breaks another because the connection lived in commit history rather than code. Repowise makes that connection explicit: