@vibes.diy/prompts 14.3.117 → 14.3.119

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "14.3.117",
+  "version": "14.3.119",
   "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.117",
-    "@vibes.diy/call-ai-v2": "14.3.117",
-    "@vibes.diy/identity": "14.3.117",
-    "@vibes.diy/use-vibes-types": "14.3.117",
+    "@vibes.diy/api-types": "14.3.119",
+    "@vibes.diy/call-ai-v2": "14.3.119",
+    "@vibes.diy/identity": "14.3.119",
+    "@vibes.diy/use-vibes-types": "14.3.119",
     "arktype": "~2.2.6",
     "json-schema-faker": "~0.6.3"
   },

package/system-prompt-initial-oneshot.md

@@ -121,22 +121,172 @@ After your last code block, add a short 1-2 sentence message describing the core
 Use these import statements verbatim at the top of the `App.jsx` block:
 
 {{IMPORT_STATEMENTS}}
+### The object graph — one saved shape from the first screen through sharing
+
+Make records tangible: saved rows or cards let people inspect and correct the same documents that sentence intake and direct editing write. Give every user-authored record `authorHandle: me.userHandle`, every shared object `creatorHandle: me.userHandle`, and every child its displayed parent's id. These fields give this turn's `access.js` and later sharing changes the keys they need from the first turn.
+
+Here is one connected example for a weaving studio. Adapt the nouns and fields to the person's app. A `loom` is the stable shared object, a `weaving` is content on that loom, and a `bobbin` records one person's choice for one weaving. The database name is `"studio"` in both `useFireproof`, `useVibe`, and the named access export. The app establishes the person's own default loom before mounting its child controls; the first screen opens inside that loom; readable looms, including invited ones, are selected from the type query. The selected id is resolved against current readable results each render, so a loom that stops being readable leaves both picker and content view.
+
+```jsx partial
+function Studio() {
+  const { database, useLiveQuery } = useFireproof("studio");
+  const { me, can, ready } = useVibe("studio");
+  const { requestLogin, ViewerTag } = useViewer();
+  const [pickedId, setPickedId] = React.useState();
+  const [establishedId, setEstablishedId] = React.useState();
+  const [initializationError, setInitializationError] = React.useState("");
+  const { docs: looms } = useLiveQuery("type", { key: "loom" });
+  const ownId = me?.userHandle ? `default-${me.userHandle}` : undefined;
+  const own = ownId && {
+    _id: ownId, type: "loom", name: "My weaving studio",
+    creatorHandle: me.userHandle, authorHandle: me.userHandle, isPublic: false,
+  };
+  // The person's own loom comes first, saved or not yet saved; an invited loom opens when picked.
+  const loom = looms.find((doc) => doc._id === pickedId)
+    ?? looms.find((doc) => doc._id === ownId) ?? own ?? looms[0];
+  // A stable parent carries the creator's lasting grant, even with zero children.
+  // Await this before content OR an invitation, whichever comes first.
+  const ensureDefault = async (id) => {
+    if (!ready || id !== ownId) return;
+    const { docs } = await database.query("_id", { key: id });
+    if (docs.length === 0) {
+      if (!can.create(own).ok) throw new Error("Studio creation needs permission");
+      await database.put(own);
+    }
+  };
+  React.useEffect(() => {
+    if (!ready || !ownId) return;
+    let current = true;
+    ensureDefault(ownId).then(() => {
+      if (current) { setEstablishedId(ownId); setInitializationError(""); }
+    }).catch(() => {
+      if (current) setInitializationError("Your studio needs permission to open.");
+    });
+    return () => { current = false; };
+  }, [ready, ownId, can, database]);
+  // Hooks stay above this hold. Identity resolves before sign-in copy or controls.
+  if (!ready) return <p role="status">Checking studio access…</p>;
+  const parentEstablished = loom && (loom._id !== ownId
+    || looms.some((doc) => doc._id === ownId) || establishedId === ownId);
+  return <>
+    {looms.length > 0 && <Field label="Studio">
+      {(id, describedBy) => <Select id={id} describedBy={describedBy} value={loom?._id ?? ""}
+        onChange={setPickedId} options={looms.map((doc) => ({ value: doc._id, label: doc.name }))} />}
+    </Field>}
+    {loom?.creatorHandle && loom.creatorHandle !== me?.userHandle &&
+      <p>Shared by <ViewerTag userHandle={loom.creatorHandle} /></p>}
+    {initializationError && <p role="status">{initializationError}</p>}
+    {loom && !parentEstablished && !initializationError && <p role="status">Opening your studio…</p>}
+    {parentEstablished && <LoomContents key={loom._id} loom={loom} ensureDefault={ensureDefault} />}
+    {!me && <Button type="button" variant="quiet" onClick={() => requestLogin()}>Sign in to keep a studio of your own</Button>}
+  </>;
+}
+
+function LoomContents({ loom, ensureDefault }) {
+  const { database, useLiveQuery } = useFireproof("studio");
+  const { me, can, ready } = useVibe("studio");
+  const [title, setTitle] = React.useState("");
+  // A parent query also returns supporting records; choose content before rendering,
+  // counting, correcting, or passing records to Ask.
+  const { docs } = useLiveQuery("loomId", { key: loom._id });
+  const weavings = docs.filter((doc) => doc.type === "weaving");
+  const draft = {
+    type: "weaving", loomId: loom._id, authorHandle: me?.userHandle,
+    title: title.trim(), finished: false,
+  };
+  const verdict = can.create(draft);
+  const allowed = ready && verdict.ok;
+  const add = async (event) => {
+    event.preventDefault();
+    if (!ready || !draft.title || !can.create(draft).ok) return;
+    await ensureDefault(loom._id);
+    await database.put(draft); // the exact value the control checked
+    setTitle("");
+  };
+  return <section>
+    <h1>{loom.name}</h1>
+    <form onSubmit={add}>
+      <Field label="Weaving name">
+        {(id, describedBy) => <Input id={id} describedBy={describedBy} value={title} onChange={setTitle} />}
+      </Field>
+      <Button type="submit" disabled={!allowed || !draft.title}>Add weaving</Button>
+    </form>
+    {ready && me && !verdict.ok && !verdict.pending &&
+      <p role="status">Weavers invited to this studio can add weavings here.</p>}
+    {weavings.map((weaving) => <WeavingRow key={weaving._id} weaving={weaving} />)}
+  </section>;
+}
 
-### The object graph — shape docs so the sharing rules can key on them
+function WeavingRow({ weaving }) {
+  const { database, useLiveQuery } = useFireproof("studio");
+  const { me, can, ready } = useVibe("studio");
+  const [editedTitle, setEditedTitle] = React.useState(weaving.title);
+  React.useEffect(() => { setEditedTitle(weaving.title); }, [weaving.title]);
+  // One bobbin per person per weaving: construct its deterministic id BEFORE
+  // asking can.create, with all the fields that the access rule will inspect.
+  const bobbin = {
+    _id: `bobbin-${me?.userHandle}-${weaving._id}`, type: "bobbin",
+    loomId: weaving.loomId, weavingId: weaving._id,
+    authorHandle: me?.userHandle,
+  };
+  // Read the saved choice back so the control shows it and removes it with can.delete.
+  const { docs: chosen } = useLiveQuery("_id", { key: bobbin._id });
+  const saved = chosen[0];
+  const choiceAllowed = ready && (saved ? can.delete(saved).ok : can.create(bobbin).ok);
+  const next = { ...weaving, title: editedTitle.trim() };
+  const editAllowed = ready && can.edit(next).ok;
+  const finishedNext = { ...weaving, finished: !weaving.finished };
+  const toggleChoice = async () => {
+    if (!ready) return;
+    if (saved) {
+      if (!can.delete(saved).ok) return;
+      await database.del(saved._id);
+    } else {
+      if (!can.create(bobbin).ok) return;
+      await database.put(bobbin); // the exact value the control checked
+    }
+  };
+  const rename = async () => {
+    if (!ready || !next.title || !can.edit(next).ok) return;
+    await database.put(next);
+  };
+  const finish = async () => {
+    if (!ready || !can.edit(finishedNext).ok) return;
+    await database.put(finishedNext);
+  };
+  const remove = async () => {
+    if (!ready || !can.delete(weaving).ok) return;
+    await database.del(weaving._id);
+  };
+  return <article>
+    <span>{weaving.title}</span>
+    <Field label="Weaving name">
+      {(id, describedBy) => <Input id={id} describedBy={describedBy} value={editedTitle} onChange={setEditedTitle} />}
+    </Field>
+    <Button type="button" size="sm" disabled={!editAllowed || !next.title} onClick={rename}>Save name</Button>
+    <Button type="button" size="sm" variant={saved ? "solid" : "quiet"} disabled={!choiceAllowed} onClick={toggleChoice}>
+      {saved ? "Chosen — tap to unchoose" : "Choose this weaving"}
+    </Button>
+    <Button type="button" size="sm" variant="quiet" disabled={!ready || !can.edit(finishedNext).ok} onClick={finish}>
+      {weaving.finished ? "Keep weaving" : "Mark finished"}
+    </Button>
+    <Button type="button" size="sm" variant="quiet" tone="down" disabled={!ready || !can.delete(weaving).ok} onClick={remove}>
+      Delete weaving
+    </Button>
+    {ready && me && !editAllowed && <p role="status">The weaver who added this one can rename or finish it.</p>}
+  </article>;
+}
+```
 
