feat(pipeline): NATS subject detection for cross-repo ASYNC_CALLS edges (Tier 2 follow-up to #292)

[sina-haseli]

What problem does this solve?

Summary

Following the protocol-aware cross-repo intelligence design in #292, I'd like to
contribute NATS subject detection as part of the Tier 2 typed-message pub/sub work.

The appendix in #292 already includes a Rust entry for async-nats but the most
common NATS client languages in production microservice stacks — Go, TypeScript,
and Python — are missing. I run a microservice fleet using NATS and can provide
real-world test fixtures.

---

Problem

Currently, NATS publish/subscribe connections between services are invisible to
codebase-memory-mcp. Given this code:

Service A (Go) — publisher:

nc.Publish("orders.created", data)
js.Publish("events.payment", msg)

Service B (TypeScript) — subscriber:

nc.subscribe("orders.*", { callback: handler })

Service C (Python) — subscriber:

await nc.subscribe("orders.created", cb=handler)

No ASYNC_CALLS or EMITS/LISTENS_ON edges are emitted between these services
today. The subject string "orders.created" is a literal at the call site —
exactly the case cbm can handle statically — but the NATS client patterns aren't
in service_patterns.c.

---

Proposed solution

Proposed Solution

Add NATS pattern entries to the service-pattern registry proposed in #292 for
these languages and clients:

Language	Client library	Publisher pattern	Subscriber pattern
Go	nats.go	nc.Publish(subject, data)	nc.Subscribe(subject, handler)
Go	nats.go JetStream	js.Publish(subject, msg)	js.Subscribe(subject, handler)
TypeScript	nats.ws / nats.deno	nc.publish(subject, payload)	nc.subscribe(subject, opts)
Python	nats-py	await nc.publish(subject, payload)	await nc.subscribe(subject, cb=handler)
Rust	async-nats	client.publish(subject, payload)	client.subscribe(subject)

NATS subjects are always literal strings or constants at the call site — no
generic type params, no config resolution needed. This makes it a clean Tier 2
addition with high precision/recall.

---

What I'll Deliver

• Pattern definitions for the 5 cases above
• Test fixtures: two minimal services (Go publisher → TypeScript subscriber)
  under testdata/cross-repo/nats/
• Tests in tests/test_pipeline.c asserting EMITS/LISTENS_ON edges are
  emitted correctly
• Wildcard subject handling (orders.*, events.>) documented as a known
  limitation (dynamic matching, out of scope for v1)

---

What I'm NOT doing (to keep scope small)

• No config-resolved subject names (that's Tier 4)
• No wildcard-to-wildcard cross-repo matching (too ambiguous statically)
• No NATS queue groups (separate concern)
• No JetStream stream/consumer config parsing

---

Questions for Maintainers

1. Should this target the YAML registry format proposed in Protocol-aware cross-repo intelligence: gRPC + typed-message + attribute-route matching (design proposal) #292, or add directly
   to service_patterns.c while the registry design is still being validated by
   Tier 1 (feat: Tier 1 cross-repo gRPC matching + production-readiness fixes #293)?
2. Where should the testdata/cross-repo/nats/ fixtures live — in-tree or
   external fixtures repo?
3. Should wildcard subjects (orders.*) emit edges with a wildcard: true
   property, or be skipped entirely in v1?

Happy to start after getting feedback here. I can also help with other NATS
client languages (Rust, Java) if useful.

Relates to: #292
Blocked by (soft): #293 (Tier 1 architecture validation)

Alternatives considered

No response

Confirmations

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

[DeusData]

Thanks. I’ve triaged this with the #292 / #398 cross-repo work and parsing/quality. NATS subject extraction fits the Tier-2 async edge track and should stay separate from the HTTP/gRPC route-linking fixes.