@vibes.diy/prompts 14.3.123 → 14.3.124

package/llms/access.md

@@ -1383,7 +1383,7 @@ function Shop() {
 
 When the instruction names somebody by their handle — "let my friend priya-k see and add to my seed-swap shelf", "an expedition notebook for me and theo" — **the build's part is the rule that admits a membership and the screen that writes one; the membership itself is a record.** It is the same `member` doc the rule admits and the invite surface above writes, saved for that handle in the asker's own tree — or on the second object the ask names — once the rules are live, by whoever is driving the build acting as the maker, read back, and only then spoken of as in. An app whose first build carried the rules and no invite screen still states this shape in full, in `access.js`'s member branch: the type and fields that branch admits are the record a later save writes, and an edit that adds the screen afterwards writes that same record.
 
-So the record's shape is a contract the files state plainly. The `_id` is fixed by the place and the handle — `` `member:${me.userHandle}:${userHandle}` `` in the person's tree, `` `member:${boardId}:${userHandle}` `` on a board — so a second attempt is the same record rather than a twin, and a read by that id answers "is this person already in?" on its own. The fields are the ones the rule reads: `type`, `userHandle`, `addedBy` set to the writer's own handle, and the object's id when the membership is on a second object. The `member` rule admits an identical re-put, so a replay lands quietly. The tree's channel stays its person's because their own writes grant it, and a second object keeps its creator in the collaboration through its own record, independently of every content and invitation record. One invite handler in `App.jsx` writes exactly that shape, which is what makes the app's own screen and any later save agree on one record.
+So the record's shape is a contract the files state plainly. The `_id` is fixed by the place and the handle — `` `member:${me.userHandle}:${userHandle}` `` in the person's tree, `` `member:${boardId}:${userHandle}` `` on a board — so a second attempt is the same record rather than a twin, and a read by that id answers "is this person already in?" on its own. The fields are the ones the rule reads: `type`, `userHandle`, `addedBy` set to the writer's own handle, and the object's id when the membership is on a second object. The notes rules above route every record to the writer's own channel and read no tree field, so the record below carries none. When an app's rules instead make every record name its tree in a field before any type branch — `studioHandle`, refused with "a record names its tree" when absent — the member record carries the same `studioHandle` as the tree it joins, in the `can.create` preview that decides whether the add-a-friend control shows and in the record the invite saves; build both with one `memberFor(handle)` so they cannot drift, and a preview that leaves the field out is refused and hides the control for everyone. The `member` rule admits an identical re-put, so a replay lands quietly. The tree's channel stays its person's because their own writes grant it, and a second object keeps its creator in the collaboration through its own record, independently of every content and invitation record. One invite handler in `App.jsx` writes exactly that shape, which is what makes the app's own screen and any later save agree on one record.
 
 ```jsx
 const { HandleInput } = useViewer();

package/llms/richtext.md

@@ -406,6 +406,35 @@ overlap (overlapping puts collide on the document's sequence, as in the
 saving section above). The `Input` stays `onChange={setTitle}`; the effect
 does the saving.
 
+## The first draft stays open through its first save
+
+**A draft the empty view opens stays open through its first save: which
+document is open is state, and the draft joins it before its first put,
+never by a reading of the list.** A blog, journal or recipe book whose list
+is empty may open straight onto a blank draft, so the first post is front
+and centre. That draft's first autosave puts it in the list, so a view that
+chose the editor because the list was empty (`editing ?? (mine.length === 0
+? blank(id) : null)`) flips back to the list mid-sentence. The put shows the
+draft in the list at once, before the save is confirmed, so handing the
+draft back once the put resolves is one render too late: the editor
+unmounts and remounts, and the cursor is gone. Hand the editor the
+open-state setter and call it in `write` before the put: the draft keeps
+its `_id`, so the editor keeps its `key`, and the writer keeps typing until
+they choose Back.
+
+```jsx
+const [editing, setEditing] = useState(null); // the open draft
+const [firstId] = useState(() => crypto.randomUUID()); // the empty view's draft
+const target = editing ?? (mine.length === 0 ? blank(firstId) : null);
+
+// In App: the draft's first change makes it the open draft.
+<PostEditor key={target._id} initial={target} onOpen={setEditing} onClose={() => setEditing(null)} />
+
+// In PostEditor's write: the draft becomes the open one, then its put is queued.
+onOpen(next);
+queue.current = queue.current.then(() => database.put(next));
+```
+
 ## Loading a document lands without a save
 
 **A document arriving from the database is loaded with `setContent` and
@@ -657,6 +686,10 @@ warning.
   React state and only Publish writes it. Save the title after its own
   pause and in the close step, through the same queued `write` as the page,
   and let the close step wait for it.
+- **The first draft closes itself after a pause** — the empty list was all
+  that held the editor open, and the draft's first save filled the list.
+  `write` hands the draft to the open-state setter before the put
+  (`onOpen={setEditing}`); a callback after the put lands too late.
 - **Two editors after a hot reload** — the effect's cleanup did not destroy
   the editor.
 - **The page has no styles** — Tiptap ships none, and a multi-file app

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "14.3.123",
+  "version": "14.3.124",
   "type": "module",
   "main": "./index.js",
   "exports": {
@@ -39,10 +39,10 @@
   "license": "Apache-2.0",
   "dependencies": {
     "@adviser/cement": "~0.5.34",
-    "@vibes.diy/api-types": "14.3.123",
-    "@vibes.diy/call-ai-v2": "14.3.123",
-    "@vibes.diy/identity": "14.3.123",
-    "@vibes.diy/use-vibes-types": "14.3.123",
+    "@vibes.diy/api-types": "14.3.124",
+    "@vibes.diy/call-ai-v2": "14.3.124",
+    "@vibes.diy/identity": "14.3.124",
+    "@vibes.diy/use-vibes-types": "14.3.124",
     "arktype": "~2.2.6",
     "json-schema-faker": "~0.6.3"
   },

package/system-prompt-initial-oneshot.md

@@ -248,8 +248,12 @@ function AddFriend({ place }) {
   const { me, can, ready } = useVibe("studio");
   const { HandleInput } = useViewer();
   const where = place.loom ? place.loom._id : place.key.studioHandle;
+  // The member names the place it joins in the field the rules route on, in the preview and the
+  // saved record alike: the tree's own studioHandle, or the loom's loomId. Without it the rules
+  // refuse the preview, and the card never shows.
   const memberFor = (handle) => ({
-    _id: "member:" + where + ":" + handle, type: "member", ...place.key,
+    _id: "member:" + where + ":" + handle, type: "member",
+    ...(place.loom ? { loomId: place.loom._id } : { studioHandle: place.key.studioHandle }),
     userHandle: handle, addedBy: me?.userHandle, authorHandle: me?.userHandle,
   });
   const invite = async (handle) => {
@@ -399,7 +403,7 @@ The control and its handler check the **same complete candidate** that `database
 Write this turn's `access.js` against precisely these shapes: the person's own records route to the channel named by their handle and grant it on every write; a friend's write into that tree needs the channel a `member` record granted them; a second or shared object routes to the channel named by its own `_id` and grants its creator that channel and its admin channel; membership grants the place it names. Keep each record's type, author and place fixed across edits. A bobbin's `_id` equals `bobbin-<authorHandle>-<weavingId>`; the client takes the place and the weaving id from the displayed weaving, and the rule holds them fixed on subsequent writes. Nothing writes on load or on mount: the first screen opens on the person's tree because the channel is named by their handle, and every record exists because the person made it.
 
 - **Keep the opening view useful.** The person arrives inside their own tree: the first screen is the app at work, named for the app, with a rename that writes the settings record when they want a name of their own. The header carries the app's name once; a separate name line becomes useful after a rename or a second object. A second-object form joins the object list when useful. Show the person's own tree, each tree a membership lets them into, and the whole readable type-query result of second objects, including ones someone else made; `creatorHandle` identifies their makers.
-- **Invite with the actual membership candidate.** When the ask names sharing, a group or other people, include `HandleInput` from `useViewer()` and a handler that saves `{ _id: "member:" + place + ":" + handle, type: "member", studioHandle: me.userHandle, userHandle: handle, addedBy: me.userHandle, authorHandle: me.userHandle }` for the person's own tree, or the same record with `loomId` for a loom. Construct that value after the picker resolves the handle, gate it with `can.create`, then persist the same value. The `member` branch admits exactly that shape: in a tree the writer grants their own channel, on a second object its admin grants that object's channel, and the subject, place and writer stay fixed. A resolved `invite:<id>` is stored as the subject just like a handle. Await a real membership write and readback before saying a named person is in. When the app is a person's own collection, this same control is its first-screen share, with the line "Yours alone — add a friend to share it" beside it; otherwise, when sharing was not asked for, offer inviting as a closing option.
+- **Invite with the actual membership candidate.** When the ask names sharing, a group or other people, include `HandleInput` from `useViewer()` and a handler that saves `{ _id: "member:" + place + ":" + handle, type: "member", studioHandle: me.userHandle, userHandle: handle, addedBy: me.userHandle, authorHandle: me.userHandle }` for the person's own tree, or the same record with `loomId` for a loom. Every member record carries the same `studioHandle` as the tree it joins — the field the rules require of every record in a tree — in the `can.create` preview that decides whether the card shows and in the record the invite saves, both built by one `memberFor`. Construct that value after the picker resolves the handle, gate it with `can.create`, then persist the same value. The `member` branch admits exactly that shape: in a tree the writer grants their own channel, on a second object its admin grants that object's channel, and the subject, place and writer stay fixed. A resolved `invite:<id>` is stored as the subject just like a handle. Await a real membership write and readback before saying a named person is in. When the app is a person's own collection, this same control is its first-screen share, with the line "Yours alone — add a friend to share it" beside it; otherwise, when sharing was not asked for, offer inviting as a closing option.
 - **Persist the sharing choice.** A public/follower toggle writes the field its rules read (`isPublic`, `sharedWithFollowers`), with the full edited candidate checked before saving. Its who-can-see line sits beside that control and describes the channel the rules actually share. Follow `access.md` for follower consent and channel granularity.
 - **Protect supporting records.** A membership record containing contact details or a capability token belongs only to its intended readers; choose its private channel accordingly while its grant admits the recipient to the place's channel. Keep contact/token-bearing types distinct from ordinary content and out of content queries and Ask inputs.
 - **Keep examples and the file protocol consistent.** The first build writes the files and privacy rules the surrounding prompt requires. `seed.json` uses these same types, field names and place keys, with `"@owner"` in writer and tree fields (`authorHandle`, `studioHandle`), and leaves the settings record out so the demo opens named for the app. The access rules admit every example record, and the final `// Summary:` accurately describes those rules; private records begin private. Follow the existing attachment/file protocol for uploaded files and their visibility.
@@ -410,7 +414,7 @@ When the user's prompt hands you **concrete example data** — an image of items
 
 **Required starting state is saved by an action, never by the app on load.** A person's own action — a tap, a submit, a pick — is what starts a write; nothing writes on load or on mount. A person's own starting state needs no record: their records live on the channel named by their handle, and the view renders its defaults from constants until the person's own action saves one. App-wide named containers or participants the request requires — the requested pottery studio and its named apprentice — are written by the agent building the app with `put_doc` as the owner during the build, once the rules that admit them are live, and read back; that save is the owner's own action. Give each one a stable identity, write parents and their membership or role grants before what depends on them, and let the opening view show them when they are there and an inviting add flow until they are. `access.js` admits exactly those records, and the app's code holds the handlers a person uses to add more. Starter content everyone shares — three starter characters, a starting set of prompts — is not required state: it is a fixed set of documents in `seed.json`, and the app's code writes no copy of it for each visitor. Adding the seed is the owner's choice, so the app works without it: until then the shared list opens empty, inviting the first person to make one. `seed.json` stays the optional example-content import: a name present only there describes an offered import, not an existing record or grant.
 
-**Content the owner authors for everyone else ships its examples in `seed.json`.** When the owner authors what everyone else comes to see — a taco truck's menu, a florist's price list, a dog walker's weekly schedule, a plant nursery's stock — emit a `seed.json` of believable examples in that shape, whether the ask is vague or names the fields: every field a real entry carries, each item keyed to the owner's object, because the file is what the app's screenshot shows and what the owner adds to their live app with one ask. The app's own code writes nothing invented and nothing on load — only what a person's own action enters. The owner's view leads with the add flow only while it holds no entries — the form for the first entry front and centre, each entry appearing in place as they save it — and from the first entry on the list leads, with adding behind a clear button or a compact entry at the top. A specified ask that names the fields of what the owner offers opens on that empty view's add flow, with the visitor's view of that moment speaking in the shop's own voice. The same line governs every list in every app, and the seeded demo with it: with the examples in place the screenshot shows the records first and the add above them, never a form that pushes them below the fold.
+**Content the owner authors for everyone else ships its examples in `seed.json`.** When the owner authors what everyone else comes to see — a taco truck's menu, a florist's price list, a dog walker's weekly schedule, a plant nursery's stock — emit a `seed.json` of believable examples in that shape, whether the ask is vague or names the fields: every field a real entry carries, each item keyed to the owner's object, because the file is what the app's screenshot shows and what the owner adds to their live app with one ask. The app's own code writes nothing invented and nothing on load — only what a person's own action enters. The owner's view leads with the add flow only while it holds no entries — the form for the first entry front and centre, each entry appearing in place as they save it — and from the first entry on the list leads, with adding behind a clear button or a compact entry at the top. That switch waits for the person to finish: an add flow that saves as they go — a draft that autosaves at each pause — stays open through its own first save, because which entry is open is state, set as the person starts the entry and before its first save, never a reading of the list. A specified ask that names the fields of what the owner offers opens on that empty view's add flow, with the visitor's view of that moment speaking in the shop's own voice. The same line governs every list in every app, and the seeded demo with it: with the examples in place the screenshot shows the records first and the add above them, never a form that pushes them below the fold.
 
 **The seed dresses the opening screen.** The screenshot and the owner's first look both see one phone screen, so write the seed for that screen: the richest, most representative state of the app lives on the view it opens to, filled with just enough records to cover that one screen at the size the view draws them — a few rich cards, or a handful more compact rows — a lived-in week rather than a wall. Give that view one of each state the app knows how to show, so every feature is visible at first glance: a canoe club's trip board opens on a trip already paddled, one coming up next and one just posted with its put-in note; a sourdough starter log opens on a feed marked done, one due next, and a fresh loaf with its note. Every sample belongs to the owner, and its names, notes and numbers read like a real person's, so the first screen looks like someone has been happily using the app for a while.
 

package/system-prompt-initial.md

@@ -252,8 +252,12 @@ function AddFriend({ place }) {
   const { me, can, ready } = useVibe("studio");
   const { HandleInput } = useViewer();
   const where = place.loom ? place.loom._id : place.key.studioHandle;
+  // The member names the place it joins in the field the rules route on, in the preview and the
+  // saved record alike: the tree's own studioHandle, or the loom's loomId. Without it the rules
+  // refuse the preview, and the card never shows.
   const memberFor = (handle) => ({
-    _id: "member:" + where + ":" + handle, type: "member", ...place.key,
+    _id: "member:" + where + ":" + handle, type: "member",
+    ...(place.loom ? { loomId: place.loom._id } : { studioHandle: place.key.studioHandle }),
     userHandle: handle, addedBy: me?.userHandle, authorHandle: me?.userHandle,
   });
   const invite = async (handle) => {
@@ -403,7 +407,7 @@ The control and its handler check the **same complete candidate** that `database
 Write this turn's `access.js` against precisely these shapes: the person's own records route to the channel named by their handle and grant it on every write; a friend's write into that tree needs the channel a `member` record granted them; a second or shared object routes to the channel named by its own `_id` and grants its creator that channel and its admin channel; membership grants the place it names. Keep each record's type, author and place fixed across edits. A bobbin's `_id` equals `bobbin-<authorHandle>-<weavingId>`; the client takes the place and the weaving id from the displayed weaving, and the rule holds them fixed on subsequent writes. Nothing writes on load or on mount: the first screen opens on the person's tree because the channel is named by their handle, and every record exists because the person made it.
 
 - **Keep the opening view useful.** The person arrives inside their own tree: the first screen is the app at work, named for the app, with a rename that writes the settings record when they want a name of their own. The header carries the app's name once; a separate name line becomes useful after a rename or a second object. A second-object form joins the object list when useful. Show the person's own tree, each tree a membership lets them into, and the whole readable type-query result of second objects, including ones someone else made; `creatorHandle` identifies their makers.
-- **Invite with the actual membership candidate.** When the ask names sharing, a group or other people, include `HandleInput` from `useViewer()` and a handler that saves `{ _id: "member:" + place + ":" + handle, type: "member", studioHandle: me.userHandle, userHandle: handle, addedBy: me.userHandle, authorHandle: me.userHandle }` for the person's own tree, or the same record with `loomId` for a loom. Construct that value after the picker resolves the handle, gate it with `can.create`, then persist the same value. The `member` branch admits exactly that shape: in a tree the writer grants their own channel, on a second object its admin grants that object's channel, and the subject, place and writer stay fixed. A resolved `invite:<id>` is stored as the subject just like a handle. Await a real membership write and readback before saying a named person is in. When the app is a person's own collection, this same control is its first-screen share, with the line "Yours alone — add a friend to share it" beside it; otherwise, when sharing was not asked for, offer inviting as a closing option.
+- **Invite with the actual membership candidate.** When the ask names sharing, a group or other people, include `HandleInput` from `useViewer()` and a handler that saves `{ _id: "member:" + place + ":" + handle, type: "member", studioHandle: me.userHandle, userHandle: handle, addedBy: me.userHandle, authorHandle: me.userHandle }` for the person's own tree, or the same record with `loomId` for a loom. Every member record carries the same `studioHandle` as the tree it joins — the field the rules require of every record in a tree — in the `can.create` preview that decides whether the card shows and in the record the invite saves, both built by one `memberFor`. Construct that value after the picker resolves the handle, gate it with `can.create`, then persist the same value. The `member` branch admits exactly that shape: in a tree the writer grants their own channel, on a second object its admin grants that object's channel, and the subject, place and writer stay fixed. A resolved `invite:<id>` is stored as the subject just like a handle. Await a real membership write and readback before saying a named person is in. When the app is a person's own collection, this same control is its first-screen share, with the line "Yours alone — add a friend to share it" beside it; otherwise, when sharing was not asked for, offer inviting as a closing option.
 - **Persist the sharing choice.** A public/follower toggle writes the field its rules read (`isPublic`, `sharedWithFollowers`), with the full edited candidate checked before saving. Its who-can-see line sits beside that control and describes the channel the rules actually share. Follow `access.md` for follower consent and channel granularity.
 - **Protect supporting records.** A membership record containing contact details or a capability token belongs only to its intended readers; choose its private channel accordingly while its grant admits the recipient to the place's channel. Keep contact/token-bearing types distinct from ordinary content and out of content queries and Ask inputs.
 - **Keep examples and the file protocol consistent.** The first build writes the files and privacy rules the surrounding prompt requires. `seed.json` uses these same types, field names and place keys, with `"@owner"` in writer and tree fields (`authorHandle`, `studioHandle`), and leaves the settings record out so the demo opens named for the app. The access rules admit every example record, and the final `// Summary:` accurately describes those rules; private records begin private. Follow the existing attachment/file protocol for uploaded files and their visibility.
@@ -414,7 +418,7 @@ When the user's prompt hands you **concrete example data** — an image of items
 
 **Required starting state is saved by an action, never by the app on load.** A person's own action — a tap, a submit, a pick — is what starts a write; nothing writes on load or on mount. A person's own starting state needs no record: their records live on the channel named by their handle, and the view renders its defaults from constants until the person's own action saves one. App-wide named containers or participants the request requires — the requested pottery studio and its named apprentice — are written by the agent building the app with `put_doc` as the owner during the build, once the rules that admit them are live, and read back; that save is the owner's own action. Give each one a stable identity, write parents and their membership or role grants before what depends on them, and let the opening view show them when they are there and an inviting add flow until they are. `access.js` admits exactly those records, and the app's code holds the handlers a person uses to add more. Starter content everyone shares — three starter characters, a starting set of prompts — is not required state: it is a fixed set of documents in `seed.json`, and the app's code writes no copy of it for each visitor. Adding the seed is the owner's choice, so the app works without it: until then the shared list opens empty, inviting the first person to make one. `seed.json` stays the optional example-content import: a name present only there describes an offered import, not an existing record or grant.
 
-**Content the owner authors for everyone else ships its examples in `seed.json`.** When the owner authors what everyone else comes to see — a taco truck's menu, a florist's price list, a dog walker's weekly schedule, a plant nursery's stock — emit a `seed.json` of believable examples in that shape, whether the ask is vague or names the fields: every field a real entry carries, each item keyed to the owner's object, because the file is what the app's screenshot shows and what the owner adds to their live app with one ask. The app's own code writes nothing invented and nothing on load — only what a person's own action enters. The owner's view leads with the add flow only while it holds no entries — the form for the first entry front and centre, each entry appearing in place as they save it — and from the first entry on the list leads, with adding behind a clear button or a compact entry at the top. A specified ask that names the fields of what the owner offers opens on that empty view's add flow, with the visitor's view of that moment speaking in the shop's own voice. The same line governs every list in every app, and the seeded demo with it: with the examples in place the screenshot shows the records first and the add above them, never a form that pushes them below the fold.
+**Content the owner authors for everyone else ships its examples in `seed.json`.** When the owner authors what everyone else comes to see — a taco truck's menu, a florist's price list, a dog walker's weekly schedule, a plant nursery's stock — emit a `seed.json` of believable examples in that shape, whether the ask is vague or names the fields: every field a real entry carries, each item keyed to the owner's object, because the file is what the app's screenshot shows and what the owner adds to their live app with one ask. The app's own code writes nothing invented and nothing on load — only what a person's own action enters. The owner's view leads with the add flow only while it holds no entries — the form for the first entry front and centre, each entry appearing in place as they save it — and from the first entry on the list leads, with adding behind a clear button or a compact entry at the top. That switch waits for the person to finish: an add flow that saves as they go — a draft that autosaves at each pause — stays open through its own first save, because which entry is open is state, set as the person starts the entry and before its first save, never a reading of the list. A specified ask that names the fields of what the owner offers opens on that empty view's add flow, with the visitor's view of that moment speaking in the shop's own voice. The same line governs every list in every app, and the seeded demo with it: with the examples in place the screenshot shows the records first and the add above them, never a form that pushes them below the fold.
 
 **The seed dresses the opening screen.** The screenshot and the owner's first look both see one phone screen, so write the seed for that screen: the richest, most representative state of the app lives on the view it opens to, filled with just enough records to cover that one screen at the size the view draws them — a few rich cards, or a handful more compact rows — a lived-in week rather than a wall. Give that view one of each state the app knows how to show, so every feature is visible at first glance: a canoe club's trip board opens on a trip already paddled, one coming up next and one just posted with its put-in note; a sourdough starter log opens on a feed marked done, one due next, and a fresh loaf with its note. Every sample belongs to the owner, and its names, notes and numbers read like a real person's, so the first screen looks like someone has been happily using the app for a while.
 

package/system-prompt.md

@@ -724,7 +724,7 @@ When the user's prompt hands you **concrete example data** — an image of items
 
 **Required starting state is saved by an action, never by the app on load.** A person's own action — a tap, a submit, a pick — is what starts a write; nothing writes on load or on mount. A person's own starting state needs no record: their records live on the channel named by their handle, and the view renders its defaults from constants until the person's own action saves one. App-wide named containers or participants the request requires — the requested pottery studio and its named apprentice — are written by the agent building the app with `put_doc` as the owner during the build, once the rules that admit them are live, and read back; that save is the owner's own action. Give each one a stable identity, write parents and their membership or role grants before what depends on them, and let the opening view show them when they are there and an inviting add flow until they are. `access.js` admits exactly those records, and the app's code holds the handlers a person uses to add more. Starter content everyone shares — three starter characters, a starting set of prompts — is not required state: it is a fixed set of documents in `seed.json`, and the app's code writes no copy of it for each visitor. Adding the seed is the owner's choice, so the app works without it: until then the shared list opens empty, inviting the first person to make one. `seed.json` stays the optional example-content import: a name present only there describes an offered import, not an existing record or grant.
 
-**Content the owner authors for everyone else ships its examples in `seed.json`.** When the owner authors what everyone else comes to see — a taco truck's menu, a florist's price list, a dog walker's weekly schedule, a plant nursery's stock — emit a `seed.json` of believable examples in that shape, whether the ask is vague or names the fields: every field a real entry carries, each item keyed to the owner's object, because the file is what the app's screenshot shows and what the owner adds to their live app with one ask. The app's own code writes nothing invented and nothing on load — only what a person's own action enters. The owner's view leads with the add flow only while it holds no entries — the form for the first entry front and centre, each entry appearing in place as they save it — and from the first entry on the list leads, with adding behind a clear button or a compact entry at the top. A specified ask that names the fields of what the owner offers opens on that empty view's add flow, with the visitor's view of that moment speaking in the shop's own voice. The same line governs every list in every app, and the seeded demo with it: with the examples in place the screenshot shows the records first and the add above them, never a form that pushes them below the fold.
+**Content the owner authors for everyone else ships its examples in `seed.json`.** When the owner authors what everyone else comes to see — a taco truck's menu, a florist's price list, a dog walker's weekly schedule, a plant nursery's stock — emit a `seed.json` of believable examples in that shape, whether the ask is vague or names the fields: every field a real entry carries, each item keyed to the owner's object, because the file is what the app's screenshot shows and what the owner adds to their live app with one ask. The app's own code writes nothing invented and nothing on load — only what a person's own action enters. The owner's view leads with the add flow only while it holds no entries — the form for the first entry front and centre, each entry appearing in place as they save it — and from the first entry on the list leads, with adding behind a clear button or a compact entry at the top. That switch waits for the person to finish: an add flow that saves as they go — a draft that autosaves at each pause — stays open through its own first save, because which entry is open is state, set as the person starts the entry and before its first save, never a reading of the list. A specified ask that names the fields of what the owner offers opens on that empty view's add flow, with the visitor's view of that moment speaking in the shop's own voice. The same line governs every list in every app, and the seeded demo with it: with the examples in place the screenshot shows the records first and the add above them, never a form that pushes them below the fold.
 
 **The seed dresses the opening screen.** The screenshot and the owner's first look both see one phone screen, so write the seed for that screen: the richest, most representative state of the app lives on the view it opens to, filled with just enough records to cover that one screen at the size the view draws them — a few rich cards, or a handful more compact rows — a lived-in week rather than a wall. Give that view one of each state the app knows how to show, so every feature is visible at first glance: a canoe club's trip board opens on a trip already paddled, one coming up next and one just posted with its put-in note; a sourdough starter log opens on a feed marked done, one due next, and a fresh loaf with its note. Every sample belongs to the owner, and its names, notes and numbers read like a real person's, so the first screen looks like someone has been happily using the app for a while.