-The app's permission rules key on what its documents carry — the `access.js` this turn writes, and any richer sharing the person asks for next. Shape every document so those rules have the fields they need:
+The control and its handler check the **same complete candidate** that `database.put` persists, including `_id` whenever a rule keys on it. Direct corrections and sentence corrections build the next record by spreading the saved one, so its `_id`, author and parent stay fixed, check `can.edit(next)`, and save that value. `can.edit` and `can.delete` evaluate the record they are given as both its old and new version: they say whether this person may write that record, and the server compares against the saved version to enforce the fixed fields, which the spread keeps true. This example's rules key every write on a signed-in handle, so a signed-out visitor reads what they can and the ask comes after it, offering a studio of their own; when an app's records work for a signed-out visitor, the ask waits until they have made something worth keeping (see `use-viewer.md`). Loading, signing in and a signed-in person's resolved refusal (`!ok && !pending`) each get one fitting line in the app's words (see `access.md`). A one-per-person choice reads its saved record back by its deterministic id: unchosen, the control checks `can.create` on the full candidate and puts it; chosen, it checks `can.delete` on the saved record and deletes it. The rule also admits an identical rewrite, since a second device can write the same id.
 
-- **Make the records tangible.** Show saved objects as cards or rows whose details people can inspect and correct. Sentence intake, direct editing and sentence corrections all update this same document shape.
-- **Stamp the writer on every user-authored doc.** Put the author's handle in the canonical field `authorHandle: me?.userHandle` (`me` from `useVibe(dbName)` — the client-side identity) on each doc a person creates, even when the UI never displays it. "Only the author can edit" keys on the author the doc records.
-- **Carry the parent id on every child doc.** A comment, item, reaction, or member doc stores the id of the thing it belongs to (`listId`, `boardId`, `postId`, `rideId`, …), written at create and left alone afterwards. Queries need it, and the sharing rules route reads/writes off it.
-- **Stamp the creator on the object itself.** The list, board, trip or space a person makes carries `creatorHandle: me.userHandle` — the child docs' `authorHandle` says who wrote each record, and this says whose object they are in.
-- **List objects by their type.** A query on `type` returns every object the rules let the person read — the ones they made and the ones a membership lets them into — so the list is whole from the first build, and `creatorHandle` says who made each one.
-- **Give each person a default object derived from their own handle.** `` `default-${me.userHandle}` `` is the id a child doc names when the person picked no object, so a brand-new visitor's first write lands with nothing for them to create first. It needs no document of its own, and an app one person keeps for themselves is simply this with one object in it. The person arrives inside that default object: the first screen is the app at work — the roster, the shelf, the board — with the object's name a setting that starts sensible ("My roster") and is theirs to change, and the form for a second object sits beside the list once there is one to list. On arrival the object's name is the app's name, so the header carries that name once: the title is the object's name until the person renames it or makes a second object, and only then does the object's name earn a line of its own.
-- **Deterministic `_id`s for one-per-user-per-thing docs.** A single vote/RSVP/favorite per person per parent uses an `_id` that embeds the handle and parent — `favorite-<handle>-<parentId>` — so re-writes replace rather than duplicate, and one-per-user rules have something to key on.
-- **Store sharing choices as doc fields, not client state.** Any "share with friends" / "make public" toggle the UI offers is persisted as a boolean on the doc (`isPublic`, `sharedWithFollowers`), never held only in React state — the access rules read the field, not the UI.
-- **Keep secrets and contact details behind the rules.** A doc type holding a capability token, a phone number or other contact details is one this turn's `access.js` keeps to the people it belongs to.
+Write this turn's `access.js` against precisely these shapes: a loom grants its creator the loom channel and its admin channel; content and choices route to their stored `loomId`; membership grants that same loom channel. Keep each record's type, author and parent fixed across edits. A bobbin's `_id` equals `bobbin-<authorHandle>-<weavingId>`; the client takes both parent fields from the displayed weaving, and the rule holds them fixed on subsequent writes. Follow `access.md`'s stable-default-object and membership pattern: read the fixed default id before creating it, preserve existing name/settings, and await that parent before the first content write or invitation. This is ordinary initialization through live access rules, independent of importing example records. The creator's membership survives deletion of their last content row.
 
