[group] Cross-repo impact analysis via repository groups

[ivkond]

Summary

Depends on: #625 (intra-repo service tracking). This PR will be rebased once #625 merges.

Adds cross-repository impact analysis on top of the group infrastructure from #625. Enables blast radius analysis that traces through contract links (HTTP routes, gRPC, Kafka topics) across repository boundaries.

What changed:

• cross-impact.ts — cross-repo blast radius traversal via contract registry
• manifest-extractor.ts — manifest-declared cross-links from group.yaml
• groupImpact() method on GroupService
• group impact CLI command with --target, --repo, --direction, --cross-depth
• group_impact MCP tool
• RFC design document (docs/specs/2026-03-31-cross-index-impact-design.md)

Why:
Completes the cross-repo analysis story started in #625. With intra-repo service tracking proven, this PR adds the virtual graph layer that connects repositories via their contract interfaces — enabling questions like "if I change this function, which other repos are affected?"

How to verify:

cd gitnexus
npx tsc --noEmit
npm run test:unit
npm run test:integration
# Cross-repo impact test:
npx vitest run test/integration/group/group-impact.test.ts

Risk / rollback:

• Adds cross-impact.ts and manifest-extractor.ts — new files, no existing code modified
• Enhances sync.ts and service.ts with manifest extraction path (additive)
• Multi-hop traversal intentionally capped at depth 1 (safe default)
• Rollback: revert the PR

Test plan

• Unit tests — cross-impact (risk scoring, fan-out, subgroup filtering)
• Unit tests — manifest-extractor (provider/consumer contracts, cross-links)
• Integration test — group-impact (local → cross-repo traversal)
• Full regression: all existing tests pass

🤖 Generated with Claude Code

[vercel]

@ivkond is attempting to deploy a commit to the NexusCore Team on Vercel.

A member of the Team first needs to authorize it.

[ivkond]

