feat: introduce global dependency graph for cross-language context resolution

[Tanmay-008]

Problem

Currently, Clawpatch uses separate mappers for each language (Node.js, Rust, Python, Go, etc.).

Each mapper can discover features and dependencies within its own language, but it has no knowledge of files written in other languages.

Because of this, Clawpatch cannot understand relationships that span across different services or languages.

---

Why This Matters

Modern monorepos are usually built with multiple languages.

For example:

Frontend (Next.js)
        │
        │ fetch("/api/login")
        ▼
Backend (Rust)

Although the frontend and backend are part of the same feature, Clawpatch currently treats them as two completely separate pieces of code.

This means AI agents only receive part of the picture instead of the complete workflow.

---

The Core Problem

Suppose we have the following files.

Frontend

// frontend/src/app.ts

await fetch("/api/login");

Backend

#[get("/api/login")]
async fn login() {
    ...
}

Current behavior:

• The Node mapper creates a Feature Seed for app.ts, but it does not include main.rs.
• The Rust mapper creates a Feature Seed for main.rs, but it does not include app.ts.

As a result, neither Feature Seed contains the complete context.

This Cross-Language Blindness makes it difficult for AI providers to perform:

• Full-stack bug fixes
• Cross-language refactoring
• End-to-end code reviews
• Repository-wide reasoning

---

Evidence

A failing test has been added to demonstrate this limitation.

src/cross-language.test.ts

The test creates a mock monorepo where:

• A Node.js frontend calls a Rust backend.
• The backend Feature Seed is expected to include the frontend file inside contextFiles.

Current result:

AssertionError:
expected undefined to be defined

This confirms that Clawpatch cannot currently discover cross-language relationships.

---

Why This Matters

To effectively support enterprise-scale monorepos, AI agents need visibility across the entire application—not just a single language.

Adding a Global Dependency Graph would eliminate cross-language blindness and enable Clawpatch to generate complete, repository-aware Feature Seeds.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 11, 2026, 12:18 AM ET / 04:18 UTC.

Summary
Current main explicitly documents the absence of import-graph expansion and still aggregates independent language-mapper outputs. This is a large new capability, not a broken existing contract, so it needs a maintainer decision on scope and matching policy. Likely related people: Josh Boys (recent mapper contributor, medium confidence) and Peter Steinberger (recent mapping-orchestrator contributor, low confidence).

Reproducibility: not applicable. as a bug reproduction: current documentation confirms a missing capability, while this issue supplies no concrete current repository fixture or executable failing test.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Share version, platform, channel/provider, and relevant config details.

Maintainer decision needed

Question	Recommendation
Should Clawpatch add a bounded cross-language relationship stage, and if so, which first relationship type and false-positive policy should it support?	Sponsor a narrow graph prototype: Specify one link type such as literal frontend-to-backend HTTP routes, require bidirectional fixtures and caps, then evaluate before generalizing.

Why: Current behavior intentionally documents the absence of import-graph expansion; choosing endpoint matching semantics, confidence thresholds, and context caps is a product and safety contract rather than a mechanical mapper repair.

Next step
A maintainer must select the supported first relationship contract before this work can be safely scoped.

Review details

Best possible solution:

Define and validate one conservative cross-service link type with explicit confidence rules, context caps, and diagnostics before considering a general global dependency graph.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a bug reproduction: current documentation confirms a missing capability, while this issue supplies no concrete current repository fixture or executable failing test.

Is this the best way to solve the issue?

Unclear: a global graph is not yet shown to be the narrowest maintainable solution; a maintainer should first choose one conservative cross-service relationship contract.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A repository-wide graph needs an explicit relationship contract to avoid false endpoint matches, unbounded context expansion, and unstable feature-record output.

Codex review notes: model internal, reasoning high; reviewed against ab5ded8beeb5.

Label changes

Label justifications:

• P3: This is a speculative large feature proposal without an established broken-behavior contract.

Evidence reviewed

What I checked:

• Documented current limitation: The feature-mapping guide explicitly lists no import-graph expansion beyond nearby tests as a known gap, so cross-language endpoint resolution is not an established behavior contract. (docs/feature-mapping.md:196, ab5ded8beeb5)
• Independent mapper aggregation: Current mapping runs each registered mapper independently, flattens their seeds, and deduplicates them; it has no cross-language relationship-resolution stage. (src/mapper.ts:315, ab5ded8beeb5)
• Rust context boundary: The Rust mapper derives context from Cargo manifests, local Rust modules, and associated tests, with no input for frontend HTTP-call matching. (src/mappers/rust.ts:25, ab5ded8beeb5)
• Feature-history provenance: The latest locally available Rust-mapper commit added source-group slices, identifying a recent contributor to the affected surface. (src/mappers/rust.ts:1, ee535cfac5ab)
• Mapping-orchestrator provenance: Local blame attributes the current orchestrator block to the v0.7.2 release commit; older file history could not be hydrated because the partial clone could not reach its remote. (src/mapper.ts:303, 3c2a1a4e2d04)
• Vision fit: VISION.md defines bounded feature mapping for auditable review and repair, but does not commit to a repository-wide semantic graph or its matching policy. (VISION.md:3, ab5ded8beeb5)

Likely related people:

• Josh Boys: Authored the latest locally available Rust-mapper change on the affected mapping surface. (role: recent mapper contributor; confidence: medium; commits: ee535cfac5ab; files: src/mappers/rust.ts, docs/feature-mapping.md)
• Peter Steinberger: Local blame attributes the current mapper-orchestrator block to the v0.7.2 release commit; earlier ownership is unavailable in this partial checkout. (role: recent mapping-orchestrator contributor; confidence: low; commits: 3c2a1a4e2d04; files: src/mapper.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.