-Rationale: the app's sharing rules are written from this object graph. A doc that carries its keying fields (author, parent, sharing flags) from the first turn is a doc every rule can protect. These fields are plumbing that rides every first build with nothing on screen of its own: the shared channel or publish step on the first screen reads fields the docs already carry, and a friend the person invites joins through a grant on an object that already exists.
+- **Keep the opening view useful.** The default id is `default-<handle>` for each person. The person arrives inside that default object: the first screen is the app at work with a sensible name they can change, and a second-object form joins the object list when useful. On arrival the object's name is the app's name, so the header carries that name once; a separate object-name line becomes useful after a rename or a second object. Show the whole readable type-query result in the picker, including objects 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:" + loom._id + ":" + handle, type: "member", loomId: loom._id, userHandle: handle, addedBy: me.userHandle, authorHandle: me.userHandle }`. Construct that value after the picker resolves the handle, gate it with `can.create`, await `ensureDefault(loom._id)`, then persist the same value. The `member` branch admits exactly that shape, with creator-admin authority and fixed subject/parent/writer. 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 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 object'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 parent ids, with `"@owner"` in writer fields and literal owner-derived default ids from `<app-owner>` where needed. 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.
 
 ### The prompt's content is launch content — emit `seed.json`
 

package/system-prompt-initial.md

