@vibes.diy/prompts 14.1.54 → 14.1.56

package/llms/access.md

@@ -2,7 +2,7 @@
 
 This doc is in view because the app is getting its `access.js`: either the prompt names sharing, privacy, teams, members, roles, approval or who-can-see-what, or the platform is running the second pass every app gets — a first build drafts the records with their keys already in place (`creatorHandle` on the object, the parent id on each child, `authorHandle` on every record) and leaves the rules and the invite screen to this pass. Every app gets record rules unless the person asked for none in their own words, and the group shape taught below is the resting default. A person the ask names is let in by a record — see _A person the ask names is let in by a record_ below — so the build states the membership record's shape and the invite handler that writes it.
 
-**On a second pass over an app that already exists, this is a whole-app upgrade, applied in full.** Read `App.jsx` for the object type the app is about, the field that names its creator and the parent id its children carry; name the channels from those records; write the complete `access.js`; then change `App.jsx` to match it — the invite screen, the `can` gates, the object id on every child — keeping everything the app already does.
+**On a second pass over an app that already exists, the pass owes only what the rules need.** Read `App.jsx` for the object type, the field that names its creator and the parent id its children carry; name the channels from those records; write the complete `access.js`; then change `App.jsx` only where the rules require it — the invite screen, and any write surface not yet gated on `can` — with SEARCH/REPLACE edits. A file the rules do not touch is not emitted, and stays as it is.
 
 **Honest copy:** until `access.js` says otherwise, all app data is shared and world-readable, and the runtime, not your UI, decides access — `access.js` is where per-document write validation and channel-based read isolation live. Write UI copy that describes what the rules actually do.
 
@@ -267,7 +267,7 @@ This matters beyond the import itself. The app's `seed.json` stays in your conte
 
 So, in the same turn as the access edit and after it:
 
-- **Re-emit `seed.json` to fit the function.** Drop items whose `type` the function does not authorize, and add to each remaining item the field its branch actually routes on — the channel-determining id, the author handle, whatever an `audience` reads. A seed item missing that field is denied `unknown document type` when the owner applies the import, and the same gap resurfaces as a hard error the moment the running app writes that type.
+- **Re-emit `seed.json` only when it does not fit the function.** Drop items whose `type` the function does not authorize, and add to each remaining item the field its branch actually routes on — the channel-determining id, the author handle, whatever an `audience` reads. A seed item missing that field is denied `unknown document type` when the owner applies the import, and the same gap resurfaces as a hard error the moment the running app writes that type.
 - **Never add a branch to `access.js` just to admit a seed item.** A branch exists because the app writes that type. If a seed item's type appears nowhere in the app's own code, delete the item — do not widen the permission model to let example data through.
 - **Keep every explicit `_id` byte-identical.** Seed items that other items reference, and well-known singletons (`config:profile`, `settings:sharing`), carry an explicit `_id` that the app's code matches literally. Renaming one during a reconcile breaks that lookup in `App.jsx` and orphans any document an owner already imported, in a single edit. Keep the `key` slugs stable for the same reason — the platform derives idempotency from them.
 

package/package.json

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

package/system-prompt.md

@@ -92,7 +92,7 @@ The sandbox serves raw ES modules, so `App.jsx` can import local `.js`/`.jsx` fi
 - **Load Google Fonts with `&display=swap` (or `&display=optional`), never `&display=block`.** Append it to the Fonts URL so text paints immediately in a fallback instead of staying invisible for seconds on slow connections (flash of invisible text) — e.g. `https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap`.
 - **The bottom-right corner belongs to the platform — never pin your own control there.** The Vibes Switch (the logo) floats over every app in that corner, so a `fixed` element anchored to both `bottom` and `right` lands underneath it: no floating add/compose button, no chat bubble, no scroll-to-top disc in that spot. Anchor a floating action bottom-left or bottom-center instead, or fold it into the layout — a header button, or a full-width sticky bar (the platform already reserves scroll clearance below your app for one).
 
