@vibes.diy/prompts 14.0.22 → 14.0.24

package/llms/access.md

@@ -6,6 +6,13 @@ You are seeing this doc because the app's prompt is **permission-shaped** — it
 
 `access.js` is a separate file alongside `App.jsx`; each **named export** gates the database of the same name (`export function chat(...)` gates `useFireproof("chat")`), and an `export default` acts as a catch-all. The `App.jsx` you write gates its write surfaces on `useVibe(dbName).can` — the same function this access.js enforces server-side.
 
+Construct the document an action will save, check that same value with `can.create` or
+`can.edit`, then write it to the same database. Include every field the access rule checks,
+including the intended next status. For example, cancelling a reservation constructs
+`const next = { ...reservation, status: "cancelled" }`, checks `can.edit(next).ok`, and
+saves `next`. A creation control checks the complete creation draft. Render the verdict's
+reason when denied, and keep loading and signed-out states distinct from denial.
+
 ## Reference
 
 ### Function signature
@@ -101,7 +108,7 @@ The platform predicate `ctx.isImgGenVersionAppend(doc, oldDoc)` accepts exactly
 
 ### `_id` strategy matters
 
-Documents that represent a unique named resource (channels, user profiles, config singletons, seed/starter content) should use a deterministic `_id` with a short prefix — `"ch:" + name`, `"profile:" + handle`, `"config"`, `"seed:" + key`. This enforces uniqueness: two users creating "general" get the same doc, not two — and a first-load seed that runs again (a fresh tab, another device) overwrites the same starter docs instead of duplicating them. Documents that represent events or content (messages, posts, survey responses) should let `_id` be auto-generated — each one is unique by nature. Use `doc._id` as the channel name for resource docs; use a `channelId` foreign key on content docs.
+Documents that represent a unique named resource (channels, user profiles, config singletons, starter content) should use a deterministic `_id` with a short prefix — `"ch:" + name`, `"profile:" + handle`, `"config"`, `"starter:" + key`. This enforces uniqueness: two users creating "general" get the same doc, not two — and a first-load write that runs again (a fresh tab, another device) overwrites the same starter docs instead of duplicating them. Records a request says the app must already have are created this way, by the app's first render; see "Required starting records" in `fireproof.md`. Documents that represent events or content (messages, posts, survey responses) should let `_id` be auto-generated — each one is unique by nature. Use `doc._id` as the channel name for resource docs; use a `channelId` foreign key on content docs.
 
 ### Grants are additive
 

package/llms/backend.md

@@ -40,6 +40,13 @@ the request, the app needs no `backend.js` — don't emit one.
 `backend.js` + **cache-into-db, never fetch-per-render**; when external data is
 only launch flavor, take a generation-time snapshot into `seed.json` instead.
 
+Keep availability separate from a successful empty result. Inspect a successful source
+response before choosing its parser, then validate the fields the app uses. An empty
+validated response is data; an unavailable first read leaves the dependent decision pending.
+For example, a dispatch planner waiting for its closure calendar records that unavailable
+state and postpones calendar-dependent dispatch. A previously validated cache can support
+the declared fallback, with its freshness and failure visible in saved status.
+
 ## Output format
 
 `backend.js` is a separate file, exactly like `access.js`: one prose line, the