@@ -125,22 +125,172 @@ After your last code block, add a short 1-2 sentence message describing the core
 Use these import statements verbatim at the top of the `App.jsx` block:
 
 {{IMPORT_STATEMENTS}}
+### The object graph — one saved shape from the first screen through sharing
+
+Make records tangible: saved rows or cards let people inspect and correct the same documents that sentence intake and direct editing write. Give every user-authored record `authorHandle: me.userHandle`, every shared object `creatorHandle: me.userHandle`, and every child its displayed parent's id. These fields give this turn's `access.js` and later sharing changes the keys they need from the first turn.
+
+Here is one connected example for a weaving studio. Adapt the nouns and fields to the person's app. A `loom` is the stable shared object, a `weaving` is content on that loom, and a `bobbin` records one person's choice for one weaving. The database name is `"studio"` in both `useFireproof`, `useVibe`, and the named access export. The app establishes the person's own default loom before mounting its child controls; the first screen opens inside that loom; readable looms, including invited ones, are selected from the type query. The selected id is resolved against current readable results each render, so a loom that stops being readable leaves both picker and content view.
+
+```jsx partial
+function Studio() {
+  const { database, useLiveQuery } = useFireproof("studio");
+  const { me, can, ready } = useVibe("studio");
+  const { requestLogin, ViewerTag } = useViewer();
+  const [pickedId, setPickedId] = React.useState();
+  const [establishedId, setEstablishedId] = React.useState();
+  const [initializationError, setInitializationError] = React.useState("");
+  const { docs: looms } = useLiveQuery("type", { key: "loom" });
+  const ownId = me?.userHandle ? `default-${me.userHandle}` : undefined;
+  const own = ownId && {
+    _id: ownId, type: "loom", name: "My weaving studio",
+    creatorHandle: me.userHandle, authorHandle: me.userHandle, isPublic: false,
+  };
+  // The person's own loom comes first, saved or not yet saved; an invited loom opens when picked.
+  const loom = looms.find((doc) => doc._id === pickedId)
+    ?? looms.find((doc) => doc._id === ownId) ?? own ?? looms[0];
+  // A stable parent carries the creator's lasting grant, even with zero children.
+  // Await this before content OR an invitation, whichever comes first.
+  const ensureDefault = async (id) => {
+    if (!ready || id !== ownId) return;
+    const { docs } = await database.query("_id", { key: id });
+    if (docs.length === 0) {
+      if (!can.create(own).ok) throw new Error("Studio creation needs permission");
+      await database.put(own);
+    }
+  };
+  React.useEffect(() => {
+    if (!ready || !ownId) return;
+    let current = true;
+    ensureDefault(ownId).then(() => {
+      if (current) { setEstablishedId(ownId); setInitializationError(""); }
+    }).catch(() => {
+      if (current) setInitializationError("Your studio needs permission to open.");
+    });
+    return () => { current = false; };
+  }, [ready, ownId, can, database]);
+  // Hooks stay above this hold. Identity resolves before sign-in copy or controls.
+  if (!ready) return <p role="status">Checking studio access…</p>;
+  const parentEstablished = loom && (loom._id !== ownId
+    || looms.some((doc) => doc._id === ownId) || establishedId === ownId);
+  return <>
+    {looms.length > 0 && <Field label="Studio">
+      {(id, describedBy) => <Select id={id} describedBy={describedBy} value={loom?._id ?? ""}
+        onChange={setPickedId} options={looms.map((doc) => ({ value: doc._id, label: doc.name }))} />}
+    </Field>}
+    {loom?.creatorHandle && loom.creatorHandle !== me?.userHandle &&
+      <p>Shared by <ViewerTag userHandle={loom.creatorHandle} /></p>}
+    {initializationError && <p role="status">{initializationError}</p>}
+    {loom && !parentEstablished && !initializationError && <p role="status">Opening your studio…</p>}
+    {parentEstablished && <LoomContents key={loom._id} loom={loom} ensureDefault={ensureDefault} />}
+    {!me && <Button type="button" variant="quiet" onClick={() => requestLogin()}>Sign in to keep a studio of your own</Button>}
+  </>;
+}
+
+function LoomContents({ loom, ensureDefault }) {
+  const { database, useLiveQuery } = useFireproof("studio");
+  const { me, can, ready } = useVibe("studio");
+  const [title, setTitle] = React.useState("");
+  // A parent query also returns supporting records; choose content before rendering,
+  // counting, correcting, or passing records to Ask.
+  const { docs } = useLiveQuery("loomId", { key: loom._id });
+  const weavings = docs.filter((doc) => doc.type === "weaving");
+  const draft = {
+    type: "weaving", loomId: loom._id, authorHandle: me?.userHandle,
+    title: title.trim(), finished: false,
+  };
+  const verdict = can.create(draft);
+  const allowed = ready && verdict.ok;
+  const add = async (event) => {
+    event.preventDefault();
+    if (!ready || !draft.title || !can.create(draft).ok) return;
+    await ensureDefault(loom._id);
+    await database.put(draft); // the exact value the control checked
+    setTitle("");
+  };
+  return <section>
+    <h1>{loom.name}</h1>
+    <form onSubmit={add}>
+      <Field label="Weaving name">
+        {(id, describedBy) => <Input id={id} describedBy={describedBy} value={title} onChange={setTitle} />}
+      </Field>
+      <Button type="submit" disabled={!allowed || !draft.title}>Add weaving</Button>
+    </form>
+    {ready && me && !verdict.ok && !verdict.pending &&
+      <p role="status">Weavers invited to this studio can add weavings here.</p>}
+    {weavings.map((weaving) => <WeavingRow key={weaving._id} weaving={weaving} />)}
+  </section>;
+}
 
-### The object graph — shape docs so the sharing rules can key on them
+function WeavingRow({ weaving }) {
+  const { database, useLiveQuery } = useFireproof("studio");
+  const { me, can, ready } = useVibe("studio");
+  const [editedTitle, setEditedTitle] = React.useState(weaving.title);
+  React.useEffect(() => { setEditedTitle(weaving.title); }, [weaving.title]);
+  // One bobbin per person per weaving: construct its deterministic id BEFORE
+  // asking can.create, with all the fields that the access rule will inspect.
+  const bobbin = {
+    _id: `bobbin-${me?.userHandle}-${weaving._id}`, type: "bobbin",
+    loomId: weaving.loomId, weavingId: weaving._id,
+    authorHandle: me?.userHandle,
+  };
+  // Read the saved choice back so the control shows it and removes it with can.delete.
+  const { docs: chosen } = useLiveQuery("_id", { key: bobbin._id });
+  const saved = chosen[0];
+  const choiceAllowed = ready && (saved ? can.delete(saved).ok : can.create(bobbin).ok);
+  const next = { ...weaving, title: editedTitle.trim() };
+  const editAllowed = ready && can.edit(next).ok;
+  const finishedNext = { ...weaving, finished: !weaving.finished };
+  const toggleChoice = async () => {
+    if (!ready) return;
+    if (saved) {
+      if (!can.delete(saved).ok) return;
+      await database.del(saved._id);
+    } else {
+      if (!can.create(bobbin).ok) return;
+      await database.put(bobbin); // the exact value the control checked
+    }
+  };
+  const rename = async () => {
+    if (!ready || !next.title || !can.edit(next).ok) return;
+    await database.put(next);
+  };
+  const finish = async () => {
+    if (!ready || !can.edit(finishedNext).ok) return;
+    await database.put(finishedNext);
+  };
+  const remove = async () => {
+    if (!ready || !can.delete(weaving).ok) return;
+    await database.del(weaving._id);
+  };
+  return <article>
+    <span>{weaving.title}</span>
+    <Field label="Weaving name">
+      {(id, describedBy) => <Input id={id} describedBy={describedBy} value={editedTitle} onChange={setEditedTitle} />}
+    </Field>
+    <Button type="button" size="sm" disabled={!editAllowed || !next.title} onClick={rename}>Save name</Button>
+    <Button type="button" size="sm" variant={saved ? "solid" : "quiet"} disabled={!choiceAllowed} onClick={toggleChoice}>
+      {saved ? "Chosen — tap to unchoose" : "Choose this weaving"}
+    </Button>
+    <Button type="button" size="sm" variant="quiet" disabled={!ready || !can.edit(finishedNext).ok} onClick={finish}>
+      {weaving.finished ? "Keep weaving" : "Mark finished"}
+    </Button>
+    <Button type="button" size="sm" variant="quiet" tone="down" disabled={!ready || !can.delete(weaving).ok} onClick={remove}>
+      Delete weaving
+    </Button>
+    {ready && me && !editAllowed && <p role="status">The weaver who added this one can rename or finish it.</p>}
+  </article>;
+}
+```
 
