@vibes.diy/prompts 12.1.0 → 12.1.1

package/llms/backend.md

@@ -81,6 +81,44 @@ than `forbidden` — keep scheduled writes small and well-guarded. `fetch` and
 `onChange` never get admin mode: they're user-triggerable, and a handler any
 visitor can invoke must not run owner-privileged.
 
+### Taking on the authorization job: `config.fetch.unfilteredReads`
+
+Because the `fetch` lane runs as the calling user, a `fetch` handler by default
+reads nothing for a caller with no session, and cannot read an access-fn-bound
+database without an opt-in. Some routes legitimately need to: a calendar feed at
+`GET /_api/faves.ics?t=<token>` is fetched by a calendar app that carries no
+login, and the docs it serves are private to one user. For those, `backend.js`
+can opt in — per database, `fetch` lane only:
+
+```js
+export const config = {
+  fetch: {
+    unfilteredReads: {
+      dbs: ["faves"],
+      why: "serves per-user .ics calendar feeds authorized by an unguessable token",
+    },
+  },
+};
+```
+
+This is an **obligation, not a convenience**. Inside that handler, for those
+databases, you are taking on the authorization job the platform normally does:
+both the anonymous refusal and the access-function scoping come off, so
+`ctx.db.query`/`ctx.db.get` return **every** document in the named databases —
+all users, all channels — to whoever called the route. The legitimate pattern is
+a **capability**: an unguessable, per-user, revocable token in the URL or a
+header, checked before you read, with the response scoped to exactly that
+token's owner. "The URL is hard to guess" only holds if you mint the token
+yourself with real entropy and never print it anywhere else.
+
+Two things to design around. The opt-in is scoped to the **lane, not the
+route**: `backend.js` exports one `fetch` handler that routes internally, so
+every path inside it can read those databases — keep the check at the top and
+name as few databases as the feature needs. And it is a **static declaration**:
+`dbs` must be plain string literals and `why` a non-empty string literal saying
+who is authorized and how, or the push is rejected. There is no call-site flag,
+and no other lane can opt in.
+
 ## ctx — what a handler gets
 
 ```js
@@ -106,6 +144,11 @@ const res = await ctx.fetch("https://api.example.com/x", { headers }); // outbou
   doc, across all users and channels. In `fetch`/`onChange`, databases bound
   to an access function cannot be queried (keep those lanes' read databases on
   plain ACLs). Made for `scheduled` sweeps: read, decide, then `put`/`delete`.
+- The one exception to that last sentence is the declared opt-in above,
+  `config.fetch.unfilteredReads` — a `fetch` handler that names a database there
+  reads it unfiltered, anonymous callers included, and owes the authorization
+  check itself. Nothing changes for writes, or for any lane or database you
+  didn't name.
 - `ctx.secrets` carries the owner's per-vibe secrets, set in the vibe's settings
   page or with `vibes-diy secrets set KEY`. Use it to verify inbound credentials —
   a webhook's shared secret or token — or to authenticate outbound calls

package/package.json

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