dsh-multi-tenant 0.1.0-rc.2
Pre-releasedsh-multi-tenant 0.1.0-rc.2
0.1.0-rc.2 is a convergence release, not a feature release. It removes one
speculative public API field before the 0.1 contract is considered for stable.
API subtraction
TenantPrincipal is now exactly:
interface TenantPrincipal {
tenantId: string
userId: string
}The required roles field from rc.1 has been removed, together with role-count /
role-length validation. The ownership kernel never consumed roles; retaining the
field would have forced every integration to adopt RBAC vocabulary that the
kernel explicitly does not own.
Callers that only supplied roles to satisfy the rc.1 type should simply remove
that property. Code that actually depended on principal.roles must move that
policy into its authentication/authorization layer rather than the ownership
kernel.
The security invariants are unchanged:
- claim-once immutable
(tenantId, userId)ownership; - unconditional cross-tenant denial;
- same tenant + different user denied in v0.1;
- unknown and foreign sessions fail closed;
- public denial remains non-enumerating;
TenantSessionStoreremains replaceable and contract-tested.
Publishing convergence
The release workflow is now OIDC-only through npm Trusted Publishing. The
one-time NPM_BOOTSTRAP_TOKEN fallback used to create the package for rc.1 is no
longer referenced by the repository.
The workflow still requires:
- dispatch from
mainwith the exact version; - GitHub Environment
npm-release; id-token: write;- full
pnpm release:checkbefore publication; - registry ownership/version preflight;
- registry external-consumer smoke before creating the Git tag / GitHub prerelease.
Compatibility baseline
- DeepSeek Harness target:
0.1.0-rc.7 - Node:
^22.19.0 || >=24.0.0 - npm channel:
next
Explicit boundary
This package still does not provide production multi-user DSH Web transport,
authentication, durable storage, MCP credential isolation, audit persistence,
general RBAC/team ACLs, or shell/filesystem/process/container/network isolation.
After rc.2, the project should stop adding speculative kernel API. Without a real
bug, upstream compatibility change, or concrete user feedback requiring another
contract change, the next release decision is whether to publish 0.1.0 stable.