@vibes.diy/prompts 2.4.12 → 2.4.13

package/llms/fireproof.md

@@ -320,14 +320,32 @@ The AI agent writes the access function (so it knows the role names) and writes
 
 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 grant:** A `channelSetup` document uses `grant.public` so all members can read, and `grant.roles` so posters can write to specific channels.
+- **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 `ownerHandle` (not `userHandle`) when rendering another user.
+- **`ViewerTag`** takes `userHandle` when rendering another user.
 
 access.js
 
@@ -335,13 +353,14 @@ access.js
 export function announcements(doc, oldDoc, user, ctx) {
   if (!user) throw { forbidden: "sign in" };
 
-  if (doc.type === "channelSetup") {
+  if (doc.type === "channel") {
     if (!user.isOwner) throw { forbidden: "owner only" };
     return {
-      channels: [doc.channel],
+      channels: [doc._id],
       grant: {
-        public: [doc.channel],
-        roles: { poster: [doc.channel] },
+        users: { [user.userHandle]: [doc._id] },
+        public: [doc._id],
+        roles: { poster: [doc._id] },
       },
     };
   }
@@ -394,7 +413,7 @@ export default function App() {
     <div>
       <ViewerTag />
 
-      {/* membership + channel gate */}
+      {/* access.hasChannel covers public + restricted — the access function handles the distinction */}
       {viewer && access.hasChannel(channel) && (
         <form
           onSubmit={(e) => {
@@ -416,7 +435,7 @@ export default function App() {
 
       {posts.map((p) => (
         <div key={p._id}>
-          <ViewerTag ownerHandle={p.authorHandle} />
+          <ViewerTag userHandle={p.authorHandle} />
           <p>{p.body}</p>
           {isOwner && <button onClick={() => database.del(p._id)}>Delete</button>}
         </div>
@@ -428,6 +447,62 @@ export default function App() {
 
 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`)
@@ -501,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.

package/llms/use-viewer.md

@@ -58,7 +58,7 @@ 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";
@@ -85,7 +85,7 @@ function CommentThread() {
       <ul>
         {comments.map((c) => (
           <li key={c._id}>
-            <ViewerTag ownerHandle={c.authorHandle} />
+            <ViewerTag userHandle={c.authorHandle} />
             <p>{c.body}</p>
           </li>
         ))}
@@ -118,7 +118,7 @@ function CommentThread() {
 
 Key points:
 
-- **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.
+- **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.
 
@@ -139,14 +139,14 @@ const { viewer, ViewerTag } = useViewer();
 <ViewerTag />
 
 // Show another user read-only (no edit affordance):
-<ViewerTag ownerHandle={comment.authorHandle} />
+<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 `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.
+**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 `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.
+**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.
 
@@ -156,4 +156,4 @@ const { viewer, ViewerTag } = useViewer();
 <ViewerTag style={{ borderRadius: 8, fontSize: 12 }} />
 ```
 
-Use `<ViewerTag />` (no props) for the current user and `<ViewerTag ownerHandle={...} />` 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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "2.4.12",
+  "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.12",
-    "@vibes.diy/use-vibes-types": "^2.4.12",
+    "@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,78 +14,39 @@ 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 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.
+- 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: 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.
+{{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 — `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.
-
-**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:
-
-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.
-
-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.
-
-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_
->
-> ```jsx
-> <<<<<<< SEARCH
-> ...filled section as it stands now...
-> =======
-> ...same section, with hooks, data, callAI, loading wired up...
-> >>>>>>> REPLACE
-> ```
->
-> _... repeat fill → wire for each feature section_
+- 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.
 
-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.
+Target ~40–60 lines. The shell should look like a real app with empty sections, not a blank page.
 
-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.
+**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.
 
-**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.
-
-**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.
+**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.
 
 > Access function — owner manages channels, authenticated users post to channels they have access to.
 >
@@ -113,20 +74,13 @@ If a feature needs hooks at the top of the component (a `useFireproof` whose `da
 
 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
-
-- 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.
-- **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). **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();`.
+## Code style rules
 
-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.
+- 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:
 

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 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.
+- 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,7 +25,7 @@ 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}}
@@ -33,33 +33,26 @@ You are an AI assistant tasked with creating React components. You should create
 
 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 — `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, 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.
-
-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.
+**The shell must contain:**
 
-**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.
-
-**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:**