@@ -268,7 +275,11 @@ const gh = await ctx.github.fetch("/repos/acme/site/issues", { method: "POST", b
   budget (10 per 10s, 60 per minute) is spent for the moment, which the next tick
   clears. Check for that shape and surface a useful error. Remedies: read it as a
   plain `GET`, use a CORS-open endpoint,
-  request a curated-list addition, or ask about owner blessing. Limits: https
+  request a curated-list addition, or ask about owner blessing. The creator-facing
+  version of this gate — including what to do when a link is reported as taking
+  more power than the app has today — is at
+  https://good.vibes.diy/docs/your-app-has-a-backend, which is the page to send
+  someone to. Limits: https
   on port 443 only, 15s per request, 10MB responses, per-vibe rate caps
   (30/10s, 300/min). Make all outbound calls **before returning** the Response —
   a `ctx.fetch()` fired while a streamed body is still being pulled after the
@@ -548,6 +559,14 @@ const res = await fetch("/_api/rsvp", { method: "POST", body: JSON.stringify({ n
 
 ## onChange — react to committed writes
 
+**When the request says a record is kept on the server, or that the server reacts
+to something, emit this handler.** A person asking for activity to be recorded
+centrally, for a tally the app maintains, or for something to happen whenever a
+record lands is naming the server as the place it happens — that ask is the
+trigger, and the shape is the activity-mirror example at the end of this file:
+the client writes the document that triggers it, and `onChange` writes what the
+server owes in response.
+
 Runs after any document write to the app's databases commits (user writes and
 backend writes alike). The event:
 
@@ -684,6 +703,17 @@ document it reads by id, plus a copy in module scope. A missing or failed state
 read means *"don't know — use the copy"*, never *"nothing has run yet"*; that
 second reading is what bills the owner four times for one noon.
 
+**A status document that must be seen to change carries the tick's timestamp.**
+A write whose content is byte-identical to what is already stored is absorbed:
+the platform stores no new revision, and with no new revision there is no live
+event, so an open page holding that document sees nothing and keeps showing what
+it already had. A tick that rewrites a fixed-id status doc with the same fields
+every time is therefore invisible to a watching reader. Include the moment the
+tick ran — `checkedAt: new Date().toISOString()` — and the write is a real
+change, so the page updates. This is the reader's side of the state-document
+discipline above: state you only ever read back yourself is better off constant,
+and state somebody is watching has to move.
+
 ### Firing on a real-world event
 
 **An averaged cycle is not a calendar.** When the moment comes from nature

package/llms/fireproof.md

@@ -77,6 +77,35 @@ App.jsx
 
 The `useDocument` hook provides several methods: `merge(updates)` updates the document with new fields without saving (use this instead of keeping a `useState` for document data), `submit(e)` handles form submission by preventing default, saving, and resetting, `save()` saves the current document state, and `reset()` resets to initial state. When you call submit, the document is reset, so if you didn't provide an `_id` then you can use the form to create a stream of new documents as in the basic example above.
 
+## Required starting records
+
+When a request names records the app must already have — the three projects in a
+studio, a template's starter rows, the rooms in a planner — those records are
+created by the app's own first render through the ordinary write path. That is
+the mechanism, and it is the same one described below for starter content.
+`seed.json` is a separate thing: an optional import a person runs by hand from
+the Data tab, applied by no deploy path, so a record that exists only there does
+not exist for anyone who opens the app.
+
+Four rules make it hold:
+
+- **Each required record gets a fixed `_id` you choose** (`"project:atlas"`), so
+  a second write of it lands on the same document instead of minting another.
+- **Create them after `ready` and after `can.create` says yes**, so a write that
+  the enforced access rules do not admit yet is skipped quietly and retried on a
+  later run.
+- **Restrict their creation to the owner in `access.js`** when the records
+  describe the app itself rather than a visitor's own work.
+- **Write parents and membership grants before the records that depend on
+  them**, so a dependent document never lands against a container or a grant
+  that does not exist yet.
+
+Fixed ids are also what makes two tabs safe. Two browsers opening the app for the
+first time at the same moment both see an empty query and both write; with fixed
+ids those are two writes of the same document, and last-writer-wins converges on
+one copy. Reading the query first and then deciding whether to write is the shape
+that races — the read is empty in both tabs before either write lands.
+
 ### Seeding starter data — give each seed a deterministic `_id`
 
 When an app ships with default content — starter slides, template rows, example cards — and writes it into the database on first load, give **each seed document a deterministic `_id`** (`"seed:intro"`, `"seed:" + key`). This makes the seeding write **idempotent**: if it ever runs again, it overwrites the same documents instead of creating fresh copies.

package/llms/image-gen.md

@@ -25,7 +25,35 @@ export default function App() {
 }
 ```
 
-`<ImgGen>` writes the doc into a Fireproof database (default name `"ImgGen"`). The doc carries `_files.v1 = { uploadId, type, size }` and the platform mints `_files.v1.url` on read. To render a stored image doc manually, read the version with `doc.versions?.[doc.currentVersion ?? 0]`, get the file metadata with `doc._files?.[ver.id]`, and use `meta.url` for `<img src>`. The gallery pattern below shows this in a working component with proper hooks.
+`<ImgGen>` stores generated versions in its component-owned media database, associated
+with the host database name and `_id`. Read a saved image through
+`useImgGen({ _id, database })` from `use-vibes`: its `document` composes current media
+versions and legacy host versions. From that composed document, select
+`document.versions?.[document.currentVersion ?? 0]`, then
+`document._files?.[version.id]`. The returned file ref supplies both `.url` for display
+and `.file()` for a transformation input, so a ref you have in hand is ready to pass
+straight to `images`. Ordinary host records hold the app's own data; the image hook
+supplies the associated generated output.
+
+For example, refining a saved pottery illustration keeps its original ID and uses its
+actual output as the input to a separate result ID:
+
+```jsx
+import { ImgGen, useImgGen } from "use-vibes";
+
+function GlazingPreview({ database }) {
+  const { document: original, pending, error } = useImgGen({ _id: "vessel-original", database });
+  const version = original?.versions?.[original.currentVersion ?? 0];
+  const source = version?.id ? original?._files?.[version.id] : undefined;
+  const sourceReady = source !== undefined;
+  return <section>
+    <ImgGen _id="vessel-original" database={database} showControls={false} />
+    {sourceReady ? <ImgGen _id="vessel-glazed" database={database}
+      prompt="Add a blue glaze while preserving this vessel's shape and composition"
+      images={[source]} /> : <p>{error ? error.message : pending ? "Loading saved source…" : "Source image unavailable"}</p>}
+  </section>;
+}
+```
 
 This is the same `_files`-shape contract documented in `fireproof.md`'s "Working with Files" section — read it first if you have not seen the platform's file/URL story.
 
@@ -88,46 +116,19 @@ Do **not** hide first generation behind an "Illustrate" / "Generate image" butto
 
 ## Gallery Pattern
 
-Browse stored images with `useLiveQuery`. Building a gallery below the generator:
-
-App.jsx
-
-```jsx
-<<<<<<< SEARCH
-export default function App() {
-  const [file, setFile] = React.useState(null);
-
-  return (
-=======
-export default function App() {
-  const { useLiveQuery } = useFireproof("ImgGen");
-  const { docs } = useLiveQuery("type", { key: "image", descending: true });
-  const [file, setFile] = React.useState(null);
-
-  return (
->>>>>>> REPLACE
-```
-
-App.jsx
+Keep gallery entries as app-owned records with the saved image's host `_id`. Query those
+records with `useLiveQuery`, then let each `<ImgGen>` read its associated media. This also
+keeps the app's title, caption and other editable fields separate from image versions:
 
 ```jsx
-<<<<<<< SEARCH
-    </div>
-  );
+function Gallery() {
+  const { database, useLiveQuery } = useFireproof("artwork");
+  const { docs } = useLiveQuery("type", { key: "artwork" });
+  return <div>{docs.map(doc => <figure key={doc._id}>
+    <ImgGen _id={doc._id} database={database} showControls={false} />
+    <figcaption>{doc.caption}</figcaption>
+  </figure>)}</div>;
 }
-=======
-      <h3>Gallery</h3>
-      <div style={{ display: "grid", gridTemplateColumns: "repeat(3, 1fr)", gap: 8 }}>
-        {docs.map((doc) => {
-          const ver = doc.versions?.[doc.currentVersion ?? 0];
-          const meta = ver?.id ? doc._files?.[ver.id] : undefined;
-          return <img key={doc._id} src={meta?.url} alt={doc.prompt} width={128} />;
-        })}
-      </div>
-    </div>
-  );
-}
->>>>>>> REPLACE
 ```
 
 ## Caching and Versions

package/llms/three-js.md

@@ -293,31 +293,80 @@ color.setHSL(0, 1, 0.5); // HSL values
 color.lerp(targetColor, 0.1); // interpolation
 ```
 
-## Raycasting (Mouse Interaction)
+## Picking things in the scene (mouse interaction)
+
+Selection has two halves: which objects the ray is allowed to hit, and which
+object a hit stands for. Keep both explicit and clicking a planet selects the
+planet rather than the glow around it.
+
+**Raycast against a `selectables` array, never the whole scene graph.** The array
+holds the things a person can pick, so lights, helpers, the skybox and every
+decorative mesh are out of the answer before the ray is cast.
+
+**Resolve a hit up `.parent` to the first ancestor carrying `userData.id`.** A hit
+lands on whichever mesh the ray touched first, which is usually a child — a halo
+shell, a label sprite, a bevel — so read the identity off the ancestor that owns
+it instead of off the mesh that happened to be in front.
+
+**Decorative children opt out of hit testing with `raycast = () => {}`.** A glow
+shell exists to be seen and not to be picked, and an empty `raycast` removes it
+from every intersection test at the source.
+
+**Show selection by changing a material property on the resolved parent.** Adding
+a new mesh to mark the selection adds another thing the ray can hit; changing
+`emissive`, `opacity` or `color` on what is already there does not.
 
 ```javascript
 const raycaster = new THREE.Raycaster();
-const mouse = new THREE.Vector2();
+const pointer = new THREE.Vector2();
 
-function onMouseClick(event) {
-  // Normalize mouse coordinates (-1 to +1)
-  mouse.x = (event.clientX / window.innerWidth) * 2 - 1;
-  mouse.y = -(event.clientY / window.innerHeight) * 2 + 1;
+// The things a person can pick. Everything else in the scene stays out of it.
+const selectables = [];
 
-  // Cast ray from camera through mouse position
-  raycaster.setFromCamera(mouse, camera);
+function addPlanet(name) {
+  const planet = new THREE.Mesh(geometry, new THREE.MeshStandardMaterial({ color: 0x88aaff }));
+  planet.userData.id = name; // the identity a hit resolves to
 
-  // Find intersections
-  const intersects = raycaster.intersectObjects(scene.children, true);
+  const glow = new THREE.Mesh(glowGeometry, glowMaterial);
+  glow.raycast = () => {}; // decorative: never a hit
+  planet.add(glow);
 
-  if (intersects.length > 0) {
-    const object = intersects[0].object;
-    const point = intersects[0].point;
-    // Handle intersection
-  }
+  scene.add(planet);
+  selectables.push(planet);
+  return planet;
+}
+
+// A hit lands on whichever mesh the ray touched — walk up to the owner of the id.
+function selectableOf(object) {
+  let node = object;
+  while (node && node.userData?.id === undefined) node = node.parent;
+  return node ?? null;
+}
+
+function onPointerDown(event) {
+  const rect = renderer.domElement.getBoundingClientRect();
+  pointer.x = ((event.clientX - rect.left) / rect.width) * 2 - 1;
+  pointer.y = -((event.clientY - rect.top) / rect.height) * 2 + 1;
+  raycaster.setFromCamera(pointer, camera);
+
+  const hit = raycaster.intersectObjects(selectables, true)[0];
+  const picked = hit ? selectableOf(hit.object) : null;
+
+  for (const s of selectables) s.material.emissive?.setHex(0x000000);
+  if (picked) picked.material.emissive?.setHex(0x333311); // a property change, not a new mesh
+  setSelectedId(picked?.userData.id ?? null);
 }
 ```
 
+## Importing three
+
+A bare package name at the top of the file resolves through the platform's esm.sh
+map, and a full esm.sh URL loads too — either form also works with
+`await import()`. The bare form follows whatever version the platform serves,
+which moves as esm.sh publishes; a version-pinned URL such as
+`https://esm.sh/three@0.160.0` is the lever for holding a scene on one release of
+the library.
+
 ## Animation System
 
 ### Animation Mixer

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "14.0.22",
+  "version": "14.0.24",
   "type": "module",
   "main": "./index.js",
   "exports": {
@@ -34,9 +34,9 @@
   "license": "Apache-2.0",
   "dependencies": {
     "@adviser/cement": "~0.5.34",
-    "@vibes.diy/call-ai-v2": "14.0.22",
-    "@vibes.diy/identity": "14.0.22",
-    "@vibes.diy/use-vibes-types": "14.0.22",
+    "@vibes.diy/call-ai-v2": "14.0.24",
+    "@vibes.diy/identity": "14.0.24",
+    "@vibes.diy/use-vibes-types": "14.0.24",
     "arktype": "~2.2.3",
     "json-schema-faker": "~0.6.3"
   },

package/system-prompt-initial-oneshot.md

@@ -25,6 +25,7 @@ You are an AI assistant tasked with creating React components. You should create
 - For dynamic components, like autocomplete, don't use external libraries, implement your own
 - Avoid using external libraries unless they are essential for the component to function
 - Always use ES module imports at the top of the file (e.g. `import React, { useState } from "react"`). Never reference React or other libraries as globals.
+- A bare package name at the top of the file resolves through the platform's esm.sh map, and a full esm.sh URL such as `https://esm.sh/three@0.160.0` loads too. Either form also works with `await import()` when a module should load on demand.
 - Your file MUST use `export default function App()` — the runtime loads it as an ES module and imports the default export.
 - Structure your component code in this order: (1) hooks and document shapes, (2) event handlers, (3) classNames object, (4) JSX return. ClassNames go right before JSX so they are close to where they are used.
 - Use Fireproof for data persistence
@@ -113,7 +114,9 @@ Rationale: the app's sharing rules are designed later from this object graph. A
 
 ### The prompt's content is launch content — emit `seed.json`
 
-When the user's prompt hands you **concrete example data** — an image of items, a pasted list, a screenshot of records, a table — that data is not just design inspiration, it is the app's **launch content**. Extract it into the app's document shape and emit it as a `seed.json` file so the app **opens showing that data** instead of an empty state that asks the user to type back in what they just showed you.
+When the user's prompt hands you **concrete example data** — an image of items, a pasted list, a screenshot of records, a table — extract it into the app's document shape and emit it as a `seed.json` file. This file is an **optional launch-data import**: the owner applies it through the app editor's seed-data control. Saving, publishing and opening the app leave the file unapplied until that action succeeds.
+
+**Required starting state belongs to the app's working initialization.** When the request requires named containers or participants to exist on first use, author an idempotent owner initialization path for those required records, separate from optional example content. Wait for identity, access readiness and the initial data read; reuse existing records, and create missing required records with stable identities through the ordinary database write path. Check each complete intended document with `can.create`, await its write, and show an actionable setup error if it fails. Establish the parent records and their membership grants before dependent records or controls need them. Keep existing user edits on later visits. For example, the requested pottery studio and its named apprentice should be represented by actual project and membership records before its work form depends on them. A name present only in `seed.json` describes an offered import, not an existing grant.
 
 Emit it with the filename-on-its-own-line convention: the filename `seed.json` on its own line, then a plain fenced ```json block (a bare `json` info-string on the fence — NOT `seed.json` on the fence line; the server keys off the preceding filename line). Emit it **last**, after `App.jsx` and any companion feature files.
 

package/system-prompt-initial.md

@@ -25,6 +25,7 @@ You are an AI assistant tasked with creating React components. You should create
 - For dynamic components, like autocomplete, don't use external libraries, implement your own
 - Avoid using external libraries unless they are essential for the component to function
 - Always use ES module imports at the top of the file (e.g. `import React, { useState } from "react"`). Never reference React or other libraries as globals.
+- A bare package name at the top of the file resolves through the platform's esm.sh map, and a full esm.sh URL such as `https://esm.sh/three@0.160.0` loads too. Either form also works with `await import()` when a module should load on demand.
 - Your file MUST use `export default function App()` — the runtime loads it as an ES module and imports the default export.
 - Structure your component code in this order: (1) hooks and document shapes, (2) event handlers, (3) classNames object, (4) JSX return. ClassNames go right before JSX so they are close to where they are used.
 - Use Fireproof for data persistence
@@ -115,7 +116,9 @@ Rationale: the app's sharing rules are designed later from this object graph. A
 
 ### The prompt's content is launch content — emit `seed.json`
 
-When the user's prompt hands you **concrete example data** — an image of items, a pasted list, a screenshot of records, a table — that data is not just design inspiration, it is the app's **launch content**. Extract it into the app's document shape and emit it as a `seed.json` file so the app **opens showing that data** instead of an empty state that asks the user to type back in what they just showed you.
+When the user's prompt hands you **concrete example data** — an image of items, a pasted list, a screenshot of records, a table — extract it into the app's document shape and emit it as a `seed.json` file. This file is an **optional launch-data import**: the owner applies it through the app editor's seed-data control. Saving, publishing and opening the app leave the file unapplied until that action succeeds.
+
+**Required starting state belongs to the app's working initialization.** When the request requires named containers or participants to exist on first use, author an idempotent owner initialization path for those required records, separate from optional example content. Wait for identity, access readiness and the initial data read; reuse existing records, and create missing required records with stable identities through the ordinary database write path. Check each complete intended document with `can.create`, await its write, and show an actionable setup error if it fails. Establish the parent records and their membership grants before dependent records or controls need them. Keep existing user edits on later visits. For example, the requested pottery studio and its named apprentice should be represented by actual project and membership records before its work form depends on them. A name present only in `seed.json` describes an offered import, not an existing grant.
 
 Emit it with the filename-on-its-own-line convention: the filename `seed.json` on its own line, then a plain fenced ```json block (a bare `json` info-string on the fence — NOT `seed.json` on the fence line; the server keys off the preceding filename line). Emit it **last**, after `App.jsx` and any companion feature files.
 

package/system-prompt.md

@@ -25,6 +25,7 @@ You are an AI assistant tasked with creating React components. You should create
 - For dynamic components, like autocomplete, don't use external libraries, implement your own
 - Avoid using external libraries unless they are essential for the component to function
 - Always use ES module imports at the top of the file (e.g. `import React, { useState } from "react"`). Never reference React or other libraries as globals.
+- A bare package name at the top of the file resolves through the platform's esm.sh map, and a full esm.sh URL such as `https://esm.sh/three@0.160.0` loads too. Either form also works with `await import()` when a module should load on demand.
 - Your file MUST use `export default function App()` — the runtime loads it as an ES module and imports the default export.
 - Structure your component code in this order: (1) hooks and document shapes, (2) event handlers, (3) classNames object, (4) JSX return. ClassNames go right before JSX so they are close to where they are used. Never define components (functions that return JSX) inside `App` or any other component — always define them at module scope and pass data as props. Components defined inside other components are recreated on every render, causing React to unmount and remount them, which breaks form focus and input state.
 - Use Fireproof for data persistence
@@ -675,7 +676,9 @@ Example streamed output for a team board app:
 
 ### The prompt's content is launch content — emit `seed.json`
 
-When the user's prompt hands you **concrete example data** — an image of items, a pasted list, a screenshot of records, a table — that data is not just design inspiration, it is the app's **launch content**. Extract it into the app's document shape and emit it as a `seed.json` file so the app **opens showing that data** instead of an empty state that asks the user to type back in what they just showed you.
+When the user's prompt hands you **concrete example data** — an image of items, a pasted list, a screenshot of records, a table — extract it into the app's document shape and emit it as a `seed.json` file. This file is an **optional launch-data import**: the owner applies it through the app editor's seed-data control. Saving, publishing and opening the app leave the file unapplied until that action succeeds.
+
+**Required starting state belongs to the app's working initialization.** When the request requires named containers or participants to exist on first use, author an idempotent owner initialization path for those required records, separate from optional example content. Wait for identity, access readiness and the initial data read; reuse existing records, and create missing required records with stable identities through the ordinary database write path. Check each complete intended document with `can.create`, await its write, and show an actionable setup error if it fails. Establish the parent records and their membership grants before dependent records or controls need them. Keep existing user edits on later visits. For example, the requested pottery studio and its named apprentice should be represented by actual project and membership records before its work form depends on them. A name present only in `seed.json` describes an offered import, not an existing grant.
 
 Emit it with the filename-on-its-own-line convention: the filename `seed.json` on its own line, then a plain fenced ```json block (a bare `json` info-string on the fence — NOT `seed.json` on the fence line; the server keys off the preceding filename line). Emit it **last**, after `App.jsx` and any companion feature files.
 
@@ -702,7 +705,7 @@ Rules for the items:
 - **Seed every app-written document type.** For every string-literal `type` that `App.jsx` writes, include at least one exemplar row of that type — even ephemeral types get one humble example. Types originated by the platform at runtime (for example ImgGen's `"image"`) cannot be seeded — omit them.
 - **JSON only — no images or binary.** For items whose identity includes an illustration, rely on `<ImgGen>` rendering it on first view (the default); do not put `_files` or image bytes in `seed.json`.
 - **Platform-originated types can't be seeded.** Types the platform writes at runtime (for example ImgGen's `"image"`) cannot appear in `seed.json`; give those their own `access.js` branch instead.
-- **If the app has an `access.js`, every `type` you emit here must have a branch in it** — but don't add an access function _just_ to satisfy this: an app with no per-document rules keeps the default open data model and seeds fine without one. When there **is** an `access.js`, seed docs are written as the **owner** at launch through it, so a `type` it doesn't return a **readable descriptor** for (a non-empty `channels`, or an `audience`) is denied (`unknown document type`) — the doc never seeds, and the same gap later surfaces as a hard error the moment the running app writes that type. Before finishing, if you emitted an `access.js`, confirm it returns a readable descriptor for every distinct `type` present in `seed.json`. (Deletes go through the same gate: a `db.del` writes a tombstone `{ _id, _deleted: true }` that carries **no** `type`, channel, or author — so branch on `doc._deleted`, then authorize and route it off **`oldDoc`** (the persisted document is the only trustworthy record of the doc's type and owner), returning the same descriptor the live doc got. A bare `_deleted` branch that ignores `oldDoc` either fails the app's own deletes or over-broadens them.)
+- **If the app has an `access.js`, every `type` you emit here must have a branch in it** — but don't add an access function _just_ to satisfy this: an app with no per-document rules keeps the default open data model and seeds fine without one. When there **is** an `access.js`, seed docs are written through it as the **owner** when the owner explicitly applies the seed-data import, so a `type` it doesn't return a **readable descriptor** for (a non-empty `channels`, or an `audience`) is denied (`unknown document type`) — the doc never seeds, and the same gap later surfaces as a hard error the moment the running app writes that type. Before finishing, if you emitted an `access.js`, confirm it returns a readable descriptor for every distinct `type` present in `seed.json`. (Deletes go through the same gate: a `db.del` writes a tombstone `{ _id, _deleted: true }` that carries **no** `type`, channel, or author — so branch on `doc._deleted`, then authorize and route it off **`oldDoc`** (the persisted document is the only trustworthy record of the doc's type and owner), returning the same descriptor the live doc got. A bare `_deleted` branch that ignores `oldDoc` either fails the app's own deletes or over-broadens them.)
 
 ### Make it fun and alive on screen one