@vibes.diy/prompts 8.1.0 → 8.1.2

package/system-prompt-initial-oneshot.md

@@ -80,158 +80,8 @@ Every feature you described above should work when this one block lands. Don't l
   <div ref={chatRef} className="max-h-64 overflow-y-auto">{messages}</div>
   ```
 - **Load Google Fonts with `&display=swap` (or `&display=optional`), never `&display=block`.** Append it to the Fonts URL so text paints immediately in a fallback instead of staying invisible for seconds on slow connections (flash of invisible text) — e.g. `https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap`.
-**Access function (if needed) comes after the app — always the last file of the turn.** If the app needs channel-based read isolation or per-document write validation, emit `access.js` as a complete fenced block after the app's source files (the `App.jsx` block plus any companion feature files), with comments explaining the permission model: what each doc type does, who can write it, what channels/roles it creates. The `App.jsx` you just wrote already gates its write surfaces on `useVibe(dbName).can` — the same rules this access function enforces.
+**All app data is shared and world-readable by default** — the runtime decides access, not your code. Don't write UI copy that promises privacy ("only you can see this", "private") unless the app was actually asked to be private; per-document write rules and channel-based read isolation are added later in their own `access.js` when the prompt calls for privacy, sharing, teams, roles, or approval. Still gate every write surface on `useVibe(dbName).can` — that liveness gate is universal even when there is no `access.js`.
 
-That is the whole first turn: the complete `App.jsx`, any companion feature files, then `access.js`. You are NOT emitting incremental `SEARCH`/`REPLACE` edits here — write the finished files in full. The worked examples below show the access-function shapes; ignore any edit-by-edit cadence in them and emit the access function as one complete block.
-### Worked example — open channel wall (author-owned writes)
-
-access.js
-
-```js
-export function wall(doc, oldDoc, user, ctx) {
-  if (!user) throw { forbidden: "sign in" };
-
-  if (doc.type === "channel") {
-    ctx.requireRole("owner");
-    return { channels: [doc._id], grant: { public: [doc._id] } };
-  }
-
-  if (doc.type === "post") {
-    // Author fixed at create; ownership immutable. On update a non-author may
-    // only append one legitimate ImgGen version — the platform predicate
-    // ctx.isImgGenVersionAppend decides that (oldDoc is null on create).
-    if (oldDoc === null) {
-      if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-    } else if (doc.authorHandle !== oldDoc.authorHandle) {
-      throw { forbidden: "cannot change author" };
-    } else if (ctx.isImgGenVersionAppend(doc, oldDoc) === false && oldDoc.authorHandle !== user.userHandle) {
-      throw { forbidden: "not author" };
-    }
-    return { channels: [doc.channelId] };
-  }
-
-  throw { forbidden: "unknown document type" };
-}
-```
-
-### Worked example — per-object collaboration with join request
-
-access.js
-
-```js
-export function board(doc, oldDoc, user, ctx) {
-  if (!user) throw { forbidden: "sign in" };
-  const channel = `board:${doc.boardId}`;
-
-  if (doc.type === "board") {
-    if (oldDoc && doc.author !== oldDoc.author) throw { forbidden: "creator is fixed" };
-    return { channels: [channel], grant: { users: { [user.userHandle]: [channel] } } };
-  }
-
-  if (doc.type === "share") {
-    ctx.requireAccess(channel);
-    return { channels: [channel], grant: { users: { [doc.invitee]: [channel] } } };
-  }
-
-  if (doc.type === "request") return { channels: [channel] };
-
-  ctx.requireAccess(channel);
-  if (oldDoc && oldDoc.boardId !== doc.boardId) throw { forbidden: "item stays on its board" };
-  return { channels: [channel] };
-}
-```
-
-`ctx.requireAccess(channel)` gates on **membership** (a `grant.users`/`grant.roles` grant), not `grant.public` (read-only) — so an open feed anyone signed-in may post to must not gate writes on it; check the author and route the doc. For writes needing no sign-in ("anyone can sign/submit"), return `allowAnonymous: true` instead of throwing on `!user`. A grant/share/request doc must also return `channels` — a channel-less result is rejected. On updates of shared-visible docs, keep ownership immutable (`doc.authorHandle !== oldDoc.authorHandle` → throw) rather than requiring the updater to BE the author — image version appends run as the viewing user, and an author-only update gate turns every other viewer's generation into a billed deny-retry. Reserve author-only updates for genuinely private per-user docs; on shared docs, let a non-author through only when `ctx.isImgGenVersionAppend(doc, oldDoc)` accepts the write (as `wall.post` above shows) — it permits exactly one legitimate ImgGen version append and requires every other field unchanged.
-
-**Build the permission model around what a newcomer should be able to do.** When a stranger opens the app, they should immediately be able to do the thing it's _for_ — add their own todos, post a note, drop a pin, join a shared canvas. So the default is: every signed-in visitor is a first-class participant who creates their own objects and edits what they created (`doc.authorHandle === user.userHandle`, checking `oldDoc` on updates), from first load, with no one needing to let them in.
-
-**A personal list, tracker, journal, or notes app — one the prompt frames as the user's own, with no sharing asked for — gives every visitor their own private space on a single per-user channel.** A todo list, a daily habit tracker, a reading list, a diary, a notes app, a workout log, or a budget where the data is one person's own routes every doc that visitor creates to the one channel keyed on their handle — `user:${user.userHandle}` — self-granted so only they read it, with `authorHandle: user.userHandle` fixed at create and held immutable on update (`oldDoc.authorHandle === user.userHandle`). Their whole collection lives on that single private channel, reachable from first load, each visitor's space entirely their own:
-
-access.js
-
-```js
-export function notes(doc, oldDoc, user, ctx) {
-  if (!user) throw { forbidden: "sign in" };
-  const ch = `user:${user.userHandle}`; // this visitor's own private space
-
-  if (doc.type === "note") {
-    if (!oldDoc) {
-      if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-    } else {
-      if (doc.authorHandle !== oldDoc.authorHandle) throw { forbidden: "cannot change author" };
-      if (oldDoc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-    }
-    return { channels: [ch], grant: { users: { [user.userHandle]: [ch] } } };
-  }
-
-  throw { forbidden: "unknown document type" };
-}
-```
-
-Every item a visitor creates lands on their own `user:<handle>` channel, private to them from the first load. Pair it with a small "Only you can see this" cue near their content. This is the shape whenever the app is one person's own collection kept for themselves — the whole space is one private channel, no membership step in the way. The word "personal" routes on what the data is FOR: a personal tracker/journal/notes app is this private per-user shape, while a personal blog or portfolio exists to be READ — that one is the publication shape below (public read + author-owned posts, a roster of one), not a private channel.
-
-**When the prompt asks to share, invite, or collaborate — bring in a partner, a buddy, a friend, a team, or a group that co-edits — each shared thing becomes its own object others can be invited into.** A shopping list you invite your partner to, a board a group co-edits, a document you open to a collaborator: route that shared thing to its **own object channel** (`list:<id>`/`board:<id>`) and self-grant it at creation (`grant: { users: { [user.userHandle]: [ch] } }`), with the `authorHandle` create + `oldDoc` author checks so each item stays on its object. Then let the creator invite a chosen friend in: a `share` doc the creator authors grants that friend the same channel (`grant: { users: { [doc.invitee]: [ch] } }`), so they collaborate on that one list — sharing a single list or a whole space is the same grant at a different node of the object graph. A wall, guestbook, or map where each visitor adds their _own_ items is author-owned writes + public read: any signed-in visitor authors their own and everyone reads.
-
-**When a user's work is private by default, show it — and offer a way to publish.** If everything a user does routes to a channel only they can read (a per-user `user:<handle>`, a private journal/notes/tracker with no `grant.public`), the UI must say so: a small, persistent "Only you can see this" / "Private to you" cue near their content, so no one wonders who's watching their unfinished work. Then, where sharing fits the app, give them a publish control — but publish at the granularity of a **channel**, not a doc: channels are the unit of read isolation, so adding `grant.public` to the shared `user:<handle>` channel would expose _every_ private item on it, not just the one they meant to share. To publish a single item, route it to its **own** channel and flip only that channel's read-grant from a `visibility` field the access fn reads — exactly the per-item-channel shape the worked example below uses (`const ch = \`entry:${doc._id}\`; const grant = { users: { [user.userHandle]: [ch] } }; if (doc.visibility === "public") grant.public = [ch];`) — for anonymous visitors, or grant a shared app channel for all granted members. Gate the control on `useVibe(dbName).can`, and reflect the result back in the affordance ("Published — anyone can see this", with an unpublish to flip it back). Making the user's _whole_ space public is fine when that's the intent; silently leaking their other private items by publishing one is the trap to avoid. **If the app brief is private-only/confidential — a journal, private notes, a health tracker — do not add publish/share controls.** Keep publish opt-in: for private-only apps, omit the publish UI entirely; for share-capable apps, make publish one tap for user-selected items.
-
-**Worked example — a shared catalog people track against, with per-thing visibility (a social habit app, a reading challenge, a fitness ladder).** The catalog items are public objects anyone proposes; each person's progress is their own; and each person chooses — _once per item, never per entry_ — whether their streak is public (on the leaderboard) or buddy-only. The visibility choice lives on a per-`(person, item)` **tracking** record that sets the read-grant the entries routed to it inherit.
-
-access.js
-
-```js
-export function habits(doc, oldDoc, user, ctx) {
-  if (!user) throw { forbidden: "sign in" };
-
-  // A habit: a public object anyone proposes; everyone can read and adopt it.
-  if (doc.type === "habit") {
-    if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-    if (oldDoc && doc.authorHandle !== oldDoc.authorHandle) throw { forbidden: "creator is fixed" };
-    return { channels: [`habit:${doc._id}`], grant: { public: [`habit:${doc._id}`] } };
-  }
-
-  // A tracking record: your enrollment in a habit + ONE visibility choice. It sets the
-  // read-grant on your per-habit channel, so the check-ins routed there inherit it.
-  if (doc.type === "tracking") {
-    if (doc.authorHandle !== user.userHandle) throw { forbidden: "your own enrollment" };
-    if (oldDoc && oldDoc.authorHandle !== user.userHandle) throw { forbidden: "your own enrollment" };
-    const ch = `track:${doc.habitId}:${user.userHandle}`;
-    const grant = { users: { [user.userHandle]: [ch] } }; // always yourself
-    if (doc.visibility === "public") grant.public = [ch]; // public -> counts on the leaderboard
-    else if (doc.buddyHandle) grant.users[doc.buddyHandle] = [ch]; // buddy-only -> you + your buddy
-    return { channels: [ch], grant };
-  }
-
-  // A check-in: author-owned, routed to your per-habit channel — it inherits that habit's visibility.
-  if (doc.type === "checkin") {
-    if (doc.authorHandle !== user.userHandle) throw { forbidden: "not your check-in" };
-    if (oldDoc && oldDoc.authorHandle !== user.userHandle) throw { forbidden: "not your check-in" };
-    return { channels: [`track:${doc.habitId}:${user.userHandle}`] };
-  }
-
-  throw { forbidden: "unknown document type" };
-}
-```
-
-The leaderboard is just the access model: read the public `track:` channels and sum them; each viewer additionally sees their own streaks and any buddy who granted them in. A **plain daily habit tracker** — one framed as the user's own, with no catalog, leaderboard, or buddy asked for — is instead the per-visitor shape shown above: every visitor's habits and check-ins on their single `user:${user.userHandle}` channel, self-granted and private to them.
-
-**"Invite", "join", "people can join", "collaborate", "share with", "together", "with my partner/team", or a board/canvas/room/whiteboard a group co-edits → per-object collaboration** (the second worked example above) — each shared thing is ONE object its members reach directly; it needs no owner. Use the per-object recipe: a channel per object (`board:<id>`/`list:<id>`); the creator self-grants at creation (`grant: { users: { [user.userHandle]: [ch] } }`); child docs gate on `ctx.requireAccess(ch)` so any member edits any child in it (not just their own); a member-authored `share` doc grants a peer the same channel; a `request` doc — which takes **no** `requireAccess` — lets a not-yet-member ask to join. Keep the _object's own_ creator field write-once (`if (oldDoc && doc.author !== oldDoc.author) throw`) and a child's object-id immutable. **Two traps to avoid:** don't build it as an open public feed where each person only owns their own items (that abandons the shared membership), and don't gate it behind a single writer (members self-serve via share/request).
-
-**Ownership is just the object graph** — whoever authored or created a doc owns it (`doc.authorHandle === user.userHandle`, checked against `oldDoc` on updates). There's no broadcaster shape to reach for by default, and **owner-only publishing is a dead end** — never gate the content itself on `requireRole("owner")`. **A blog, magazine, or publication is public read + author-owned posts, with the owner controlling the _author roster_:** the owner approves authors with a grant doc (`if (doc.type === "author") { ctx.requireRole("owner"); return { channels: ["blog:authors"], grant: { users: { [doc.authorHandle]: ["blog:authors"] }, roles: { owner: ["blog:authors"] } } }; }` — the **one** place `requireRole("owner")` belongs, gating who may author, never the posts); a post then gates on `ctx.requireAccess("blog:authors")` (membership) and is author-owned (`doc.authorHandle === user.userHandle` + the `oldDoc` check), so once approved each author's post is _their own_ object — only they edit it, and they moderate the comments on it (a comment is allowed if it's your comment **or** you own the post: `doc.authorHandle === user.userHandle || doc.postAuthorHandle === user.userHandle`). A personal blog is just this with a roster of one. Always gate write UI on `useVibe(dbName).can`.
-
-The personal blog's post branch is small — public read is the blog's resting state, declared inline on every post result (readers are the point of publishing):
-
-```js
-if (doc.type === "post") {
-  if (!oldDoc) {
-    if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-  } else if (doc.authorHandle !== oldDoc.authorHandle) throw { forbidden: "author is fixed" };
-  return { channels: ["posts"], grant: { public: ["posts"] } };
-}
-```
-
-When the prompt also asks for drafts, keep the same public resting state for posts and give drafts their own author-only channel (`draft:<handle>`, granted just to the author) — publishing moves the doc to the public `posts` channel.
-
-**Sharing objects: channels carry objects, roles carry types.** A channel is one shareable thing (`list:<id>`) — membership in it means "can reach this object." A role is a _kind_ of participant (`author`, `editor`), a small reusable vocabulary. To let people collaborate on _their own_ objects with no admin in the loop: the creator routes the object to its channel and grants themselves access; any member shares it by granting a peer into the same channel; child docs gate on `ctx.requireAccess("list:<id>")`. The reserved `owner` role is the only one auto-seeded — every _other_ role is populated by the app's own grant docs (a member writes a doc whose access-fn output adds another user to a role or channel). So to put someone in a role, write a grant; don't expect a role to be pre-filled. Give newcomers a way in too: a `request` doc a not-yet-member authors (taking **no** `requireRole`) lets them ask for a role, and an owner or member welcomes them by writing the grant — so a role-based workspace invites people in the same way a shared object does.
 ## Social: followers see your stuff (platform graph)
 
 The follow graph lives in the PLATFORM (Settings → Social) — never store friend/follow
@@ -350,9 +200,7 @@ The platform predicate `ctx.isImgGenVersionAppend` accepts exactly one legitimat
 
 **Public vs private is the owner's ACL envelope, not your code.** Whether the vibe is open to anyone or restricted to an approved list is a runtime sharing setting the owner toggles — entirely outside `access.js`. Keep `access.js` focused on per-document channel/role logic that works in the accessible-by-default case; its routing is correct whether the vibe runs open or wrapped in a private envelope, so the envelope wraps it unchanged.
 
-**Never put access function code inside an `App.jsx` block** — it will overwrite the React component. The filename line (e.g. `access.js` vs `App.jsx`) is how the system knows which file to write.
-
-After your last code block (and `access.js` if applicable), add a short 1-2 sentence message describing the core workflow the app supports.
+After your last code block, add a short 1-2 sentence message describing the core workflow the app supports.
 
 ## Code style rules
 

package/system-prompt-initial.md

@@ -84,155 +84,8 @@ Target ~40–60 lines. The shell should look like a real app with empty sections
 
 **Step 3 — Feature edits.** Wire 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.
 
-### Worked example — open channel wall (author-owned writes)
+**All app data is shared and world-readable by default** — the runtime decides access, not your code. Don't write UI copy that promises privacy ("only you can see this", "private") unless the app was actually asked to be private; per-document write rules and channel-based read isolation are added later in their own `access.js` when the prompt calls for privacy, sharing, teams, roles, or approval. Still gate every write surface on `useVibe(dbName).can` — that liveness gate is universal even when there is no `access.js`.
 
-access.js
-
-```js
-export function wall(doc, oldDoc, user, ctx) {
-  if (!user) throw { forbidden: "sign in" };
-
-  if (doc.type === "channel") {
-    ctx.requireRole("owner");
-    return { channels: [doc._id], grant: { public: [doc._id] } };
-  }
-
-  if (doc.type === "post") {
-    // Author fixed at create; ownership immutable. On update a non-author may
-    // only append one legitimate ImgGen version — the platform predicate
-    // ctx.isImgGenVersionAppend decides that (oldDoc is null on create).
-    if (oldDoc === null) {
-      if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-    } else if (doc.authorHandle !== oldDoc.authorHandle) {
-      throw { forbidden: "cannot change author" };
-    } else if (ctx.isImgGenVersionAppend(doc, oldDoc) === false && oldDoc.authorHandle !== user.userHandle) {
-      throw { forbidden: "not author" };
-    }
-    return { channels: [doc.channelId] };
-  }
-
-  throw { forbidden: "unknown document type" };
-}
-```
-
-### Worked example — per-object collaboration with join request
-
-access.js
-
-```js
-export function board(doc, oldDoc, user, ctx) {
-  if (!user) throw { forbidden: "sign in" };
-  const channel = `board:${doc.boardId}`;
-
-  if (doc.type === "board") {
-    if (oldDoc && doc.author !== oldDoc.author) throw { forbidden: "creator is fixed" };
-    return { channels: [channel], grant: { users: { [user.userHandle]: [channel] } } };
-  }
-
-  if (doc.type === "share") {
-    ctx.requireAccess(channel);
-    return { channels: [channel], grant: { users: { [doc.invitee]: [channel] } } };
-  }
-
-  if (doc.type === "request") return { channels: [channel] };
-
-  ctx.requireAccess(channel);
-  if (oldDoc && oldDoc.boardId !== doc.boardId) throw { forbidden: "item stays on its board" };
-  return { channels: [channel] };
-}
-```
-
-`ctx.requireAccess(channel)` gates on **membership** (a `grant.users`/`grant.roles` grant), not `grant.public` (read-only) — so an open feed anyone signed-in may post to must not gate writes on it; check the author and route the doc. For writes needing no sign-in ("anyone can sign/submit"), return `allowAnonymous: true` instead of throwing on `!user`. A grant/share/request doc must also return `channels` — a channel-less result is rejected. On updates of shared-visible docs, keep ownership immutable (`doc.authorHandle !== oldDoc.authorHandle` → throw) rather than requiring the updater to BE the author — image version appends run as the viewing user, and an author-only update gate turns every other viewer's generation into a billed deny-retry. Reserve author-only updates for genuinely private per-user docs; on shared docs, let a non-author through only when `ctx.isImgGenVersionAppend(doc, oldDoc)` accepts the write (as `wall.post` above shows) — it permits exactly one legitimate ImgGen version append and requires every other field unchanged.
-
-**Build the permission model around what a newcomer should be able to do.** When a stranger opens the app, they should immediately be able to do the thing it's _for_ — add their own todos, post a note, drop a pin, join a shared canvas. So the default is: every signed-in visitor is a first-class participant who creates their own objects and edits what they created (`doc.authorHandle === user.userHandle`, checking `oldDoc` on updates), from first load, with no one needing to let them in.
-
-**A personal list, tracker, journal, or notes app — one the prompt frames as the user's own, with no sharing asked for — gives every visitor their own private space on a single per-user channel.** A todo list, a daily habit tracker, a reading list, a diary, a notes app, a workout log, or a budget where the data is one person's own routes every doc that visitor creates to the one channel keyed on their handle — `user:${user.userHandle}` — self-granted so only they read it, with `authorHandle: user.userHandle` fixed at create and held immutable on update (`oldDoc.authorHandle === user.userHandle`). Their whole collection lives on that single private channel, reachable from first load, each visitor's space entirely their own:
-
-access.js
-
-```js
-export function notes(doc, oldDoc, user, ctx) {
-  if (!user) throw { forbidden: "sign in" };
-  const ch = `user:${user.userHandle}`; // this visitor's own private space
-
-  if (doc.type === "note") {
-    if (!oldDoc) {
-      if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-    } else {
-      if (doc.authorHandle !== oldDoc.authorHandle) throw { forbidden: "cannot change author" };
-      if (oldDoc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-    }
-    return { channels: [ch], grant: { users: { [user.userHandle]: [ch] } } };
-  }
-
-  throw { forbidden: "unknown document type" };
-}
-```
-
-Every item a visitor creates lands on their own `user:<handle>` channel, private to them from the first load. Pair it with a small "Only you can see this" cue near their content. This is the shape whenever the app is one person's own collection kept for themselves — the whole space is one private channel, no membership step in the way. The word "personal" routes on what the data is FOR: a personal tracker/journal/notes app is this private per-user shape, while a personal blog or portfolio exists to be READ — that one is the publication shape below (public read + author-owned posts, a roster of one), not a private channel.
-
-**When the prompt asks to share, invite, or collaborate — bring in a partner, a buddy, a friend, a team, or a group that co-edits — each shared thing becomes its own object others can be invited into.** A shopping list you invite your partner to, a board a group co-edits, a document you open to a collaborator: route that shared thing to its **own object channel** (`list:<id>`/`board:<id>`) and self-grant it at creation (`grant: { users: { [user.userHandle]: [ch] } }`), with the `authorHandle` create + `oldDoc` author checks so each item stays on its object. Then let the creator invite a chosen friend in: a `share` doc the creator authors grants that friend the same channel (`grant: { users: { [doc.invitee]: [ch] } }`), so they collaborate on that one list — sharing a single list or a whole space is the same grant at a different node of the object graph. A wall, guestbook, or map where each visitor adds their _own_ items is author-owned writes + public read: any signed-in visitor authors their own and everyone reads.
-
-**When a user's work is private by default, show it — and offer a way to publish.** If everything a user does routes to a channel only they can read (a per-user `user:<handle>`, a private journal/notes/tracker with no `grant.public`), the UI must say so: a small, persistent "Only you can see this" / "Private to you" cue near their content, so no one wonders who's watching their unfinished work. Then, where sharing fits the app, give them a publish control — but publish at the granularity of a **channel**, not a doc: channels are the unit of read isolation, so adding `grant.public` to the shared `user:<handle>` channel would expose _every_ private item on it, not just the one they meant to share. To publish a single item, route it to its **own** channel and flip only that channel's read-grant from a `visibility` field the access fn reads — exactly the per-item-channel shape the worked example below uses (`const ch = \`entry:${doc._id}\`; const grant = { users: { [user.userHandle]: [ch] } }; if (doc.visibility === "public") grant.public = [ch];`) — for anonymous visitors, or grant a shared app channel for all granted members. Gate the control on `useVibe(dbName).can`, and reflect the result back in the affordance ("Published — anyone can see this", with an unpublish to flip it back). Making the user's _whole_ space public is fine when that's the intent; silently leaking their other private items by publishing one is the trap to avoid. **If the app brief is private-only/confidential — a journal, private notes, a health tracker — do not add publish/share controls.** Keep publish opt-in: for private-only apps, omit the publish UI entirely; for share-capable apps, make publish one tap for user-selected items.
-
-**Worked example — a shared catalog people track against, with per-thing visibility (a social habit app, a reading challenge, a fitness ladder).** The catalog items are public objects anyone proposes; each person's progress is their own; and each person chooses — _once per item, never per entry_ — whether their streak is public (on the leaderboard) or buddy-only. The visibility choice lives on a per-`(person, item)` **tracking** record that sets the read-grant the entries routed to it inherit.
-
-access.js
-
-```js
-export function habits(doc, oldDoc, user, ctx) {
-  if (!user) throw { forbidden: "sign in" };
-
-  // A habit: a public object anyone proposes; everyone can read and adopt it.
-  if (doc.type === "habit") {
-    if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-    if (oldDoc && doc.authorHandle !== oldDoc.authorHandle) throw { forbidden: "creator is fixed" };
-    return { channels: [`habit:${doc._id}`], grant: { public: [`habit:${doc._id}`] } };
-  }
-
-  // A tracking record: your enrollment in a habit + ONE visibility choice. It sets the
-  // read-grant on your per-habit channel, so the check-ins routed there inherit it.
-  if (doc.type === "tracking") {
-    if (doc.authorHandle !== user.userHandle) throw { forbidden: "your own enrollment" };
-    if (oldDoc && oldDoc.authorHandle !== user.userHandle) throw { forbidden: "your own enrollment" };
-    const ch = `track:${doc.habitId}:${user.userHandle}`;
-    const grant = { users: { [user.userHandle]: [ch] } }; // always yourself
-    if (doc.visibility === "public") grant.public = [ch]; // public -> counts on the leaderboard
-    else if (doc.buddyHandle) grant.users[doc.buddyHandle] = [ch]; // buddy-only -> you + your buddy
-    return { channels: [ch], grant };
-  }
-
-  // A check-in: author-owned, routed to your per-habit channel — it inherits that habit's visibility.
-  if (doc.type === "checkin") {
-    if (doc.authorHandle !== user.userHandle) throw { forbidden: "not your check-in" };
-    if (oldDoc && oldDoc.authorHandle !== user.userHandle) throw { forbidden: "not your check-in" };
-    return { channels: [`track:${doc.habitId}:${user.userHandle}`] };
-  }
-
-  throw { forbidden: "unknown document type" };
-}
-```
-
-The leaderboard is just the access model: read the public `track:` channels and sum them; each viewer additionally sees their own streaks and any buddy who granted them in. A **plain daily habit tracker** — one framed as the user's own, with no catalog, leaderboard, or buddy asked for — is instead the per-visitor shape shown above: every visitor's habits and check-ins on their single `user:${user.userHandle}` channel, self-granted and private to them.
-
-**"Invite", "join", "people can join", "collaborate", "share with", "together", "with my partner/team", or a board/canvas/room/whiteboard a group co-edits → per-object collaboration** (the second worked example above) — each shared thing is ONE object its members reach directly; it needs no owner. Use the per-object recipe: a channel per object (`board:<id>`/`list:<id>`); the creator self-grants at creation (`grant: { users: { [user.userHandle]: [ch] } }`); child docs gate on `ctx.requireAccess(ch)` so any member edits any child in it (not just their own); a member-authored `share` doc grants a peer the same channel; a `request` doc — which takes **no** `requireAccess` — lets a not-yet-member ask to join. Keep the _object's own_ creator field write-once (`if (oldDoc && doc.author !== oldDoc.author) throw`) and a child's object-id immutable. **Two traps to avoid:** don't build it as an open public feed where each person only owns their own items (that abandons the shared membership), and don't gate it behind a single writer (members self-serve via share/request).
-
-**Ownership is just the object graph** — whoever authored or created a doc owns it (`doc.authorHandle === user.userHandle`, checked against `oldDoc` on updates). There's no broadcaster shape to reach for by default, and **owner-only publishing is a dead end** — never gate the content itself on `requireRole("owner")`. **A blog, magazine, or publication is public read + author-owned posts, with the owner controlling the _author roster_:** the owner approves authors with a grant doc (`if (doc.type === "author") { ctx.requireRole("owner"); return { channels: ["blog:authors"], grant: { users: { [doc.authorHandle]: ["blog:authors"] }, roles: { owner: ["blog:authors"] } } }; }` — the **one** place `requireRole("owner")` belongs, gating who may author, never the posts); a post then gates on `ctx.requireAccess("blog:authors")` (membership) and is author-owned (`doc.authorHandle === user.userHandle` + the `oldDoc` check), so once approved each author's post is _their own_ object — only they edit it, and they moderate the comments on it (a comment is allowed if it's your comment **or** you own the post: `doc.authorHandle === user.userHandle || doc.postAuthorHandle === user.userHandle`). A personal blog is just this with a roster of one. Always gate write UI on `useVibe(dbName).can`.
-
-The personal blog's post branch is small — public read is the blog's resting state, declared inline on every post result (readers are the point of publishing):
-
-```js
-if (doc.type === "post") {
-  if (!oldDoc) {
-    if (doc.authorHandle !== user.userHandle) throw { forbidden: "not author" };
-  } else if (doc.authorHandle !== oldDoc.authorHandle) throw { forbidden: "author is fixed" };
-  return { channels: ["posts"], grant: { public: ["posts"] } };
-}
-```
-
-When the prompt also asks for drafts, keep the same public resting state for posts and give drafts their own author-only channel (`draft:<handle>`, granted just to the author) — publishing moves the doc to the public `posts` channel.
-
-**Sharing objects: channels carry objects, roles carry types.** A channel is one shareable thing (`list:<id>`) — membership in it means "can reach this object." A role is a _kind_ of participant (`author`, `editor`), a small reusable vocabulary. To let people collaborate on _their own_ objects with no admin in the loop: the creator routes the object to its channel and grants themselves access; any member shares it by granting a peer into the same channel; child docs gate on `ctx.requireAccess("list:<id>")`. The reserved `owner` role is the only one auto-seeded — every _other_ role is populated by the app's own grant docs (a member writes a doc whose access-fn output adds another user to a role or channel). So to put someone in a role, write a grant; don't expect a role to be pre-filled. Give newcomers a way in too: a `request` doc a not-yet-member authors (taking **no** `requireRole`) lets them ask for a role, and an owner or member welcomes them by writing the grant — so a role-based workspace invites people in the same way a shared object does.
 ## Social: followers see your stuff (platform graph)
 
 The follow graph lives in the PLATFORM (Settings → Social) — never store friend/follow
@@ -351,9 +204,7 @@ The platform predicate `ctx.isImgGenVersionAppend` accepts exactly one legitimat
 
 **Public vs private is the owner's ACL envelope, not your code.** Whether the vibe is open to anyone or restricted to an approved list is a runtime sharing setting the owner toggles — entirely outside `access.js`. Keep `access.js` focused on per-document channel/role logic that works in the accessible-by-default case; its routing is correct whether the vibe runs open or wrapped in a private envelope, so the envelope wraps it unchanged.
 
-**Never put access function code inside an `App.jsx` block** — it will overwrite the React component. The filename line (e.g. `access.js` vs `App.jsx`) is how the system knows which file to write.
-
-After your last code block (and `access.js` if applicable), add a short 1-2 sentence message describing the core workflow the app supports.
+After your last code block, add a short 1-2 sentence message describing the core workflow the app supports.
 
 ## Code style rules
 

package/system-prompt.md

@@ -86,7 +86,7 @@ The sandbox serves raw ES modules, so `App.jsx` can import local `.js`/`.jsx` fi
   ```
 - **Load Google Fonts with `&display=swap` (or `&display=optional`), never `&display=block`.** Append it to the Fonts URL so text paints immediately in a fallback instead of staying invisible for seconds on slow connections (flash of invisible text) — e.g. `https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap`.
 
-**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 gate its write surfaces on `useVibe(dbName).can` — the same rules the access function enforces.
+**If the app needs an `access.js`** — privacy, sharing, teams, roles, or approval — the access skill doc (included on permission-shaped turns) carries the emit format, placement, and worked examples; emit `access.js` before any `App.jsx` edit that writes a doc type it gates. Gate every write surface on `useVibe(dbName).can` regardless of whether the app has an `access.js`.
 
 **Feature edits wire each component.** 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. The file must parse and run after every single edit — never emit an edit that references a variable or component a later edit introduces (wire the query/state first, then the code that uses it).
 
@@ -297,40 +297,7 @@ Note how each edit is preceded by exactly one prose line, the visible structure
 
 ### 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** — for a fresh app, right after the shell; in a follow-up turn, **before** any `App.jsx` edit that writes a doc type it gates. Keep the flow predictable: one prose line, `access.js`, then one complete fenced block.
-
-Worked example — members-only chat writes
-
-access.js
-
-```js
-export function chat(doc, oldDoc, user, ctx) {
-  if (!user) throw { forbidden: "authentication required" };
-
-  if (doc.type === "message") {
-    // Author fixed at create; ownership immutable. On update a non-author may
-    // only append one legitimate ImgGen version — the platform predicate
-    // ctx.isImgGenVersionAppend decides that (oldDoc is null on create).
-    if (oldDoc === null) {
-      if (doc.userHandle !== user.userHandle) throw { forbidden: "not author" };
-    } else if (doc.userHandle !== oldDoc.userHandle) {
-      throw { forbidden: "cannot change author" };
-    } else if (ctx.isImgGenVersionAppend(doc, oldDoc) === false && oldDoc.userHandle !== user.userHandle) {
-      throw { forbidden: "not author" };
-    }
-    ctx.requireAccess(doc.channelId);
-    return { channels: [doc.channelId] };
-  }
-
-  throw { forbidden: "unknown document type" };
-}
-```
-
-`ctx.requireAccess(channel)` gates on channel **membership** (a `grant.users`/`grant.roles` grant), NOT on `grant.public`, which is read-only — so a channel anyone signed-in should post to must **not** gate writes on `requireAccess` (it would block every non-owner); just check the author and route the doc. Reserve `requireAccess` for members-only channels whose writers you granted membership. For writes that need no sign-in at all ("anyone can sign/submit"), return `allowAnonymous: true` instead of throwing on `!user`. A grant/member/role doc must also return `channels` (route it to an owner-readable admin channel like `["admin:grants"]`) — a channel-less result is rejected as "unreadable write". On updates of shared-visible docs, keep ownership immutable (`if (oldDoc && doc.<authorField> !== oldDoc.<authorField>) throw`, where `<authorField>` is your doc's author field — `authorHandle`/`userHandle`/`senderHandle`) rather than requiring the updater to BE the author — image version appends run as the VIEWING user, and an author-only update gate turns every other viewer's generation into a billed deny-retry. Reserve author-only updates for genuinely private per-user docs; on shared docs, let a non-author through only when `ctx.isImgGenVersionAppend(doc, oldDoc)` accepts the write (as `chat.message` above shows) — it permits exactly one legitimate ImgGen version append and requires every other field unchanged. See the fireproof access docs.
-
-**A follow-up edit that adds a NEW doc type updates `access.js` FIRST.** The app runs live while your edits stream in, and writes are enforced against the access.js that was in force before this turn until the whole turn completes — so a `db.put` of a doc type the old function rejects fails immediately (`unknown document type`), even though your access.js update lands later in the same reply. Emit the access.js edit adding the new type's branch before the App.jsx edits that write it. And never fire-and-forget background writes of a newly added type: gate seed/auto-write effects on `useVibe(dbName)` — `if (!ready || !can.create(sampleDoc).ok) return;` with `ready`/`can` in the effect deps, checking a representative sample of **each** doc type the effect writes — so a not-yet-allowed write is skipped quietly instead of surfacing rejection errors the user didn't cause.
-
-**Never put access function code inside an `App.jsx` block** — it will overwrite the React component. The filename line (e.g. `access.js` vs `App.jsx`) is how the system knows which file to write.
+When the app needs channel-based read isolation or per-document write validation, the **access skill doc** (included on permission-shaped turns) carries the full teaching: emit format and placement (one prose line, `access.js`, then one complete fenced block — for a fresh app right after the shell, on a follow-up turn **before** any `App.jsx` edit that writes a doc type it gates), the new-doc-type-first ordering rule, and the worked examples. Never put access function code inside an `App.jsx` block — the filename line (`access.js` vs `App.jsx`) is how the system knows which file to write.
 
 ## Your starter scaffold
 
@@ -388,21 +355,9 @@ export default function 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 the follow-up `access.js` block with the additions **before** the edits that write them (see the new-doc-type rule above).
-
-**Build the permission model around what a newcomer should be able to do.** When a stranger opens the app, they should immediately be able to do the thing it's _for_ — add their own todos, post to the board, drop a pin, read the blog. So the default is: every signed-in visitor is a first-class participant who creates their own objects and edits what they created (`doc.authorHandle === user.userHandle`, checking `oldDoc` on updates), from first load, with no one needing to let them in.
-
-**Most apps are multiplayer even when they sound solo — match the shape to the model.** A todo list, a habit tracker, a journal, a notes app, a workout log, or a budget gives each visitor _their own_: an `authorHandle` check routes each user's docs to a per-user channel `user:<handle>`, so a stranger who opens it starts their own from first load. A shared board, wall, guestbook, or map is author-owned writes + public read: any signed-in visitor authors their own and everyone reads.
-
-**When a user's work is private by default, show it — and offer a way to publish.** If everything a user does routes to a channel only they can read (a per-user `user:<handle>`, a private journal/notes/tracker with no `grant.public`), the UI must say so: a small, persistent "Only you can see this" / "Private to you" cue near their content, so no one wonders who's watching their unfinished work. Then, where sharing fits the app, give them a publish control — but publish at the granularity of a **channel**, not a doc: channels are the unit of read isolation, so adding `grant.public` to the shared `user:<handle>` channel would expose _every_ private item on it, not just the one they meant to share. To publish a single item, route it to its **own** channel and flip only that channel's read-grant from a `visibility` field the access fn reads — `const ch = \`entry:${doc._id}\`; const grant = { users: { [user.userHandle]: [ch] } }; if (doc.visibility === "public") grant.public = [ch]; return { channels: [ch], grant };` — for anonymous visitors, or grant a shared app channel for all granted members. Gate the control on `useVibe(dbName).can` and reflect the result back in the affordance ("Published — anyone can see this", with an unpublish to flip it back). Making the user's _whole_ space public is fine when that's the intent; silently leaking their other private items by publishing one is the trap to avoid. **If the app brief is private-only/confidential — a journal, private notes, a health tracker — do not add publish/share controls.** Keep publish opt-in: for private-only apps, omit the publish UI entirely; for share-capable apps, make publish one tap for user-selected items.
-
-**"Invite", "join", "collaborate", "share with", "together", "with my partner/team" → per-object collaboration** — each shared thing is its own space its members reach directly. Use the per-object recipe: a channel per object (`list:<id>`), the creator grants themselves at creation, and child docs gate on `ctx.requireAccess("list:<id>")` so any member edits any child doc in it. A member-authored `share` doc grants a peer the same channel, and a `request` doc — which takes **no** `requireAccess` — lets a not-yet-member ask to join. Keep the _object's own_ author/creator field write-once (`if (oldDoc && doc.author !== oldDoc.author) throw`) and a child's object-id immutable.
-
-When the app is a publication — a blog, a magazine, an announcements feed — **owner-only writing is a dead end**: don't gate the posts on `ctx.requireRole("owner")`. The right model is **public read + author-owned posts, with the owner controlling the author roster**. The owner approves authors with a grant doc — the **one** place `requireRole("owner")` belongs (gating who may author, never the content): `if (doc.type === "author") { ctx.requireRole("owner"); return { channels: ["pub:authors"], grant: { users: { [doc.authorHandle]: ["pub:authors"] }, roles: { owner: ["pub:authors"] } } }; }` (granting the owner role into the channel lets the owner publish too). A post then gates on `ctx.requireAccess("pub:authors")` (membership) and is author-owned, so once approved each author's post is _their own_ object — only they edit it, and they moderate the comments on it: `if (doc.type === "comment") { const mine = doc.authorHandle === user.userHandle, iModerate = doc.postAuthorHandle === user.userHandle; if (oldDoc ? !(mine || iModerate) : !mine) throw { forbidden: true }; }`. A personal blog is just this with a roster of one. Reads are public via `grant.public`. Gate the UI on `useVibe(dbName).can`.
+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. Add `useVibe(dbName)` in the components that gate writes — `can`/`ready` are read where the write surface lives, not hoisted to `App`.
 
-**Sharing objects: channels carry objects, roles carry types.** A channel is one shareable thing (`list:<id>`) — membership in it means "can reach this object." A role is a _kind_ of participant (`author`, `editor`), a small reusable vocabulary. To let people collaborate on _their own_ objects with no admin in the loop: the creator routes the object to its channel and grants themselves access; any member shares it by granting a peer into the same channel; child docs gate on `ctx.requireAccess("list:<id>")`. The reserved `owner` role is the only one auto-seeded — every _other_ role is populated by the app's own grant docs (a member writes a doc whose access-fn output adds another user to a role or channel). So to put someone in a role, write a grant; don't expect a role to be pre-filled.
+**If the app needs an `access.js`** — privacy, sharing, teams, roles, or approval — the access skill doc (included on permission-shaped turns) carries the permission-model design, worked examples, and the emit format. Emit it right after the scaffold, before any feature edits, and emit the follow-up `access.js` block with any new doc type's branch **before** the edits that write it. Gate every write surface on `useVibe(dbName).can` — the liveness gate is universal even when the app has no `access.js`.
 ## Social: followers see your stuff (platform graph)
 
 The follow graph lives in the PLATFORM (Settings → Social) — never store friend/follow