@voltro/plugin-multitenancy 0.32.0 → 0.34.0

package/dist/guard.d.ts

@@ -5,6 +5,22 @@ import { Subject } from '@voltro/protocol';
  * Guard a tenant-scoped mutation against cross-tenant spoofing. Throws
  * `TenantMismatch` if `input.tenantId` doesn't equal `subject.tenantId`.
  *
+ * **What this does NOT cover, and what covers it instead.** This checks a
+ * CLAIMED `input.tenantId` — it can only fire on a mutation that carries one and
+ * whose author remembered to call it. It is a convention, not a boundary. The
+ * boundary is in the store middleware: every write is tenant-enforced by
+ * construction — inserts auto-stamp `tenantId` and refuse a null tenant, reads /
+ * `updateMany` / `deleteMany` AND-merge `eq('tenantId', …)`, and a KEYED-BY-PK
+ * write (`ctx.store.update(table, id, …)`, `delete`, `hardDelete`, `patchJson`)
+ * resolves its target row inside the caller's tenant and fails with
+ * `TenantRowNotFound` otherwise. A mutation that takes a row id from user input
+ * is therefore safe whether or not it calls this.
+ *
+ * Reach for it when the input carries an explicit `tenantId` you are about to
+ * USE (an admin form, a webhook payload) and you want a typed, early
+ * `TenantMismatch` at the top of the handler rather than a store-level refusal
+ * partway through.
+ *
  * The subject's tenantId may be null (anonymous subjects without a
  * tenant scope); those callers can't write to ANY tenant so the guard
  * always throws — anonymous + tenant-scoped writes need a different

package/dist/index.d.ts

@@ -9,6 +9,22 @@ import { Subject } from '@voltro/protocol';
  * Guard a tenant-scoped mutation against cross-tenant spoofing. Throws
  * `TenantMismatch` if `input.tenantId` doesn't equal `subject.tenantId`.
  *
+ * **What this does NOT cover, and what covers it instead.** This checks a
+ * CLAIMED `input.tenantId` — it can only fire on a mutation that carries one and
+ * whose author remembered to call it. It is a convention, not a boundary. The
+ * boundary is in the store middleware: every write is tenant-enforced by
+ * construction — inserts auto-stamp `tenantId` and refuse a null tenant, reads /
+ * `updateMany` / `deleteMany` AND-merge `eq('tenantId', …)`, and a KEYED-BY-PK
+ * write (`ctx.store.update(table, id, …)`, `delete`, `hardDelete`, `patchJson`)
+ * resolves its target row inside the caller's tenant and fails with
+ * `TenantRowNotFound` otherwise. A mutation that takes a row id from user input
+ * is therefore safe whether or not it calls this.
+ *
+ * Reach for it when the input carries an explicit `tenantId` you are about to
+ * USE (an admin form, a webhook payload) and you want a typed, early
+ * `TenantMismatch` at the top of the handler rather than a store-level refusal
+ * partway through.
+ *
  * The subject's tenantId may be null (anonymous subjects without a
  * tenant scope); those callers can't write to ANY tenant so the guard
  * always throws — anonymous + tenant-scoped writes need a different

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/plugin-multitenancy",
-  "version": "0.32.0",
+  "version": "0.34.0",
   "description": "Multi-tenancy plugin — ships the `tenant()` schema mixin (auto-scopes reads, fills tenantId on inserts) plus the `assertOwnTenant` write-guard and `TenantMismatch` typed error.",
   "keywords": [
     "voltro",
@@ -32,7 +32,8 @@
       "types": "./dist/guard.d.ts",
       "import": "./dist/guard.js",
       "default": "./dist/guard.js"
-    }
+    },
+    "./package.json": "./package.json"
   },
   "main": "./dist/index.js",
   "module": "./dist/index.js",
@@ -42,9 +43,9 @@
     "node": ">=24.0.0"
   },
   "dependencies": {
-    "@voltro/database": "0.32.0",
-    "@voltro/plugin-audit": "0.32.0",
-    "@voltro/protocol": "0.32.0"
+    "@voltro/database": "0.34.0",
+    "@voltro/plugin-audit": "0.34.0",
+    "@voltro/protocol": "0.34.0"
   },
   "peerDependencies": {
     "effect": "^3.22.0"