@vibes.diy/prompts 14.3.81 → 14.3.83

package/llms/access.md

@@ -122,6 +122,8 @@ if (doc.type === "entry") {
 }
 
 throw { forbidden: "unknown document type" }; // every access.js ends by denying what it does not know
+
+// Summary: each person's workout log is theirs, shared with the buddies they pick and, once they say so, with their followers. Every record carries its writer's handle in authorHandle, and a share names the buddy in buddyHandle.
 ```
 
 ### Private generated images and published snapshots
@@ -154,6 +156,8 @@ function posterMedia(doc, oldDoc, user) {
   return { channels: [channel], grant: { users: { [doc.authorHandle]: [channel] } } };
 }
 export { posterMedia as "media:posters" };
+
+// Summary: each person's generated poster images are theirs alone to see, and every version stays as it was made. A media record carries its writer's handle in authorHandle and names its poster in hostDocId.
 ```
 
 Each writer's versions are private even if another writer guesses the same
@@ -238,6 +242,8 @@ export function notes(doc, oldDoc, user, ctx) {
   const mine = `user:${user.userHandle}`;
   return { channels: [mine], grant: { users: { [user.userHandle]: [mine] } } };
 }
+
+// Summary: members of a channel read, post and edit everything in its chat, and each person's notes are theirs alone. A chat record names its channel in channelId.
 ```
 
 Databases without a matching named export fall through to `export default` if one exists. If there is no default export either, the database uses the default app-level permissions (no access function).
@@ -251,6 +257,8 @@ function crewChat(doc, oldDoc, user, ctx) {
   return { channels: [doc.channelId] };
 }
 export { crewChat as "crew-chat" };
+
+// Summary: members of a channel read, post and edit everything in its crew chat. A record names its channel in channelId.
 ```
 
 ### Catch-all with `export default`
@@ -270,6 +278,8 @@ export default function (doc, oldDoc, user, ctx) {
   const mine = `user:${user.userHandle}`;
   return { channels: [mine], grant: { users: { [user.userHandle]: [mine] } } };
 }
+
+// Summary: members of a channel read, post and edit everything in its chat, and everything else each person writes is theirs alone. A chat record names its channel in channelId.
 ```
 
 This is especially useful when an app has many databases.
@@ -302,7 +312,7 @@ One trap: applying a release's `seed.json` is the **platform** writing, not the
 
 The **placement** of `access.js` depends on which turn shape you are in — one-shot whole-app generation vs. incremental scaffold/follow-up edits. Follow the subsection that matches your turn; the other one's ordering is wrong for you and will strand writes.
 
-**Variant-neutral rules (always):** write `access.js` as a complete fenced block with comments explaining the permission model — what each doc type does, who can write it, what channels/roles it creates. **Never put access function code inside an `App.jsx` block** — it will overwrite the React component; the path heading (e.g. `access.js` vs `App.jsx`) is how the system knows which file to write. Whatever the turn shape, `App.jsx` gates its write surfaces on `useVibe(dbName).can` — the same rules this access function enforces.
+**Variant-neutral rules (always):** write `access.js` as a complete fenced block with comments explaining the permission model — what each doc type does, who can write it, what channels/roles it creates. End the file with its `// Summary:` line (see _The `// Summary:` line_ below). **Never put access function code inside an `App.jsx` block** — it will overwrite the React component; the path heading (e.g. `access.js` vs `App.jsx`) is how the system knows which file to write. Whatever the turn shape, `App.jsx` gates its write surfaces on `useVibe(dbName).can` — the same rules this access function enforces.
 
 **One-shot generation (the whole app in one full-file block):** emit `access.js` as the **last file of the turn** — after the complete `App.jsx` and any companion feature files. You are NOT emitting incremental `SEARCH`/`REPLACE` edits here — write the finished files in full. The worked examples below show the access-function shapes; ignore any edit-by-edit cadence in them and emit the access function as one complete block.
 
