dsh-multi-tenant 0.4.0-alpha.2

dsh-multi-tenant 0.4.0-alpha.2

Release posture: alpha integration release. The focused implementation and adversarial closure review completed on 2026-09-03. Git tag v0.4.0-alpha.2 identifies the reviewed source; npm distribution belongs on the alpha dist-tag and must not move latest. A GitHub prerelease and the npm artifact are separate, explicitly created distribution records.

Who should use it

Alpha.2 is intended for DSH host authors who can provide authenticated Principal identities, keep the built-in SQLite directory single-active-process, and treat the shared runtime as logical rather than hostile-code isolation. It is suitable for integrating Agent CRUD, restart/resume, and Agent-scoped MCP before the 0.4 API is declared stable.

Use an exact version for reproducible environments. Expect later alphas to refine host provider contracts. Do not deploy stock DSH /api as the tenant ingress, and do not rely on this plugin to authenticate requests, certify strong isolation, coordinate multiple active processes, or forcibly terminate uncooperative host code.

Stable direction

The project remains a DSH multi-tenant plugin. Its authority path is unchanged:

trusted PrincipalContext
  -> plugin-minted AgentId
  -> Principal-scoped Agent directory
  -> host capability/isolation protocols
  -> native DSH Agent / Session / MCP lifecycle

Alpha.2 improves operational correctness inside that boundary. It does not turn the plugin into a process manager, distributed ownership service, secret broker, sandbox, or public ingress.

Abandoned provisioning

The built-in SQLite repository now reconciles every persisted provisioning record to terminal failed when it opens. The update is atomic, revisioned, and completed before the repository can back a MultiTenantService. Ready, already-failed, and deleted records remain unchanged.

Reconciled resources stay indistinguishable from unknown or foreign resources at the product boundary. They are never resumed, and a retry receives fresh Agent and internal session identities. The repository state type and both reference implementations enforce only provisioning -> ready | failed and ready -> ready | deleted.

This behavior relies on the documented host invariant that one process is active for the built-in database. It deliberately adds no lock, PID record, heartbeat, lease, fencing token, takeover, or multi-replica coordination. Custom repositories own recovery for their topology before service registration.

Cooperative provider lifecycle

TenantMcpProvider.load, SecretProvider.acquire, RuntimePartitionRequest, and DshAgentSpecification now carry required lifecycle signals. MCP and Secret acquisition receive the service signal. Runtime-partition acquisition and DSH create/resume receive its combination with SecretLease revocation.

The service validates and freezes MCP snapshots, Secret leases, runtime-partition leases, drivers, and Agent handles before trusting them. Invalid capability results fail closed with stable errors and are disposed when a usable disposer exists. Reference disposers are idempotent.

Shutdown stops admission, aborts pending cooperative acquisition, invalidates callback scopes, cancels live Agents, drains accepted work, then disposes handle, partition, and secret in order. Secret revocation keeps its existing behavior: cancel the live Agent and resume the same session with a fresh lease on the next authorized use.

AbortSignal is a cooperation contract, not forced interruption. A provider or callback that ignores abort or never settles may still delay delete or shutdown indefinitely. No generic timeout, retry framework, provider certification harness, attestation system, or second DI layer was added.

Accepted evidence

• #49: SQLite restart proves abandoned provisioning becomes failed before service use, never reaches DSH, and retries with new identities; both repositories run the legal-state/CAS/Principal-scope contract.
• #50: adversarial tests cover lifecycle propagation through MCP, Secret, partition, create and resume; malformed results, Secret revocation, shutdown mapping, capability invalidation, and cleanup order.
• #54: the final adversarial review checks code, types, documentation, upstream identity, release controls, and the exact final main CI before milestone closure.
• The existing native DSH alpha.5 AgentLoop/JSONL/official-MCP create, restart, same-session resume, and delete evidence remains green.
• Installed-tarball smoke typechecks the required provider signal contracts and exercises every public subpath.
• The latest upstream release was re-queried at review time; it remains DSH 0.1.2-alpha.5 at db6bdc3576c2d4e7c965e8e3ed0c2a731eed87f5.

Explicit limits

• The shared runtime is same-process logical isolation, not a hostile-code boundary.
• Built-in SQLite supports local, single-node, host-enforced single-active-process use only.
• Typert public ingress is absent; stock DSH /api remains private/administrative.
• Strong isolation is a host provider claim; the plugin only negotiates the declared level.
• Delete revokes plugin access but does not claim physical erasure of DSH logs.
• Host-managed database paths retain host-owned ACL, backup, and encryption policy.
• No 0.3 API/data migration or unpublished candidate-schema migration is provided.
• Non-cooperative callbacks and providers may prevent bounded shutdown.

中文复盘

发布定位：用于集成的 alpha 预发布版本。v0.4.0-alpha.2 标识完成审查的源码；npm 只应通过 alpha dist-tag 分发，不得移动 latest。GitHub prerelease 与 npm artifact 是独立、显式创建的分发记录。

Alpha.2 面向能够提供已认证 Principal identity、保证内置 SQLite single-active-process，并且把 shared runtime 视为逻辑隔离而不是 hostile-code 边界的 DSH 宿主。它适合在 0.4 API 稳定前接入 Agent CRUD、restart/resume 和 Agent-scoped MCP；需要可复现部署时应固定精确版本，并预期后续 alpha 仍可能调整宿主 provider 契约。

0.4.0-alpha.2 没有改变项目定位，仍然只负责 PrincipalContext -> AgentId -> Principal-scoped Directory -> DSH Agent/Session/MCP。不要把 stock DSH /api 用作租户入口，也不要依赖本插件完成请求认证、强隔离认证、多活动进程协调或强制终止不合作的宿主代码。

#49 在内置 SQLite 打开时，用一次原子更新把全部遗留 provisioning 转为终态 failed，revision 加一；ready、failed、deleted 不受影响。恢复后的资源对产品 API 仍是 not-found，不会触发 DSH resume，重试使用新的 AgentId 和 session。类型和两个参考 Repository 只允许 provisioning -> ready | failed 与 ready -> ready | deleted。

该恢复建立在宿主保证 single-active-process 的明确前提上。插件不实现 lock、PID、heartbeat、lease、fencing、自动 takeover 或分布式协调；自定义 Repository 必须在注册前完成自己的拓扑恢复。

#50 将 service lifecycle AbortSignal 传入 MCP、Secret、runtime partition 和 DSH setup，并把它与 SecretLease revoke signal 组合。所有 provider 返回值会先被校验和冻结；malformed capability 在 DSH 前 fail closed，可用 disposer 会被调用。Shutdown 先停止 admission 和 abort acquisition，再失效 callback、cancel Agent、合作式 drain，最后按 handle、partition、secret 顺序清理。

Abort 不是强制终止。忽略 signal 或永不结束的宿主 provider/callback 仍可能无限延迟 delete/shutdown。本版本不增加默认 timeout、重试框架、provider 认证工具、隔离 attestation、sandbox 或第二套 DI。

其他限制保持不变：shared provider 只有进程内逻辑隔离；SQLite 只支持 local/single-node/宿主保证单活；无 Typert 公网入口；stock DSH /api 仅限私有/管理用途；strong isolation 的真实性由宿主负责；删除不物理擦除 DSH 日志；不迁移 0.3 或旧候选 schema。