Use Case

As the Compass/browser client,
I want a new browser-targeted CCS client that can be feature-flagged on/off,
So that we can roll out the new implementation safely while retaining the current websocket/tls flow as a fallback.

User Experience

• When the feature flag is on, the browser uses the new CCS client to open and multiplex connections; when off, it continues using the existing ws/tls implementation.
• Flagging can be flipped per-organization to validate behavior per customer

Risks/Unknowns

• We will be implementing this concurrently with independent compass deploys we should have our "insert local compass version" dev flow working before picking up this work.

Acceptance Criteria

Implementation Requirements

• Introduce a browser CCS client (built for Compass) that mirrors the Node.js reference client behavior (socket multiplexing, header handling, message framing) but runs in the browser.
• Add a feature flag to switch between the new browser client and the existing ws/tls implementation; when the flag is enabled, the old implementation becomes a no-op/shim.
• Ensure the new client integrates cleanly in the Compass repo and can be toggled without code redeploy (config-driven).

Testing Requirements

• E2E tests in data-explorer/e2e-tests using Playwright run with the feature flag enabled to validate the new client path.
• Regression checks (manual or automated) with the flag disabled to confirm the legacy path still works.
• Basic cross-browser validation (at least Chrome + one other) for the new client's websocket flow.

References

• Existing ws.ts/tls.ts implementation remains as the legacy path; new Compass-resident client is activated via the feature flag.
• Reference behavior aligns with the test utility in test/utils/reference_client.mts for framing/multiplexing semantics.