@vibes.diy/prompts 2.5.18 → 2.5.26

package/llms/fireproof.md

@@ -614,7 +614,7 @@ Channel `_id` is the channel identifier everywhere. The access function uses `do
 
 ### Example: Per-object sharing (collaborate on your own objects, no admin)
 
-A list app where every signed-in user makes their own lists, sees only their own, and can invite anyone to collaborate on a specific list — peer to peer, with no app admin in the loop. The pattern: **a channel per object** (`list:<id>`); the creator grants themselves that channel at creation; child docs (items) gate on `ctx.requireAccess` of the list's channel; any current member shares the list by granting another user the same channel. Membership is direct `grant.users`, so each viewer's access scales with their own memberships.
+Reach for this whenever the prompt says **invite, join, collaborate, share with, together, with my partner/team** — a shared shopping list you invite a partner to, a whiteboard people can join, a trip a group plans together. A list app where every signed-in user makes their own lists, sees only their own, and can invite anyone to collaborate on a specific list — peer to peer, with no app admin in the loop. The pattern: **a channel per object** (`list:<id>`); the creator grants themselves that channel at creation; child docs (items) gate on `ctx.requireAccess` of the list's channel, so **any member edits any item**; any current member shares the list by granting another user the same channel. Membership is direct `grant.users`, so each viewer's access scales with their own memberships.
 
 access.js
 
@@ -654,7 +654,46 @@ export default function (doc, oldDoc, user, ctx) {
 }
 ```
 
-To invite someone who isn't a member yet without knowing their handle in advance, invert the flow with a request doc: a `request` type takes **no** `ctx.requireAccess` (any signed-in user may create one — their handle is `user.userHandle`, unforgeable) and routes to the list channel `ch(doc.listId)`, where current members read it (the requester can't read their own request back — they aren't a member yet — which is fine; they just wait to be granted). A member then writes the `share` above to approve. The UI gates each surface with `useVibe("lists").can` and reflects which lists the viewer can see with `access.hasChannel(...)`.
+To invite someone who isn't a member yet without knowing their handle in advance, invert the flow with a request doc: a `request` type takes **no** `ctx.requireAccess` (any signed-in user may create one — their handle is `user.userHandle`, unforgeable) and routes to the list channel `ch(doc.listId)`, where current members read it (the requester can't read their own request back — they aren't a member yet — which is fine; they just wait to be granted). A member then writes the `share` above to approve.
+
+App.jsx — `access.hasChannel()` shows only the lists the viewer belongs to; `useVibe("lists").can` gates each write surface (create list, add item, invite peer):
+
+```jsx
+<<<<<<< SEARCH
+  const { database, useLiveQuery, access } = useFireproof("notes");
+=======
+  const { database, useLiveQuery, access } = useFireproof("lists");
+  const { me, can } = useVibe("lists");
+  const { docs: lists } = useLiveQuery("type", { key: "list" });
+  const visible = lists.filter((l) => access.hasChannel(`list:${l._id}`));
+  // Each member edits any item — items gate on requireAccess(list:<id>), not authorHandle.
+  const canAddItem = (list) => can.create({ type: "item", listId: list._id, authorHandle: me?.userHandle }).ok;
+  const canShare = (list) => can.create({ type: "share", listId: list._id, invitee: "x" }).ok;
+>>>>>>> REPLACE
+```
+
+```jsx
+<<<<<<< SEARCH
+      {viewer && <button onClick={addNote}>+ note</button>}
+=======
+      {/* create list — any signed-in visitor can start their own */}
+      {can.create({ type: "list", author: me?.userHandle }).ok && (
+        <button onClick={() => database.put({ type: "list", author: me.userHandle, name: "new list" })}>
+          + new list
+        </button>
+      )}
+
+      {visible.map((list) => (
+        <section key={list._id}>
+          <h3>{list.name}</h3>
+          {/* add-item form is shown only when the access fn would accept the write */}
+          {canAddItem(list) && <AddItemForm listId={list._id} />}
+          {/* invite peer — only shown to members of this list */}
+          {canShare(list) && <ShareForm listId={list._id} />}
+        </section>
+      ))}
+>>>>>>> REPLACE
+```
 
 ---
 
