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. Detection is a purely temporal, same-author signal — commits from the same author across repos within a 24-hour window count as a pair, with strength decaying over a 180-day time constant so recent co-changes count more than old ones.

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, Laravel, Go (gin/echo/chi), ASP.NET (attribute + minimal API), Rust (Axum). Consumers: fetch/axios (JS/TS), requests/httpx (Python), HttpClient/UnityWebRequest/Best.HTTP (C#), reqwest (Rust).
• gRPC service definitions — .proto files (services + RPCs), plus per-language dialects (Go, Java, Python, C#, TypeScript, NestJS).
• Data / DB contracts — table providers (DDL, ORM entities via SQLAlchemy/Django, JPA, EF Core, ActiveRecord, or Eloquent) paired with table consumers (SQL string literals in app code, matched heuristically). Renders as a db edge.
• Message topics — Kafka, RabbitMQ, 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.

Test files are excluded from extraction: directories named tests/, __tests__/, or __mocks__/ are skipped by name, and files matching test_*.py, *_test.py, *_test.go, *.test.*, *.spec.*, *.e2e.*, or conftest.py are always excluded regardless of directory.

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

Each contract type can be toggled off via the contracts: block in .repowise-workspace.yaml:

contracts:
  detect_http: true
  detect_grpc: true
  detect_topics: true
  detect_data: true

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:

Where this goes next

Co-changes, contracts, and package deps are each a flat list. Repowise folds all three into one normalized system graph, the structure every other cross-repo view reads:

• System graph & map renders services and their typed relationships, with extraction diagnostics that explain why a contract link did or didn't form.
• Cross-repo blast radius walks the graph to show what breaks downstream when you change a service.
• Breaking-change guard diffs provider contracts on every update and flags the consumers each incompatible change endangers.
• Architecture conformance checks the live graph against the dependency rules you declare, and detects cycles.
• Architecture metrics give propagation cost, the cyclic core, per-service roles, and a 1-10 score.