@vibes.diy/prompts 9.4.0 → 9.4.2

package/llms/web-audio.md

@@ -272,7 +272,18 @@ External sync and drift
 - Latency budget: device `baseLatency` + your lookahead + any Worklet buffering.
 - Headphones recommended for monitoring to avoid acoustic feedback.
 
-## 6) Restraint — sound belongs on the core actions
+## 6) File layout — audio apps split, proactively
+
+Audio apps run long: an engine (context/graph/scheduler), a playable surface (keyboard, pads, step grid), transport/parameter controls, and a preset list each carry real code. A single-file synth blows past the ~500-line `App.jsx` split threshold almost immediately — so split from the start rather than after the fact. The sandbox serves raw ES modules: relative imports work, local `.css` imports do not (style stays in `App.jsx`).
+
+The shape that works (filenames illustrative — split by responsibility, matched to the app's actual surfaces, not by count):
+
+- `lib/audio-engine.js` — everything that touches `AudioContext`: the `unlockAudio()` gate, node graph construction, voice management, the lookahead scheduler. Plain module, no React; export functions/objects the UI calls. Keeping the engine React-free is what makes gesture-synchronous unlock (§1) and clean scheduling (§4) easy — no re-render can rebuild the graph.
+- `components/Keyboard.jsx` (or `StepGrid.jsx`, `Pads.jsx`) — the playable surface; calls engine functions from `pointerdown`-family handlers.
+- `components/TransportControls.jsx`, `components/PresetList.jsx` — parameter knobs/sliders and preset browsing; presets live in the database, the engine consumes plain parameter objects.
+- `App.jsx` — layout, styling, database wiring; imports the above (`import { createEngine } from "./lib/audio-engine.js"`).
+
+## 7) Restraint — sound belongs on the core actions
 
 - No sound on every keystroke, hover, or list render — that reads as noise, not life.
 - Never autoplay audio on load; playback must follow a user gesture (the `unlockAudio()` gate in §1).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibes.diy/prompts",
-  "version": "9.4.0",
+  "version": "9.4.2",
   "type": "module",
   "main": "./index.js",
   "description": "",
@@ -24,9 +24,9 @@
   "license": "Apache-2.0",
   "dependencies": {
     "@adviser/cement": "~0.5.34",
-    "@vibes.diy/call-ai-v2": "^9.4.0",
-    "@vibes.diy/identity": "^9.4.0",
-    "@vibes.diy/use-vibes-types": "^9.4.0",
+    "@vibes.diy/call-ai-v2": "^9.4.2",
+    "@vibes.diy/identity": "^9.4.2",
+    "@vibes.diy/use-vibes-types": "^9.4.2",
     "arktype": "~2.2.3",
     "json-schema-faker": "~0.6.2"
   },

package/system-prompt-initial-oneshot.md

@@ -132,7 +132,8 @@ seed.json
 Rules for the items:
 
 - Every item carries a short immutable **`key`** slug (`"alert"`, `"setname"`), **unique within its database's array**. The key is the item's identity across codegen turns — the platform derives the document id and idempotency from it, so **do NOT invent `_id`s or write any dedupe logic**. Re-emitting an unchanged `seed.json` on a later turn is a no-op; changing an item's content updates that one document.
-- Set `_id` explicitly **only** for a well-known singleton (a `config:setname` settings doc); the `key` is still required.
+- Set `_id` explicitly in exactly two cases — a well-known singleton (a `config:setname` settings doc), or an item that other seed items reference by id (next rule); every other item gets no `_id`. The `key` is still required either way.
+- **Cross-references need an explicit `_id`.** Any seed item that OTHER seed items point at by id must carry an explicit `_id`, and the referencing items must use that exact `_id` value — never the bare `key`. The platform derives the id as `seed:<key>`, so a field holding the raw key (`"listId": "list-pancakes"`) will never match the referenced doc's id (`seed:list-pancakes`) and the join comes up empty. Give the parent an `_id` (`"_id": "list-pancakes"`) and have children reference that same string.
 - Multi-db apps get one array per db; use the exact db names from `App.jsx`.
 - **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`.

package/system-prompt-initial.md

@@ -134,7 +134,8 @@ seed.json
 Rules for the items:
 
 - Every item carries a short immutable **`key`** slug (`"alert"`, `"setname"`), **unique within its database's array**. The key is the item's identity across codegen turns — the platform derives the document id and idempotency from it, so **do NOT invent `_id`s or write any dedupe logic**. Re-emitting an unchanged `seed.json` on a later turn is a no-op; changing an item's content updates that one document.
-- Set `_id` explicitly **only** for a well-known singleton (a `config:setname` settings doc); the `key` is still required.
+- Set `_id` explicitly in exactly two cases — a well-known singleton (a `config:setname` settings doc), or an item that other seed items reference by id (next rule); every other item gets no `_id`. The `key` is still required either way.
+- **Cross-references need an explicit `_id`.** Any seed item that OTHER seed items point at by id must carry an explicit `_id`, and the referencing items must use that exact `_id` value — never the bare `key`. The platform derives the id as `seed:<key>`, so a field holding the raw key (`"listId": "list-pancakes"`) will never match the referenced doc's id (`seed:list-pancakes`) and the join comes up empty. Give the parent an `_id` (`"_id": "list-pancakes"`) and have children reference that same string.
 - Multi-db apps get one array per db; use the exact db names from `App.jsx`.
 - **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`.

package/system-prompt.md

@@ -436,15 +436,24 @@ docs in your database, and never build follow UI state machines.
   `requestFollowersAccess(): Promise<void>` (the preflight consent path). For a normal app,
   `followersEnabled` is ON by default — sharing with followers just works, so DON'T gate your
   audience UI on it or make users flip a switch first. It is `false` only for the minority:
-  the viewer explicitly turned this app off, chose a never-share standing policy, or the app is
-  marked privacy-sensitive (a diary, a personal tracker), where sharing stays off until a
-  deliberate opt-in. Show a small "open to followers so friends can see your picks" callout
+  the viewer explicitly turned this app off, chose a never-share standing preference, or the app
+  is marked privacy-sensitive (a diary, a personal tracker), where sharing stays off until a
+  deliberate opt-in. Show a small "open to followers so followers can see your picks" callout
   wired to `requestFollowersAccess()` ONLY when `!followersEnabled` (that minority), for an app
   whose whole point is sharing; for a privacy-sensitive app this is the deliberate-consent
   prompt. `requestFollowersAccess()` resolves quietly with no state change (including when the
   app is already enabled, or the viewer already declined/opted out) — never call it in a loop,
   on every render, or more than once per explicit user action. Don't invent a callout an app's
   own privacy doesn't call for.
+- For an explicit visibility control (a settings toggle inside your app), `useSocial()` returns
+  `visibility: "followers" | "private"` (read-only: the effective level for THIS viewer/app —
+  `followersEnabled` is just `visibility !== "private"`) and
+  `setVisibility(level): Promise<void>` to change it. `"followers"` means followers can see;
+  `"private"` turns this app's sharing off for the viewer. Call `setVisibility` only from an
+  explicit user action (a toggle), then re-render from `visibility` — it resolves after the
+  change lands. (`"public"`/world-readable is not settable yet; don't offer it.) Most apps don't
+  need this — the default already shares with followers; reach for it only when the app's own UX
+  wants an in-app privacy switch.
 - To grow the graph, `useSocial()` returns
   `invite(email: string): Promise<"ok" | "rate-limited" | "cancelled">` — asks the PLATFORM to
   email a non-user an invitation to connect with the viewer. The platform shows a consent prompt,
@@ -634,7 +643,8 @@ seed.json
 Rules for the items:
 
 - Every item carries a short immutable **`key`** slug (`"alert"`, `"setname"`), **unique within its database's array**. The key is the item's identity across codegen turns — the platform derives the document id and idempotency from it, so **do NOT invent `_id`s or write any dedupe logic**. Re-emitting an unchanged `seed.json` on a later turn is a no-op; changing an item's content updates that one document.
-- Set `_id` explicitly **only** for a well-known singleton (a `config:setname` settings doc); the `key` is still required.
+- Set `_id` explicitly in exactly two cases — a well-known singleton (a `config:setname` settings doc), or an item that other seed items reference by id (next rule); every other item gets no `_id`. The `key` is still required either way.
+- **Cross-references need an explicit `_id`.** Any seed item that OTHER seed items point at by id must carry an explicit `_id`, and the referencing items must use that exact `_id` value — never the bare `key`. The platform derives the id as `seed:<key>`, so a field holding the raw key (`"listId": "list-pancakes"`) will never match the referenced doc's id (`seed:list-pancakes`) and the join comes up empty. Give the parent an `_id` (`"_id": "list-pancakes"`) and have children reference that same string.
 - Multi-db apps get one array per db; use the exact db names from `App.jsx`.
 - **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`.