propose: shared-module multi-attribution

[HumanBean17]

What

Adds propose/SHARED-MODULE-MULTI-ATTRIBUTION-PROPOSE.md — a draft proposal for moving Symbol.microservice from a single-string attribution to a multi-attribution model that correctly handles the shared-contracts Maven module pattern.

Why

PR-E3 review observation #1 flagged that the CALLS invariant guard's pre-filter has a precondition: it only fires when at least one same-microservice candidate exists in _lookup_method_candidates's result. Today's audit on bank-chat-system shows this precondition is violated by exactly the shared-DTO failure mode:

=== CALLS: 8 cross-service edges ===
  Top microservice pairs:
    chat-assign -> chat-core: 8 edges
  Likely shared-library/DTO pattern: 8/8 (100%)
  Top callee FQNs:
       3  com.bank.chat.contracts.AssignmentRequest#getConversationId()
       2  com.bank.chat.contracts.AssignmentRequest#getPriorityScore()
       …

AssignmentRequest lives at chat-core/chat-contracts/src/... so microservice_for_path returns chat-core. But chat-assign/pom.xml declares a <dependency> on chat-contracts, so at runtime the DTO's bytecode is in both JVMs. The guard sees member.microservice=chat-assign, candidate.microservice=chat-core with no same-ms peer and skips, emitting a false-positive cross-service CALLS edge.

EXTENDS / IMPLEMENTS / INJECTS are clean on bank-chat-system today but vulnerable to the same failure mode (e.g. extending a base class from *-contracts, implementing an interface from *-shared).

What's in the proposal

• §1 — current state, exact reproduction of the failure mode
• §2 — design: sidecar Microservice / MEMBER_OF table, build-graph parser, generalised PR-E3 guard (set-disjoint instead of scalar-equal)
• §3 — risks: Maven/Gradle parsing fragility, membership explosion, build-time-only deps, brownfield interaction
• §4 — verification: determinism, single-service equivalence, shared-DTO fix on bank-chat-system, FQN-collision case still guarded
• §5 — five-PR breakdown (~930 LOC, ~24 tests, one schema bump 7→8)
• §10 — eight [TBD] decisions to resolve before implementable plan

What's NOT in the proposal

• Per-microservice resolution scoping in pass3 — already deferred to Tier-2 incremental rebuild
• Schema rename of Symbol.microservice — kept as primary attribution for back-compat
• Cross-repo memberships
• Bazel / Pants / sbt parsing

Status

Draft — open for review. The user has explicitly deferred this work ("will come back to this later"). After review and §10 [TBD] resolution, implementable plan derives at plans/PLAN-SHARED-MODULE-MULTI-ATTRIBUTION.md.

Manual evidence (motivating audit)

The audit script that exposed the gap:

python /tmp/audit_inter_service_edges.py /tmp/check_xs

Reports:

• CALLS: 8 cross-service edges, 100% shared-library/DTO pattern
• EXTENDS / IMPLEMENTS / INJECTS / DECLARES: 0 cross-service (clean)
• Symbol → Route relationships (HTTP_CALLS / ASYNC_CALLS / EXPOSES): out-of-scope (cross-service is legal)

This audit will become a built-in MCP tool in proposed PR-5.