@vibes.diy/prompts 10.8.4 → 11.0.0

package/llms/access.md

@@ -31,11 +31,18 @@ type AccessDescriptor = {
     roles?: Record<roleName, string[]>; // role → channel grants (reduced by union)
     public?: string[]; // member-public read — any member, no channel grant needed
   };
+  audience?: { followersOf: userHandle } | { mutualsOf: userHandle }; // platform follow-graph reach
   expiry?: string | number | null; // ISO date or unix seconds
   allowAnonymous?: boolean; // opt-in for null-user writes
 };
 ```
 
+`audience` is the one field resolved against the PLATFORM follow graph instead of this app's own grants: add it to an otherwise normal result, always keyed on the live writer (`audience: { followersOf: user.userHandle }`), and the platform decides at read time who that reaches. The arm you emit is only a ceiling — the subject's own visibility setting for this app picks the actual rung (off / their followers / anyone at all), and it can shrink that reach but never grow it. The full teaching — which arm, the three-rung ladder, the `useSocial()` / `useInterest()` surfaces, and the copy rules that go with them — is in the social section of the system prompt; don't re-derive it here.
+
+### Person or place: `audience` or `grant`
+
+The question that decides which one a doc wants is whose thing it is: **personal content belongs to the PERSON; a contribution to a shared artifact belongs to the PLACE.** Someone's picks, favorites, streaks, or profile items are the person's — give them an `audience` arm keyed on their own handle, so the reach tracks that person's settings and follows them everywhere. Guestbook entries, posts on a communal wall, items on a shared board are the place's — route them to the place's channel with `grant.public` or explicit grants exactly as the rest of this doc shows, unaffected by the author's later profile flips: a guestbook entry doesn't vanish because the signer went private.
+
 ### The ImgGen version-append nuance
 
 The platform predicate `ctx.isImgGenVersionAppend(doc, oldDoc)` accepts exactly one legitimate ImgGen version append by a non-author — prior versions/files and all other fields must be unchanged, so a field you didn't anticipate stays author-protected by default; deletes stay author-only. Because `versions`/`currentVersion` are among the version fields it allows, a non-author can also advance the DISPLAYED version (the shared-generation feature); guard `currentVersion` specifically for author-only display control. Write-once docs can simply `if (oldDoc === null) {} else throw`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "10.8.4",
+  "version": "11.0.0",
   "type": "module",
   "main": "./index.js",
   "description": "",
@@ -24,9 +24,9 @@
   "license": "Apache-2.0",
   "dependencies": {
     "@adviser/cement": "~0.5.34",
-    "@vibes.diy/call-ai-v2": "^10.8.4",
-    "@vibes.diy/identity": "^10.8.4",
-    "@vibes.diy/use-vibes-types": "^10.8.4",
+    "@vibes.diy/call-ai-v2": "^11.0.0",
+    "@vibes.diy/identity": "^11.0.0",
+    "@vibes.diy/use-vibes-types": "^11.0.0",
     "arktype": "~2.2.3",
     "json-schema-faker": "~0.6.2"
   },

package/system-prompt.md

@@ -431,8 +431,28 @@ docs in your database, and never build follow UI state machines.
   channel and let the item's own audience carry it, keeping each `followersOf`/`mutualsOf` subject
   `user.userHandle`. Keep at least one real channel; keep PRIVATE data
   on channels+grant without `audience`; never write channel names starting with `~`.
+- **`followersOf` is a CEILING, not the audience.** The arm your access function emits says who this
+  doc may reach at most; WHO actually receives it is the subject's own visibility setting for this
+  app, resolved live at read time. Three rungs, per person per app:
+  - **not armed** — nobody but the writer. Arming is the master off-switch (see
+    `requestFollowersAccess()` below), and it is ON by default for a normal sharing app.
+  - **armed, visibility `"public"`** — everyone, signed-out visitors included. Both arms widen to
+    everyone at this rung.
+  - **armed, visibility `"followers"`** — the graph only: `followersOf` reaches the subject's
+    followers, `mutualsOf` only people they follow back. This is the default rung.
+
+  A subject's own setting can only SHRINK the reach, never grow it past what your arm allows — and a
+  privacy-sensitive app (a diary, a personal tracker) never reaches the public rung at all. So pick the arm
+  for the widest audience the content could ever legitimately want (`followersOf` for shared picks,
+  `mutualsOf` for both-directions-only), emit it the same way in every branch, and let the person's
+  own setting choose the rung. Your code never reads the rung to decide what to emit.
 - Copy: "followers can see your picks" / "people you follow" — never "friends".
   Following someone is low-stakes (it reveals none of YOUR data) — no confirm dialogs.
+  Next to a control that widens reach, say what it actually does: "Anyone can see this while your
+  profile is public"; for one that narrows it, "Going private keeps your existing followers" —
+  never "removes you from feeds". Turning sharing off, unfollowing, and blocking all mean the other
+  side **stops receiving** your new content; never write copy promising their existing copies are
+  erased or that they "can no longer see" what they already have.
 - `useSocial()` also returns `followersEnabled: boolean` (read-only: can THIS app's
   audience-gated docs currently reach the viewer's followers?) and
   `requestFollowersAccess(): Promise<void>` (the preflight consent path). For a normal app,
@@ -440,7 +460,7 @@ docs in your database, and never build follow UI state machines.
   audience UI on it or make users flip a switch first. It is `false` only for the minority:
   the viewer explicitly turned this app off, chose a never-share standing preference, or the app
   is marked privacy-sensitive (a diary, a personal tracker), where sharing stays off until a
-  deliberate opt-in. Show a small "open to followers so followers can see your picks" callout
+  deliberate opt-in. Show a small "open to followers so people can see your picks" callout
   wired to `requestFollowersAccess()` ONLY when `!followersEnabled` (that minority), for an app
   whose whole point is sharing; for a privacy-sensitive app this is the deliberate-consent
   prompt. `requestFollowersAccess()` resolves quietly with no state change (including when the
@@ -448,14 +468,33 @@ docs in your database, and never build follow UI state machines.
   on every render, or more than once per explicit user action. Don't invent a callout an app's
   own privacy doesn't call for.
 - For an explicit visibility control (a settings toggle inside your app), `useSocial()` returns
-  `visibility: "followers" | "private"` (read-only: the effective level for THIS viewer/app —
-  `followersEnabled` is just `visibility !== "private"`) and
-  `setVisibility(level): Promise<void>` to change it. `"followers"` means followers can see;
-  `"private"` turns this app's sharing off for the viewer. Call `setVisibility` only from an
-  explicit user action (a toggle), then re-render from `visibility` — it resolves after the
-  change lands. (`"public"`/world-readable is not settable yet; don't offer it.) Most apps don't
-  need this — the default already shares with followers; reach for it only when the app's own UX
-  wants an in-app privacy switch.
+  `visibility: "public" | "followers" | "private"` (read-only: the effective level for THIS
+  viewer/app — `followersEnabled` is just `visibility !== "private"`) and
+  `setVisibility(level): Promise<void>` to change it. `"public"` means anyone can see, follower or
+  not, signed in or not; `"followers"` means the graph only (the default); `"private"` turns this
+  app's sharing off for the viewer. All three are settable — a three-rung control ("Anyone" /
+  "Followers" / "Only me") is the right shape for an app built around showing people your stuff.
+  The exception is a privacy-sensitive app (a diary, a personal tracker): a NEW `"public"` request
+  on one is REFUSED — the level stays exactly where it was, and like every other refusal
+  `setVisibility` resolves quietly with no error, so an "Anyone" rung there is a button that
+  silently does nothing. On a privacy-sensitive app, leave the "Anyone" rung out (or disable it)
+  and offer "Followers" / "Only me" only. (Read side, for completeness: a level stored `"public"`
+  before an app became sensitive is capped down to `"followers"` when anyone reads it.) Whichever
+  rungs you render, re-render from `visibility` after the await and show what actually took effect,
+  never what you asked for. Call `setVisibility` only from an explicit user action (a toggle).
+  Most apps don't need this — the default already shares with followers; reach for it only when
+  the app's own UX wants an in-app privacy switch.
+- To show ANOTHER person's content on a profile page, hold an interest in them while their page is
+  open: `useInterest(handle)` from `use-vibes` (`useInterest(handle)` at the top of the page
+  component; a `null`/absent handle is a no-op, so call it unconditionally while the route param
+  resolves). Their content streams into this replica while you hold it and stops when the component
+  unmounts. It works for signed-out visitors too — a scanned QR code is often first contact — so
+  never gate it on being signed in, and never call it for the viewer's own content (you already
+  have that). Interest is DELIVERY only: the server hands over exactly what this viewer could
+  already read, so it never widens who may see anything, and asking about a private subject simply
+  delivers nothing. Dropping it is not revocation — docs already pulled stay put; what stops is
+  future delivery. Following is the durable upgrade: a follower's replica keeps pulling with no
+  interest held, so present follow as "keep seeing their picks", not as a permission request.
 - To grow the graph, `useSocial()` returns
   `invite(email: string): Promise<"ok" | "rate-limited" | "cancelled">` — asks the PLATFORM to
   email a non-user an invitation to connect with the viewer. The platform shows a consent prompt,