@@ -330,12 +340,24 @@ export function chat(doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: members of a channel read and post its messages, and each author edits their own. A message carries its writer's handle in userHandle and its channel in channelId.
 ```
 
 `ctx.requireAccess(channel)` gates on channel **membership** (a `grant.users`/`grant.roles` grant), NOT on `grant.public`, which is read-only — so a channel anyone signed-in should post to must **not** gate writes on `requireAccess` (it would block every non-owner); just check the author and route the doc. Reserve `requireAccess` for members-only channels whose writers you granted membership. For writes that need no sign-in at all ("anyone can sign/submit"), return `allowAnonymous: true` instead of throwing on `!user`. A grant/member/role doc must also return `channels` (route it to an owner-readable admin channel like `["admin:grants"]`) — a channel-less result is rejected as "unreadable write". On updates, keep ownership immutable (`if (oldDoc && doc.<authorField> !== oldDoc.<authorField>) throw`, where `<authorField>` is your doc's author field — `authorHandle`/`userHandle`/`senderHandle`) and let the author edit their own (as `chat.message` above shows). Pictures other viewers make for a shared doc are their own records in the media database, so an author-only update keeps every picture flowing.
 
 **A follow-up edit that adds a NEW doc type updates `access.js` FIRST.** The app runs live while your edits stream in, and writes are enforced against the access.js that was in force before this turn until the whole turn completes — so a `db.put` of a doc type the old function rejects fails immediately (`unknown document type`), even though your access.js update lands later in the same reply. Emit the access.js edit adding the new type's branch before the App.jsx edits that write it. And never fire-and-forget background writes of a newly added type: gate seed/auto-write effects on `useVibe(dbName)` — `if (!ready || !can.create(sampleDoc).ok) return;` with `ready`/`can` in the effect deps, checking a representative sample of **each** doc type the effect writes — so a not-yet-allowed write is skipped quietly instead of surfacing rejection errors the user didn't cause.
 
+### The `// Summary:` line — the rules in one plain sentence
+
+Every `access.js` ends with one plain-language summary line after the function: the file closes with a comment starting `// Summary:`, and nothing follows it (a long one may wrap onto further `//` lines). In one or two sentences in the app's own nouns, it says what people can do — who can see and change what — and what a record needs to be admitted: the field that carries its writer's handle, and the state a new record starts in:
+
+```js partial
+// Summary: each person's recipes are theirs alone; a friend added to a recipe can read it. A recipe carries its writer's handle in authorHandle; orders start with status "new".
+```
+
+Name each field exactly as the function reads it — the line is how the person, and the platform, read the rules at a glance. Whenever this turn changes the function, rewrite the summary in the same block so it describes the rules as they now stand. The seed's records follow the line: each one carries `"@owner"` in the writer field it names and starts in the state it names. Every worked example below ends with its own.
+
 ### Reconciling `seed.json` when you write or change `access.js`
 
 An app usually gets its `seed.json` on an earlier turn than its `access.js`. So when you add or change an access function, you are almost always meeting a seed file that was written before any of these rules existed — **and the seed is yours to bring into line, not the other way round.** The access function is the constraint; the seed is a sample of the data. When a sample violates a constraint, change the sample.
@@ -348,6 +370,8 @@ So, in the same turn as the access edit and after it:
 - **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.
 
+**Write the seed as its writer: the owner.** Applying the import writes every record as the owner, with `user = { userHandle: <the owner's handle>, isOwner: true }`, and stamps nothing on the record. So a field a branch compares to the writer — `authorHandle`, `creatorHandle`, `hostHandle` — carries `"@owner"`, and the platform fills in the handle of whoever applies the seed: `{ "key": "pancakes", "type": "recipe", "title": "Sunday pancakes", "authorHandle": "@owner" }` is the owner's own record in the app you build and in every remix of it. Write the marker as the whole value, exactly `"@owner"`. Where the rules set the state a new record starts in ("orders start as new"), each seeded record starts in that state.
+
 **Order the seed so the function admits it.** Applying the import runs every document through `access.js` as the owner's first write, in file order, so the seed passes its own rules or it does not arrive at all. A document whose branch reads a channel off a parent needs that parent earlier in the file, granting the channel the child will be routed into; a type the function routes on a field carries that field on every item. A task list seeded as `{ type: "task", listId: "main" }` needs a `list` item with `_id: "main"` above it whose branch grants `list:main` — without it every task is refused on the first apply, and the app opens empty with nothing on screen to say why.
 
 If the reconcile removes every item, **still emit `seed.json`, containing `{}`**. Omitting the file does NOT delete it — a file your turn does not touch is carried forward from the previous version verbatim, so leaving `seed.json` out preserves exactly the stale, unauthorized seed you were removing. An empty object is a valid seed and replaces it.
@@ -388,6 +412,8 @@ export function wall(doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: the owner opens channels everyone can read, and anyone signed in posts to them and edits their own posts. A post carries its writer's handle in authorHandle and its channel in channelId.
 ```
 
 ### Worked example — per-object collaboration with join request
@@ -414,6 +440,8 @@ export function board(doc, oldDoc, user, ctx) {
   if (oldDoc && oldDoc.boardId !== doc.boardId) throw { forbidden: "item stays on its board" };
   return { channels: [channel] };
 }
+
+// Summary: anyone signed in writes a board record and joins that board, members share it with a friend and add and edit everything on it, and anyone signed in can ask to join. A board record keeps its first author, and every record names its board in boardId.
 ```
 
 `ctx.requireAccess(channel)` gates on **membership** (a `grant.users`/`grant.roles` grant), not `grant.public` (read-only) — so an open feed anyone signed-in may post to must not gate writes on it; check the author and route the doc. For writes needing no sign-in ("anyone can sign/submit"), return `allowAnonymous: true` instead of throwing on `!user`. A grant/share/request doc must also return `channels` — a channel-less result is rejected. On updates, keep ownership immutable (`doc.authorHandle !== oldDoc.authorHandle` → throw) and let the author edit their own (as `wall.post` above shows). Pictures other viewers make for a shared doc are their own records in the media database, so an author-only update keeps every picture flowing.
@@ -442,6 +470,8 @@ export function notes(doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: each person's notes are theirs alone, private from the first one they write. A note carries its writer's handle in authorHandle.
 ```
 
 Every item a visitor creates lands on their own `user:<handle>` channel, private to them from the first load. Pair it with a small "Only you can see this" cue near their content. This is the shape whenever the app is one person's own collection kept for themselves — the whole space is one private channel, no membership step in the way. The word "personal" routes on what the data is FOR: a personal tracker/journal/notes app is this private per-user shape, while a personal blog or portfolio exists to be READ — that one is the publication shape below (public read + author-owned posts, a roster of one), not a private channel.
@@ -487,6 +517,8 @@ export function pieces(doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: anyone signed in proposes pieces everyone can see, and each person's practice is their own — on the leaderboard or shared with one buddy, as they choose. Every record carries its writer's handle in authorHandle, and tracking records and check-ins name their piece in pieceId.
 ```
 
 The leaderboard is just the access model: read the public `track:` channels and sum them; each viewer additionally sees their own tallies and any buddy who granted them in. A practice log whose owner **asked to keep it to themselves** is instead the per-visitor shape shown above: every visitor's pieces and check-ins on their single `user:${user.userHandle}` channel, self-granted and private to them.
@@ -626,6 +658,8 @@ export function announcements(doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: the owner opens channels everyone can read and names who posts; posters write in their channels and edit their own posts. A post carries its writer's handle in authorHandle.
 ```
 
 App.jsx — `useVibe().can` gates every write surface (posts AND owner-only management); `access.hasChannel()` reflects display-only membership:
@@ -771,6 +805,8 @@ export function chat(doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: the owner opens channels everyone can read, and anyone signed in posts in them and edits their own posts. A post carries its writer's handle in authorHandle.
 ```
 
 App.jsx — `access.hasChannel()` filters which channels are visible (display); `useVibe().can` gates the write surface:
@@ -842,6 +878,8 @@ export default function (doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: each person makes their own lists and shares one with a friend, and everyone on a list adds and edits its items. A list carries its writer's handle in author, and items and shares name their list in listId.
 ```
 
 To invite someone who isn't a member yet without knowing their handle in advance, invert the flow with a request doc: a `request` type takes **no** `ctx.requireAccess` (any signed-in user may create one — their handle is `user.userHandle`, unforgeable) and routes to the list channel `ch(doc.listId)`, where current members read it (the requester can't read their own request back — they aren't a member yet — which is fine; they just wait to be granted). A member then writes the `share` above to approve.
@@ -944,6 +982,8 @@ export function boards(doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: everyone signed in has their own boards, a board's creator lets a friend in with a member record, and members add and edit every card on it. A board carries its creator's handle in creatorHandle, a card names its board in boardId, and a member record names the friend in userHandle and its writer in addedBy.
 ```
 
 App.jsx — the invite surface is `HandleInput` plus one `member` write, shown to whoever the access fn would accept:
@@ -1116,6 +1156,8 @@ export function chat(doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: a channel's owner names its members, and members read and post messages and invite others in. A channel carries its owner in ownerHandle, a message its writer in userHandle, and an invite its sender in senderHandle.
 ```
 
 This single access function handles three document types: **channel-meta** — owner creates a channel and grants access to listed members, **message** — only the author can post, must already have channel access, **channel-invite** — any channel member can invite others; deleting the invite revokes the grant.
@@ -1186,6 +1228,8 @@ export function survey(doc, oldDoc, user, ctx) {
 
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: anyone, signed in or not, submits responses that stay as written; the owner sets up the survey so the feedback team reads the responses, and the feedback team publishes the final results for everyone.
 ```
 
 Key patterns: `allowAnonymous: true` on survey-response lets unauthenticated visitors submit, `grant.public` on final-results makes them readable by any member without a specific channel grant, and the **singleton grant doc** pattern (survey-config) wires role-to-channel access in one place.
@@ -1243,6 +1287,8 @@ export function guestbook(doc, oldDoc, user, ctx) {
   }
   throw { forbidden: "unknown document type" };
 }
+
+// Summary: anyone, signed in or not, signs the guestbook and everyone reads it; each entry stays as it was signed.
 ```
 
 In `App.jsx`, gate the form on `useVibe("guestbook").can.create({ type: "entry" }).ok` (true for anon here) and stamp `authorHandle: me?.userHandle` only when signed in. Without `allowAnonymous: true` the runtime rejects the null-user write even though the function didn't throw — so the guestbook would silently require login, the exact miss to avoid.

package/llms/blockly.d.ts

@@ -0,0 +1,2 @@
+import type { LlmConfig } from "./types.js";
+export declare const blocklyConfig: LlmConfig;

package/llms/blockly.js

@@ -0,0 +1,59 @@
+export const blocklyConfig = {
+    name: "blockly",
+    label: "Blockly",
+    description: "Block editors built with Blockly, where people snap pieces together instead of typing code. " +
+        "Two audiences, one recipe. Teaching code: Scratch-like coding playgrounds for kids and " +
+        "beginners, drag-and-drop page builders with a live preview and Code Peek, turtle and robot " +
+        "sequences. Business logic edited by the people who own it: no-code rules engines (credit " +
+        "scoring, fraud flags, approval thresholds, compliance checks, discount and pricing rules, " +
+        "eligibility, routing and triage) whose blocks compile to a JSON rule tree the app evaluates in " +
+        "the browser and in backend.js; CRM, ERP and ticket workflow automations (when a record arrives, " +
+        "if it matches, tag it, assign it, send it to a queue, schedule a follow-up); low-code form and " +
+        "screen builders; device, robot and conveyor step sequences; QA, test-case and integration " +
+        "scripts (steps, expectations, mock responses). Covers the one pinned esm.sh ?bundle import, " +
+        "custom blocks with connection checks as the type system, JSON toolboxes with shadow defaults, " +
+        "custom CodeGenerator output (HTML, JSON, steps) and the standard javascriptGenerator run in a " +
+        "sandboxed iframe with step highlighting, workspace JSON saved to Fireproof with autosave, a " +
+        "Blockly theme from the app's tokens, locales via setLocale, and the zelos renderer on phones. " +
+        "blockly, scratch, blocks, block editor, visual programming, drag and drop code, no-code, low-code, " +
+        "rules engine, rule builder, decision rules, business rules, policy builder, workflow builder, " +
+        "automation builder, if-this-then-that, approval flow, test builder, puzzle pieces",
+    cues: [
+        "blockly",
+        "scratch",
+        "scratch-like",
+        "block editor",
+        "block coding",
+        "blocks editor",
+        "visual programming",
+        "visual scripting",
+        "drag-and-drop blocks",
+        "drag and drop blocks",
+        "snap together",
+        "snap blocks",
+        "puzzle pieces",
+        "rules builder",
+        "rule builder",
+        "rules engine",
+        "business rules",
+        "decision rules",
+        "policy builder",
+        "approval rules",
+        "scoring rules",
+        "fraud rules",
+        "compliance rules",
+        "eligibility rules",
+        "routing rules",
+        "no-code",
+        "low-code",
+        "workflow builder",
+        "automation builder",
+        "if this then that",
+        "trigger and action",
+        "test builder",
+        "test script builder",
+        "robot program",
+        "program the robot",
+    ],
+};
+//# sourceMappingURL=blockly.js.map

package/llms/blockly.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"blockly.js","sourceRoot":"","sources":["../../jsr/llms/blockly.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,aAAa,GAAc;IACtC,IAAI,EAAE,SAAS;IACf,KAAK,EAAE,SAAS;IAChB,WAAW,EACT,8FAA8F;QAC9F,yFAAyF;QACzF,6FAA6F;QAC7F,2FAA2F;QAC3F,4FAA4F;QAC5F,iGAAiG;QACjG,kGAAkG;QAClG,iGAAiG;QACjG,4FAA4F;QAC5F,8FAA8F;QAC9F,gGAAgG;QAChG,gGAAgG;QAChG,8FAA8F;QAC9F,gGAAgG;QAChG,qGAAqG;QACrG,gGAAgG;QAChG,mFAAmF;IACrF,IAAI,EAAE;QACJ,SAAS;QACT,SAAS;QACT,cAAc;QACd,cAAc;QACd,cAAc;QACd,eAAe;QACf,oBAAoB;QACpB,kBAAkB;QAClB,sBAAsB;QACtB,sBAAsB;QACtB,eAAe;QACf,aAAa;QACb,eAAe;QACf,eAAe;QACf,cAAc;QACd,cAAc;QACd,gBAAgB;QAChB,gBAAgB;QAChB,gBAAgB;QAChB,gBAAgB;QAChB,eAAe;QACf,aAAa;QACb,kBAAkB;QAClB,mBAAmB;QACnB,eAAe;QACf,SAAS;QACT,UAAU;QACV,kBAAkB;QAClB,oBAAoB;QACpB,mBAAmB;QACnB,oBAAoB;QACpB,cAAc;QACd,qBAAqB;QACrB,eAAe;QACf,mBAAmB;KACpB;CAMF,CAAC"}