Module cross_service 

Cross-service / cross-process edges (Plan competitive-harvest t-002).

Call edges link two symbols by qname within one repo. Cross-service edges are different: a client call (requests.post("/charge")) in one repo and a route handler (@app.post("/charge")) in another can’t be linked by qname — they’re linked by a shared contract: the HTTP method+path, the pub-sub topic name. We therefore keep symbol_id repo-scoped and unchanged, and add a separate contract-keyed layer:

• Each repo detects the endpoints it exposes (inbound: routes/listeners) and consumes (outbound: client calls/emits), normalizes each to a ServiceEndpoint with a stable contract key and a repo_id.
• A repo exports its endpoints as a ServiceManifest; other repos import manifests to match contracts cross-repo (federated — no shared DB, no global symbol identity).
• match_edges pairs outbound→inbound endpoints sharing a contract key into CrossServiceEdges. Matching is by string equality on the normalized contract, so the normalizers below are load-bearing: a client and a server must phrase the same endpoint identically.

HTTP and pub-sub share this machinery. Data-flow edges are a distinct intra-process mechanism (arg→param / field chains) tracked separately.

Structs

CrossServiceEdge

A matched cross-service edge: an outbound endpoint linked to an inbound endpoint sharing a contract key. Computed on demand, not materialized.

DetectedEndpoint

An endpoint detected by a language adapter, before the index pipeline enriches it with this repo’s repo_id and the owning symbol’s symbol_id. Adapters work in qnames, so a DetectedEndpoint names its owner by qname.

EndpointRef

A lightweight reference to one end of a cross-service edge.

ServiceEndpoint

A detected service-boundary point owned by a local symbol.

ServiceManifest

A repo’s exported endpoints — the unit shared for cross-repo matching.

Enums

Direction

Whether an endpoint exposes/handles a contract (inbound) or consumes/calls it (outbound).

Transport

Transport a service endpoint communicates over.

Functions

contract_hash

Stable 16-hex-char hash of a contract key, for use as a filesystem-/path-safe segment (raw contract keys contain spaces, /, and :).

endpoints_from_tree

Flatten the on-disk endpoint registry tree (contract_hash → repo_id → symbol_id → ServiceEndpoint) into a flat list. Malformed entries are skipped.

federated_edges

Federated edges over a set of per-repo manifests: match_edges on the union of every manifest’s endpoints. Each edge carries cross_repo (consumer and producer in different repos). With cross_repo_only, in-repo edges are dropped — the federated view a Team-tier tool wants: “a client in repo A calls a route served by repo B” (Plan Q t-005).

http_contract

Build a normalized HTTP contract key from a method and a path (or full URL). A client call and a server route for the same endpoint must produce the same string: the method is upper-cased, any scheme+host is stripped, path parameters ({id}, :id, <id>, <int:id>) collapse to {}, query and fragment are dropped, and trailing slashes are removed.

match_edges

Pair outbound endpoints with inbound endpoints sharing a contract key, producing cross-service edges. Endpoints may come from any repo (local + imported manifests). Edge confidence is the weaker of the two detections; cross_repo is set when the ends live in different repos.

normalize_repo_id

Normalize a git remote URL into a stable repo_id. SCP-form and HTTPS-form URLs for the same repo collapse to one id:

pubsub_contract

Build a normalized pub-sub contract key from a topic / queue / event name.

resolve_repo_id

Resolve this repo’s id: an explicit override wins; otherwise the normalized origin git remote; otherwise the working-directory name as a last resort.