Hi @abhigyanpatwari! This is a proposal PR for cross-repository impact analysis (#256, #306, #77). I'd appreciate your feedback on:

• Whether this direction aligns with your vision for GitNexus
• The architecture choice (hybrid lazy virtual graph vs unified super-graph)
• Any concerns about the scope or implementation approach

This is a demo/proof-of-concept — BM25/embedding matching, gRPC/topic extractors, and multi-hop traversal are intentionally deferred. Happy to iterate based on your feedback.

[github-actions]

CI Report

✅ All checks passed

Pipeline Status

Stage	Status	Details
✅ Typecheck	success	tsc --noEmit
✅ Tests	success	unit tests, 3 platforms
✅ E2E	success	gitnexus-web changes only

Test Results

Tests	Passed	Failed	Skipped	Duration
6119	6022	0	97	237s

✅ All 6022 tests passed

97 test(s) skipped — expand for details

• Swift MethodExtractor > isTypeDeclaration > recognizes class_declaration
• Swift MethodExtractor > isTypeDeclaration > recognizes protocol_declaration
• Swift MethodExtractor > isTypeDeclaration > rejects import_declaration
• Swift MethodExtractor > visibility > extracts public method
• Swift MethodExtractor > visibility > extracts private method
• Swift MethodExtractor > visibility > defaults to internal when no modifier
• Swift MethodExtractor > protocol methods > marks protocol method as abstract
• Swift MethodExtractor > static and class methods > detects static func as isStatic
• Swift MethodExtractor > static and class methods > detects class func as isStatic
• Swift MethodExtractor > parameters > extracts parameters with types and default values
• Swift MethodExtractor > return type > extracts return type from -> annotation
• Swift MethodExtractor > annotations > extracts @objc attribute
• Swift MethodExtractor > isFinal > detects final func
• Swift MethodExtractor > isFinal > is false when not final
• Swift MethodExtractor > isAsync > detects async func
• Swift MethodExtractor > isOverride > detects override method
• buildTypeEnv > constructor inference (Tier 1 fallback) > lookupClassByName regression coverage > Swift lookupClassByName regression coverage > Swift cross-file constructor inference uses lookupClassByName
• buildTypeEnv > constructor inference (Tier 1 fallback) > lookupClassByName regression coverage > Swift lookupClassByName regression coverage > Swift explicit init inference uses lookupClassByName
• buildTypeEnv > constructor inference (Tier 1 fallback) > lookupClassByName regression coverage > Swift lookupClassByName regression coverage > Swift cross-file constructor inference does not bind plain functions
• buildTypeEnv > known limitations (documented skip tests) > Ruby block parameter: users.each { |user| } — closure param inference, different feature
• Swift constructor-inferred type resolution > detects User and Repo classes, both with save methods
• Swift constructor-inferred type resolution > resolves user.save() to Models/User.swift via constructor-inferred type
• Swift constructor-inferred type resolution > resolves repo.save() to Models/Repo.swift via constructor-inferred type
• Swift constructor-inferred type resolution > emits exactly 2 save() CALLS edges (one per receiver type)
• Swift self resolution > detects User and Repo classes, each with a save function
• Swift self resolution > resolves self.save() inside User.process to User.save, not Repo.save
• Swift parent resolution > detects BaseModel and User classes plus Serializable protocol
• Swift parent resolution > emits EXTENDS edge: User → BaseModel
• Swift parent resolution > emits IMPLEMENTS edge: User → Serializable (protocol conformance)
• Swift cross-file User.init() inference > resolves user.save() via User.init(name:) inference
• Swift cross-file User.init() inference > resolves user.greet() via User.init(name:) inference
• Swift return type inference > detects User class and getUser function
• Swift return type inference > detects save function on User (Swift class methods are Function nodes)
• Swift return type inference > resolves user.save() to User#save via return type of getUser() -> User
• Swift return-type inference via function return type > resolves user.save() to User#save via return type of getUser()
• Swift return-type inference via function return type > user.save() does NOT resolve to Repo#save
• Swift return-type inference via function return type > resolves repo.save() to Repo#save via return type of getRepo()
• Swift implicit imports (cross-file visibility) > detects UserService class in Models.swift
• Swift implicit imports (cross-file visibility) > resolves UserService() constructor call across files (no explicit import)
• Swift implicit imports (cross-file visibility) > resolves service.fetchUser() member call across files
• Swift implicit imports (cross-file visibility) > creates IMPORTS edges between files in the same module
• Swift extension deduplication > detects Product class
• Swift extension deduplication > resolves Product() constructor despite extension creating duplicate class node
• Swift extension deduplication > resolves product.save() to Product.swift (primary definition)
• Swift constructor call fallback (no new keyword) > resolves OCRService() as constructor call across files
• Swift constructor call fallback (no new keyword) > resolves ocr.recognize() member call via constructor-inferred type
• Swift export visibility (internal vs private) > resolves PublicService() constructor across files
• Swift export visibility (internal vs private) > resolves internalHelper() across files (internal = module-scoped)
• Swift if let / guard let binding resolution > detects User and Repo classes
• Swift if let / guard let binding resolution > resolves user.save() inside if-let to User#save
• Swift if let / guard let binding resolution > resolves repo.save() inside guard-let to Repo#save
• Swift if let / guard let binding resolution > user.save() in if-let does NOT resolve to Repo#save
• Swift await / try expression unwrapping > resolves user.save() via await fetchUser() return type
• Swift await / try expression unwrapping > resolves repo.save() via try parseRepo() return type
• Swift await / try expression unwrapping > detects fetchUser and parseRepo as functions
• Swift for-in loop element type inference > detects User and Repo classes
• Swift for-in loop element type inference > creates implicit import edges between files
• Swift field-type resolution > detects classes and their properties
• Swift field-type resolution > emits HAS_PROPERTY edges from class to field
• Swift field-type resolution > resolves field-chain call user.address.save() → Address#save
• Swift field-type resolution > emits ACCESSES edges for field reads in chains
• Swift field-type resolution > populates field metadata (visibility, declaredType) on Property nodes
• Swift call-result binding > resolves call-result-bound method call user.save() → User#save
• Swift call-result binding > getUser() is present as a defined function
• Swift call-result binding > emits processUser -> getUser CALLS edge for let-assigned free function call
• Swift method enrichment > detects Animal protocol and Dog class
• Swift method enrichment > emits IMPLEMENTS edge Dog -> Animal
• Swift method enrichment > emits HAS_METHOD edges for Dog methods
• Swift method enrichment > marks protocol Animal.speak as isAbstract
• Swift method enrichment > marks Dog.speak as NOT isAbstract
• Swift method enrichment > marks breathe as isFinal
• Swift method enrichment > marks classify as isStatic
• Swift method enrichment > captures @objc annotation on breathe
• Swift method enrichment > populates parameterTypes for classify(_ name: String)
• Swift method enrichment > records parameterCount for classify
• Swift method enrichment > records returnType for speak
• Swift method enrichment > resolves dog.speak() CALLS edge
• Swift method enrichment > resolves Dog.classify("dog") CALLS edge
• Swift abstract dispatch > detects Repository protocol and SqlRepository class
• Swift abstract dispatch > emits IMPLEMENTS edge SqlRepository -> Repository
• Swift abstract dispatch > emits HAS_METHOD edges for Repository.find and Repository.save
• Swift abstract dispatch > emits HAS_METHOD edges for SqlRepository.find and SqlRepository.save
• Swift abstract dispatch > marks base Repository.find as isAbstract
• Swift abstract dispatch > marks base Repository.save as isAbstract
• Swift abstract dispatch > marks concrete SqlRepository.find as NOT isAbstract
• Swift abstract dispatch > resolves repo.find(id: 42) CALLS edge
• Swift abstract dispatch > resolves repo.save(entity: user) CALLS edge
• Swift abstract dispatch > populates parameterTypes for Repository.find
• Swift abstract dispatch > populates parameterTypes for Repository.save
• Swift abstract dispatch > records returnType for SqlRepository.find
• Swift abstract dispatch > emits METHOD_IMPLEMENTS edges from SqlRepository methods → Repository protocol methods
• Swift overloaded method disambiguation > detects 2 distinct find Method nodes on SqlRepository
• Swift overloaded method disambiguation > emits METHOD_IMPLEMENTS edges for both find overloads
• Swift overloaded method disambiguation > emits METHOD_IMPLEMENTS edge for save
• Swift overloaded method disambiguation > emits exactly 3 METHOD_IMPLEMENTS edges total
• Swift Child extends Parent — inherited method resolution (SM-9) > detects Parent and Child classes
• Swift Child extends Parent — inherited method resolution (SM-9) > resolves c.parentMethod() to Parent.parentMethod via first-wins MRO walk

Code Coverage

Tests

Metric	Coverage	Covered	Base	Delta	Status
Statements	73.13%	16519/22588	72.2%	📈 +0.9	🟢 ██████████████░░░░░░
Branches	61.94%	10688/17254	61.29%	📈 +0.6	🟢 ████████████░░░░░░░░
Functions	77.92%	1525/1957	76.99%	📈 +0.9	🟢 ███████████████░░░░░
Lines	75.35%	15009/19919	74.37%	📈 +1.0	🟢 ███████████████░░░░░

---

_{📋 View full run · Generated by CI}

[xkonjin]

Code Review: Cross-Index Impact Groups

Overall: Impressive RFC-to-implementation PR. The design document is thorough and the implementation appears solid. This is a significant feature that addresses real gaps in multi-repo analysis.

Issues

1. Graph schema gaps not addressed in this PR (medium risk)
The RFC acknowledges several schema gaps that block full functionality:

• No Route node label exists
• No HANDLES_ROUTE or FETCHES relation types
• Route data is ephemeral (reduced to CALLS edges with reason)
• .proto files not a supported language
• impact tool resolves symbols by name with LIMIT 1, not by UID

The PR implements the group infrastructure but these gaps mean the cross-link extraction for HTTP routes, gRPC, and topics will not work as designed. Consider:

• Adding prerequisite schema changes first
• Or reducing the scope to shared_lib and manifest contract types initially
• Documenting which contract types are actually functional

2. Contract ID format could collide (low risk)
The format <type>::<discriminator> uses :: as a delimiter, which appears in:

• gRPC package names: grpc::hr.UserService/GetUser
• HTTP paths with empty segments (edge case)

Consider using a less common delimiter or proper escaping. URL-encoding the discriminator could prevent collisions.

3. BM25 threshold hardcoded at 0.7 (minor)
The matching cascade tuning in group.yaml has a BM25 threshold of 0.7. This seems arbitrary — was this tuned on real data? Consider:

• Making the default data-driven
• Or documenting how the threshold was chosen
• Providing a calibration tool

4. Embedding vectors stored separately (question)
embeddings.bin is stored alongside contracts.json. Is this:

• Generated fresh on each group sync?
• Or incrementally updated?
• What happens if the embedding model changes version?

The doc mentions no automatic migration — this could leave stale vectors with incompatible dimensions.

5. Test coverage looks good
The 31 new test files covering config parsing, contract extraction, matching, and sync are comprehensive. Nice work.

Minor

• The RFC mentions group_impact and group_contracts tools, but I do not see them added to the MCP tools in the diff. Are they implemented?
• Consider adding a group validate command to check group.yaml syntax before sync.

Verdict

Approve with suggestions. The design is sound and the implementation is solid. The main concern is the gap between designed capability (all contract types) and actual capability (limited by schema). Documenting this honestly would help users understand what works today vs what is planned.

[ivkond]

Thanks for the thorough review! Addressing each point:

1. Graph schema gaps

The RFC "Prerequisites and Current State" section describes the codebase as of the RFC writing date, not the current state. The implementation plan (docs/plans/2026-03-31-cross-index-impact-plan.md) documents the divergences explicitly:

RFC claim	Actual state in codebase
No Route node label	Route exists in schema.ts
No HANDLES_ROUTE/FETCHES	Present in VALID_RELATION_TYPES (13 types)
P2 prerequisite needed (4 relation types)	Already 13 types in runtime filter
impact resolves by name with LIMIT 1	impactByUid added in this PR (UID-based resolution)

The HttpRouteExtractor uses a graph-first strategy — it queries Route/HANDLES_ROUTE/FETCHES nodes first, and falls back to source-scan only when graph data is absent.

gRPC, topic, and shared lib extractors are intentionally out of scope for Demo PR (documented in PR description).

2. Contract ID :: delimiter

By design. The :: delimiter separates the type prefix (http, grpc, topic, lib) from the discriminator. It does not appear inside real API paths, gRPC service names, or topic names in practice. URL-encoding would complicate readability of contracts.json and debug output without solving a real collision scenario.

3. BM25 threshold / 4. Embedding vectors

Both are out of scope for this Demo PR — the matching cascade is exact-match only. BM25 and embedding matching are designed in the spec but not implemented. The 0.7 default is configurable via group.yaml matching.bm25_threshold and will be tuned when BM25 is added.

Minor: MCP tools

All 6 group tools are in the diff — tools.ts lines 381-477: group_list, group_sync, group_contracts, group_impact, group_query, group_status. The tool count assertion is updated from 11 to 17 in tools.test.ts.

Minor: group validate

Good suggestion. parseGroupConfig already validates schema, required fields, link references, and roles — so group validate would be a thin CLI wrapper. Worth adding as a follow-up.

[ivkond]

@claude ultra-think while identifying cross-indexing impact analysis gaps. Perfom this analysis on this pull request and verify those findings. Act as a senior compiler font-end engineer and expert in static analysis tools and review this change from that perpective and review the architectural fit. Also check out previous comments and reason with their requests.

[abhigyanpatwari]

@ivkond This is a great idea. I had been implementing something like this myself in the enterprise version of gitnexus. Our indexing system allows cross-repo analyses too but will need a bridge ( virtual graph ). Correct approach. But I would also look at intra repo rpc, grpc, kafka, rabbitmq, api endpoints, etc tracking. Once this can be done for intra repo we can move the same logic into building the virtual graph system so multi-repo support is bulletproof.

A good test would be to see if microservice based repos can be indexed well. If that is done cross repo becomes easy

[ivkond]

@abhigyanpatwari Thanks for the direction! I've started implementing intra-repo service communication tracking on a separate branch (stacked on this PR):

What's added (ivkond/GitNexus#1):

• ServiceBoundaryDetector — auto-detects service boundaries within monorepos via markers (package.json, go.mod, Dockerfile, pom.xml, Cargo.toml, etc.)
• GrpcExtractor — parses .proto files + detects Go/Java/Python/TS gRPC servers and clients (RegisterXxxServer, @GrpcService, add_XxxServicer_to_server, @GrpcMethod)
• TopicExtractor — detects Kafka, RabbitMQ, NATS producers/consumers across Java/Node/Go/Python (@KafkaListener, producer.send, channel.publish, nc.Subscribe, etc.)
• Intra-repo matching — relaxed the same-repo guard so contracts from different services within one repo can match (backward compatible — existing cross-repo matching unchanged)

Proof of concept: Fixture monorepo with 3 services (auth, orders, gateway) connected via gRPC + Kafka + HTTP routes — all cross-links are discovered automatically. 47 new tests, zero regressions (2643 unit + 2016 integration).

The service field on contracts is backward-compatible. Once this PR merges, the same extractors feed directly into the virtual graph for multi-repo support.

Next: test on a real microservice repo, add more framework patterns, then wire into cross-repo virtual graph.

[ivkond]

Update: Following your suggestion, I've split the work into two PRs:

1. [group] Intra-repo service communication tracking #625 (→ main) — Intra-repo service tracking: group infrastructure, extractors (HTTP/gRPC/Kafka/RabbitMQ/NATS), service boundary detection, intra-repo matching. Self-contained, no cross-repo deps.

2. This PR ([group] Cross-repo impact analysis via repository groups #606) — Will be rebased on top of [group] Intra-repo service communication tracking #625 once merged. Adds: cross-repo impact analysis (group_impact), manifest-declared links, virtual graph.

This way the intra-repo foundation lands first, proving that microservice monorepos index well, before cross-repo is layered on top.

[ivkond]

Update: Following your suggestion, I've split the work into two PRs:

1. [group] Intra-repo service communication tracking #626 (→ main) — Intra-repo service tracking: group infrastructure, extractors (HTTP/gRPC/Kafka/RabbitMQ/NATS), service boundary detection, intra-repo matching. Self-contained, no cross-repo deps.

2. This PR ([group] Cross-repo impact analysis via repository groups #606) — Will be rebased on top of [group] Intra-repo service communication tracking #626 once merged. Adds: cross-repo impact analysis (group_impact), manifest-declared links, virtual graph.

This way the intra-repo foundation lands first, proving that microservice monorepos index well, before cross-repo is layered on top.

(Supersedes #625 which was closed due to branch rename.)

[vercel]

Deployment failed with the following error:

The provided GitHub repository does not contain the requested branch or commit reference. Please ensure the repository is not empty.

[ivkond]

@abhigyanpatwari This PR is ready for re-review. I've addressed both items from your PR #626 review:

1. Contract storage → bridge.lbug

• Contracts and cross-links are now stored in LadybugDB (bridge.lbug) as Cypher-queryable graph nodes and edges
• group_impact Phase 2 uses direction-dependent Cypher queries instead of JS iteration
• Atomic write via temp-file-then-rename with Windows EBUSY retry
• Backward compat: automatic contracts.json fallback with deprecation warning

2. gRPC normalization mismatch

• buildProtoMap() scans .proto files to resolve ServiceName → package.Service
• Go/Java/Python/TS source scanners produce canonical grpc::pkg.Service/* IDs when proto is available
• New runWildcardMatch() handles remaining unresolved wildcards as a separate matching pass
• Confidence adjustments: reduced without proto (0.65/0.55), unchanged with proto

Tests: 239 in group module (11 new coverage tests), 5410 total in CI. Build: clean.

Note on force-push: Rebased on current main (includes PR #626) and squashed 24 intermediate commits into 3 logical units — original feature, documentation (spec + plan), implementation. The intermediate commits were iterative spec review rounds and per-task TDD commits that added noise to the history without providing bisect value.

[ivkond]

@abhigyanpatwari hi! Friendly follow-up on this PR — I’d really appreciate your feedback when you have time, especially on whether this direction and architecture fit your vision.

[abhigyanpatwari]

@claude do a deep review of it, especially focused on coverage of cross repo communication protocols. Also see that there are real world test to validate it against real multi repo and microsercice based repos.

[github-actions]

Claude finished @abhigyanpatwari's task in 2m 43s —— View job

---

Deep Review: Cross-Repo Impact Analysis — Protocol Coverage & Real-World Test Validation

Todo list:

• Post initial comment
• Read core implementation files (cross-impact.ts, grpc-extractor.ts, matching.ts, service.ts)
• Read manifest-extractor.ts and bridge-db.ts
• Review protocol extractor coverage (HTTP, gRPC, Kafka, RabbitMQ, NATS)
• Review test files for real-world coverage
• Assess real-world multi-repo / microservice test gaps
• Write comprehensive review

---

Summary

The architecture is fundamentally sound — the hybrid lazy virtual graph via bridge.lbug, direction-aware Cypher queries, and the extraction→matching→bridge pipeline are all well-designed. However, the protocol coverage has significant gaps for real-world polyglot microservice repos, and there are no true end-to-end tests against real multi-repo structures. Below is a detailed breakdown.

---

1. Protocol Coverage: What Works vs. What's Missing

HTTP (http-route-extractor.ts)

Covered providers: Spring @GetMapping/@PostMapping, Express router.get/post, Laravel Route::get, FastAPI @app.get.

Covered consumers: fetch() and axios.get/post in TS/JS.

Critical gaps:

Missing pattern	Impact
Go HTTP handlers (gin.GET, echo.GET, mux.HandleFunc, stdlib http.HandleFunc)	Any Go-based API service goes undetected as provider
NestJS @Controller/@Get/@Post decorators	NestJS is the dominant Node.js microservice framework; not covered
Python requests.get/post consumer	Python consumer side is entirely absent
Java RestTemplate.getForEntity, WebClient.get(), OkHttpClient	Java inter-service HTTP calls not tracked
Go http.Get, resty.R().Get() consumer patterns	Go consumer side absent

The fallback consumer detection source scan, lines 409–423 only scans .ts,.tsx,.js,.jsx,.vue,.svelte — Go, Python, Java, PHP consumers are never found without graph data. Fix this →

gRPC (grpc-extractor.ts)

Covered: Proto parsing (definitive), Go Register*Server/New*Client, Java @GrpcService/*ImplBase/*Grpc.newStub, Python add_*Servicer_to_server/*Stub, NestJS @GrpcMethod (server only).

Critical gap — TypeScript gRPC consumer is entirely missing:

// These are completely invisible to the extractor:
// grpc-js
const client = new proto.hr.UserService('host', credentials.createInsecure());
// NestJS @GrpcClient (consumer side)
@GrpcClient({ service: 'UserService', url: '...' })
private readonly userClient: ClientGrpc;
// NestJS ClientGrpc
const svc = this.userClient.getService<UserServiceClient>('UserService');

scanTsProviders handles @GrpcMethod only (server side). There is no scanTsConsumers. Given TypeScript/NestJS is a primary gRPC consumer framework in Node.js microservices, this is a significant real-world gap. Fix this →

Other gaps: No C# gRPC (GrpcChannel.ForAddress, new Service.ServiceClient()), no Ruby (Grpc::ClientStub), no Rust tonic patterns. These matter less than TypeScript but are worth documenting.

Proto import resolution not implemented: When a .proto uses import "other.proto" to reference types from another package, the buildProtoMap doesn't follow imports. This means services that split their types across files may get wrong or missing package names.

Topic/Messaging (topic-extractor.ts)

Covered well: Java Spring Kafka/RabbitMQ annotations, basic Node.js producer/consumer, Go sarama ConsumePartition, Python Kafka. This is the most complete extractor.

Notable gaps:

Missing	Framework	Impact
consumer.run({ eachMessage: ... })	kafkajs (most popular Node Kafka lib)	Node.js Kafka consumers won't be detected as they use run() not subscribe()
kafka.NewWriter / kafka.NewReader	segmentio/kafka-go	Second most popular Go Kafka library
sarama.NewSyncProducer / sarama.NewAsyncProducer	sarama (most popular Go Kafka)	Go Kafka producers missing
js.Publish / js.Subscribe	NATS JetStream	JetStream is the modern NATS API, largely replacing core NATS
nats.connect / nc.subscribe (Python)	nats-py	NATS Python consumer absent
Redis Pub/Sub, AWS SQS/SNS, Azure Service Bus	—	Common in enterprise microservices

The kafkajs gap is the most impactful — fix this →

---

2. Real-World Test Coverage: The Main Gap

The integration test (test/integration/group/group-impact.test.ts) is explicitly noted as "mocks localImpactFn / crossImpactFn. E2E with real graphs is a follow-up." This is the most important gap to close.

What exists today:

• Synthetic in-memory registry with hardcoded cross-links
• Single test scenario (upstream fan-out via UID match)
• Test-monorepo fixture (test/fixtures/group/test-monorepo/) with 3 service stubs — not wired to any integration test

What's needed for real multi-repo / microservice validation:

A. Fixture-based integration test against real code

The test-monorepo fixture exists but isn't exercised end-to-end. A test like:

it('discovers gRPC link from gateway → auth across service boundaries', async () => {
  // 1. Index each service directory with real indexer
  // 2. Run group sync against the fixture
  // 3. Assert bridge.lbug contains expected ContractLink
  // 4. Run group impact on a gateway function
  // 5. Assert auth service appears in cross-repo hits
});

This requires running the real extractor pipeline — but it would catch bugs that the current mocked tests cannot.

B. Known-good open-source repo test

There are popular open-source microservice demos (e.g., Google's Online Boutique, Netflix's Conductor) that have well-documented service boundaries. A test that clones a specific commit and asserts specific cross-links would give confidence that the system works on real code.

C. Confidence degradation test

No test verifies that removing a .proto file degrades confidence from 0.8 to 0.65 for Go providers. No test exercises the wildcard→method match path end-to-end.

---

3. Correctness Bugs Found

Bug 1: outOfScope always empty in Cypher path (cross-impact.ts:417)

// runGroupImpact returns:
return {
  ...
  outOfScope: [],  // ← always empty, never populated
  ...
};

The legacy runGroupImpactLegacy populates outOfScope when a matched repo falls outside the subgroup filter. The Cypher-based runGroupImpact uses a WHERE clause to filter, so matches never come back — but the caller has no way to know which repos were filtered. This is a silent information loss that affects UX when --subgroup is used. Fix this →

Bug 2: Manifest cross-links silently dropped for gRPC/lib (manifest-extractor.ts:92)

private async resolveSymbol(...): Promise<...> {
  ...
  } else {
    return null;  // ← gRPC and lib types always return null
  }

When null is returned, symbolRef = { filePath: '', name: link.contract }. In bridge-db.ts the cross-link insert query matches nodes by c.filePath = $fp AND c.symbolName = $sn with fp = ''. Since no contract node will have an empty filePath, fromRows or toRows will be empty and the edge is silently skipped (line 209: if (!fromRows.length || !toRows.length) continue). Manifest-declared gRPC cross-links produce contracts but no ContractLink edges in the bridge DB, making group_impact miss them entirely.

Bug 3: resolveProtoConflict directory proximity heuristic fails for centralized proto repos

// Matches character-by-character, not path-segment-by-segment
for (let i = 0; i < min; i++) {
  if (sourceDir[i] === protoDir[i]) shared++;
  else break;
}

For a monorepo with protos/ at root and services in services/auth/, services/orders/, the paths share the same repo prefix. A source file at services/auth/server.go and proto at protos/auth/auth.proto will score lower than proto at protos/orders/orders.proto if "protos/auth" lexically matches less of the path than another option. The heuristic should compare normalized path segments, not characters. Fix this →

---

4. Minor Issues

phase1Timeout ignores user intent for large timeouts (cross-impact.ts:129/312): Math.min(5000, timeout) means users who set timeout: 60000 still only get 5s for Phase 1. For large graphs this might truncate the local impact result. Consider Math.min(timeout * 0.3, 10000) or make it configurable.

Deduplication key in GrpcExtractor uses file path (grpc-extractor.ts:491): ${c.contractId}|${c.role}|${c.symbolRef.filePath}. A file that registers both UserService and UserService (via two different patterns) would only keep one. This is correct but worth a comment.

Topic extractor scans .go but Kafka/NATS patterns use Go-style calls without Go file detection — the glob pattern includes *.go but many Go patterns like ConsumePartition may appear in test files. Consider filtering *_test.go.

---

5. What's Working Well

• The bridge.lbug atomic write (temp→rename with .bak recovery) is solid for concurrent use
• Wildcard gRPC matching (runWildcardMatch) correctly handles the case where a consumer doesn't have proto context — this is a real-world pattern
• normalizeContractId handles HTTP method case and trailing slashes, gRPC package lowercasing correctly
• Graph-first strategy in HttpRouteExtractor is the right approach — when graph data is available, use it; fall back to source scan only when needed
• Test naming convention (test_verb_condition_expectation) is clean and consistent throughout

---

Recommended Next Steps (Prioritized)

1. High — Add fixture-based end-to-end test using test-monorepo that runs the real extractor pipeline and asserts specific ContractLink edges in bridge.lbug
2. High — Add TypeScript gRPC consumer detection (@GrpcClient, ClientGrpc, grpc-js new ServiceClient())
3. High — Fix manifest cross-link silently dropped for gRPC/lib types (Bug 2)
4. Medium — Add Go HTTP provider patterns (gin, echo, stdlib mux)
5. Medium — Add kafkajs consumer.run({ eachMessage }) and sarama Go producer patterns
6. Medium — Fix outOfScope always empty in Cypher path (Bug 1)
7. Low — Fix directory proximity heuristic to use path segments (Bug 3)
8. Low — Add NestJS @Controller/@Get provider detection

[abhigyanpatwari]

@ivkond can u look into these pls 🙏. Also great work, mostly clean implementation few easy bugs to bash

[ivkond]

@ivkond can u look into these pls 🙏. Also great work, mostly clean implementation few easy bugs to bash

Hi @abhigyanpatwari — heads-up and an offer.

Apologies for the commit noise on this PR. 14 commits from my side,
including two duplicated WIP iterations (restore out-of-scope reporting…
and expand grpc extraction… each landed twice during earlier review
rounds). I should have been squashing before each re-request for review.

After the last round I also ran a systematic self-review of the
cross-impact module and landed a batch of correctness / robustness
fixes in a single commit d15b8cb fix(group): self-review before merge.
The commit body has a severity-ordered breakdown with per-finding
rationale and test coverage — easy to skim or cherry-pick. Two larger
items are intentionally deferred to separate follow-up PRs:
AbortSignal plumbing for the Phase-1 timeout path, and the
runGroupImpact / runGroupImpactLegacy de-duplication.

Two options — whichever saves your review time

Option A — merge as-is with Squash & Merge. main ends up with
one clean commit regardless; the messy interim history stays only in
the PR.

Option B — I close this and open a fresh PR with a clean 3–4
commit history:

1. feat(group): infrastructure, contract matching, service boundary detection
2. feat(group): bridge.lbug storage + gRPC canonical IDs
3. feat(group): http / grpc / topic extractor coverage across languages
4. fix(group): self-review — correctness + robustness

Same content, same CI result, reviewer-friendly diffs per logical step.
The review thread here is lost but main stays clean. I can have it up
within an hour if that's easier for you.

No preference from my side — whichever works best for your review
cadence. Let me know.

[magyargergo]

@ivkond Thank you for your contribution! You've made an amazing impact with you changes. We would like to ask you to split this up, thus we can iterate on it much confidentially.

[ivkond]

@ivkond Thank you for your contribution! You've made an amazing impact with you changes. We would like to ask you to split this up, thus we can iterate on it much confidentially.

@magyargergo Thanks — happy to do this. Here's what I'd propose; let me
know if the shape works before I start moving commits around.

Proposed split — 4 stacked PRs

Linear dependency chain, each PR has one clear responsibility. Every
self-review fix from d15b8cb travels with the code it patches, so
there's no orphan "fix" PR at the end.

1. feat(group): bridge.lbug storage + contract matching foundation
   (~1.5k LOC + ~1.2k LOC tests)
   Files: bridge-db, matching, normalization, types, storage,
   config-parser, bridge-schema, contract-extractor interface.
   Pure infra, no user-facing surface yet.
   Base: main.

2. feat(group): service boundary detection + per-language contract extractors
   (~2.5k LOC + ~2.5k LOC tests)
   Files: service-boundary-detector plus http-route-extractor,
   grpc-extractor, topic-extractor, manifest-extractor. Mostly
   regex/parser logic across Go, Java, Python, Node, TS.
   Base: PR 1 (for types only).

3. feat(group): sync pipeline (~500 LOC + ~700 LOC tests)
   Files: sync.ts wiring extractors → matching → bridge write.
   Deliberately small and standalone so the pipeline wiring is easy
   to review in isolation from the algorithm.
   Base: PR 2.

4. feat(group): cross-repo impact analysis + CLI + MCP tool
   (~1.5k LOC + ~1.5k LOC tests)
   Files: cross-impact.ts, GroupService (groupImpact +
   groupContracts + groupQuery), cli/group.ts, mcp/tools.ts
   (the group_impact tool entry), and the RFC doc
   2026-03-31-cross-index-impact-design.md. The user-visible feature.
   Base: PR 3.

PR 1 and PR 2 have no code-level coupling (only a type import) and
can be reviewed in parallel if you'd like.

Alternatives I considered

• 3 PRs — merge 1+2 into a single "foundation" PR and 3+4 into
  a single "feature" PR. Fewer review rounds, but each PR ends up
  5k–8k LOC which largely defeats the point of splitting.
• 5–7 PRs — further split the extractors per language or per
  broker. Adds a lot of ceremony without meaningfully reducing
  per-PR review load, and manifest-extractor imports types from the
  other extractors which would create awkward cross-dependencies.

Thanks for the quick review turnaround.

[magyargergo]

Please proceed one by one. I can see they have linear deps on them? Is there a way you could split them up, so they can be done parallel?

[ivkond]

Good question. The only thing making PR 1 → PR 2 linear in my first
proposal is a type import; everything else is genuinely independent. I
can fix that by pulling a tiny "types + interface" PR ahead of them.
Here's the revised stack:

Revised split — 5 PRs, with PR 1 and PR 2 truly parallel

• PR 0 — types.ts + contract-extractor.ts interface. Pure
  shared type definitions that everyone downstream imports. No logic,
  no user-facing surface. ~230 LOC.
  Base: main. Should be a trivial review.

• PR 1 — bridge-db, bridge-schema, matching, normalization,
  storage, config-parser. Bridge storage infra + contract matching

  • group config parser. ~1.5k LOC + ~1.2k LOC tests.
    Base: PR 0. Parallel with PR 2.

• PR 2 — service-boundary-detector + 4 contract extractors
  (HTTP / gRPC / topic / manifest). ~2.5k LOC + ~2.5k LOC tests.
  Base: PR 0. Parallel with PR 1.

• PR 3 — sync.ts pipeline wiring extractors → matching → bridge
  write. ~500 LOC + ~700 LOC tests.
  Base: PR 1 + PR 2 (needs both merged).

• PR 4 — cross-impact.ts, GroupService, cli/group.ts,
  mcp/tools.ts (group_impact), RFC doc
  2026-03-31-cross-index-impact-design.md. The user-visible feature.
  ~1.5k LOC + ~1.5k LOC tests.
  Base: PR 3.

So it's still "one at a time" in terms of review context-switching,
except for the PR 1 / PR 2 pair which you can take in whichever order. Each
PR has a clear, non-overlapping scope and none blocks on anything
other than its direct dependency.

I'll start on PR 0 as soon as you confirm the shape.

[magyargergo]

Nice! This sounds like a good plan! Please create tickets for them so we can track this progress

[ivkond]

Done! Tickets for the split:

• [group] Shared types and ContractExtractor interface (split 1/5 of #606) #790 — shared types + ContractExtractor interface (bootstrap)
• [group] Bridge storage and contract matching foundation (split 2/5 of #606) #791 — bridge storage + contract matching foundation
• [group] Service boundary detection and language contract extractors (split 3/5 of #606) #792 — service boundary detection + language contract extractors
• [group] Sync pipeline (split 4/5 of #606) #793 — sync pipeline
• [group] Cross-repo impact analysis, CLI and MCP tool (split 5/5 of #606) #794 — cross-repo impact analysis + CLI + MCP tool

Each issue has full what / why / verify / risk sections per CONTRIBUTING.md, plus a scope-discipline note per GUARDRAILS.md confirming no drive-by refactors and no CI/release/security changes.

Dependency chain: #790 first, then #791 and #792 in parallel, then #793, then #794.

#606 will stay open until #794 merges, at which point it will be closed with backlinks to all 5.

Starting on #790 now.

[magyargergo]

Thank you for doing it! Let me know when you are ready with the first PR and I'll review it ASAP!

[ivkond]

@abhigyanpatwari @magyargergo — closing this one.

The split plan agreed in #issuecomment-4229689301 is complete. Everything from this PR landed piecemeal via 4 follow-up PRs against the 5 tracking issues:

#	Issue	Merged via	Scope
1	#790	#795	Shared types.ts + ContractExtractor interface (rolled into PR 2)
2	#791	#795	bridge.lbug storage + contract matching foundation
3	#792	#796	Service boundary detection + HTTP/gRPC/topic/manifest extractors
4	#793	#817	Sync pipeline + extractor contract-resolution fixes
5	#794	#984	group_impact / cross-repo traversal + @<group> MCP routing + group resources

Net effect on main matches the original intent of this PR, minus the items explicitly deferred along the way — tracked separately:

• AbortSignal plumbing for the Phase-1 timeout path.
• runGroupImpact / runGroupImpactLegacy unification.
• NITs from the feat: cross-repo impact analysis (#794) — @repo MCP routing + group resources #984 second-pass review (crossDepth tool description, groupStatus Promise.all, ensuredPoolFTS invalidation on closeLbug).

Happy to open follow-up issues for any of the above if useful.

Thanks for the patience with the split and for the reviews along the way 🙏 — closing without merge.

[magyargergo]

@ivkond thank you for this amazing work! You made a big impact on GitNexus! We appreciate your hard work. We have open positions for maintainers if you are interested.

Please join to our community on Discord.