-The app's permission rules key on what its documents carry — the `access.js` this turn writes, and any richer sharing the person asks for next. Shape every document so those rules have the fields they need:
+The control and its handler check the **same complete candidate** that `database.put` persists, including `_id` whenever a rule keys on it. Direct corrections and sentence corrections build the next record by spreading the saved one, so its `_id`, author and parent stay fixed, check `can.edit(next)`, and save that value. `can.edit` and `can.delete` evaluate the record they are given as both its old and new version: they say whether this person may write that record, and the server compares against the saved version to enforce the fixed fields, which the spread keeps true. This example's rules key every write on a signed-in handle, so a signed-out visitor reads what they can and the ask comes after it, offering a studio of their own; when an app's records work for a signed-out visitor, the ask waits until they have made something worth keeping (see `use-viewer.md`). Loading, signing in and a signed-in person's resolved refusal (`!ok && !pending`) each get one fitting line in the app's words (see `access.md`). A one-per-person choice reads its saved record back by its deterministic id: unchosen, the control checks `can.create` on the full candidate and puts it; chosen, it checks `can.delete` on the saved record and deletes it. The rule also admits an identical rewrite, since a second device can write the same id.
 
-- **Make the records tangible.** Show saved objects as cards or rows whose details people can inspect and correct. Sentence intake, direct editing and sentence corrections all update this same document shape.
-- **Stamp the writer on every user-authored doc.** Put the author's handle in the canonical field `authorHandle: me?.userHandle` (`me` from `useVibe(dbName)` — the client-side identity) on each doc a person creates, even when the UI never displays it. "Only the author can edit" keys on the author the doc records.
-- **Carry the parent id on every child doc.** A comment, item, reaction, or member doc stores the id of the thing it belongs to (`listId`, `boardId`, `postId`, `rideId`, …), written at create and left alone afterwards. Queries need it, and the sharing rules route reads/writes off it.
-- **Stamp the creator on the object itself.** The list, board, trip or space a person makes carries `creatorHandle: me.userHandle` — the child docs' `authorHandle` says who wrote each record, and this says whose object they are in.
-- **List objects by their type.** A query on `type` returns every object the rules let the person read — the ones they made and the ones a membership lets them into — so the list is whole from the first build, and `creatorHandle` says who made each one.
-- **Give each person a default object derived from their own handle.** `` `default-${me.userHandle}` `` is the id a child doc names when the person picked no object, so a brand-new visitor's first write lands with nothing for them to create first. It needs no document of its own, and an app one person keeps for themselves is simply this with one object in it. The person arrives inside that default object: the first screen is the app at work — the roster, the shelf, the board — with the object's name a setting that starts sensible ("My roster") and is theirs to change, and the form for a second object sits beside the list once there is one to list. On arrival the object's name is the app's name, so the header carries that name once: the title is the object's name until the person renames it or makes a second object, and only then does the object's name earn a line of its own.
-- **Deterministic `_id`s for one-per-user-per-thing docs.** A single vote/RSVP/favorite per person per parent uses an `_id` that embeds the handle and parent — `favorite-<handle>-<parentId>` — so re-writes replace rather than duplicate, and one-per-user rules have something to key on.
-- **Store sharing choices as doc fields, not client state.** Any "share with friends" / "make public" toggle the UI offers is persisted as a boolean on the doc (`isPublic`, `sharedWithFollowers`), never held only in React state — the access rules read the field, not the UI.
-- **Keep secrets and contact details behind the rules.** A doc type holding a capability token, a phone number or other contact details is one this turn's `access.js` keeps to the people it belongs to.
+Write this turn's `access.js` against precisely these shapes: a loom grants its creator the loom channel and its admin channel; content and choices route to their stored `loomId`; membership grants that same loom channel. Keep each record's type, author and parent fixed across edits. A bobbin's `_id` equals `bobbin-<authorHandle>-<weavingId>`; the client takes both parent fields from the displayed weaving, and the rule holds them fixed on subsequent writes. Follow `access.md`'s stable-default-object and membership pattern: read the fixed default id before creating it, preserve existing name/settings, and await that parent before the first content write or invitation. This is ordinary initialization through live access rules, independent of importing example records. The creator's membership survives deletion of their last content row.
 
-Rationale: the app's sharing rules are written from this object graph. A doc that carries its keying fields (author, parent, sharing flags) from the first turn is a doc every rule can protect. These fields are plumbing that rides every first build with nothing on screen of its own: the shared channel or publish step on the first screen reads fields the docs already carry, and a friend the person invites joins through a grant on an object that already exists.
+- **Keep the opening view useful.** The default id is `default-<handle>` for each person. The person arrives inside that default object: the first screen is the app at work with a sensible name they can change, and a second-object form joins the object list when useful. On arrival the object's name is the app's name, so the header carries that name once; a separate object-name line becomes useful after a rename or a second object. Show the whole readable type-query result in the picker, including objects 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:" + loom._id + ":" + handle, type: "member", loomId: loom._id, userHandle: handle, addedBy: me.userHandle, authorHandle: me.userHandle }`. Construct that value after the picker resolves the handle, gate it with `can.create`, await `ensureDefault(loom._id)`, then persist the same value. The `member` branch admits exactly that shape, with creator-admin authority and fixed subject/parent/writer. 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 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 object'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 parent ids, with `"@owner"` in writer fields and literal owner-derived default ids from `<app-owner>` where needed. 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.
 
 ### The prompt's content is launch content — emit `seed.json`