@vibes.diy/prompts 2.4.11 → 2.4.13

package/llms/fireproof.md

@@ -7,7 +7,7 @@ Fireproof is a lightweight embedded document database with encrypted live sync,
 - **Apps run anywhere:** Bundle UI, data, and logic together.
 - **Real-Time & Offline-First:** Automatic persistence and live queries, runs in the browser - no loading or error states.
 - **Unified API:** TypeScript works with Deno, Bun, Node.js, and the browser.
-- **React Hooks:** Leverage `useLiveQuery` and `useDocument` for live collaboration. Note: these are NOT top-level exports — they are returned by the `useFireproof()` hook. Always destructure from `const { useLiveQuery, useDocument, database } = useFireproof("db-name")`.
+- **React Hooks:** Leverage `useLiveQuery` and `useDocument` for live collaboration. Note: these are NOT top-level exports — they are returned by the `useFireproof()` hook. Always destructure from `const { useLiveQuery, useDocument, database } = useFireproof("dbName")`.
 
 **File structure:** A vibe's source is one or more files. `/App.jsx` is the entry point (React component). `/access.js` is optional — include it when the app needs per-document write validation or channel-based read isolation. Both files are pushed together and the server discovers `/access.js` automatically.
 
@@ -30,7 +30,7 @@ Fireproof databases store data across sessions and can sync in real-time. Each d
 ```js
 import { useFireproof } from "use-fireproof";
 
-const { database, useLiveQuery, useDocument } = useFireproof("my-ledger");
+const { database, useLiveQuery, useDocument } = useFireproof("myLedger");
 ```
 
 #### Put and Get Documents
@@ -47,7 +47,7 @@ This example shows Fireproof's `_id` allows easy sorting with `useLiveQuery`.
 
 ```js
 const App = () => {
-  const { useDocument, useLiveQuery } = useFireproof("my-ledger");
+  const { useDocument, useLiveQuery } = useFireproof("myLedger");
 
   const { doc, merge, submit } = useDocument({ text: "" });
 
@@ -72,12 +72,23 @@ const App = () => {
 };
 ```
 
+The access function lives in a separate file. Even simple apps include one — it's the server-side authority for who can write:
+
+access.js
+
+```js
+export default function (doc, oldDoc, user) {
+  if (!user) throw { forbidden: "sign in to save" };
+  return {};
+}
+```
+
 ### Editing Documents
 
 Address documents by a known `_id` if you want to force conflict resolution or work with a real world resource, like a schedule slot or a user profile. In a complex app this might come from a route parameter or correspond to an outside identifier.
 
 ```js
-const { useDocument } = useFireproof("my-ledger");
+const { useDocument } = useFireproof("myLedger");
 
 const { doc, merge, submit, save, reset } = useDocument({ _id: "user-profile:abc@example.com" });
 ```
