@vibes.diy/prompts 3.0.4 → 4.0.3

package/README.md

@@ -1,23 +1,23 @@
 [![Join our
   Discord](https://discord-badge.selem.workers.dev/i/vnpWycj4Ta.svg)](https://discord.gg/vnpWycj4Ta)
 
-# ✨ Vibes DIY — make apps with your friends
+# ✨ Vibes DIY — make apps with your friends, run the front counter
 
 Software is getting weird again. Describe what you want and get a real, live app — fun, done, and alive. [Try it now](https://vibes.diy/) or [fork on GitHub](https://github.com/VibesDIY/vibes.diy).
 
-Make apps with your friends, so easy even AI can do it. Describe your app in plain words, it builds instantly, and you keep changing it just by talking to it. Share the link and your friends join right away — no setup, no "wait, let me send you the invite."
+Make apps with your friends — or run the front counter. So easy even AI can do it. Describe your app in plain words, it builds instantly, and you keep changing it just by talking to it. Share the link and your friends — or your customers — join right away. No setup, no "wait, let me send you the invite."
 
 ## Why it's different
 
-- **Fun** — build for any reason, or no reason at all.
-- **Done** — it's a real app at its own live link, not a prototype. State is saved automatically.
+- **Fun** — build for any reason, or no reason at all. Or because the spreadsheet is killing you.
+- **Done** — it's a real app at its own live link, not a prototype. It can take an order — add a payment flow when you wire one up. State is saved automatically.
 - **Alive** — keep talking to it and it keeps changing. So can anyone you share it with.
 
 Seeing a vibe makes you want to change it. Start from someone else's, tweak it to fit you, share it, and the people you share with remix their own version. You're not a user anymore — you're a maker.
 
 ## What people make
 
-A character bot that answers in your voice. A neighborhood resource tracker you share at the next town meeting. A flashcard app remixed into collaborative trivia your students change live. A workout tracker a whole gym swaps routines on. Every one is the same move: start, tweak, share, remix.
+From the group chat to the front counter. A character bot that answers in your voice. A neighborhood resource tracker you share at the next town meeting. A daily-specials board that takes the order. The shared spreadsheet your team fights over, turned into a real app with a form and a dashboard. A booking-and-intake app your clients fill out themselves. Every one is the same move: start, tweak, share, remix.
 
 ## Yours to control
 

package/llms/fireproof.md

@@ -367,6 +367,22 @@ Each capability (`read`, `write`, `delete`) is independent. Omitting one falls b
 
 Other `acl` variants: `useFireproof("drafts", { acl: { read: ["editors"], write: ["editors"], delete: ["editors"] } })` for editors-only space, or omit `acl` entirely to fall back to app-level role gates (existing behavior, always safe).
 
+## Anonymous local writes (`anonymousLocal`)
+
+For "let a logged-out visitor try it and save a little state before signing in," pass `{ anonymousLocal: true }`. While logged out, `put`/`del`/`useLiveQuery`/`useDocument` run against a local (localStorage) store with the identical API — no auth branching in your code. On first sign-in the local docs migrate into the cloud database, then local storage clears.
+
+```js
+const { useLiveQuery, database } = useFireproof("favorites", {
+  anonymousLocal: true,
+  // Optional: reshape/stamp each local doc for its new owner; return falsy to drop it.
+  // Preserve `_id` (spread `...doc`) — migration retries are only idempotent when
+  // the id is kept, otherwise a retry after a partial failure creates duplicates.
+  migrate: (doc, userHandle) => ({ ...doc, owner: userHandle }),
+});
+```
+
+Notes: use it only where anonymous-first state makes sense (favorites, drafts, a scratch list). A returning signed-out visitor is automatically steered to sign in rather than starting a fresh throwaway local session. Migration keeps local data intact if it fails, so nothing is lost.
+
 ## 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. Use `access.roles` (ReadonlySet), `access.channels` (ReadonlySet), `access.hasRole(name)`, and `access.hasChannel(name)`. Use these to reflect roles/channels in the UI; gate writes with `useVibe(dbName).can`.
@@ -434,7 +450,7 @@ This example shows the full round-trip — access.js declares channels and grant
 - **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 `useVibe(dbName).can.create/edit/delete` — it runs this same access function, so the UI verdict matches the server. Render `.reason` when denied. (See use-vibe docs.)
-- **`ViewerTag`** takes `userHandle` when rendering another user.
+- **`ViewerTag`** takes `userHandle` to render another user (authors, rosters). The current viewer's own pill and sign-in button are system chrome in the Vibes Switch (the logo) — don't add one to the app's UI, except a guarded no-prop `{viewer && <ViewerTag />}` when you want inline avatar self-edit for any signed-in member (see use-viewer docs).
 
 access.js
 
@@ -519,7 +535,8 @@ export default function App() {
 
   return (
     <div>
-      <ViewerTag />
+      {/* No current-user pill / sign-in button here — that's system chrome in the
+          Vibes Switch (the panel the logo opens). ViewerTag below renders post authors. */}
 
       {/* gate the write surface on useVibe().can — it runs the access function */}
       {canPost.ok ? (

package/llms/use-vibe.md

@@ -16,20 +16,19 @@ Pass the Fireproof database name you are writing to. You get:
 
 ## The rule
 
-Gate every write affordance on `can.*`. Render `reason` when denied. Never branch write permission on `viewer`, `access.hasRole()`/`access.hasChannel()`, or document fields — those drift from what `access.js` actually does. Identity display (avatars, "signed in as") comes from `useViewer()`'s `ViewerTag`, not from `useVibe`.
+Gate every write affordance on `can.*`. Render `reason` when denied. Never branch write permission on `viewer`, `access.hasRole()`/`access.hasChannel()`, or document fields — those drift from what `access.js` actually does. Rendering **other** users (authors, rosters) is `useViewer()`'s `<ViewerTag userHandle={...} />`, not `useVibe`. The current viewer's own pill and the "signed in as" / sign-in button are system chrome in the Vibes Switch (the logo) — don't build them into the app. (The one exception is inline avatar self-edit: a guarded no-prop `{viewer && <ViewerTag />}` lets any signed-in member change their own photo in place — see use-viewer docs.)
 
 ```jsx
-import { useVibe, useViewer } from "use-vibes";
+import { useVibe } from "use-vibes";
 
 function PromptBar({ database }) {
   const { can, ready, me } = useVibe("aestheticBoard");
-  const { ViewerTag } = useViewer();
   if (!ready) return <div className="skeleton" />;
   const v = can.create({ type: "tile", authorHandle: me?.userHandle });
   if (!v.ok) return <p className="muted">{v.reason}</p>; // e.g. "authentication required"
   return (
     <form onSubmit={/* … */}>
-      <ViewerTag />
+      {/* no current-user pill — identity + sign-in live in the Vibes Switch (the logo) */}
       <input placeholder="Add a tile…" />
       <button type="submit">Post</button>
     </form>

package/llms/use-viewer.md

@@ -1,12 +1,14 @@
 # useViewer Hook
 
-`useViewer()` is a **read-only window** into viewer identity. The platform owns the rules — who's the owner, who has been granted read or write — and `useViewer()` lets your app see who's signed in and render their identity. You cannot grant or revoke access from code; you can only reflect the runtime's verdict in your UI.
+`useViewer()` is a **read-only window** into viewer identity. The platform owns the rules — who's the owner, who has been granted read or write — and `useViewer()` lets your app see who's signed in and render identity. You cannot grant or revoke access from code; you can only reflect the runtime's verdict in your UI.
 
-Use `useViewer()` for identity and display only — `ViewerTag`, avatars, and showing who's signed in. **Write surfaces are gated with `useVibe(dbName).can`** (see use-vibe docs), not with `viewer`/`access.*`.
+**The signed-in viewer's own pill and the Sign in button are system chrome — you don't build them.** The platform shows the current user (and a "Sign in" button when anonymous) inside the **Vibes Switch**, the panel that opens when you click the logo. A visitor always has a way to see who they are and sign in from there, so your app does **not** need to add a header pill or a login button for the current viewer — don't render a no-prop `<ViewerTag />` just to show "who's signed in" or to offer sign-in. To find the login button, click the logo.
+
+Use `useViewer()` to render **other** people's identity — comment authors, rosters, "added by" labels — with `<ViewerTag userHandle={...} />`, and to read `viewer`/`can` when your UI needs to branch on who's looking. **Write surfaces are gated with `useVibe(dbName).can`** (see use-vibe docs), not with `viewer`/`access.*`.
 
 ## Basic Usage
 
-Start with a minimal component that shows the viewer identity:
+Start with a minimal component that reads the viewer identity. You don't render a sign-in button or a current-user pill — those live in the Vibes Switch (click the logo). Just branch on `viewer` for any welcome/empty copy your app needs:
 
 App.jsx
 
@@ -16,17 +18,15 @@ import { useFireproof } from "use-fireproof";
 import { useViewer } from "use-vibes";
 
 export default function App() {
-  const { viewer, isViewerPending, ViewerTag } = useViewer();
+  const { viewer, isViewerPending } = useViewer();
 
   if (isViewerPending) return null;
 
   return (
     <div>
-      <header>
-        <ViewerTag />
-      </header>
-      {!viewer && <p>Sign in.</p>}
-      {viewer && <p>Welcome back!</p>}
+      {/* No sign-in button here — the logo opens the Vibes Switch, which shows
+          the current user and a "Sign in" button as system chrome. */}
+      {viewer ? <p>Welcome back, {viewer.displayName ?? viewer.userHandle}!</p> : <p>Sign in from the logo menu to get started.</p>}
     </div>
   );
 }
@@ -41,7 +41,7 @@ export default function App() {
 
 ## Gating UI
 
-Add a "commenting as" label and a write-gated form. Use `useVibe("comments").can` to gate the form; `ViewerTag` handles sign-in/identity display:
+Gate the comment form on `useVibe("comments").can` — not on `viewer`. The current viewer never needs a pill here (that's in the Vibes Switch); just render the gated form and its `reason` when denied:
 
 App.jsx
 
@@ -57,9 +57,9 @@ App.jsx
 
 ```jsx
 <<<<<<< SEARCH
-  const { viewer, isViewerPending, ViewerTag } = useViewer();
+  const { viewer, isViewerPending } = useViewer();
 =======
-  const { viewer, isViewerPending, ViewerTag } = useViewer();
+  const { viewer, isViewerPending } = useViewer();
   const { can, ready, me } = useVibe("comments");
 >>>>>>> REPLACE
 ```
@@ -68,15 +68,8 @@ App.jsx
 
 ```jsx
 <<<<<<< SEARCH
-      {!viewer && <p>Sign in.</p>}
-      {viewer && <p>Welcome back!</p>}
+      {viewer ? <p>Welcome back, {viewer.displayName ?? viewer.userHandle}!</p> : <p>Sign in from the logo menu to get started.</p>}
 =======
-      {/* identity display */}
-      <div style={{ display: "flex", alignItems: "center", gap: 8 }}>
-        {viewer && <span style={{ fontSize: 13, color: "var(--muted, #888)" }}>commenting as</span>}
-        <ViewerTag />
-      </div>
-
       {/* write gate: useVibe().can, not viewer */}
       {!ready ? null : (() => {
         const v = can.create({ type: "comment", authorHandle: me?.userHandle });
@@ -111,7 +104,7 @@ import { useFireproof } from "use-fireproof";
 
 ```jsx
 <<<<<<< SEARCH
-  const { viewer, isViewerPending, ViewerTag } = useViewer();
+  const { viewer, isViewerPending } = useViewer();
   const { can, ready, me } = useVibe("comments");
 =======
   const { viewer, isViewerPending, ViewerTag } = useViewer();
@@ -137,6 +130,7 @@ import { useFireproof } from "use-fireproof";
         );
       })()}
 =======
+      {/* render OTHER users with userHandle — that's what ViewerTag is for here */}
       <ul>
         {comments.map((c) => (
           <li key={c._id}>
@@ -146,12 +140,6 @@ import { useFireproof } from "use-fireproof";
         ))}
       </ul>
 
-      {/* identity display */}
-      <div style={{ display: "flex", alignItems: "center", gap: 8 }}>
-        {viewer && <span style={{ fontSize: 13, color: "var(--muted, #888)" }}>commenting as</span>}
-        <ViewerTag />
-      </div>
-
       {/* write gate: useVibe().can, not viewer */}
       {!ready ? null : (() => {
         const v = can.create({ type: "comment", authorHandle: me?.userHandle });
@@ -201,36 +189,23 @@ Key points:
 
 ## ViewerTag
 
-`ViewerTag` is a ready-made inline user pill returned alongside `viewer` from `useViewer()`. It is not a separate import — you get it from the hook.
-
-Show the current viewer (edit ring appears — they can tap to change their avatar):
-
-App.jsx
+`ViewerTag` is a ready-made inline user pill returned alongside `viewer` from `useViewer()`. It is not a separate import — you get it from the hook. **Use it to render _other_ people** — comment authors, roster rows, "added by" labels — by passing `userHandle`:
 
 ```jsx
-<<<<<<< SEARCH
-      <div style={{ display: "flex", alignItems: "center", gap: 8 }}>
-        {viewer && <span style={{ fontSize: 13, color: "var(--muted, #888)" }}>commenting as</span>}
-        <ViewerTag />
-      </div>
-=======
-      <div style={{ display: "flex", alignItems: "center", gap: 8 }}>
-        {viewer && <span style={{ fontSize: 13, color: "var(--muted, #888)" }}>commenting as</span>}
-        <ViewerTag />
-        {/* Show another user read-only (no edit affordance): */}
-        <ViewerTag userHandle={comments[0]?.authorHandle} />
-        {/* Style override: */}
-        <ViewerTag style={{ borderRadius: 8, fontSize: 12 }} />
-      </div>
->>>>>>> REPLACE
+{/* Show another user read-only: */}
+<ViewerTag userHandle={comment.authorHandle} />
+{/* Style override: */}
+<ViewerTag userHandle={member.userHandle} style={{ borderRadius: 8, fontSize: 12 }} />
 ```
 
-**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.
+**The current viewer's identity and sign-in are system chrome, not app UI.** The platform already shows the current user — and offers a "Sign in" button to anonymous viewers — inside the Vibes Switch that opens from the logo. So don't add a no-prop `<ViewerTag />` as a header pill or login button just to show who's signed in; reach for `userHandle` to render someone else instead.
+
+**The one in-app reason to render a no-prop `<ViewerTag />` is inline avatar self-edit.** A no-prop tag shows the signed-in viewer a dashed edit ring that lets them change their _own_ avatar in place, and that works for **every** signed-in viewer — the Switch's avatar editing is owner-only. So if your app wants any member (not just the owner) to update their photo without leaving the app, render a guarded `{viewer && <ViewerTag />}` for that — otherwise leave the current-viewer pill to the Switch.
 
 **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 `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.
+**Anonymous & always-safe.** `ViewerTag` never throws regardless of login state. A no-prop `<ViewerTag />` would render a "Sign in" button for anonymous viewers, but you don't need to place one for sign-in — the logo's Vibes Switch already offers it.
 
 **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.
 
-Use `<ViewerTag />` (no props) for the current user and `<ViewerTag userHandle={...} />` for others. That's the whole API.
+Pass `<ViewerTag userHandle={...} />` to render other people. The no-prop `<ViewerTag />` (current user) covers identity and sign-in too, but the logo's Vibes Switch already does that — reach for it only when you specifically want inline avatar self-edit for any signed-in member.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "3.0.4",
+  "version": "4.0.3",
   "type": "module",
   "main": "./index.js",
   "description": "",
@@ -24,13 +24,9 @@
   "license": "Apache-2.0",
   "dependencies": {
     "@adviser/cement": "~0.5.34",
-    "@fireproof/core": "~0.24.19",
-    "@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": "^3.0.4",
-    "@vibes.diy/identity": "^3.0.4",
-    "@vibes.diy/use-vibes-types": "^3.0.4",
+    "@vibes.diy/call-ai-v2": "^4.0.3",
+    "@vibes.diy/identity": "^4.0.3",
+    "@vibes.diy/use-vibes-types": "^4.0.3",
     "arktype": "~2.2.1",
     "json-schema-faker": "~0.6.2"
   },

package/system-prompt-initial.md

@@ -17,7 +17,7 @@ You are an AI assistant tasked with creating React components. You should create
 - 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); }`
 - Give instant feedback for Fireproof writes too, not just for callAI/fetch. A `database.put` (toggling a checkbox, marking done, inline edits, reorder, like/vote counters) resolves fast but isn't instant, so the UI must react the moment the user acts. Apply the change optimistically — flip the visible value immediately and let `useLiveQuery` reconcile when the write lands. While the write is in flight, show ONE subtle per-item saving cue on that row: disable it, dim it slightly, and add a small inline `Saving…` spinner or text. Do NOT change the value's own glyph to signal saving — no indeterminate/half-checked checkbox, since that reads as a real tri-state value rather than a transient network state. Track pending state in a keyed collection (e.g. a `Set` of saving ids in `useState` — add the id before the write, delete it in `.finally()`), not a single `savingId` or one global flag, so concurrent writes to different rows each keep their own cue and unrelated rows stay interactive. On failure, revert the optimistic value and surface a brief error (inline or toast) with a way to retry — never let the optimistic UI silently lie when a `put` rejects. Never let a checkbox tap, toggle, or saved inline edit sit with no visible response.
 - 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 your code. Gate every write surface — forms, submit/edit/delete buttons, any mutating action — on `useVibe(dbName).can`. `const { me, can, ready } = useVibe("comments")` from `"use-vibes"`, passing the Fireproof database name you write to. Show the editor when `can.create(draft).ok` (or `can.edit(doc)` / `can.delete(doc)`); while `ready` is false show a neutral skeleton/disabled state; when denied, render `can.create(draft).reason` as the fallback copy (the sign-in or join prompt). `can.*` runs the app's own `access.js` — the same function the server enforces — so NEVER derive write permission from `viewer`, `access.hasRole()`/`access.hasChannel()`, or document fields. `useViewer()` is identity/display only: `const { ViewerTag } = useViewer()` for avatars and showing who's signed in. Owner-only management UI is gated on `can.*` too (the access.js encodes the owner rule). This applies to every app — the runtime decides sharing, not the prompt. Writes can still be rejected server-side even when `can.*` allows, so keep the optimistic-write + rollback handling. See use-vibe docs.
+- Access control is decided by the runtime, not your code. Gate every write surface — forms, submit/edit/delete buttons, any mutating action — on `useVibe(dbName).can`. `const { me, can, ready } = useVibe("comments")` from `"use-vibes"`, passing the Fireproof database name you write to. Show the editor when `can.create(draft).ok` (or `can.edit(doc)` / `can.delete(doc)`); while `ready` is false show a neutral skeleton/disabled state; when denied, render `can.create(draft).reason` as the fallback copy (the sign-in or join prompt). `can.*` runs the app's own `access.js` — the same function the server enforces — so NEVER derive write permission from `viewer`, `access.hasRole()`/`access.hasChannel()`, or document fields. `useViewer()` is identity/display only: `const { ViewerTag } = useViewer()` renders **other** people (`<ViewerTag userHandle={...} />` for comment authors, rosters, "added by" labels). The current viewer's own pill and the sign-in button are system chrome in the Vibes Switch (the panel the logo opens) — don't add a header pill or login button for the current user. Owner-only management UI is gated on `can.*` too (the access.js encodes the owner rule). This applies to every app — the runtime decides sharing, not the prompt. Writes can still be rejected server-side even when `can.*` allows, so keep the optimistic-write + rollback handling. See use-vibe 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
@@ -41,7 +41,7 @@ Every code block must be preceded by the file name on its own line — `App.jsx`
 - The `<header>` with the real brand title and any always-visible chrome.
 - One stub function component per feature with a heading — these are the anchors for later edits.
 - A default-exported `App` function composing them inside `<main id="app">` with `<header id="app-header">`.
-- When a write surface needs gating, destructure `useVibe` for the database it writes to — `const { can, ready } = useVibe("<dbName>");` — and `useViewer` for identity — `const { ViewerTag } = useViewer();`
+- When a write surface needs gating, destructure `useVibe` for the database it writes to — `const { can, ready } = useVibe("<dbName>");`. Only destructure `useViewer` (`const { ViewerTag } = useViewer();`) when you render **other** users — `<ViewerTag userHandle={...} />` for authors/rosters. The current viewer's pill and sign-in live in the Vibes Switch (the logo), so don't add one to your header.
 - **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 `useVibe`/`useViewer`, NO data wiring — those land in the feature edits.
 

package/system-prompt.md

@@ -17,7 +17,7 @@ You are an AI assistant tasked with creating React components. You should create
 - 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); }`
 - Give instant feedback for Fireproof writes too, not just for callAI/fetch. A `database.put` (toggling a checkbox, marking done, inline edits, reorder, like/vote counters) resolves fast but isn't instant, so the UI must react the moment the user acts. Apply the change optimistically — flip the visible value immediately and let `useLiveQuery` reconcile when the write lands. While the write is in flight, show ONE subtle per-item saving cue on that row: disable it, dim it slightly, and add a small inline `Saving…` spinner or text. Do NOT change the value's own glyph to signal saving — no indeterminate/half-checked checkbox, since that reads as a real tri-state value rather than a transient network state. Track pending state in a keyed collection (e.g. a `Set` of saving ids in `useState` — add the id before the write, delete it in `.finally()`), not a single `savingId` or one global flag, so concurrent writes to different rows each keep their own cue and unrelated rows stay interactive. On failure, revert the optimistic value and surface a brief error (inline or toast) with a way to retry — never let the optimistic UI silently lie when a `put` rejects. Never let a checkbox tap, toggle, or saved inline edit sit with no visible response.
 - 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 your code. Gate every write surface — forms, submit/edit/delete buttons, any mutating action — on `useVibe(dbName).can`. `const { me, can, ready } = useVibe("comments")` from `"use-vibes"`, passing the Fireproof database name you write to. Show the editor when `can.create(draft).ok` (or `can.edit(doc)` / `can.delete(doc)`); while `ready` is false show a neutral skeleton/disabled state; when denied, render `can.create(draft).reason` as the fallback copy (the sign-in or join prompt). `can.*` runs the app's own `access.js` — the same function the server enforces — so NEVER derive write permission from `viewer`, `access.hasRole()`/`access.hasChannel()`, or document fields. `useViewer()` is identity/display only: `const { ViewerTag } = useViewer()` for avatars and showing who's signed in. Owner-only management UI is gated on `can.*` too (the access.js encodes the owner rule). This applies to every app — the runtime decides sharing, not the prompt. Writes can still be rejected server-side even when `can.*` allows, so keep the optimistic-write + rollback handling. See use-vibe docs.
+- Access control is decided by the runtime, not your code. Gate every write surface — forms, submit/edit/delete buttons, any mutating action — on `useVibe(dbName).can`. `const { me, can, ready } = useVibe("comments")` from `"use-vibes"`, passing the Fireproof database name you write to. Show the editor when `can.create(draft).ok` (or `can.edit(doc)` / `can.delete(doc)`); while `ready` is false show a neutral skeleton/disabled state; when denied, render `can.create(draft).reason` as the fallback copy (the sign-in or join prompt). `can.*` runs the app's own `access.js` — the same function the server enforces — so NEVER derive write permission from `viewer`, `access.hasRole()`/`access.hasChannel()`, or document fields. `useViewer()` is identity/display only: `const { ViewerTag } = useViewer()` renders **other** people (`<ViewerTag userHandle={...} />` for comment authors, rosters, "added by" labels). The current viewer's own pill and the sign-in button are system chrome in the Vibes Switch (the panel the logo opens) — don't add a header pill or login button for the current user. Owner-only management UI is gated on `can.*` too (the access.js encodes the owner rule). This applies to every app — the runtime decides sharing, not the prompt. Writes can still be rejected server-side even when `can.*` allows, so keep the optimistic-write + rollback handling. See use-vibe 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
@@ -49,7 +49,7 @@ Every code block must be preceded by the file name on its own line — `App.jsx`
 - one stub function component per feature with a heading — these are the anchors for later edits
 - 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`
-- When a write surface needs gating, destructure `useVibe` for the database it writes to — `const { can, ready } = useVibe("<dbName>");` — and `useViewer` for identity — `const { ViewerTag } = useViewer();`
+- When a write surface needs gating, destructure `useVibe` for the database it writes to — `const { can, ready } = useVibe("<dbName>");`. Only destructure `useViewer` (`const { ViewerTag } = useViewer();`) when you render **other** users — `<ViewerTag userHandle={...} />` for authors/rosters. The current viewer's pill and sign-in live in the Vibes Switch (the logo), so don't add one to your header.
 - NO hooks beyond `useVibe`/`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.
 
@@ -331,7 +331,7 @@ function FeatureThree() {
 }
 
 export default function App() {
-  const { ViewerTag } = useViewer();
+  // No sign-in/current-user pill here — that's system chrome in the Vibes Switch (the logo).
   return (
     <main id="app" className={classNames.page}>
       <header id="app-header" className={classNames.header}>
@@ -345,7 +345,7 @@ export default function App() {
 }
 ````
 
-Keep `useViewer` (for `ViewerTag`) on `App`'s first line, and add `useVibe(dbName)` in the feature components that gate writes — `can`/`ready` are read where the write surface lives, not hoisted to `App`.
+Don't put a current-user `<ViewerTag />` or login button in the header — the logo's Vibes Switch already shows who's signed in and offers sign-in. Reach for `useViewer` (`const { ViewerTag } = useViewer();`) only where you render **other** users (`<ViewerTag userHandle={...} />`) — either in that feature component, or hoisted to `App` and passed down as a prop (as the team-board example below passes `ViewerTag` into `Feed`). Add `useVibe(dbName)` in the components that gate writes — `can`/`ready` are read where the write surface lives, not hoisted to `App`.
 
 **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 gate its write surfaces on `useVibe(dbName).can` — the same rules the access function enforces. If later feature edits introduce new doc types, emit a follow-up `access.js` block with the additions.
 
@@ -403,7 +403,7 @@ Example streamed output for a team board app:
 >     <div className={c.page}>
 >       <header id="app-header" className={c.header}>
 >         <h1>Crew Board</h1>
->         <ViewerTag />
+>         {/* no current-user pill — the logo's Vibes Switch carries identity + sign-in */}
 >       </header>
 >       <main id="app">
 >         <Channels />