@vibes.diy/prompts 14.3.135 → 14.3.138

package/llms/access.md

@@ -1045,7 +1045,7 @@ Reach for this when the person makes a *second* thing of the same kind, or a thi
 - **The object is a stored document written by the person's own action** — a submit that names it ("Start a board"), a tap on a template, a pick from a list. It has its own branch in `access.js`, carries `creatorHandle`, and its `_id` names the channel its records route to (`board:<_id>`). The creator holds that channel and its admin channel from the object's own write, so they remain a member when the board is empty, when a collaborator writes first, and after the last creator-authored item is deleted. Nothing creates it on load or on mount. **The child doc stores that board id rather than having each writer derive one**: the create uses the displayed object's id and the rule holds it fixed from then on, so a card stays on the board its creator put it on however many people edit it later.
 - **Membership is a `member` doc, and picking the friend is `HandleInput`** (`useViewer()`, see use-viewer.md — the platform's people-picker, so the handle on the doc is one the platform resolved). The doc grants the named person the object's channel: `` grant: { users: { [doc.userHandle]: [chan] } } ``.
 - **The object's creator is its admin**, held on a second channel (`` `${chan}/admin` ``) that the creator self-grants at creation. Adding a member is gated on that admin channel, so members collaborate and the creator decides who joins. The app owner holds no place in any of this: every rule reads `user.userHandle` or the object's own `creatorHandle`.
-- **Recipients can select every readable object.** The ordinary object query already applies the access rules, including grants from independent membership records. Its complete result supplies the picker. Prefer the person's own object as the initial selection while keeping invited objects selectable alongside it. Resolve the selected id against the current readable results on each render, so a revoked object leaves both the picker and the content view. Use the selected object's id for child queries, new content, and invitations; `can` continues to gate each write.
+- **Recipients can select every readable object.** The ordinary object query already applies the access rules, including grants from independent membership records. Its complete result supplies the picker. Prefer the person's own object as the initial selection once it holds something, keeping invited objects selectable alongside it. A person with nothing of their own yet (the friend who just followed an invite) opens on the object shared with them, so their first screen is the trip, board or list they were invited to rather than an empty one of their own. This matters most when each person's own space exists without being created (a list per handle): an empty implicit space never outranks a shared object. Resolve the selected id against the current readable results on each render, so a revoked object leaves both the picker and the content view. Use the selected object's id for child queries, new content, and invitations; `can` continues to gate each write.
 
 ### `access.js`
 ```js partial

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "14.3.135",
+  "version": "14.3.138",
   "type": "module",
   "main": "./index.js",
   "exports": {
@@ -39,10 +39,10 @@
   "license": "Apache-2.0",
   "dependencies": {
     "@adviser/cement": "~0.5.34",
-    "@vibes.diy/api-types": "14.3.135",
-    "@vibes.diy/call-ai-v2": "14.3.135",
-    "@vibes.diy/identity": "14.3.135",
-    "@vibes.diy/use-vibes-types": "14.3.135",
+    "@vibes.diy/api-types": "14.3.138",
+    "@vibes.diy/call-ai-v2": "14.3.138",
+    "@vibes.diy/identity": "14.3.138",
+    "@vibes.diy/use-vibes-types": "14.3.138",
     "arktype": "~2.2.6",
     "json-schema-faker": "~0.6.3"
   },