Shared KB/MC deployment profile and validation

Context

Sub-epic #10691 defines the shared KB/MC team deployment MVP under #9999. The MVP should remove per-developer staleness by giving a team one shared Knowledge Base and Memory Core backing store, while preserving separate collections and provenance.

Earlier #9999 topology work supported both unified local and federated cloud Chroma modes. For the MVP, the simpler maintained path should be one shared Chroma process for KB + MC, not separate Chroma processes per service.

The Problem

The repo has pieces of unified topology already, but no single deployment profile that tells an operator or future agent what the shared-team MVP actually means.

Without a profile, agents will keep rediscovering or rearguing:

• Whether KB and MC should share a Chroma process.
• Whether sharing a Chroma process means sharing one collection.
• Which MCP servers still run separately.
• Which tests validate the supported topology.
• What to do with #10009 if federated Chroma is no longer a first-class product mode.

The Architectural Reality

Current anchors:

• #10001 and #10007 shipped unified topology plumbing.
• #10008 is still open for unified monolithic topology validation.
• #10009 is still open for federated cloud topology validation, but federated Chroma may no longer be worth maintaining as a default product path.
• KB and MC should remain separate MCP tool surfaces.
• Chroma data should remain separated by collection, not collapsed into one collection.

The Fix

Create and validate a shared KB/MC deployment profile:

1. Document the MVP topology: one Chroma process, separate KB/MC collections, two MCP servers.
2. Define required environment/config flags for shared mode.
3. Define healthcheck expectations for KB and MC in shared mode.
4. Add or point to tests that validate KB and MC read/write against the same Chroma process without collection collision.
5. Review #10009 and decide whether it should be superseded, demoted to diagnostic/non-default coverage, or retained as a future non-MVP path.
6. Include migration notes from per-developer local mode to shared team mode.

Acceptance Criteria

• Documentation states that shared Chroma means one process/service, not one collection.
• Documentation states that KB and MC remain separate MCP servers/tool surfaces.
• Shared-mode configuration is explicit and reproducible.
• Healthcheck output lets operators verify the effective shared Chroma topology.
• #10008 is either completed or explicitly linked as the validation path.
• #10009 receives a clear disposition: superseded, demoted, or retained with non-MVP rationale.
• Migration notes explain how a team moves from per-developer local Chroma to the shared MVP.

Out of Scope

• Implementing client-scoped session lifecycle.
• Implementing summarization coordination.
• Final Native Edge Graph tenant isolation.
• Provider-specific OAuth work; auth is already provider-agnostic and can be validated separately.
• GitLab/GitHub connector work for forwarding private requests into public Neo tickets.

Avoided Traps / Gold Standards Rejected

• Rejected: keep every topology as equally supported in the MVP. A broad matrix slows delivery and confuses operators.
• Rejected: collapse KB and MC into one collection. Collection boundaries preserve query semantics and migration safety.
• Gold standard retained: observable topology. Operators should verify the actual topology from healthcheck output, not by reading environment files or logs.

Related

• Parent sub-epic: #10691
• Parent cloud epic: #9999
• Existing topology sub-epic: #10015
• Unified topology validation: #10008
• Federated topology validation candidate for disposition: #10009
• Team/private retrieval policy: #10010

Origin Session ID: d9cd4943-3285-47a6-b629-c05a9a2a38e4

Retrieval Hint: "shared KB MC deployment profile one Chroma process separate collections healthcheck validation"