Phase 5B — KB Tenant Isolation Integration Tests (post-Phase-0/1D)

Context

Sub of Phase 5 Epic #11643 (meta-Epic #11624).

Blocked-by Phase 0/1D #11632 — tenant-isolation integration tests need server-stamping (Phase 0/1C) + read-side filter (Phase 0/1D) shipped first.

Topology anchor: Per ADR 0003 — Chroma Topology Unified Only, tests validate tenant isolation on the knowledge-base collection in the unified Chroma daemon. MC's existing TeamPrivateRetrieval + CrossTenantIsolation tests target the neo-agent-memory / neo-agent-sessions collections in the SAME daemon — same DB, separate collections, same RLS/auth substrate, parallel test patterns.

The Problem

After Phase 0/1D ships, KB has write-side server-stamping + read-side tenant filter. But these are validated only at unit-test + fail-closed-spec level (Phase 0/1D ACs). Integration-level validation in dockerized unified-Chroma topology with multi-identity proxy authentication is the parity gap with MC's:

• TeamPrivateRetrieval.integration.spec.mjs — memorySharing teams/private retrieval with proxy identities
• CrossTenantIsolation.integration.spec.mjs — cross-tenant memory reads with different proxy identities

Without this integration coverage, KB tenant-isolation semantics could regress silently under deployment-specific auth configurations.

The Fix

Create parallel KB integration test specs at test/playwright/integration/:

1. KBTeamPrivateRetrieval.integration.spec.mjs — KB tenant-isolated reads with proxy identities; Neo 'neo-shared' content cross-tenant-visible; per-tenant content 'private'-by-default to that tenant; team-namespace semantics correctly applied
2. KBCrossTenantIsolation.integration.spec.mjs — KB read-side filter prevents tenant A from retrieving tenant B private chunks via every public KB facade (ask_knowledge_base, query_documents, get_class_hierarchy, get_document_by_id, list_documents); forged client tenantId in query parameters ignored (filter from authenticated AgentIdentity)
3. KBAuthRejection.tenant.integration.spec.mjs (extension to Phase 5A's KBAuthRejection) — KB MCP server rejects ingestion attempts spoofing tenant identity; server-stamping overrides client-supplied tenantId/visibility per Phase 0/1C config (spoofRejectionMode)

Acceptance Criteria

• KBTeamPrivateRetrieval.integration.spec.mjs exists and passes; covers 'neo-shared' cross-tenant visibility + per-tenant private isolation
• KBCrossTenantIsolation.integration.spec.mjs exists and passes; covers all 5 public KB query facades; forged tenantId rejection in query parameters
• KBAuthRejection.tenant.integration.spec.mjs extension covers spoof-rejection-mode invariants (overwrite + warn vs reject)
• Tests run in npm run test-integration-unified (post-Phase-0/1D in dev)
• CI integration: Phase 0/1 + Phase 2 work cannot regress tenant-isolation guarantees
• Fixtures reused from existing composeWebServer.mjs + mcpClient.mjs

Out of Scope

• Phase 0/1 unit-level fail-closed tests → Phase 0/1D (#11632) ACs (this sub adds INTEGRATION-level coverage on top)
• Cloud-ingestion push pipeline tests → Phase 2F (#11638)
• Performance under multi-tenant load → future ticket if needed

Related

• Parent: #11643
• Blocked-by: #11632 (Phase 0/1D — read-side filter ships)
• Parallel'd specs: TeamPrivateRetrieval.integration.spec.mjs, CrossTenantIsolation.integration.spec.mjs

Origin Session ID

7360e917-1733-4cdd-a6f3-5ac51c34b838

Handoff Retrieval Hints

• MC TeamPrivateRetrieval + CrossTenantIsolation specs are the architectural templates — adapt for KB endpoint + KB tool surface
• Memory Core's tenant-isolation test pattern uses different proxy identities via headers — same pattern applies to KB
• Phase 5A's KBAuthRejection is the foundation; this sub extends it with tenant-context scenarios