@@ -143,7 +154,7 @@ Documents can be updated by multiple clients, and synced later. To create an eve
 
 ```js
 const App = () => {
-  const { useLiveQuery, database } = useFireproof("my-ledger");
+  const { useLiveQuery, database } = useFireproof("myLedger");
 
   const { docs } = useLiveQuery("counter", { key: "my-event-name" });
   const counterValue = docs.length;
@@ -198,7 +209,7 @@ Sortable lists are a common pattern. Here's how to implement them using Fireproo
 
 ```js
 function App() {
-  const { database, useLiveQuery } = useFireproof("my-ledger");
+  const { database, useLiveQuery } = useFireproof("myLedger");
 
   // Initialize list with evenly spaced positions
   async function initializeList() {
@@ -255,7 +266,7 @@ const { useLiveQuery, database } = useFireproof("drafts", {
 });
 
 // No acl — falls back to app-level role gates (existing behavior, always safe)
-const { useLiveQuery, database } = useFireproof("public-notes");
+const { useLiveQuery, database } = useFireproof("publicNotes");
 ```
 
 **Subject groups** — who each name covers:
@@ -271,16 +282,237 @@ Owner is always implicitly included — never list `owner` explicitly in an ACL.
 
 Each capability (`read`, `write`, `delete`) is independent. Omitting one falls back to the app-level role gate for that operation. The `acl` is sent once on first database open and persists across sessions (last-write-wins). Only the **app owner** can set ACLs; non-owner apps opening a database with an `acl` option have it silently ignored — the database still opens and works normally.
 
+## Reading Resolved Grants (`access`)
+
+`useFireproof()` returns an `access` property — the viewer's resolved roles and channels for that database, computed server-side from the access function's `members` and `grant` declarations.
+
+```jsx
+const { database, useLiveQuery, access } = useFireproof("comments");
+
+access.roles; // ReadonlySet<string> — roles the viewer belongs to
+access.channels; // ReadonlySet<string> — channels the viewer can access
+
+access.hasRole("moderator"); // boolean convenience
+access.hasChannel("engineering"); // boolean convenience
+```
+
+For databases without an access function export, `access` has empty roles and channels. No separate pending flag — grants arrive alongside the viewer identity, so `useViewer().isViewerPending` covers both.
+
+```jsx
+function App() {
+  const { viewer, isViewerPending, ViewerTag } = useViewer();
+  const { database, useLiveQuery, access } = useFireproof("comments");
+
+  if (isViewerPending) return null;
+
+  return (
+    <div>
+      <ViewerTag />
+      {access.hasRole("poster") && <CommentForm database={database} />}
+      {access.hasRole("moderator") && <ModTools database={database} />}
+      {access.hasChannel("announcements") && <Announcements />}
+    </div>
+  );
+}
+```
+
+The AI agent writes the access function (so it knows the role names) and writes the UI (so it knows which roles gate which components). The `access` object is the bridge — it lets the UI reflect server-enforced permissions without duplicating the logic.
+
+The access function is the single source of truth for permissions. The UI reads its verdict from `access` — gate with `access.hasChannel(name)` and `access.hasRole(name)`. Grants may reflect logic the UI can't see (other documents, role memberships, owner state), so `access` is always the right check.
+
+`access.hasChannel()` covers every grant path — public channels, restricted channels, role-expanded channels. The access function decides who gets access and how; the UI just asks `access.hasChannel(name)`:
+
+```jsx
+// Channel list — access.hasChannel covers both public and restricted channels
+const visibleChannels = channels.filter(ch => access.hasChannel(ch._id));
+
+// Compose gate — access.hasChannel is the only check needed
+{viewer && access.hasChannel(activeChannel) && <ComposeForm />}
+
+// Channel with mixed access modes — the UI doesn't need to know which mode
+// The access function granted public channels via grant.public and
+// restricted channels via grant.users — access.hasChannel handles both
+{visibleChannels.map(ch => (
+  <li key={ch._id} onClick={() => setActive(ch._id)}>#{ch.name}</li>
+))}
+```
+
+### Complete example: Team announcements with channels
+
+This example shows the full round-trip — access.js declares channels and grants; App.jsx reads them back via `access`. Key details:
+
+- **Owner bootstrap:** `user.isOwner` gates management operations (channel setup, role grants, moderation). No bootstrap problem — the owner can always manage without needing a role granted first.
+- **Channel identity:** Channel docs use `_id: "ch:" + name` so names are unique. The `_id` is the channel identifier everywhere — in `channels`, `grant`, and `ctx.requireAccess()`.
+- **Channel grant:** A channel document grants the creator (`grant.users`), adds `grant.public` so all members can read, and `grant.roles` so posters can write.
+- **Write surfaces** are gated with `viewer` (signed in?), `access.hasChannel()` (channel access), or `isOwner` (management).
+- **`ViewerTag`** takes `userHandle` when rendering another user.
+
+access.js
+
+```js
+export function announcements(doc, oldDoc, user, ctx) {
+  if (!user) throw { forbidden: "sign in" };
+
+  if (doc.type === "channel") {
+    if (!user.isOwner) throw { forbidden: "owner only" };
+    return {
+      channels: [doc._id],
+      grant: {
+        users: { [user.userHandle]: [doc._id] },
+        public: [doc._id],
+        roles: { poster: [doc._id] },
+      },
+    };
+  }
+
+  if (doc.type === "roleGrant") {
+    if (!user.isOwner) throw { forbidden: "owner only" };
+    return { members: { [doc.role]: [doc.userHandle] } };
+  }
+
+  if (doc.type === "post") {
+    if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
+    ctx.requireAccess(doc.channel);
+    return { channels: [doc.channel] };
+  }
+
+  return {};
+}
+```
+
+App.jsx — `isOwner` and `access.hasChannel()` gate the UI based on what the access function declared:
+
+```jsx
+import React from "react";
+import { useFireproof } from "use-fireproof";
+import { useViewer } from "use-vibes";
+
+export default function App() {
+  const { viewer, isOwner, isViewerPending, ViewerTag } = useViewer();
+  const { database, useLiveQuery, access } = useFireproof("announcements");
+
+  const { docs: posts } = useLiveQuery("type", { key: "post" });
+  const [draft, setDraft] = React.useState("");
+  const [channel, setChannel] = React.useState("general");
+
+  if (isViewerPending) return null;
+
+  async function submitPost() {
+    if (!draft.trim() || !viewer) return;
+    await database.put({
+      type: "post",
+      channel,
+      body: draft.trim(),
+      authorHandle: viewer.userHandle,
+      createdAt: Date.now(),
+    });
+    setDraft("");
+  }
+
+  return (
+    <div>
+      <ViewerTag />
+
+      {/* access.hasChannel covers public + restricted — the access function handles the distinction */}
+      {viewer && access.hasChannel(channel) && (
+        <form
+          onSubmit={(e) => {
+            e.preventDefault();
+            submitPost();
+          }}
+        >
+          <textarea value={draft} onChange={(e) => setDraft(e.target.value)} />
+          <button type="submit">Post</button>
+        </form>
+      )}
+
+      {/* owner-only management */}
+      {isOwner && (
+        <button onClick={() => database.put({ type: "roleGrant", role: "poster", userHandle: "newUser" })}>
+          Grant poster role
+        </button>
+      )}
+
+      {posts.map((p) => (
+        <div key={p._id}>
+          <ViewerTag userHandle={p.authorHandle} />
+          <p>{p.body}</p>
+          {isOwner && <button onClick={() => database.del(p._id)}>Delete</button>}
+        </div>
+      ))}
+    </div>
+  );
+}
+```
+
+The pattern: `viewer` checks sign-in, `access.hasChannel()` checks what the access function granted, `isOwner` gates management. The access function is the server-side authority — the UI just reflects its decisions. Real apps can graduate to `access.hasRole("moderator")` when they need to delegate management to non-owners.
+
+### Example: Channel board with restricted channels
+
+Some channels are open to all members, others are restricted. The access function decides — the UI just asks `access.hasChannel()`.
+
+access.js
+
+```js
+export function chat(doc, oldDoc, user, ctx) {
+  if (!user) throw { forbidden: "sign in" };
+
+  if (doc.type === "channel") {
+    if (!user.isOwner) throw { forbidden: "owner only" };
+    return {
+      channels: [doc._id],
+      grant: {
+        users: { [user.userHandle]: [doc._id] },
+        public: [doc._id],
+      },
+    };
+  }
+
+  if (doc.type === "post") {
+    if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
+    ctx.requireAccess(doc.channel);
+    return { channels: [doc.channel] };
+  }
+
+  return {};
+}
+```
+
+App.jsx — the UI uses `access.hasChannel()` for everything. It has no idea which channels are restricted — that's the access function's job.
+
+```jsx
+const { database, useLiveQuery, access } = useFireproof("chat");
+const { docs: channels } = useLiveQuery("type", { key: "channel" });
+
+// client creates channels with a deterministic _id
+await database.put({ _id: "ch:" + name, type: "channel", createdAt: Date.now() });
+
+// filter to channels the viewer can see — use _id as channel identifier
+const visible = channels.filter((ch) => isOwner || access.hasChannel(ch._id));
+
+// can post? just check channel access
+const canPost = viewer && (isOwner || access.hasChannel(activeChannel._id));
+
+// gate the compose form
+{canPost ? (
+  <Composer channel={activeChannel._id} />
+) : (
+  <p>{viewer ? "Read-only in this channel." : "Sign in to post."}</p>
+)}
+```
+
+Channel `_id` is the channel identifier everywhere. The `canPost` check uses `access.hasChannel(ch._id)`. The access function uses `doc._id` for routing and grants. A deterministic `_id` like `"ch:" + name` enforces uniqueness — two users can't create duplicate channels.
+
 ---
 
 ## Access Function (`/access.js`)
 
 Access functions are **the room** — they govern what members can do with data once inside the app. The per-vibe membership system is **the door** — it decides who can see the app at all. Once a user is through the door (approved as a member), the access function is the sole authority for data permissions. Access functions are server-run on every write (including deletes) before storing the document. They validate writes, route documents to channels, and declare grants that control who can read what. Only create an `/access.js` file when the user asks for per-document routing, channel-based isolation, or document-level write validation.
 
-Access functions live in `/access.js`, a separate file in the vibe's filesystem alongside `/App.jsx`. Each **named export** maps to a database name — `export function chat(...)` gates `useFireproof("chat")`. An `export default` function acts as a catch-all: it gates any database that doesn't have its own named export. Named exports always take precedence over the default.
+Access functions live in `/access.js`, a separate file in the vibe's filesystem alongside `/App.jsx`. **Always emit the access function as a block preceded by the filename `access.js` on its own line — never inside an `App.jsx` block.** Each **named export** maps to a database name — `export function chat(...)` gates `useFireproof("chat")`. An `export default` function acts as a catch-all: it gates any database that doesn't have its own named export. Named exports always take precedence over the default.
 
+access.js
 ```js
-// /access.js — each export name = the database it gates
 export function chat(doc, oldDoc, user, ctx) {
   if (!user) throw { forbidden: "authentication required" };
   if (doc.type === "message") {
@@ -292,8 +524,8 @@ export function chat(doc, oldDoc, user, ctx) {
 }
 ```
 
-```js
-// /App.jsx — no access option needed; the server matches by database name
+App.jsx
+```jsx
 const { useLiveQuery, database } = useFireproof("chat");
 ```
 
@@ -344,6 +576,8 @@ type AccessDescriptor = {
 
 **Channels** route documents. A document with `channels: ["general"]` is only visible to users who have been granted access to `"general"`. Channels are the unit of read isolation.
 
+**`_id` strategy matters.** Documents that represent a unique named resource (channels, user profiles, config singletons) should use a deterministic `_id` with a short prefix — `"ch:" + name`, `"profile:" + handle`, `"config"`. This enforces uniqueness: two users creating "general" get the same doc, not two. Documents that represent events or content (messages, posts, survey responses) should let `_id` be auto-generated — each one is unique by nature. Use `doc._id` as the channel name for resource docs; use a `channelId` foreign key on content docs.
+
 **Grants are additive.** The effective access state is the union of every current document's `AccessDescriptor` output. There is no "remove grant" operation — deleting a document drops its contribution from the union automatically. This makes revocation trivial: delete the document that granted access, and the grant disappears on next sync.
 
 **Grant resolution order:** The server resolves per-user channel access in two passes — first expand `grant.roles` through `members`, then union with `grant.users` direct grants.
@@ -354,8 +588,8 @@ type AccessDescriptor = {
 
 ### Example: Workspace chat with channels
 
+access.js
 ```js
-// /access.js
 export function chat(doc, oldDoc, user, ctx) {
   if (!user) throw { forbidden: "authentication required" };
 
@@ -397,8 +631,8 @@ This single access function handles three document types:
 
 ### Example: Anonymous survey with role-gated results
 
+access.js
 ```js
-// /access.js
 export function survey(doc, oldDoc, user, ctx) {
   if (doc.type === "survey-response") {
     if (oldDoc) throw { forbidden: "responses are write-once" };
@@ -406,11 +640,10 @@ export function survey(doc, oldDoc, user, ctx) {
   }
 
   if (doc.type === "survey-config") {
-    ctx.requireRole("survey-admin");
+    if (!user.isOwner) throw { forbidden: "owner only" };
     return {
       grant: {
         roles: {
-          "survey-admin": ["inbound-responses"],
           "feedback-team": ["inbound-responses"],
         },
       },
@@ -438,8 +671,8 @@ Key patterns:
 
 Each named export gates its own database. A single `/access.js` can gate all databases the app uses:
 
+access.js
 ```js
-// /access.js
 export function chat(doc, oldDoc, user, ctx) {
   if (!user) throw { forbidden: "authentication required" };
   ctx.requireAccess(doc.channelId);
@@ -454,12 +687,24 @@ export function notes(doc, oldDoc, user, ctx) {
 
 Databases without a matching named export fall through to `export default` if one exists. If there is no default export either, the database uses the default app-level permissions (no access function).
 
+**Hyphenated database names** are rare — prefer camelCase (`useFireproof("crewChat")`). If you inherit a hyphenated name, use `export { localName as "db-name" }` to map a local function:
+
+access.js
+```js
+function crewChat(doc, oldDoc, user, ctx) {
+  if (!user) throw { forbidden: "authentication required" };
+  ctx.requireAccess(doc.channelId);
+  return { channels: [doc.channelId] };
+}
+export { crewChat as "crew-chat" }
+```
+
 ### Catch-all with `export default`
 
-Use `export default` to gate every database without writing a named export for each one. Named exports still take precedence for databases that need custom logic:
+Use `export default` to gate every database without writing a named export for each one. Named exports (including `as` exports) still take precedence for databases that need custom logic:
 
+access.js
 ```js
-// /access.js
 export function chat(doc, oldDoc, user, ctx) {
   if (!user) throw { forbidden: "authentication required" };
   ctx.requireAccess(doc.channelId);
@@ -473,7 +718,7 @@ export default function (doc, oldDoc, user, ctx) {
 }
 ```
 
-This is especially useful when an app has many databases or uses hyphenated names (`error-log`, `user-prefs`) that can't be JavaScript identifiers.
+This is especially useful when an app has many databases.
 
 ### Roles via `members` reduce
 
@@ -482,7 +727,7 @@ Roles are not a fixed registry. They are materialized from document contribution
 ```js
 // A team-meta doc contributes members to a role
 if (doc.type === "team-meta") {
-  ctx.requireRole("admin");
+  if (!user.isOwner) throw { forbidden: "owner only" };
   return {
     members: { [doc.teamId]: doc.memberHandles },
     grant: { roles: { [doc.teamId]: doc.channels } },
@@ -536,7 +781,7 @@ You can use the core API in HTML or on the backend. Instead of hooks, import the
 ```js
 import { fireproof } from "use-fireproof";
 
-const database = fireproof("my-ledger");
+const database = fireproof("myLedger");
 ```
 
 The document API is async, but doesn't require loading states or error handling.
@@ -553,7 +798,7 @@ To subscribe to real-time updates, use the `subscribe` method. This is useful fo
 ```js
 import { fireproof } from "use-firproof";
 
-const database = fireproof("todo-list-db");
+const database = fireproof("todoList");
 
 database.subscribe((changes) => {
   console.log("Recent changes:", changes);
@@ -572,7 +817,7 @@ Fireproof documents carry attachments under `_files`. Save a `File` (or `Blob`)
 #### Attaching files on save
 
 ```jsx
-const { useDocument } = useFireproof("photo-album");
+const { useDocument } = useFireproof("photoAlbum");
 const { doc, merge, submit } = useDocument({ _files: {}, caption: "" });
 
 // In a file input change handler:
@@ -671,7 +916,7 @@ import { useFireproof } from "use-fireproof";
 
 export default function App() {
   // 1. Hooks and document shapes
-  const { useLiveQuery, useDocument, database } = useFireproof("todo-list-db");
+  const { useLiveQuery, useDocument, database } = useFireproof("todoList");
 
   const {
     doc: newTodo,
@@ -752,6 +997,20 @@ export default function App() {
 
 IMPORTANT: Don't use `useState()` on form data, instead use `merge()` and `submit()` from `useDocument`. Only use `useState` for ephemeral UI state (active tabs, open/closed panels, cursor positions). Keep your data model in Fireproof.
 
+The todo app's access function validates authorship:
+
+access.js
+
+```js
+export function todoList(doc, oldDoc, user) {
+  if (!user) throw { forbidden: "sign in" };
+  if (doc.type === "todo" && doc.createdBy !== user.userHandle) {
+    throw { forbidden: "only the author can edit" };
+  }
+  return {};
+}
+```
+
 ## Example Image Uploader
 
 This pattern uses `_files` end-to-end: save a `File` directly, render thumbnails with `<img src={meta.url}>`.
@@ -762,7 +1021,7 @@ import { useFireproof } from "use-fireproof";
 
 export default function App() {
   // 1. Hooks and document shapes
-  const { useDocument, useLiveQuery } = useFireproof("image-uploads");
+  const { useDocument, useLiveQuery } = useFireproof("imageUploads");
 
   const { doc, merge, submit } = useDocument({
     _files: {},
@@ -825,3 +1084,12 @@ export default function App() {
   );
 }
 ```
+
+access.js
+
+```js
+export function imageUploads(doc, oldDoc, user) {
+  if (!user) throw { forbidden: "sign in to upload" };
+  return {};
+}
+```

package/llms/three-js.md

@@ -1068,7 +1068,7 @@ import { useFireproof } from "use-fireproof";
 import * as THREE from "three";
 
 export default function SkyGlider() {
-  const { database, useLiveQuery } = useFireproof("sky-glider-scores");
+  const { database, useLiveQuery } = useFireproof("skyGliderScores");
   const canvasRef = useRef(null);
   const gameStateRef = useRef({
     scene: null,
@@ -1475,7 +1475,7 @@ import { RenderPass } from "three/addons/postprocessing/RenderPass.js";
 import { HalftonePass } from "three/addons/postprocessing/HalftonePass.js";
 
 export default function HalftoneArtStudio() {
-  const { database, useLiveQuery } = useFireproof("halftone-studio");
+  const { database, useLiveQuery } = useFireproof("halftoneStudio");
   const canvasRef = useRef(null);
   const sceneRef = useRef(null);
   const [currentPreset, setCurrentPreset] = useState(null);

package/llms/use-viewer.md

@@ -2,7 +2,7 @@
 
 `useViewer()` is a **read-only window** into runtime-managed access control. The platform owns the rules — who's the owner, who has been granted read or write — and `useViewer()` lets your app see what the runtime decided. You cannot grant or revoke access from code; you can only reflect the runtime's verdict in your UI.
 
-The contract: **every write surface (form, submit button, edit input, delete button) must consult `can("write")`** and render a read-only fallback when it returns false. This applies even when the app sounds single-user — sharing is the runtime's decision, not the prompt's.
+The contract: **every write surface (form, submit button, edit input, delete button) must check `viewer`** (signed in?) and render a read-only fallback when null. For apps with access functions, gate further with `access.hasRole()` or `access.hasChannel()` from `useFireproof()`. The access function is the server-side authority — the UI reflects its decisions.
 
 ## Basic Usage
 
@@ -10,7 +10,7 @@ The contract: **every write surface (form, submit button, edit input, delete but
 import { useViewer } from "use-vibes";
 
 function App() {
-  const { viewer, isViewerPending, can, ViewerTag } = useViewer();
+  const { viewer, isViewerPending, ViewerTag } = useViewer();
 
   // isViewerPending is true until the platform has resolved the viewer identity.
   // Gate on it to avoid flashing the anonymous state on first render.
@@ -27,16 +27,17 @@ function App() {
 
 ## What you get
 
-- `viewer` — `{ userSlug, displayName?, avatarUrl }` or `null` for anonymous visitors. `avatarUrl` is a stable opaque URL — just use it in `<img src>`, don't construct it yourself.
+- `viewer` — `{ userHandle, displayName?, avatarUrl }` or `null` for anonymous visitors. `avatarUrl` is a stable opaque URL — just use it in `<img src>`, don't construct it yourself.
 - `isViewerPending` — `true` while the platform is still resolving the viewer identity (e.g. on first render before the parent shell has pushed the identity update). **Gate any auth-dependent UI on `!isViewerPending`** to avoid flashing the wrong state. Once it becomes `false`, `viewer` is either populated or definitively `null`.
-- `can(action, dbName?)` — `true`/`false` for `"read"`, `"write"`, `"delete"`. Pass a `dbName` for multi-db apps; omit for single-db apps. Use it to hide forms when the viewer can't post.
+- `isOwner` — `true` when the viewer owns this vibe. Use it for management UI (settings, role grants, moderation).
+- `can(action, dbName?)` — `true`/`false` for `"read"`, `"write"`, `"delete"`. Checks app-level ACLs. In most apps `viewer` and `access.hasRole()`/`access.hasChannel()` are the right gates instead.
 - `ViewerTag` — ready-made user pill; see the ViewerTag section below.
 
 ## Gating UI
 
 ```jsx
 function CommentForm() {
-  const { viewer, isViewerPending, can, ViewerTag } = useViewer();
+  const { viewer, isViewerPending, ViewerTag } = useViewer();
   if (isViewerPending) return null;
 
   return (
@@ -48,8 +49,8 @@ function CommentForm() {
         <ViewerTag />
       </div>
 
-      {viewer && !can("write", "comments") && <p>Contact the owner to request write access so you can post.</p>}
-      {viewer && can("write", "comments") && <form>...</form>}
+      {!viewer && <p>Sign in to post.</p>}
+      {viewer && <form>...</form>}
     </div>
   );
 }
@@ -57,15 +58,15 @@ function CommentForm() {
 
 ## Tagging content with the viewer (write/render pattern)
 
-When one user writes content others will see (comments, posts, messages), **stamp the viewer's identity onto the doc at write time**. Then any user can render the author info from the doc itself — no extra lookup. The `avatarUrl` is a stable indirection URL so it keeps working when the author later changes their avatar.
+When one user writes content others will see (comments, posts, messages), **stamp `authorHandle` on the doc at write time**. That's it — just the handle. Render with `<ViewerTag userHandle={doc.authorHandle} />` which resolves display name and avatar automatically. Do not stamp `displayName` or `avatarUrl` on docs — ViewerTag handles that from the handle alone.
 
 ```jsx
 import { useFireproof } from "use-fireproof";
 import { useViewer } from "use-vibes";
 
 function CommentThread() {
-  const { viewer, isViewerPending, can, ViewerTag } = useViewer();
-  const { useLiveQuery, database } = useFireproof("comments");
+  const { viewer, isViewerPending, ViewerTag } = useViewer();
+  const { useLiveQuery, database, access } = useFireproof("comments");
   const { docs: comments } = useLiveQuery("createdAt");
   const [body, setBody] = useState("");
 
@@ -74,11 +75,7 @@ function CommentThread() {
     await database.put({
       body: body.trim(),
       createdAt: Date.now(),
-      // Stamp the viewer's identity at write time. Other users will
-      // render from these fields — no need to look anything up later.
-      authorUserSlug: viewer.userSlug,
-      authorDisplayName: viewer.displayName ?? viewer.userSlug,
-      authorAvatarUrl: viewer.avatarUrl,
+      authorHandle: viewer.userHandle,
     });
     setBody("");
   }
@@ -88,8 +85,7 @@ function CommentThread() {
       <ul>
         {comments.map((c) => (
           <li key={c._id}>
-            <img src={c.authorAvatarUrl} alt={c.authorUserSlug} className="avatar" />
-            <strong>{c.authorDisplayName}</strong>
+            <ViewerTag userHandle={c.authorHandle} />
             <p>{c.body}</p>
           </li>
         ))}
@@ -101,8 +97,8 @@ function CommentThread() {
             {viewer && <span style={{ fontSize: 13, color: "var(--muted, #888)" }}>commenting as</span>}
             <ViewerTag />
           </div>
-          {viewer && !can("write", "comments") && <p>Contact the owner to request write access so you can post.</p>}
-          {viewer && can("write", "comments") && (
+          {!viewer && <p>Sign in to post.</p>}
+          {viewer && (
             <form
               onSubmit={(e) => {
                 e.preventDefault();
@@ -122,14 +118,15 @@ function CommentThread() {
 
 Key points:
 
-- **Write-time stamping** — the doc carries the author info, not a foreign-key lookup. Old comments keep working even if the author later deletes their account.
-- **`avatarUrl` is stable** — if the author changes their avatar tomorrow, every historical comment shows the new image because the URL stays the same, the bytes change.
-- **One source of identity** — never store the viewer's user ID, only `userSlug` + `displayName` + `avatarUrl`. The trio is everything a renderer needs.
+- **Stamp `authorHandle` at write time** — persist the author's handle on the doc. Render with `<ViewerTag userHandle={authorHandle} />` which resolves display name and avatar automatically.
+- **`avatarUrl` is stable** — if the author changes their avatar, the URL stays the same and the bytes update. ViewerTag handles this for you.
+- **One source of identity** — persist `authorHandle` on the doc. ViewerTag does the rest.
 
 ## Notes
 
-- Never use Clerk user IDs. Only `userSlug` crosses into vibe code.
+- Never use Clerk user IDs. Only `userHandle` crosses into vibe code.
 - Avatar URLs are stable indirection URLs — when a user changes their avatar, the URL stays the same and the bytes update. Treat them as opaque strings.
+- For per-database permissions (roles and channels), use `access` from `useFireproof()`: `access.hasRole("moderator")`, `access.hasChannel("engineering")`. The access function (access.js) is the server-side authority; `access` in the UI reflects its decisions.
 
 ## ViewerTag
 
@@ -142,14 +139,14 @@ const { viewer, ViewerTag } = useViewer();
 <ViewerTag />
 
 // Show another user read-only (no edit affordance):
-<ViewerTag userSlug={comment.authorUserSlug} />
+<ViewerTag userHandle={comment.authorHandle} />
 ```
 
 **Self-detection is automatic.** When `ViewerTag` renders the current viewer it shows a dashed indigo ring and pencil overlay on the avatar. Clicking it opens a file picker; the upload and profile save happen internally.
 
-**Undefined safety.** If `userSlug` is present in props but falsy (e.g. a missing field from a loop lookup), `ViewerTag` renders a dim italic placeholder instead of the edit ring. This prevents a broken data source from accidentally granting photo-edit access to an arbitrary pill.
+**Undefined safety.** If `userHandle` is present in props but falsy (e.g. a missing field from a loop lookup), `ViewerTag` renders a dim italic placeholder instead of the edit ring. This prevents a broken data source from accidentally granting photo-edit access to an arbitrary pill.
 
-**Anonymous safety.** `ViewerTag` is always safe to call regardless of login state — it never throws. When the viewer is anonymous and no `userSlug` prop is given, it renders a "Sign in" button that opens the platform login UI when clicked. Wrap it in a `{viewer && <ViewerTag />}` guard if you want to suppress it entirely for anonymous users.
+**Anonymous safety.** `ViewerTag` is always safe to call regardless of login state — it never throws. When the viewer is anonymous and no `userHandle` prop is given, it renders a "Sign in" button that opens the platform login UI when clicked. Wrap it in a `{viewer && <ViewerTag />}` guard if you want to suppress it entirely for anonymous users.
 
 **Theming.** `ViewerTag` reads `--accent`, `--accent-text`, `--card-bg`, `--border`, `--text`, and `--muted` from the app's CSS variables with sensible fallbacks. If your app defines these on `:root` (which most generated themes do), `ViewerTag` inherits the theme automatically with no extra props.
 
@@ -159,4 +156,4 @@ const { viewer, ViewerTag } = useViewer();
 <ViewerTag style={{ borderRadius: 8, fontSize: 12 }} />
 ```
 
-Use `<ViewerTag />` (no props) for the current user and `<ViewerTag userSlug={...} />` for others. That's the whole API.
+Use `<ViewerTag />` (no props) for the current user and `<ViewerTag userHandle={...} />` for others. That's the whole API.

package/llms/webxr.md

@@ -455,14 +455,14 @@ function buildGalaxy(scene) {
 
 function buildCoreShader(scene) {
   if (!BABYLON.Effect.ShadersStore["galaxyCoreVertexShader"]) {
-    BABYLON.Effect.ShadersStore["galaxyCoreVertexShader"] = `
+  BABYLON.Effect.ShadersStore["galaxyCoreVertexShader"] = `
     precision highp float;
     attribute vec3 position; attribute vec2 uv;
     uniform mat4 worldViewProjection;
     varying vec2 vUv;
     void main() { vUv = uv; gl_Position = worldViewProjection * vec4(position, 1.0); }
   `;
-    BABYLON.Effect.ShadersStore["galaxyCoreFragmentShader"] = `
+  BABYLON.Effect.ShadersStore["galaxyCoreFragmentShader"] = `
     precision highp float;
     varying vec2 vUv; uniform float time;
     void main() {
@@ -506,7 +506,7 @@ async function enableVR(scene) {
 // ── React container component ──────────────────────────────────────────────
 
 export default function App() {
-  const { database, useLiveQuery } = useFireproof("galaxy-sessions");
+  const { database, useLiveQuery } = useFireproof("galaxySessions");
   const canvasRef = useRef(null);
   const { docs: sessions } = useLiveQuery("type", { key: "session" });
 
@@ -661,7 +661,7 @@ async function enableAR(scene, onPlace) {
 // ── React container ────────────────────────────────────────────────────────
 
 export default function App() {
-  const { database, useLiveQuery } = useFireproof("ar-orbs");
+  const { database, useLiveQuery } = useFireproof("arOrbs");
   const canvasRef = useRef(null);
   const sceneRef = useRef(null);
   const orbMatRef = useRef(null);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "2.4.11",
+  "version": "2.4.13",
   "type": "module",
   "main": "./index.js",
   "description": "",
@@ -30,8 +30,8 @@
     "@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": "^2.4.11",
-    "@vibes.diy/use-vibes-types": "^2.4.11",
+    "@vibes.diy/call-ai-v2": "^2.4.13",
+    "@vibes.diy/use-vibes-types": "^2.4.13",
     "arktype": "~2.2.0",
     "json-schema-faker": "~0.6.1"
   },

package/system-prompt-initial.md

@@ -14,97 +14,73 @@ You are an AI assistant tasked with creating React components. You should create
 - Use `callAI` to fetch AI, use schema like this: `JSON.parse(await callAI(prompt, { schema: { properties: { todos: { type: 'array', items: { type: 'string' } } } } }))` and save final responses as individual Fireproof documents.
 - Always show loading states during any async operation (callAI, fetch, database queries): use a useState boolean (e.g. `isLoading`), set it true before the call and false in .finally(). While loading: (1) disable the trigger button with `disabled={isLoading}`, (2) replace the button text with a spinning SVG icon using CSS animation `animate-spin` (a simple circle with a gap), (3) optionally show a short status text like 'Loading...' near the button. Never leave the user clicking a button with no visual feedback. Pattern: `setIsLoading(true); try { await callAI(...); } finally { setIsLoading(false); }`
 - For file uploads use drag and drop and store using the `doc._files` API; for AI image generation use `<ImgGen prompt="..." />`
-- Access control (who can read, who can write) is decided by the runtime, not by your code. `useViewer()` is the app's read-only window into that decision — call `const { viewer, can } = useViewer();` from `"use-vibes"`. `viewer` is `{ userSlug, displayName?, avatarUrl } | null` (null for anonymous). `can("write")` returns the runtime's verdict; you cannot grant or override it. Your only job is to reflect that verdict in the UI: **every write surface (form, submit button, edit input, delete button) must be wrapped in `can("write")` — show it only when true, render a read-only state otherwise.** Pattern: `if (!can("write")) return <p>Read-only view — contact the owner for write access.</p>;` Render avatars with `<img src={viewer.avatarUrl} />` (opaque URL — use directly). For multi-db apps pass the dbName: `can("write", "comments")`. This applies to every app — never skip useViewer because the app "sounds single-user"; the runtime decides sharing, not the prompt. See use-viewer docs.
+- Access control is decided by the runtime, not by your code. `useViewer()` from `"use-vibes"` gives you `const { viewer, isOwner, isViewerPending, ViewerTag } = useViewer();`. `viewer` is `{ userHandle, displayName?, avatarUrl } | null` (null for anonymous). **Gate write surfaces on `viewer`** — show forms only when signed in, render a read-only fallback otherwise. For apps with an access function (`access.js`), gate further with `access.hasRole()` or `access.hasChannel()` from `useFireproof()` — never re-derive permissions from document fields client-side. Use `isOwner` for management UI (settings, moderation). Render avatars with `<ViewerTag userHandle={authorHandle} />`. This applies to every app — never skip useViewer because the app "sounds single-user"; the runtime decides sharing, not the prompt. See use-viewer docs.
 - Don't try to generate png or base64 data, use placeholder image APIs instead, like https://picsum.photos/400 where 400 is the square size
 - Never use emojis in the UI. Use inline SVG icons instead — simple, single-color, stroke-based SVGs (24x24 viewBox, strokeWidth 2, strokeLinecap round, strokeLinejoin round). Build icons directly in JSX, do not import icon libraries.
 - List data items on the main page of your app so users don't have to hunt for them
 - If you save data, make sure it is browsable in the app, eg lists should be clickable for more details
-- Add small AI-powered suggestion buttons next to form field groups and empty states. When tapped, use callAI to generate example ideas and fill them in, so users can see what's possible without typing from scratch. Use the same callAI calls the app already makes for real functionality — don't create separate AI functions just for suggestions.{{DEMO_DATA}}
+- Add small AI-powered suggestion buttons next to form field groups and empty states. When tapped, use callAI to generate example ideas and fill them in, so users can see what's possible without typing from scratch. Use the same callAI calls the app already makes for real functionality — don't create separate AI functions just for suggestions. Use callAI only when the user's prompt calls for AI features — a message board that doesn't mention AI should save posts directly without running sentiment analysis or auto-tagging.{{DEMO_DATA}}
 
 {{CONCATENATED_LLMS}}
 {{THEME_DESIGN}}
-{{TITLE_SECTION}}{{ENRICHED_PROMPT}}{{USER_PROMPT}}IMPORTANT: You are working in one JavaScript file (`App.jsx`). This is the **first turn** — `App.jsx` does not exist yet. You'll paint a colored shell once, then grow each feature into it through small fill-then-wire passes the user watches land in the preview.
+{{TITLE_SECTION}}{{ENRICHED_PROMPT}}{{USER_PROMPT}}IMPORTANT: Your main file is `App.jsx` (the React component). If the app needs an access function for per-document write validation or channel-based read isolation, emit it as a separate file named `access.js` — never put access function code inside `App.jsx`. This is the **first turn** — `App.jsx` does not exist yet. Ship the complete working app in one block, then follow with `access.js` and at most 1–2 small refinement edits.
 
 Before writing code, provide a title and brief description of the app. Then list the top 3 features that are the best fit for a mobile web database with real-time collaboration and describe a short planned workflow showing how those features connect into a coherent user experience.
 
-## Output format (one colored shell + 4–6 feature passes)
+## Output format (colored shell → access.js → working app)
 
-Every code block must be preceded by the file name on its own line. The file is `App.jsx`.
+Every code block must be preceded by the file name on its own line — `App.jsx` for the React component, or `access.js` for the access function (if needed).
 
-**Step 1 — Colored shell (one full-file `create` block).** Emit a single fenced ```jsx block containing the full initial file. No SEARCH/REPLACE markers, no `=======`, no `>>>>>>> REPLACE`—`App.jsx` doesn't exist yet.
-
-**The shell must paint colored shape on the first render.** It contains:
+**Step 1 — Colored shell (one `create` block).** Emit a single fenced ```jsx block — `App.jsx` doesn't exist yet. The shell paints real colors and shape on the first render so the user sees the app taking form immediately. It contains:
 
 - Imports.
-- A full `classNames` / `c` object with **real Tailwind colors filled in** — page background, header colors, section frames, button styles. Final-ish colors, not placeholders.
-- The `<header>` with the real brand title (and any always-visible top chrome).
-- One empty `<section id="…">` shell per planned feature inside `<main>` — stable ids, real chrome, no content yet. Each shell looks like:
-
-```jsx
-<section id="feature-id" className={c.section}>
-  <h2>{/* feature-name pass */}</h2>
-</section>
-```
-
-Target ~40–60 lines total.
+- A full `classNames` / `c` object with **real Tailwind colors** — page background, header colors, section frames, button styles. Final-ish colors, not placeholders.
+- The `<header>` with the real brand title and any always-visible chrome.
+- One stub function component per feature with a heading and placeholder comment — these are the anchors for later edits.
+- A default-exported `App` function composing them inside `<main id="app">` with `<header id="app-header">`.
+- `useViewer` destructured at the top of `App()` — `const { viewer, isOwner, isViewerPending, ViewerTag } = useViewer();`
+- **Be creative with the layout, but respect mobile idioms.** Thumb-reachable primary actions, generous tap targets (`min-h-[44px]`), scrollable lists, no hover-only interactions.
+- NO hooks beyond `useViewer`, NO data wiring — those land in the feature edits.
 
-**Step 2 — Fill-then-wire feature passes.** After the shell, emit **4–6 SEARCH/REPLACE pairs**, each preceded by **exactly one line of prose** (≤25 words) saying what just landed. The user watches the colored shell paint, then each feature grows into it: structure first (so the layout fills in visibly), then wiring (so it starts working). For each feature, do these two passes back-to-back before moving to the next feature:
+Target ~40–60 lines. The shell should look like a real app with empty sections, not a blank page.
 
-1. **Fill pass** — replace one empty `<section id="feature-id">…</section>` with the section's real structure: heading, form fields, list rows, button placements, static placeholder copy ("Add a task", a couple of example rows). No hooks, no callAI, no live data yet.
-2. **Wire pass** — replace the now-filled section with the same section plus hooks (`useState`, `useFireproof`, `useLiveQuery`), `callAI` if the feature uses it, and `isLoading` flags around async calls. Placeholders become controlled inputs and live data.
+**Step 2 — Access function (if needed).** Emit `access.js` as a complete fenced block with comments explaining the permission model: what each doc type does, who can write it, what channels/roles it creates. This commits to the permission design before any feature edits, so every subsequent edit can destructure `access` and gate with `access.hasRole()` / `access.hasChannel()` from the start.
 
-For an app with 2 features → 4 passes total. With 3 features → 6 passes total. If a feature is trivial (display-only, no async, no input) you may collapse its two passes into one combined fill-and-wire pass — but only when there's truly nothing to wire.
+**Step 3 — Feature edits.** Fill in each feature with SEARCH/REPLACE edits. Each edit gets exactly one prose line (≤25 words) before it. Wire hooks, data, handlers, and `useFireproof` with `access` in these edits. The first feature edit should also add the `useFireproof` destructure to `App()`. Keep edits focused — one feature per edit, fully working after it lands.
 
-The cadence is:
-
-> _prose line — what the fill pass adds_
->
-> ```jsx
-> <<<<<<< SEARCH
-> ...empty <section id="…"> shell from the scaffold...
-> =======
-> ...same section, structure + placeholder copy filled in...
-> >>>>>>> REPLACE
-> ```
->
-> _prose line — what the wire pass adds_
+> Access function — owner manages channels, authenticated users post to channels they have access to.
 >
-> ```jsx
-> <<<<<<< SEARCH
-> ...filled section as it stands now...
-> =======
-> ...same section, with hooks, data, callAI, loading wired up...
-> >>>>>>> REPLACE
+> access.js
+> ```js
+> // Each channel doc grants public read access to that channel.
+> // Posts require channel access — the server enforces this via ctx.requireAccess.
+> // Only the owner can create channels.
+> export function chat(doc, oldDoc, user, ctx) {
+>   if (!user) throw { forbidden: "sign in" }
+>   if (doc.type === "channel") {
+>     if (!user.isOwner) throw { forbidden: "owner only" }
+>     return { channels: [doc.name], grant: { public: [doc.name] } }
+>   }
+>   if (doc.type === "message") {
+>     if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" }
+>     ctx.requireAccess(doc.channelId)
+>     return { channels: [doc.channelId] }
+>   }
+>   return {}
+> }
 > ```
->
-> _... repeat fill → wire for each feature section_
-
-Each `<<<<<<< SEARCH` snippet anchors on the `<section id="...">` open tag and its closing `</section>` — the stable ids you set in the shell guarantee a unique match. **One SR pair per change**, never bundled across sections, never split within a section. Each pair gets its own fenced block.
-
-If a feature needs hooks at the top of the component (a `useFireproof` whose `database` is shared between sections), introduce those hooks **inside the first wire pass that needs them** — emit a separate small SR pair anchored on the `function App() {` line that inserts the hooks just above the JSX return. Do NOT mix that hooks-insertion edit into a section SR pair; it lives as its own tiny SR pair just before the wire pass that uses it. That keeps section SR anchors clean.
 
-**Each pair is small — typically 20–50 lines on each side of the `=======`.** Fill passes are smaller (structure only). Wire passes are slightly larger (add hooks + handlers). If a wire pair would exceed ~60 lines per side, split the section into a smaller scope or move the hooks insertion to its own tiny pair as described above. **Bias toward many small visible deltas over fewer giant ones** — each pass should be a watchable paint.
+**Never put access function code inside an `App.jsx` block** — it will overwrite the React component. The filename line (`access.js` vs `App.jsx`) is how the system knows which file to write.
 
-After your final edit, add a short 1-2 sentence message describing the core workflow the app supports.
+After the final edit (and `access.js` if applicable), add a short 1-2 sentence message describing the core workflow the app supports.
 
-## Pass-1 scaffold rules
+## Code style rules
 
-- Import statements (React + the libraries listed below) — use the imports listed under "Your starter scaffold" at the bottom.
-- A `classNames` / `c` object with **real, final-ish Tailwind colors** for the layout-level keys (`page`, `header`, `title`, `section`, `btn`, `input`, list rows, etc.). Pick a coherent palette that fits the app's vibe — page background, header chrome, section frames, button accents, text colors all land here so the first paint is colored, not monochrome. Bracket notation is fine (`bg-[#0f172a]`, `text-[#f8fafc]`). Reference via `className={c.page}` / `className={classNames.foo}`. Real layout values (sizing, spacing, flex/grid) live here too.
-- Semantic HTML tags throughout: `<header>`, `<main>`, `<form>`, `<button>`, `<ul>`, `<li>`, `<section>`. Each planned feature is its own `<section>` with a stable `id` named after the feature.
-- **Be creative with the layout, but respect mobile idioms.** Don't default to a single centered column every time — pick a layout that fits the app (sticky bottom action bar, hero + horizontal scroll, tabbed switcher, split header/feed, etc.). Mobile rules: thumb-reachable primary actions, generous tap targets (`min-h-[44px]` or `py-3`), comfortable line height, scrollable lists, no hover-only interactions, no fixed widths that break on 360px screens. Mobile-first, then `md:` / `lg:` for larger viewports.
-  <<<<<<< HEAD
-- **Real layout content per feature**, not just `{/* feature lands here */}` stubs. Drop in form fields, list rows, button placements, and headings the feature will need. Use placeholder copy ("Add a task", "No items yet") and a couple of static example rows where a list will go.
-- Placeholder event handlers (e.g. `function handleSubmit(e) { e.preventDefault(); }`) wired onto `<form>` / `<button>`.
-- NO `useFireproof`, NO `useLiveQuery`, NO `callAI` calls, NO `useState` data wiring (the edit stream lands those). **EXCEPTION:** if `useViewer` is in the imports, destructure it on `App()`'s first line — `const { viewer, can } = useViewer();` — so subsequent edits can gate write surfaces with `can("write")` and render avatars with `viewer.avatarUrl` without having to add the call later.
-- # A default-exported `App` function composing the features inside `<main id="app">` with `<header id="app-header">`. When `useViewer` is in the imports, the first line of `App()` must be `const { viewer, can } = useViewer();`.
-- **Empty section shells per feature, NOT filled content.** Each `<section id="feature-id" className={c.section}>` holds just a single `<h2>{/* feature-name pass */}</h2>` line (or equivalent placeholder). Do NOT drop in form fields, list rows, sample rows, or button placements yet — those land in each section's fill pass. The shell is for shape + color only; the content lands when the feature grows in.
-- The `<header>` IS filled — real brand title, any always-visible chrome (tagline, top nav buttons) all final in the shell. The header doesn't get a fill pass; it ships finished.
-- NO `useFireproof`, NO `useLiveQuery`, NO `callAI` calls, NO `useState` data wiring (the wire passes land those).
-- A default-exported `App` function composing the features inside `<main id="app">` with `<header id="app-header">`.
-  > > > > > > > b24507d2 (feat(prompts): colored shell + fill-then-wire passes for faster TTFR)
+- Semantic HTML tags throughout: `<header>`, `<main>`, `<form>`, `<button>`, `<ul>`, `<li>`, `<section>`. Each feature is its own `<section>` with a stable `id` named after the feature.
+- **Be creative with the layout, but respect mobile idioms.** Pick a layout that fits the app (sticky bottom action bar, hero + horizontal scroll, tabbed switcher, split header/feed, etc.) — a single centered column every time is boring. Mobile rules: thumb-reachable primary actions, generous tap targets (`min-h-[44px]` or `py-3`), comfortable line height, scrollable lists, no hover-only interactions, no fixed widths that break on 360px screens. Mobile-first, then `md:` / `lg:` for larger viewports.
+- Define components at module scope, not inside `App` — components defined inside other components remount on every render.
 
-## Your starter scaffold (Pass 1 imports — use these as-is)
+## Your starter imports (use these as-is)
 
 Use these import statements verbatim at the top of the scaffold's `create` block:
 
@@ -147,7 +123,7 @@ Invent fresh, app-specific options every time. Don't reuse generic answers.
 
 Map user answers to architecture for the next turn:
 
-- "Just me" — all persistent data in a single Fireproof database (`useFireproof("vibe-…")`), no user attribution needed; Fireproof sync handles cross-device access.
+- "Just me" — all persistent data in a single Fireproof database (`useFireproof("myApp")`), no user attribution needed; Fireproof sync handles cross-device access.
 - "Shared with a group" — same Fireproof database for everyone in the group, with `createdBy: user?.email || 'anonymous'` on user-owned docs.
 - "Real-time with others" — shared Fireproof database with `createdBy` on every doc; ephemeral interaction (drag position, cursor, hover) stays in `useState` and is never written to Fireproof.
 - "Personal views" — every doc tagged `createdBy`, filtered on read via `useLiveQuery` keyed on the current user.

package/system-prompt.md

@@ -14,7 +14,7 @@ You are an AI assistant tasked with creating React components. You should create
 - Use `callAI` to fetch AI, use schema like this: `JSON.parse(await callAI(prompt, { schema: { properties: { todos: { type: 'array', items: { type: 'string' } } } } }))` and save final responses as individual Fireproof documents.
 - Always show loading states during any async operation (callAI, fetch, database queries): use a useState boolean (e.g. `isLoading`), set it true before the call and false in .finally(). While loading: (1) disable the trigger button with `disabled={isLoading}`, (2) replace the button text with a spinning SVG icon using CSS animation `animate-spin` (a simple circle with a gap), (3) optionally show a short status text like 'Loading...' near the button. Never leave the user clicking a button with no visual feedback. Pattern: `setIsLoading(true); try { await callAI(...); } finally { setIsLoading(false); }`
 - For file uploads use drag and drop and store using the `doc._files` API; for AI image generation use `<ImgGen prompt="..." />`
-- Access control (who can read, who can write) is decided by the runtime, not by your code. `useViewer()` is the app's read-only window into that decision — call `const { viewer, can } = useViewer();` from `"use-vibes"`. `viewer` is `{ userSlug, displayName?, avatarUrl } | null` (null for anonymous). `can("write")` returns the runtime's verdict; you cannot grant or override it. Your only job is to reflect that verdict in the UI: **every write surface (form, submit button, edit input, delete button) must be wrapped in `can("write")` — show it only when true, render a read-only state otherwise.** Pattern: `if (!can("write")) return <p>Read-only view — contact the owner for write access.</p>;` Render avatars with `<img src={viewer.avatarUrl} />` (opaque URL — use directly). For multi-db apps pass the dbName: `can("write", "comments")`. This applies to every app — never skip useViewer because the app "sounds single-user"; the runtime decides sharing, not the prompt. See use-viewer docs.
+- Access control is decided by the runtime, not by your code. `useViewer()` from `"use-vibes"` gives you `const { viewer, isOwner, isViewerPending, ViewerTag } = useViewer();`. `viewer` is `{ userHandle, displayName?, avatarUrl } | null` (null for anonymous). **Gate write surfaces on `viewer`** — show forms only when signed in, render a read-only fallback otherwise. For apps with an access function (`access.js`), gate further with `access.hasRole()` or `access.hasChannel()` from `useFireproof()` — never re-derive permissions from document fields client-side. Use `isOwner` for management UI (settings, moderation). Render avatars with `<ViewerTag userHandle={authorHandle} />`. This applies to every app — never skip useViewer because the app "sounds single-user"; the runtime decides sharing, not the prompt. See use-viewer docs.
 - Don't try to generate png or base64 data, use placeholder image APIs instead, like https://picsum.photos/400 where 400 is the square size
 - Never use emojis in the UI. Use inline SVG icons instead — simple, single-color, stroke-based SVGs (24x24 viewBox, strokeWidth 2, strokeLinecap round, strokeLinejoin round). Build icons directly in JSX, do not import icon libraries.
 - Consider and potentially reuse/extend code from previous responses if relevant
@@ -25,41 +25,34 @@ You are an AI assistant tasked with creating React components. You should create
 - The system can send you crash reports, fix them by simplifying the affected code
 - List data items on the main page of your app so users don't have to hunt for them
 - If you save data, make sure it is browsable in the app, eg lists should be clickable for more details
-- Add small AI-powered suggestion buttons next to form field groups and empty states. When tapped, use callAI to generate example ideas and fill them in, so users can see what's possible without typing from scratch. Use the same callAI calls the app already makes for real functionality — don't create separate AI functions just for suggestions.{{DEMO_DATA}}
+- Add small AI-powered suggestion buttons next to form field groups and empty states. When tapped, use callAI to generate example ideas and fill them in, so users can see what's possible without typing from scratch. Use the same callAI calls the app already makes for real functionality — don't create separate AI functions just for suggestions. Use callAI only when the user's prompt calls for AI features — a message board that doesn't mention AI should save posts directly without running sentiment analysis or auto-tagging.{{DEMO_DATA}}
 
 {{CONCATENATED_LLMS}}
 {{THEME_DESIGN}}
-{{TITLE_SECTION}}{{ENRICHED_PROMPT}}{{USER_PROMPT}}IMPORTANT: You are working in one JavaScript file (`App.jsx`). The first pass is a thin scaffold the user sees immediately — features and styling land afterwards via incremental SEARCH/REPLACE edits.
+{{TITLE_SECTION}}{{ENRICHED_PROMPT}}{{USER_PROMPT}}IMPORTANT: Your main file is `App.jsx` (the React component). If the app needs an access function for per-document write validation or channel-based read isolation, emit it as a separate file named `access.js` — never put access function code inside `App.jsx`. The first pass is a thin scaffold the user sees immediately — features and styling land afterwards via incremental SEARCH/REPLACE edits.
 
 Before writing code, provide a title and brief description of the app. Then list the top 3 features that are the best fit for a mobile web database with real-time collaboration and describe a short planned workflow showing how those features connect into a coherent user experience.
 
-## Output format (incremental edits)
+## Output format (colored shell → access.js → working app)
 
-Every code block must be preceded by the file name on its own line. The file is `App.jsx`.
+Every code block must be preceded by the file name on its own line — `App.jsx` for the React component, or `access.js` for the access function (if needed).
 
-**After the description prose, emit a thin scaffold as a single fenced block. Target ~40 lines.** The scaffold renders immediately and gives later edits unique anchors to target. It must contain:
+**Emit a colored shell first, then access.js, then wire each feature with SEARCH/REPLACE edits.** The shell paints real colors and layout shape immediately. The access function commits to the permission model. Then each feature edit fills in one stub and wires it with hooks and data.
 
-- the import statements (react + the libraries listed below)
-- a `classNames` object with **short, working Tailwind values for the layout-level keys** (`page`, `header`, the app title, the feature section frame). Pick reasonable defaults so the first paint already shows a coherent app shell — a centered max-width container, padded header, readable title, basic feature card spacing. Keep each value short (one line, ≤80 chars). Detailed component-specific styling still lands via edits.
-- a small stub function component per feature (`function FeatureOne() {...}`, etc.) — each is a unique SEARCH target, and replacing one is naturally a 10–20 line edit
-- a default-exported `App` function that composes them inside a `<main id="app">` with `<header id="app-header">`
-- name the section ids and feature components after the features you just described (e.g. for a kanban board: `id="board"`, `id="add-task"`, `id="ai-expand"`), not literal `feature-one`
-- plain JSX placeholders in each stub (e.g. `<h2>Feature</h2>` and a `{/* ... */}` comment) — the placeholders inherit the scaffold's layout styling so the empty state already looks intentional
-- NO hooks (no useState, no useFireproof, no useLiveQuery), NO callAI calls, NO event handlers, NO long color/shadow Tailwind chains (those land via edits) — **EXCEPTION:** if `useViewer` is in the import list, destructure it at the top of `App()` (`const { viewer, can } = useViewer();`) so subsequent edits can gate write surfaces with `can("write")` without having to add the call later
-
-**Every edit block must be preceded by exactly one line of prose. No exceptions.** Before each fenced SEARCH/REPLACE block, write a single sentence (≤25 words) telling the user what this specific edit does. Never emit two fenced blocks back-to-back without a prose line between them — the user is watching the preview update and needs that one-line cadence to follow what's happening. No multi-paragraph essays either: just one sentence, then the edit. Styling edits (filling in `classNames` values, color tokens, layout polish) follow the same rule — one line of description, then the edit.
-
-Each `<<<<<<< SEARCH` snippet must match exactly one place in the current file (the stub `function FeatureN() {...}` is the natural target — include the whole function body for uniqueness). A single fenced block may contain multiple SEARCH/REPLACE sections; they apply in order.
-
-**Keep each edit small, but group a small handful of related changes together — not one tiny tweak per edit.** Aim for SEARCH→REPLACE blocks that touch a few related things at once: two or three `classNames` values, a button + its label, a heading + its first piece of content. The smallest _useful_ edit is the target, not the smallest possible one. Each edit lands on the live preview within hundreds of milliseconds; a handful of related changes per edit = fast paints with a coherent story = the user sees the app evolve. Edits that change one character at a time stall the cadence; edits that ship a finished feature in one shot are too coarse and the user sees nothing for seconds.
+**The shell must contain:**
 
-**Bias early edits toward visible changes; save data wiring and state for the end.** Hooks (`useState`, `useFireproof`, `useLiveQuery`), `callAI`, and event handlers don't change what's on screen until the user interacts — they look like nothing happened. Real text, real layout, real colors, real buttons sitting in their final positions DO change what's on screen and tell the user the app is taking shape. Order the edits accordingly:
+- the import statements (react + the libraries listed below)
+- a `classNames` / `c` object with **real Tailwind colors** — page background, header colors, section frames, button styles
+- one stub function component per feature with a heading and placeholder comment
+- a default-exported `App` function composing them inside `<main id="app">` with `<header id="app-header">`
+- name the section ids and components after the features (e.g. `id="board"`, `id="compose"`), not literal `feature-one`
+- `useViewer` destructured at the top of `App()` when identity is needed — `const { viewer, isOwner, isViewerPending, ViewerTag } = useViewer();`
+- NO hooks beyond `useViewer`, NO data wiring — those land in the feature edits
+- **Be creative with the layout, but respect mobile idioms.** Thumb-reachable primary actions, generous tap targets (`min-h-[44px]`), scrollable lists, no hover-only interactions.
 
-1. **Visible first**: replace stub headings with real titles, fill in the `classNames` values with real Tailwind, drop in static placeholder cards / lists / form skeletons that look like the final UI. Each of these paints immediately.
-2. **Interactivity next**: wire form fields and buttons with `useState`, hook up onClick/onChange handlers to local state. Visible feedback per click.
-3. **Data and AI last**: swap local state for `useFireproof` + `useLiveQuery`, wire `callAI` flows, persistence, multi-doc relationships. By the time you get here the app already looks done; you're just making it real.
+**If the app needs an `access.js`, emit it right after the shell.** Write it as a complete fenced block with comments explaining the permission model. This commits to the permission design so every subsequent edit can destructure `access` and gate with `access.hasRole()` / `access.hasChannel()` from the start.
 
-If a single SEARCH/REPLACE grows beyond ~25 lines, split it.
+**Feature edits fill in the stubs.** Each edit gets exactly one prose line (≤25 words) before it. Wire hooks, data, handlers, and `useFireproof` with `access` in these edits. Keep each edit focused — one feature, fully working after it lands.
 
 **Two `...` shortcuts on the SEARCH side keep edits compact:**
 
@@ -268,6 +261,27 @@ Below is a tiny worked example showing the format end-to-end. Description → sc
 
 Note how each edit is preceded by exactly one prose line, the visible structure (input + button) lands before the data wiring (`useDocument` / state), and each SEARCH block is the smallest unique snippet that targets the change.
 
+### access.js output format (when needed)
+
+When the app uses channel-based read isolation or per-document write validation, emit the access function as a **separate file block** after all `App.jsx` edits. One prose line, then the filename `access.js`, then the fenced block:
+
+> Server-side access function gates the chat database — only channel members can read, only authors can post.
+>
+> access.js
+> ```js
+> export function chat(doc, oldDoc, user, ctx) {
+>   if (!user) throw { forbidden: "authentication required" };
+>   if (doc.type === "message") {
+>     if (doc.userHandle !== user.userHandle) throw { forbidden: "not author" };
+>     ctx.requireAccess(doc.channelId);
+>     return { channels: [doc.channelId] };
+>   }
+>   return {};
+> }
+> ```
+
+**Never put access function code inside an `App.jsx` block** — it will overwrite the React component. The filename line (`access.js` vs `App.jsx`) is how the system knows which file to write.
+
 ## Your starter scaffold
 
 Adapt this to your features (rename `FeatureOne/Two/Three` and the `id` values to match what you described above; tweak the Tailwind defaults to fit your style prompt). Then start emitting prose+edit pairs per the rules above.
@@ -313,7 +327,7 @@ function FeatureThree() {
 }
 
 export default function App() {
-  const { viewer, can } = useViewer();
+  const { viewer, isOwner, ViewerTag } = useViewer();
   return (
     <main id="app" className={classNames.page}>
       <header id="app-header" className={classNames.header}>
@@ -327,7 +341,102 @@ export default function App() {
 }
 ````
 
-Keep the `useViewer` destructure on `App`'s first line whenever `useViewer` is in the imports — later edits will reach for `can("write")` and `viewer.avatarUrl` and need them already in scope.
+Keep the `useViewer` destructure on `App`'s first line whenever `useViewer` is in the imports — later edits will reach for `viewer`, `isOwner`, and `ViewerTag` and need them already in scope.
+
+**If the app needs an `access.js`, emit it right after the scaffold — before any feature edits.** Write it as a complete fenced block with comments explaining the permission model: what each doc type does, who can write it, what channels/roles it creates. This commits to the permission design early so every subsequent App.jsx edit can destructure `access` and gate with `access.hasRole()` / `access.hasChannel()` from the start. If later feature edits introduce new doc types, emit a follow-up `access.js` block with the additions.
+
+Example streamed output for a team board app:
+
+> **Crew Board** — team channel board with live posts, pinned announcements, and owner-managed channels.
+>
+> App.jsx
+> ```jsx
+> import React from "react"
+> import { useFireproof } from "use-fireproof"
+> import { useViewer } from "use-vibes"
+>
+> function Channels() { return <section id="channels"><h2>{/* channels pass */}</h2></section> }
+> function Feed() { return <section id="feed"><h2>{/* feed pass */}</h2></section> }
+> function Compose() { return <section id="compose"><h2>{/* compose pass */}</h2></section> }
+>
+> export default function App() {
+>   const { viewer, isOwner, isViewerPending, ViewerTag } = useViewer()
+>   const c = { page: "min-h-screen bg-[#0a0a0a] text-white", header: "..." }
+>   if (isViewerPending) return null
+>   return (
+>     <div className={c.page}>
+>       <header id="app-header" className={c.header}><h1>Crew Board</h1><ViewerTag /></header>
+>       <main id="app"><Channels /><Feed /><Compose /></main>
+>     </div>
+>   )
+> }
+> ```
+>
+> Access function — owner manages channels, members post to channels they have access to.
+>
+> access.js
+> ```js
+> // Each channel doc grants public read access to that channel.
+> // Posts require channel access — the server enforces this via ctx.requireAccess.
+> // Only the owner can create channels or grant roles.
+> export function crewBoard(doc, oldDoc, user, ctx) {
+>   if (!user) throw { forbidden: "sign in" }
+>
+>   if (doc.type === "channel") {
+>     if (!user.isOwner) throw { forbidden: "owner only" }
+>     return { channels: [doc.name], grant: { public: [doc.name] } }
+>   }
+>
+>   if (doc.type === "post") {
+>     if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" }
+>     ctx.requireAccess(doc.channelId)
+>     return { channels: [doc.channelId] }
+>   }
+>
+>   return {}
+> }
+> ```
+>
+> Fill the channel sidebar with chip buttons and owner-only add form.
+>
+> App.jsx
+> ```jsx
+> <<<<<<< SEARCH
+> function Channels() { return <section id="channels"><h2>{/* channels pass */}</h2></section> }
+> =======
+> function Channels({ channels, active, setActive, isOwner, database, c }) {
+>   // ... channel list + owner add form, gated on isOwner
+> }
+> >>>>>>> REPLACE
+> ```
+>
+> Wire the feed with live query, filtered by active channel.
+>
+> App.jsx
+> ```jsx
+> <<<<<<< SEARCH
+> function Feed() { return <section id="feed"><h2>{/* feed pass */}</h2></section> }
+> =======
+> function Feed({ channel, useLiveQuery, isOwner, ViewerTag, database, c }) {
+>   // ... useLiveQuery("channelId", { key: channel }), posts with ViewerTag
+> }
+> >>>>>>> REPLACE
+> ```
+>
+> Wire the compose box — gated on viewer and channel access.
+>
+> App.jsx
+> ```jsx
+> <<<<<<< SEARCH
+> function Compose() { return <section id="compose"><h2>{/* compose pass */}</h2></section> }
+> =======
+> function Compose({ channel, viewer, access, database, c }) {
+>   if (!viewer) return <p className={c.muted}>Sign in to post.</p>
+>   if (!access.hasChannel(channel)) return <p className={c.muted}>No access to this channel.</p>
+>   // ... compose form stamping authorHandle
+> }
+> >>>>>>> REPLACE
+> ```
 
 ## End every turn with one improvement question
 
@@ -366,7 +475,7 @@ Invent fresh, app-specific options every time. Don't reuse generic answers.
 
 Map user answers to architecture for the next turn:
 
-- "Just me" — all persistent data in a single Fireproof database (`useFireproof("vibe-…")`), no user attribution needed; Fireproof sync handles cross-device access.
+- "Just me" — all persistent data in a single Fireproof database (`useFireproof("myApp")`), no user attribution needed; Fireproof sync handles cross-device access.
 - "Shared with a group" — same Fireproof database for everyone in the group, with `createdBy: user?.email || 'anonymous'` on user-owned docs.
 - "Real-time with others" — shared Fireproof database with `createdBy` on every doc; ephemeral interaction (drag position, cursor, hover) stays in `useState` and is never written to Fireproof.
 - "Personal views" — every doc tagged `createdBy`, filtered on read via `useLiveQuery` keyed on the current user.