简体中文 | English

dsh-multi-tenant

Composable multi-tenant / SaaS plugin suite for DeepSeek Harness (DSH).

Phase: engineering foundation. The kernel baseline is established and test-pinned; its public contract remains prerelease. The suite grows around it one plugin at a time. See ROADMAP.md.

What this is

A plugin family, not a single plugin. A kernel — dsh-multi-tenant — owns the tenant/session contract (identity, ownership, fail-closed authorization). This repository ships the official default implementations (storage, web enforcement, …) as independently publishable Cordis plugins, each following DSH's service/bundle logic and each replaceable by a third-party implementation that passes the same contract tests.

Maintaining a complete default stack matters because a single party can then hold the end-to-end tenant-isolation invariant — tenant A can never touch tenant B across auth → RPC → session → MCP → downstream — something no single plugin's unit test can prove.

Guiding principles

• Typical capability layering — Contract (a native DSH/Cordis seam: Service, event, or protocol) → Provider (plugin) → Composition (cordis.patch.yml bundle), where applicable. Pure integration / security-boundary plugins compose directly against native seams.
• One-way dependency — the kernel owns only the minimal cross-suite tenant primitives and depends on nothing transport- or vendor-specific (no JWT, no PostgreSQL, no HTTP, no MCP, no Redis); capability packages own their own contracts and may depend on the kernel's primitives.
• Split by replaceable capability, not size — and a single security invariant is not split across packages.
• Default ≠ only — the suite ships defaults; third parties may swap any layer, if it passes the same contract test.

See CONTRIBUTING.md for how development is done here. Full documentation lives in docs/.

Packages

Development

pnpm install
pnpm typecheck
pnpm test
pnpm build

Root scripts delegate to every workspace package via pnpm -r.

License

MIT