@vibes.diy/prompts 8.0.7 → 8.0.9

package/package.json

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

package/system-prompt-initial-oneshot.md

@@ -302,15 +302,20 @@ docs in your database, and never build follow UI state machines.
   on channels+grant without `audience`; never write channel names starting with `~`.
 - 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.
-- `useSocial()` also returns `followersEnabled: boolean` (read-only: is THIS app currently
-  armed to share the viewer's own activity with followers?) and
-  `requestFollowersAccess(): Promise<void>` (invites the platform's consent prompt for this
-  app; resolves quietly with no state change if the viewer already declined or opted out —
-  never call it in a loop, on every render, or more than once per explicit user action). An
-  app whose whole point is sharing with followers (a picks list, a public-feeling log) shows a
-  small callout when `!followersEnabled` — "open to followers so friends can see your picks" —
-  wired to this action; an app that's inherently private (a diary, a personal tracker) renders
-  nothing here at all. Don't invent a callout an app's own privacy doesn't call for.
+- `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,
+  `followersEnabled` is ON by default — sharing with followers just works, so DON'T gate your
+  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 policy, 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 friends 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
+  app is already enabled, or the viewer already declined/opted out) — never call it in a loop,
+  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.
 - 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,

package/system-prompt-initial.md

@@ -303,15 +303,20 @@ docs in your database, and never build follow UI state machines.
   on channels+grant without `audience`; never write channel names starting with `~`.
 - 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.
-- `useSocial()` also returns `followersEnabled: boolean` (read-only: is THIS app currently
-  armed to share the viewer's own activity with followers?) and
-  `requestFollowersAccess(): Promise<void>` (invites the platform's consent prompt for this
-  app; resolves quietly with no state change if the viewer already declined or opted out —
-  never call it in a loop, on every render, or more than once per explicit user action). An
-  app whose whole point is sharing with followers (a picks list, a public-feeling log) shows a
-  small callout when `!followersEnabled` — "open to followers so friends can see your picks" —
-  wired to this action; an app that's inherently private (a diary, a personal tracker) renders
-  nothing here at all. Don't invent a callout an app's own privacy doesn't call for.
+- `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,
+  `followersEnabled` is ON by default — sharing with followers just works, so DON'T gate your
+  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 policy, 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 friends 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
+  app is already enabled, or the viewer already declined/opted out) — never call it in a loop,
+  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.
 - 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,

package/system-prompt.md

@@ -473,15 +473,20 @@ docs in your database, and never build follow UI state machines.
   on channels+grant without `audience`; never write channel names starting with `~`.
 - 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.
-- `useSocial()` also returns `followersEnabled: boolean` (read-only: is THIS app currently
-  armed to share the viewer's own activity with followers?) and
-  `requestFollowersAccess(): Promise<void>` (invites the platform's consent prompt for this
-  app; resolves quietly with no state change if the viewer already declined or opted out —
-  never call it in a loop, on every render, or more than once per explicit user action). An
-  app whose whole point is sharing with followers (a picks list, a public-feeling log) shows a
-  small callout when `!followersEnabled` — "open to followers so friends can see your picks" —
-  wired to this action; an app that's inherently private (a diary, a personal tracker) renders
-  nothing here at all. Don't invent a callout an app's own privacy doesn't call for.
+- `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,
+  `followersEnabled` is ON by default — sharing with followers just works, so DON'T gate your
+  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 policy, 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 friends 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
+  app is already enabled, or the viewer already declined/opted out) — never call it in a loop,
+  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.
 - 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,