@vibes.diy/prompts 2.4.11 → 2.4.12

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,162 @@ 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.
+
+### 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 grant:** A `channelSetup` document uses `grant.public` so all members can read, and `grant.roles` so posters can write to specific channels.
+- **Write surfaces** are gated with `viewer` (signed in?), `access.hasChannel()` (channel access), or `isOwner` (management).
+- **`ViewerTag`** takes `ownerHandle` (not `userHandle`) when rendering another user.
+
+access.js
+
+```js
+export function announcements(doc, oldDoc, user, ctx) {
+  if (!user) throw { forbidden: "sign in" };
+
+  if (doc.type === "channelSetup") {
+    if (!user.isOwner) throw { forbidden: "owner only" };
+    return {
+      channels: [doc.channel],
+      grant: {
+        public: [doc.channel],
+        roles: { poster: [doc.channel] },
+      },
+    };
+  }
+
+  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 />
+
+      {/* membership + channel gate */}
+      {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 ownerHandle={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.
+
 ---
 
 ## 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 +449,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");
 ```
 
@@ -354,8 +511,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 +554,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 +563,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 +594,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 +610,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 +641,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 +650,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 +704,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 +721,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 +740,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 +839,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 +920,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 +944,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 +1007,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>
   );
 }
@@ -64,8 +65,8 @@ 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 ownerHandle={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 ownerHandle={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 ownerHandle={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 `ownerHandle` 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 `ownerHandle` 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 ownerHandle={...} />` 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.12",
   "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.12",
+    "@vibes.diy/use-vibes-types": "^2.4.12",
     "arktype": "~2.2.0",
     "json-schema-faker": "~0.6.1"
   },

package/system-prompt-initial.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 ownerHandle={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
@@ -23,13 +23,13 @@ You are an AI assistant tasked with creating React components. You should create
 
 {{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. 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.
 
 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)
 
-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.
 
@@ -85,7 +85,33 @@ If a feature needs hooks at the top of the component (a `useFireproof` whose `da
 
 **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.
 
-After your final edit, add a short 1-2 sentence message describing the core workflow the app supports.
+**If the app needs an `access.js`, emit it right after the colored shell — before any fill/wire passes.** 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 fill/wire pass can use `access.hasRole()` / `access.hasChannel()` from the start. If later passes introduce new doc types, emit a follow-up `access.js` block with the additions.
+
+> Access function — owner manages channels, authenticated users 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.
+> 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 {}
+> }
+> ```
+
+**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 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
 
@@ -93,16 +119,12 @@ After your final edit, add a short 1-2 sentence message describing the core work
 - 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)
+- NO `useFireproof`, NO `useLiveQuery`, NO `callAI` calls, NO `useState` data wiring (the wire passes land those). **EXCEPTION:** if `useViewer` is in the imports, destructure it on `App()`'s first line — `const { viewer, isOwner, ViewerTag } = useViewer();` — so subsequent edits can gate write surfaces with `viewer` and render identity with `ViewerTag` 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, isOwner, isViewerPending, ViewerTag } = useViewer();`.
+
+Since `access.js` was emitted before the feature passes, the first `useFireproof` wire pass should destructure `access` — `const { database, useLiveQuery, access } = useFireproof("dbName")` — so permission gates can use `access.hasRole()` and `access.hasChannel()` immediately.
 
 ## Your starter scaffold (Pass 1 imports — use these as-is)
 
@@ -147,7 +169,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 ownerHandle={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
@@ -29,13 +29,13 @@ You are an AI assistant tasked with creating React components. You should create
 
 {{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)
 
-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:
 
@@ -45,7 +45,7 @@ Every code block must be preceded by the file name on its own line. The file is
 - 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
+- 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, isOwner, ViewerTag } = useViewer();`) so subsequent edits can gate write surfaces with `viewer` and render identity with `ViewerTag` 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.
 
@@ -268,6 +268,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 +334,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 +348,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 +482,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.