unified-bridge crate scaffold: registry + projection orchestrator for Spine impls

[AdaWorldAPI]

Why

The current architecture sketch implies two parallel orchestrator crates (medcare-bridge, smb-bridge) that each glue consumer types to the triplet graph. That shape does not scale: every new consumer (callcenter Supabase transcode, future verticals) would either spawn yet another bridge crate or get force-fitted into one of the existing two, both of which leak consumer-specific types into the bridge layer.

Collapse the two-bridge picture into one thin orchestrator: many Spine impls living in their owner crates, plus ONE unified-bridge crate that knows how to register and project them. The bridge contains zero consumer types; it only depends on lance-graph-contract (the Spine trait + TripletGraph).

The trap to call out for reviewers: this crate must NOT accumulate consumer-specific code. If anyone proposes adding pub struct MedicalRecord or pub struct Invoice here, fix the dep graph; do not pollute the bridge.

What

A new workspace crate (proposed path: crates/lance-graph-bridge/) that is the single orchestrator for all Spine impls in the lance-graph universe.

Surface (initial):

• Registry of Spine impls. Two viable mechanisms; pick whichever is cheaper to land first:
  • Compile-time: trait-bound generics / a &[&dyn Spine] slice passed by the caller.
  • Runtime: inventory crate or ctor macro auto-registration. Neither is currently a workspace dep — pick whichever requires the smallest delta.
• Unified projection API: bridge::project_all(impls: &[&dyn Spine]) -> TripletGraph.
• Health/status surface: which impls are registered, round-trip pass rate, last error per impl.
• Smoke harness: two trivial fake Spine impls (FakeColor, FakeShape) baked into the crate's tests so the registry + round-trip path can be validated without depending on any real consumer.

Architecture

lance-graph-contract           <-- Spine trait, TripletGraph (A1)
        ^                ^
        |                |
lance-graph-bridge      consumer crates (medcare, smb, callcenter, ...)
  (THIS ISSUE)            each owns its own Spine impl
        ^
        |
   downstream apps call bridge::project_all(&[&medcare_spine, &smb_spine, ...])

Key invariants:

• lance-graph-bridge/Cargo.toml depends on lance-graph-contract only. No medcare, no smb, no callcenter deps.
• The crate compiles standalone in the workspace with zero consumer crates present.
• Consumer-specific types never appear in the bridge's public API.
• Replaces the conceptual medcare-bridge and smb-bridge orchestrators — those are not separate crates; they are Spine impls inside their owner crates.

Acceptance criteria

• New crate crates/lance-graph-bridge/ (or equivalent) exists and is added to the workspace members in the root Cargo.toml.
• Cargo.toml lists lance-graph-contract as the only first-party dep. No consumer crates.
• Public API exposes:
  • A registry registration mechanism (compile-time slice or runtime inventory/ctor).
  • project_all(impls: &[&dyn Spine]) -> TripletGraph (or equivalent signature once A1 lands).
  • A health/status accessor reporting registered impl count + per-impl round-trip status.
• Smoke test: two fake Spine impls (FakeColor, FakeShape) in tests/ or #[cfg(test)] that:
  • Register via the chosen mechanism.
  • Pass project_all.
  • Pass verify_roundtrip for each.
  • Health surface reports both as registered.
• cargo build -p lance-graph-bridge and cargo test -p lance-graph-bridge pass without any consumer crate in the build graph.

Out of scope

• Real consumer Spine impls (medcare, smb) — those are tracked under B2 / B3.
• callcenter Supabase transcode — that is a separate consumer Spine impl, not the bridge.
• Materialization backends (Lance, parquet, etc.) — the bridge returns TripletGraph; persistence is downstream.
• Any consumer type definition. If a PR for this issue adds consumer structs, it should be rejected.

Dependencies

• Blocks on A1: Spine trait + TripletGraph must exist on lance-graph-contract. This issue cannot land until A1 is merged. Once A1 is in, this scaffold is mechanical.

[AdaWorldAPI]

M-S2: Blocks on A1 lance-graph#331. Downstream: B2 MedCare-rs#96 + B3 smb-office-rs#28 will register Spine impls via this orchestrator. Verify registry mechanism is committed (compile-time trait bounds vs inventory/ctor) — undecided forks the consumer pattern.

---

Generated by Claude Code

[AdaWorldAPI]

R-SHSR — most valuable single refinement: ship the compile-time slice form first, defer inventory/ctor to a follow-up; reuse A1's MockSpine for the smoke harness.

Two refinements bundled:

1. API shape v1: project_all(impls: &[&dyn Spine]) -> TripletGraph. Zero new workspace deps, lands fast, and the API can grow into runtime registration later without breakage. Runtime inventory/ctor is appealing but adds a build-time-discovery surface that's easy to mis-debug (silent missing impls). Compile-time slice keeps the registration explicit and greppable; bridge consumers pass the &[&dyn Spine] they want, period.

2. Don't reinvent FakeColor/FakeShape if A1 ships MockSpine in the contract crate (recommended in A1's review). Just parameterise two MockSpine instances:

   #[test]
   fn registry_smoke() {
       let red = MockSpine { triplets: vec![Triplet::new("sky","is","red")] };
       let blue = MockSpine { triplets: vec![Triplet::new("sky","is","blue")] };
       let g = bridge::project_all(&[&red, &blue]);
       assert_eq!(g.len(), 2);
       assert_eq!(bridge::health(&[&red, &blue]).registered, 2);
   }

Iron-rule check to add to AC: grep -E "(medcare|smb|callcenter)" lance-graph-bridge/Cargo.toml returns zero matches. If a future PR adds a consumer crate as a dep, that grep fails CI — layering bug detected mechanically.

---

Generated by Claude Code