@vibes.diy/prompts 2.5.15 → 2.5.16

package/llms/fireproof.md

@@ -521,6 +521,35 @@ export default function App() {
 
 The pattern: `useVibe().can` gates every write surface — including owner-only management, which the access function enforces via `if (!user.isOwner) throw` so `can.create({ type: "roleGrant", … })` is false for non-owners. `access.hasChannel()` reflects display-only membership, and `isOwner` is a display hint only, never the write gate. The access function is the server-side authority — `useVibe().can` is how the UI reflects its decisions for writes.
 
+**Owner-management panels (appoint/revoke moderators, grant/revoke roles) gate on `can.*`, not `isOwner`.** It's tempting to wrap an admin panel in `{isOwner && <ModeratorPanel />}` and have its buttons call `database.put`/`database.del` directly. Don't let `isOwner` be what decides a write — it's the same display hint as everywhere else. Gate each mutating control on the verdict from the doc you'll actually write — appoint on `can.create({ type: "modGrant", role: "moderator", userHandle }).ok`, revoke on `can.delete(grantDoc).ok` — and render `.reason` when denied. `can.*` runs the app's own `access.js` to produce the verdict, so the control's enabled state and message track what the access function decides and stay correct as it grows beyond owner-only (a delegated admin role, say). Gate the panel's *visibility* on those same verdicts too, not `isOwner` alone — otherwise a delegated admin the access function now allows never reaches the controls or their reason.
+
+```jsx
+// Don't: isOwner decides visibility AND the writes are ungated — a non-owner the
+// access function would allow never reaches the controls, and isOwner drifts from access.js
+{isOwner && (
+  <ModeratorPanel>
+    <button onClick={() => database.put({ type: "modGrant", role: "moderator", userHandle })}>Appoint</button>
+    <button onClick={() => database.del(grantDoc._id)}>Revoke</button>
+  </ModeratorPanel>
+)}
+
+// Do: can.* decides visibility AND gates each write, and supplies the denial reason
+const canAppoint = can.create({ type: "modGrant", role: "moderator", userHandle });
+const canRevoke = can.delete(grantDoc);
+{(canAppoint.ok || canRevoke.ok) && (
+  <ModeratorPanel>
+    {canAppoint.ok && (
+      <button onClick={() => database.put({ type: "modGrant", role: "moderator", userHandle })}>Appoint</button>
+    )}
+    {canRevoke.ok ? (
+      <button onClick={() => database.del(grantDoc._id)}>Revoke</button>
+    ) : (
+      <p>{canRevoke.reason}</p>
+    )}
+  </ModeratorPanel>
+)}
+```
+
 ### Example: Channel board with open channels (any member posts)
 
 Channels everyone can read, and any signed-in user can post to. The channel doc is `grant.public` (read for everyone) and the post rule checks only the author — **no `ctx.requireAccess`**, because public is read-only and would block every non-owner. (For a members-only board where the owner appoints who can post, grant a poster role and `requireAccess` it, as in the announcements example above.) The UI uses `access.hasChannel()` to filter which channels to display, and `useVibe().can` to gate writes.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "2.5.15",
+  "version": "2.5.16",
   "type": "module",
   "main": "./index.js",
   "description": "",
@@ -30,9 +30,9 @@
     "@fireproof/core-types-base": "~0.24.19",
     "@fireproof/core-types-protocols-cloud": "~0.24.19",
     "@fireproof/use-fireproof": "~0.24.19",
-    "@vibes.diy/call-ai-v2": "^2.5.15",
-    "@vibes.diy/identity": "^2.5.15",
-    "@vibes.diy/use-vibes-types": "^2.5.15",
+    "@vibes.diy/call-ai-v2": "^2.5.16",
+    "@vibes.diy/identity": "^2.5.16",
+    "@vibes.diy/use-vibes-types": "^2.5.16",
     "arktype": "~2.2.1",
     "json-schema-faker": "~0.6.2"
   },