@cosmicdrift/kumiko-bundled-features 0.5.1 → 0.5.2

package/CHANGELOG.md

@@ -1,5 +1,29 @@
 # @cosmicdrift/kumiko-bundled-features
 
+## 0.5.2
+
+### Patch Changes
+
+- 4f0d781: fix(tenant): updateMemberRoles erlaubt "system"-Rolle (symmetrisch zu create)
+
+  Drift innerhalb des tenant-Features: `tenant:write:create` akzeptierte
+  `["system", "SystemAdmin"]`, `tenant:write:update-member-roles` aber
+  nur `["SystemAdmin"]`. Konsequenz: ops-tooling und seed-migrations
+  (`createSystemUser` mit `roles: ["system"]`) konnten den Handler nicht
+  aufrufen — `access_denied`.
+
+  Live entdeckt beim ersten Driver-Sample der es-ops Phase 1: publicstatus
+  seed `2026-05-20-fix-admin-roles.ts` rief `update-member-roles` via
+  `systemWriteAs` → access_denied → Pod CrashLoopBackOff.
+
+  Plus access-rule-Pinning-Test in `tenant.integration.ts`-scenario-7.
+
+- Updated dependencies [4f0d781]
+  - @cosmicdrift/kumiko-framework@0.5.2
+  - @cosmicdrift/kumiko-dispatcher-live@0.5.2
+  - @cosmicdrift/kumiko-renderer@0.5.2
+  - @cosmicdrift/kumiko-renderer-web@0.5.2
+
 ## 0.5.1
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cosmicdrift/kumiko-bundled-features",
-  "version": "0.5.1",
+  "version": "0.5.2",
   "description": "Built-in features — tenant, user, auth, delivery. The stuff you'd rewrite anyway, already typed.",
   "license": "BUSL-1.1",
   "author": "Marc Frost <marc@cosmicdriftgamestudio.com>",
@@ -74,10 +74,10 @@
     "@aws-sdk/client-s3": "^3.1045.0",
     "@aws-sdk/lib-storage": "^3.1045.0",
     "@aws-sdk/s3-request-presigner": "^3.1045.0",
-    "@cosmicdrift/kumiko-dispatcher-live": "0.5.1",
-    "@cosmicdrift/kumiko-framework": "0.5.1",
-    "@cosmicdrift/kumiko-renderer": "0.5.1",
-    "@cosmicdrift/kumiko-renderer-web": "0.5.1",
+    "@cosmicdrift/kumiko-dispatcher-live": "0.5.2",
+    "@cosmicdrift/kumiko-framework": "0.5.2",
+    "@cosmicdrift/kumiko-renderer": "0.5.2",
+    "@cosmicdrift/kumiko-renderer-web": "0.5.2",
     "@mollie/api-client": "^4.5.0",
     "@node-rs/argon2": "^2.0.2",
     "@types/nodemailer": "^8.0.0",

package/src/tenant/__tests__/tenant.integration.ts

@@ -337,6 +337,11 @@ describe("scenario 7: access rules on handlers", () => {
     expect(rolesOf(stack.registry.getWriteHandler(TenantHandlers.disable)?.access)).toEqual([
       "SystemAdmin",
     ]);
+    // updateMemberRoles akzeptiert "system" (für seed-migrations + ops-tooling)
+    // PLUS "SystemAdmin" (echter Operator-Pfad). Symmetrisch zu create.
+    expect(
+      rolesOf(stack.registry.getWriteHandler(TenantHandlers.updateMemberRoles)?.access),
+    ).toEqual(["system", "SystemAdmin"]);
     expect(rolesOf(stack.registry.getQueryHandler(TenantQueries.list)?.access)).toEqual([
       "SystemAdmin",
     ]);

package/src/tenant/handlers/update-member-roles.write.ts

@@ -16,7 +16,11 @@ export const updateMemberRolesWrite = defineWriteHandler({
     tenantId: z.string(),
     roles: z.array(z.string()).min(1),
   }),
-  access: { roles: ["SystemAdmin"] },
+  // "system" + "SystemAdmin" — symmetrisch zu tenant:write:create. System-
+  // User (createSystemUser, roles=["system"]) braucht den Access für seed-
+  // migrations + andere ops-tooling-Pfade. SystemAdmin ist der echte
+  // human-Operator-Pfad über die UI.
+  access: { roles: ["system", "SystemAdmin"] },
   handler: async (event, ctx) => {
     const db = ctx.db;
     const existing = await fetchOne(