Skip to content

dsh-multi-tenant 0.3.0-rc.2

Pre-release
Pre-release

Choose a tag to compare

View all tags
@github-actions github-actions released this 25 Aug 14:43
· 56 commits to main since this release
v0.3.0-rc.2
a5485ec
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

dsh-multi-tenant 0.3.0-rc.2 — First Product Experience

0.3.0-rc.2 moves the v0.3 line from a strong multi-tenant Framework Core to a product-facing MVP that a developer can actually try, understand and copy without first learning the internal composition graph.

What changes for a product developer

The supported first-success path is now:

existing JWT / Cookie / req.user
  -> product-owned authentication
  -> TrustedSubject
  -> canonical Tenant / Principal
  -> Tenant MCP config + Principal credentials
  -> Principal-aware Agent create/resume
  -> official @deepseek-ai/dsh-mcp-client
  -> real MCP Tool
  -> visible Session / identity isolation

The package still does not own authentication. Products continue to verify JWTs, cookies, OIDC sessions or other credentials using their existing auth stack, then map the trusted result into the multi-tenant Runtime.

Highlights

Runnable First Product Experience on real DSH Web

Install the package into the shipped Web profile and explicitly opt in to the starter:

dsh plugin --profile web add dsh-multi-tenant
DSH_MULTI_TENANT_STARTER=1 dsh web

Open the printed DSH URL plus /_dsh-multi-tenant.

The starter is dormant by default and demonstrates three identities:

Acme / Alice
Acme / Bob
Globex / Alice

The demo uses a real DSH Agent, the official DSH MCP client and a real stdio MCP JSON-RPC server. Its who_am_i Tool proves that the correct Tenant/Principal and Principal credential reached the MCP process without returning the raw credential.

The same flow proves owner Session resume, denied cross-Principal resume, and a second Tenant.

Short product-facing API

createMcpSaaSRuntime() composes the already-proven Core into an opinionated MCP-specific product facade. First-time product code mainly owns four things:

  1. trusted identity mapping;
  2. Tenant MCP configuration;
  3. Principal credentials;
  4. Agent create/resume.

The Core architecture remains available for advanced composition; this facade does not introduce a second Runtime or DI/lifecycle system.

Thin Web identity/admission bridge

mountMcpSaaSWebBridge() mounts product-aware routes into the existing DSH ctx.webServer.

readBearerToken() and readCookie() are transport extractors only. JWT verification, server-session lookup, OAuth/OIDC, refresh and req.user construction remain product-owned.

First-use diagnostics

Product-facing failures now carry stable, secret-safe stages for identity, Tenant MCP config, Principal credentials, Session ownership, MCP setup and explicit post-create discovery checks.

Raw underlying auth/vendor/credential causes remain server-side and are not serialized by toProductDiagnostic().

Executable release evidence

The permanent First Product Experience proof:

pnpm probe:fpe

packs the current candidate, installs it into a clean pinned DSH Web profile, boots real dsh web, then proves over HTTP:

  • anonymous identity is rejected;
  • Acme/Alice resolves to the correct canonical Principal;
  • real Agent creation succeeds;
  • official MCP initial connect + tools/list + Tool registration succeeds;
  • real ToolRuntime.execute() -> MCP tools/call succeeds;
  • the Principal credential reaches MCP without being exposed;
  • Acme/Alice can resume the persisted Session;
  • Acme/Bob is denied Alice's Session before DSH resume runs;
  • Globex/Alice proves a second Tenant;
  • HTTP/stdout/stderr do not expose the raw starter credential.

pnpm release:check now includes this real-Web FPE proof, so publication cannot succeed if the headline rc.2 product experience regresses.

Public rc.2 product surface

The release preflight and packed-artifact smoke now explicitly protect these public subpaths:

dsh-multi-tenant/product
dsh-multi-tenant/web
dsh-multi-tenant/diagnostics
dsh-multi-tenant/starter

alongside the existing Runtime, composition, ingress, credentials, MCP, store and testing surfaces.

Known boundaries

This release is deliberately an MVP/value-validation prerelease. It does not claim that every stock DSH Web RPC automatically carries a product-authenticated Principal authority. The pinned DSH Web carrier does not yet expose that request-scoped product Principal seam across all existing business RPC dispatch.

Also intentionally non-blocking for rc.2:

  • production Redis/Postgres/MySQL TenantSessionStore implementations;
  • universal Credential Broker / Capability-as-Authority public contract;
  • generic OAuth/OIDC/token refresh framework;
  • Permission/Policy plugin;
  • full Audit/OTel product;
  • second ERP/direct-business-API integration;
  • hostile-code process/Pod isolation;
  • MCP Resources/Prompts beyond the pinned Harness consumer seams.

These gaps should be prioritized from real product usage rather than pulled into the Runtime spec preemptively.

Compatibility

  • Node: ^22.19.0 || >=24.0.0
  • Cordis: >=4.0.1 <5
  • pinned DSH baseline: 0.1.1-rc.2 @ b150a551b8d465e31e418e1b2eaf5e79bbb7d28e

0.3.0-rc.2 remains a prerelease. Deliberate breaking changes remain acceptable when real integrations prove a better product or authority contract.

Assets 2
Loading