-**Every app gets an `access.js`** unless the person asked for none in their own words, and the access skill doc carries the emit format, placement, and worked examples whenever a turn writes one. When the instruction is the platform's second pass over an app drafted without one, that is a whole-app upgrade applied in full: read `App.jsx` for the records it already writes, emit the complete `access.js` first, then the `App.jsx` edits it needs — the invite screen, the `can` gates, the object id on every child. On any turn, emit `access.js` before any `App.jsx` edit that writes a doc type it gates. Gate every write surface on `useVibe(dbName).can` regardless of whether the app has an `access.js` yet. When the instruction names a person to let in, the build's part is the rule and the invite handler that write a membership record under an id fixed by the object and the handle, as the access skill doc's _A person the ask names is let in by a record_ shows — the record for that person is saved through that same shape once the rules are live, so the files carry the shape and the database carries the name.
+**Every app gets an `access.js`** unless the person asked for none in their own words, and the access skill doc carries the emit format, placement, and worked examples whenever a turn writes one. When the instruction is the platform's second pass over an app drafted without one, the pass owes the complete `access.js` first, then only the `App.jsx` SEARCH/REPLACE edits the rules need — the invite screen and any ungated write surface; every other file stays untouched, and `seed.json` is re-emitted only when it does not fit the rules — a record lacking a field they key on, a type they do not authorize, or a child ordered before the parent that grants its channel. On any turn, emit `access.js` before any `App.jsx` edit that writes a doc type it gates. Gate every write surface on `useVibe(dbName).can` regardless of whether the app has an `access.js` yet. When the instruction names a person to let in, the build's part is the rule and the invite handler that write a membership record under an id fixed by the object and the handle, as the access skill doc's _A person the ask names is let in by a record_ shows — the record for that person is saved through that same shape once the rules are live, so the files carry the shape and the database carries the name.
 
 **Keep `access.js` in step with the data model.** The app's current `access.js` and `seed.json` are always in view (the `APP_STATE` block). When an edit adds a new written doc `type` — or a field the rules key on — update `access.js` in the same reply so the new writes are allowed; an existing terminal branch that rejects unknown types will reject them at runtime.
 
@@ -747,7 +747,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` — put binaries in the Files tab instead.
 - **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.
-- **`access.js` decides which types a seed may carry — not the other way round.** Don't add an access function just to satisfy a seed: 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. So when you write or change an `access.js`, bring `seed.json` into line with it in the same turn: drop items whose type it doesn't authorize, add the field each branch routes on, and never add a branch just to admit a seed item. The full rule, including which ids must stay byte-identical, is in the `access.js` skill under _Reconciling `seed.json` when you write or change `access.js`_. (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.)
+- **`access.js` decides which types a seed may carry — not the other way round.** Don't add an access function just to satisfy a seed: 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. So when you write or change an `access.js`, bring `seed.json` into line with it in the same turn when it is out of line: drop items whose type it doesn't authorize, add the field each branch routes on, and never add a branch just to admit a seed item. The full rule, including which ids must stay byte-identical, is in the `access.js` skill under _Reconciling `seed.json` when you write or change `access.js`_. (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
 

package/themes/colorsets.js

@@ -361,7 +361,7 @@ the sandbox import map:
 
 \`\`\`js
 import { Button, Card, CardHeader, CardTitle, CardDescription, CardContent, CardFooter, Input, Textarea, Label, Badge, Tabs, TabsList, TabsTrigger, TabsContent, Separator, Skeleton, Table, TableHeader, TableBody, TableRow, TableHead, TableCell, Progress } from "@vibes.diy/look";
-import { Dialog, DialogTrigger, DialogContent, DialogHeader, DialogTitle, DialogDescription, DialogFooter, Sheet, SheetTrigger, SheetContent, Popover, PopoverTrigger, PopoverContent, Select, SelectTrigger, SelectContent, SelectItem, SelectValue, DropdownMenu, DropdownMenuTrigger, DropdownMenuContent, DropdownMenuItem, Tooltip, TooltipTrigger, TooltipContent, TooltipProvider } from "@vibes.diy/look/overlay";
+import { Dialog, DialogTrigger, DialogContent, DialogHeader, DialogTitle, DialogDescription, DialogFooter, Sheet, SheetTrigger, SheetContent, SheetHeader, SheetTitle, SheetDescription, SheetFooter, Popover, PopoverTrigger, PopoverContent, Select, SelectTrigger, SelectContent, SelectItem, SelectValue, DropdownMenu, DropdownMenuTrigger, DropdownMenuContent, DropdownMenuItem, Tooltip, TooltipTrigger, TooltipContent, TooltipProvider } from "@vibes.diy/look/overlay";
 \`\`\`
 
 Hand-rolling one the package already offers is a defect — anything that floats