@vibes.diy/prompts 3.0.1 → 3.0.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "3.0.1",
+  "version": "3.0.3",
   "type": "module",
   "main": "./index.js",
   "description": "",
@@ -25,13 +25,12 @@
   "dependencies": {
     "@adviser/cement": "~0.5.34",
     "@fireproof/core": "~0.24.19",
-    "@fireproof/core-runtime": "~0.24.19",
     "@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": "^3.0.1",
-    "@vibes.diy/identity": "^3.0.1",
-    "@vibes.diy/use-vibes-types": "^3.0.1",
+    "@vibes.diy/call-ai-v2": "^3.0.3",
+    "@vibes.diy/identity": "^3.0.3",
+    "@vibes.diy/use-vibes-types": "^3.0.3",
     "arktype": "~2.2.1",
     "json-schema-faker": "~0.6.2"
   },

package/system-prompt-initial.md

@@ -107,6 +107,8 @@ export function board(doc, oldDoc, user, ctx) {
 
 **Most apps are collaborative even when they sound solo — give each person their own, and let them invite others in.** A todo list, a habit tracker, a journal, a notes app, a workout log, or a budget belongs to its creator by default: route each list/log/board to its **own object channel** (`list:<id>`/`log:<id>`) and self-grant it at creation (`grant: { users: { [user.userHandle]: [ch] } }`), with the `authorHandle` create + `oldDoc` author checks so each item stays on its object. Then let the owner invite a chosen friend in: a `share` doc the owner authors grants that friend the same channel (`grant: { users: { [doc.invitee]: [ch] } }`), so they collaborate on that one list — sharing a single list or a whole space is the same grant at a different node of the object graph. The solo-sounding ones are no different — a habit tracker shares a streak with an accountability buddy, a journal opens an entry to a coach, a budget invites a partner — each is your object to share with chosen people when you want. A wall, guestbook, or map where each visitor adds their _own_ items is author-owned writes + public read: any signed-in visitor authors their own and everyone reads.
 
+**When a user's work is private by default, show it — and offer a way to publish.** If everything a user does routes to a channel only they can read (a per-user `user:<handle>`, a private journal/notes/tracker with no `grant.public`), the UI must say so: a small, persistent "Only you can see this" / "Private to you" cue near their content, so no one wonders who's watching their unfinished work. Then, where sharing fits the app, give them a publish control — but publish at the granularity of a **channel**, not a doc: channels are the unit of read isolation, so adding `grant.public` to the shared `user:<handle>` channel would expose _every_ private item on it, not just the one they meant to share. To publish a single item, route it to its **own** channel and flip only that channel's read-grant from a `visibility` field the access fn reads — exactly the per-item-channel shape the worked example below uses (`const ch = \`entry:${doc._id}\`; const grant = { users: { [user.userHandle]: [ch] } }; if (doc.visibility === "public") grant.public = [ch];`) — for anonymous visitors, or grant a shared app channel for all granted members. Gate the control on `useVibe(dbName).can`, and reflect the result back in the affordance ("Published — anyone can see this", with an unpublish to flip it back). Making the user's _whole_ space public is fine when that's the intent; silently leaking their other private items by publishing one is the trap to avoid. **If the app brief is private-only/confidential — a journal, private notes, a health tracker — do not add publish/share controls.** Keep publish opt-in: for private-only apps, omit the publish UI entirely; for share-capable apps, make publish one tap for user-selected items.
+
 **Worked example — a shared catalog people track against, with per-thing visibility (a social habit app, a reading challenge, a fitness ladder).** The catalog items are public objects anyone proposes; each person's progress is their own; and each person chooses — _once per item, never per entry_ — whether their streak is public (on the leaderboard) or buddy-only. The visibility choice lives on a per-`(person, item)` **tracking** record that sets the read-grant the entries routed to it inherit.
 
 access.js

package/system-prompt.md

@@ -353,6 +353,8 @@ Keep `useViewer` (for `ViewerTag`) on `App`'s first line, and add `useVibe(dbNam
 
 **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.
 
+**When a user's work is private by default, show it — and offer a way to publish.** If everything a user does routes to a channel only they can read (a per-user `user:<handle>`, a private journal/notes/tracker with no `grant.public`), the UI must say so: a small, persistent "Only you can see this" / "Private to you" cue near their content, so no one wonders who's watching their unfinished work. Then, where sharing fits the app, give them a publish control — but publish at the granularity of a **channel**, not a doc: channels are the unit of read isolation, so adding `grant.public` to the shared `user:<handle>` channel would expose _every_ private item on it, not just the one they meant to share. To publish a single item, route it to its **own** channel and flip only that channel's read-grant from a `visibility` field the access fn reads — `const ch = \`entry:${doc._id}\`; const grant = { users: { [user.userHandle]: [ch] } }; if (doc.visibility === "public") grant.public = [ch]; return { channels: [ch], grant };` — for anonymous visitors, or grant a shared app channel for all granted members. Gate the control on `useVibe(dbName).can` and reflect the result back in the affordance ("Published — anyone can see this", with an unpublish to flip it back). Making the user's _whole_ space public is fine when that's the intent; silently leaking their other private items by publishing one is the trap to avoid. **If the app brief is private-only/confidential — a journal, private notes, a health tracker — do not add publish/share controls.** Keep publish opt-in: for private-only apps, omit the publish UI entirely; for share-capable apps, make publish one tap for user-selected items.
+
 **"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 a publication — a blog, a magazine, an announcements feed — **owner-only writing is a dead end**: don't gate the posts on `ctx.requireRole("owner")`. The right model is **public read + author-owned posts, with the owner controlling the author roster**. The owner approves authors with a grant doc — the **one** place `requireRole("owner")` belongs (gating who may author, never the content): `if (doc.type === "author") { ctx.requireRole("owner"); return { channels: ["pub:authors"], grant: { users: { [doc.authorHandle]: ["pub:authors"] }, roles: { owner: ["pub:authors"] } } }; }` (granting the owner role into the channel lets the owner publish too). A post then gates on `ctx.requireAccess("pub:authors")` (membership) and is author-owned, so once approved each author's post is _their own_ object — only they edit it, and they moderate the comments on it: `if (doc.type === "comment") { const mine = doc.authorHandle === user.userHandle, iModerate = doc.postAuthorHandle === user.userHandle; if (oldDoc ? !(mine || iModerate) : !mine) throw { forbidden: true }; }`. A personal blog is just this with a roster of one. Reads are public via `grant.public`. Gate the UI on `useVibe(dbName).can`.