@@ -764,6 +803,42 @@ export function chat(doc, oldDoc, user, ctx) {
 
 This single access function handles three document types: **channel-meta** — owner creates a channel and grants access to listed members, **message** — only the author can post, must already have channel access, **channel-invite** — any channel member can invite others; deleting the invite revokes the grant.
 
+App.jsx — show only channels the viewer is in (`access.hasChannel`), gate the compose box and invite form on `useVibe().can`:
+
+```jsx
+<<<<<<< SEARCH
+  const { database, useLiveQuery, access } = useFireproof("notes");
+=======
+  const { database, useLiveQuery, access } = useFireproof("chat");
+  const { me, can } = useVibe("chat");
+  const { docs: channels } = useLiveQuery("type", { key: "channel-meta" });
+  // Filter to channels the viewer has been granted into — non-members never see them in the list.
+  const myChannels = channels.filter((ch) => access.hasChannel(ch._id));
+  const [channelId, setChannelId] = React.useState(null);
+  const canPost = can.create({ type: "message", channelId, userHandle: me?.userHandle });
+  const canInvite = can.create({ type: "channel-invite", channelId, senderHandle: me?.userHandle, inviteeHandle: "x" });
+>>>>>>> REPLACE
+```
+
+```jsx
+<<<<<<< SEARCH
+      {viewer && <Compose onSend={send} />}
+=======
+      {/* sidebar lists only the channels the viewer is in */}
+      <nav>{myChannels.map((ch) => <button key={ch._id} onClick={() => setChannelId(ch._id)}>{ch.name}</button>)}</nav>
+
+      {/* compose is shown only when the viewer is a member of the selected channel */}
+      {channelId && canPost.ok ? (
+        <Compose onSend={(text) => database.put({ type: "message", channelId, userHandle: me.userHandle, text })} />
+      ) : (
+        <p>{canPost.reason || "Pick a channel"}</p>
+      )}
+
+      {/* any member of this channel may invite a peer */}
+      {channelId && canInvite.ok && <InviteForm channelId={channelId} senderHandle={me.userHandle} />}
+>>>>>>> REPLACE
+```
+
 ### Example: Anonymous survey with role-gated results
 
 access.js
@@ -799,6 +874,45 @@ export function survey(doc, oldDoc, user, ctx) {
 
 Key patterns: `allowAnonymous: true` on survey-response lets unauthenticated visitors submit, `grant.public` on final-results makes them readable by any member without a specific channel grant, and the **singleton grant doc** pattern (survey-config) wires role-to-channel access in one place.
 
+App.jsx — anonymous-friendly submit form, owner-only config panel, role-gated results view:
+
+```jsx
+<<<<<<< SEARCH
+  const { database } = useFireproof("notes");
+=======
+  const { database, useLiveQuery, access } = useFireproof("survey");
+  const { me, can } = useVibe("survey");
+  // Submit form is shown for anyone — allowAnonymous makes this can.create return ok for null user.
+  const canSubmit = can.create({ type: "survey-response", question: "q1", answer: "" });
+  // Owner-only — survey-config rule calls ctx.requireRole("owner").
+  const canConfigure = can.create({ type: "survey-config" });
+  const { docs: results } = useLiveQuery("type", { key: "final-results" });
+>>>>>>> REPLACE
+```
+
+```jsx
+<<<<<<< SEARCH
+      <input value={answer} onChange={(e) => setAnswer(e.target.value)} />
+=======
+      {/* anyone (signed in OR anonymous) can submit — only stamp authorHandle when present */}
+      {canSubmit.ok ? (
+        <form onSubmit={(e) => {
+          e.preventDefault();
+          database.put({ type: "survey-response", question: "q1", answer, ...(me && { authorHandle: me.userHandle }) });
+        }}>
+          <input value={answer} onChange={(e) => setAnswer(e.target.value)} />
+          <button type="submit">Submit</button>
+        </form>
+      ) : <p>{canSubmit.reason}</p>}
+
+      {/* owner-only admin to wire up the feedback-team role */}
+      {canConfigure.ok && <ConfigPanel />}
+
+      {/* results render only for users with the feedback-team role — access.hasChannel filters them in */}
+      {results.filter((r) => access.hasChannel(r._id)).map((r) => <ResultCard key={r._id} doc={r} />)}
+>>>>>>> REPLACE
+```
+
 ### Example: Public guestbook / contact form (anonymous writes)
 
 When the prompt says **anyone can sign / submit without logging in** (a guestbook, a contact form, an RSVP), do **not** throw on `!user` — return `allowAnonymous: true` so the write is accepted for anonymous visitors. `useVibe().can.create(...)` then returns `ok` for an anonymous viewer, and the form shows instead of a sign-in wall. Stamp `authorHandle` only when there is a user.
@@ -818,6 +932,43 @@ export function guestbook(doc, oldDoc, user, ctx) {
 
 In `App.jsx`, gate the form on `useVibe("guestbook").can.create({ type: "entry" }).ok` (true for anon here) and stamp `authorHandle: me?.userHandle` only when signed in. Without `allowAnonymous: true` the runtime rejects the null-user write even though the function didn't throw — so the guestbook would silently require login, the exact miss to avoid.
 
+App.jsx — gate the form on `can.create({ type: "entry" }).ok`, which is true even when nobody is signed in:
+
+```jsx
+<<<<<<< SEARCH
+  const { database } = useFireproof("notes");
+=======
+  const { database, useLiveQuery } = useFireproof("guestbook");
+  const { me, can } = useVibe("guestbook");
+  const { docs: entries } = useLiveQuery("type", { key: "entry" });
+  // allowAnonymous: true on the access fn → this returns ok for an anon viewer.
+  // The form is visible from first load, no sign-in wall.
+  const canSign = can.create({ type: "entry", message: "" });
+>>>>>>> REPLACE
+```
+
+```jsx
+<<<<<<< SEARCH
+      <SignInGate>
+        <input value={message} onChange={(e) => setMessage(e.target.value)} />
+      </SignInGate>
+=======
+      {canSign.ok ? (
+        <form onSubmit={(e) => {
+          e.preventDefault();
+          // Stamp authorHandle only when signed in — anon entries simply omit it.
+          database.put({ type: "entry", message, createdAt: Date.now(), ...(me && { authorHandle: me.userHandle }) });
+          setMessage("");
+        }}>
+          <input value={message} onChange={(e) => setMessage(e.target.value)} placeholder="Leave a note" />
+          <button type="submit">Sign</button>
+        </form>
+      ) : <p>{canSign.reason}</p>}
+
+      {entries.map((e) => <li key={e._id}>{e.message} — {e.authorHandle || "anonymous"}</li>)}
+>>>>>>> REPLACE
+```
+
 ### Multiple databases in one file
 
 Each named export gates its own database. A single `/access.js` can gate all databases the app uses:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "2.5.18",
+  "version": "2.5.26",
   "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.18",
-    "@vibes.diy/identity": "^2.5.18",
-    "@vibes.diy/use-vibes-types": "^2.5.18",
+    "@vibes.diy/call-ai-v2": "^2.5.26",
+    "@vibes.diy/identity": "^2.5.26",
+    "@vibes.diy/use-vibes-types": "^2.5.26",
     "arktype": "~2.2.1",
     "json-schema-faker": "~0.6.2"
   },

package/system-prompt-initial.md

@@ -77,6 +77,18 @@ Target ~40–60 lines. The shell should look like a real app with empty sections
 
 `ctx.requireAccess(channel)` gates on **membership** (a `grant.users`/`grant.roles` grant), not `grant.public` (read-only) — so an open channel anyone signed-in may post to must not gate writes on it; check the author and route the doc. For writes needing no sign-in ("anyone can sign/submit"), return `allowAnonymous: true` instead of throwing on `!user`. A grant/member doc must also return `channels` (route it to an owner-readable admin channel) — a channel-less result is rejected. On updates, also check the old author field (`oldDoc.authorHandle`/`userHandle`/`senderHandle`) so a writer can't overwrite or re-author someone else's doc.
 
+**Build the permission model around what a newcomer should be able to do.** When a stranger opens the app, they should immediately be able to do the thing it's _for_ — add their own todos, post to the board, drop a pin, read the blog. So the default is: every signed-in visitor is a first-class participant who creates their own objects and edits what they created (`doc.authorHandle === user.userHandle`, checking `oldDoc` on updates), from first load, with no one needing to let them in.
+
+**Most apps are multiplayer even when they sound solo — match the shape to the model.** A todo list, a habit tracker, a journal, a notes app, a workout log, or a budget gives each visitor _their own_: an `authorHandle` check routes each user's docs to a per-user channel `user:<handle>`, so a stranger who opens it starts their own from first load. A shared board, wall, guestbook, or map is author-owned writes + public read: any signed-in visitor authors their own and everyone reads.
+
+**"Invite", "join", "collaborate", "share with", "together", "with my partner/team" → per-object collaboration** — each shared thing is its own space its members reach directly. Use the per-object recipe: a channel per object (`list:<id>`), the creator grants themselves at creation, and child docs gate on `ctx.requireAccess("list:<id>")` so any member edits any child doc in it. A member-authored `share` doc grants a peer the same channel, and a `request` doc — which takes **no** `requireAccess` — lets a not-yet-member ask to join. Keep the _object's own_ author/creator field write-once (`if (oldDoc && doc.author !== oldDoc.author) throw`) and a child's object-id immutable.
+
+When the app is genuinely one person's to publish — a personal blog, an announcements feed — the newcomer's job is to _read_: gate writes with `ctx.requireRole("owner")` (the vibe owner is always auto-seeded into the reserved `owner` role, so this needs no setup) and make reads public. For "author edits their own, owner moderates anyone's" in one branch, let `requireRole` be the fallback: `if (doc.authorHandle !== user.userHandle) ctx.requireRole("owner")` — it only throws when the author check fails, so authors pass for their own docs and the owner passes for any. Gate the UI on `useVibe(dbName).can`, never on `user.isOwner`.
+
+**Sharing objects: channels carry objects, roles carry types.** A channel is one shareable thing (`list:<id>`) — membership in it means "can reach this object." A role is a _kind_ of participant (`author`, `editor`), a small reusable vocabulary. To let people collaborate on _their own_ objects with no admin in the loop: the creator routes the object to its channel and grants themselves access; any member shares it by granting a peer into the same channel; child docs gate on `ctx.requireAccess("list:<id>")`. The reserved `owner` role is the only one auto-seeded — every _other_ role is populated by the app's own grant docs (a member writes a doc whose access-fn output adds another user to a role or channel). So to put someone in a role, write a grant; don't expect a role to be pre-filled.
+
+**Public vs private is the owner's ACL envelope, not your code.** Whether the vibe is open to anyone or restricted to an approved list is a runtime sharing setting the owner toggles — entirely outside `access.js`. Keep `access.js` focused on per-document channel/role logic that works in the accessible-by-default case; its routing is correct whether the vibe runs open or wrapped in a private envelope, so the envelope wraps it unchanged.
+
 **Never put access function code inside an `App.jsx` block** — it will overwrite the React component. The filename line (`access.js` vs `App.jsx`) is how the system knows which file to write.
 
 After the final edit (and `access.js` if applicable), add a short 1-2 sentence message describing the core workflow the app supports.

package/system-prompt.md

@@ -349,6 +349,10 @@ Keep `useViewer` (for `ViewerTag`) on `App`'s first line, and add `useVibe(dbNam
 
 **Build the permission model around what a newcomer should be able to do.** When a stranger opens the app, they should immediately be able to do the thing it's _for_ — add their own todos, post to the board, drop a pin, read the blog. So the default is: every signed-in visitor is a first-class participant who creates their own objects and edits what they created (`doc.authorHandle === user.userHandle`, checking `oldDoc` on updates), from first load, with no one needing to let them in.
 
+**Most apps are multiplayer even when they sound solo — match the shape to the model.** A todo list, a habit tracker, a journal, a notes app, a workout log, or a budget gives each visitor _their own_: an `authorHandle` check routes each user's docs to a per-user channel `user:<handle>`, so a stranger who opens it starts their own from first load. A shared board, wall, guestbook, or map is author-owned writes + public read: any signed-in visitor authors their own and everyone reads.
+
+**"Invite", "join", "collaborate", "share with", "together", "with my partner/team" → per-object collaboration** — each shared thing is its own space its members reach directly. Use the per-object recipe: a channel per object (`list:<id>`), the creator grants themselves at creation, and child docs gate on `ctx.requireAccess("list:<id>")` so any member edits any child doc in it. A member-authored `share` doc grants a peer the same channel, and a `request` doc — which takes **no** `requireAccess` — lets a not-yet-member ask to join. Keep the _object's own_ author/creator field write-once (`if (oldDoc && doc.author !== oldDoc.author) throw`) and a child's object-id immutable.
+
 When the app is genuinely one person's to publish — a personal blog, an announcements feed — the newcomer's job is to _read_: gate writes with `ctx.requireRole("owner")` (the vibe owner is always auto-seeded into the reserved `owner` role, so this needs no setup) and make reads public. For "author edits their own, owner moderates anyone's" in one branch, let `requireRole` be the fallback: `if (doc.authorHandle !== user.userHandle) ctx.requireRole("owner")` — it only throws when the author check fails, so authors pass for their own docs and the owner passes for any. Gate the UI on `useVibe(dbName).can`, never on `user.isOwner`.
 
 **Sharing objects: channels carry objects, roles carry types.** A channel is one shareable thing (`list:<id>`) — membership in it means "can reach this object." A role is a _kind_ of participant (`author`, `editor`), a small reusable vocabulary. To let people collaborate on _their own_ objects with no admin in the loop: the creator routes the object to its channel and grants themselves access; any member shares it by granting a peer into the same channel; child docs gate on `ctx.requireAccess("list:<id>")`. The reserved `owner` role is the only one auto-seeded — every _other_ role is populated by the app's own grant docs (a member writes a doc whose access-fn output adds another user to a role or channel). So to put someone in a role, write a grant; don't expect a role to be pre-filled.