rivet-design 0.9.2 → 0.9.4

package/dist/utils/skills/cursor-rules.js

@@ -1,9 +1,19 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.CURSOR_RULES_CONTENT = exports.CURSOR_RULES_FILENAME = exports.CURSOR_RULES_VERSION = void 0;
-exports.CURSOR_RULES_VERSION = 12;
+const shared_variants_protocol_1 = require("./shared-variants-protocol");
+exports.CURSOR_RULES_VERSION = 20;
 exports.CURSOR_RULES_FILENAME = 'rivet.mdc';
 const CURSOR_RULES_VERSION_MARKER = `rivet-rules-version: ${exports.CURSOR_RULES_VERSION}`;
+const AGENT_VARIANTS_SECTION = (0, shared_variants_protocol_1.buildAgentVariantsSection)({
+    inChatEmphasis: 'in chat',
+    step9: `**Run all leased code-gen items IN PARALLEL** via parallel tool calls in a single response. For each:
+   - Read \`input.briefBody\` and \`input.target\`
+   - Edit files in \`input.worktreePath\` (each variant has its own isolated worktree)
+   - Call \`report_variant_complete({ sessionId, workItemId, leaseId, attempt, status: 'succeeded' })\`. On failure, status \`'failed'\` with error description.`,
+    step11Suffix: `When \`hasChanges: true\`, you'll see a \`VariantChangeItem\` in \`changes[]\`.`,
+    nativeGenLabel: 'Task tool',
+});
 exports.CURSOR_RULES_CONTENT = `---
 description: Rivet — apply when the user says "open rivet", "open the visual editor", "create variants", "show me options for X", "build me X from scratch", "create a new Y app", or wants to make visual/UI changes or explore design directions
 alwaysApply: false
@@ -15,14 +25,7 @@ Two flows: the **visual editor** (point-and-click changes to a running web app)
 
 > Tip: type \`@rivet.mdc\` in chat to invoke this rule manually.
 
-## Picking the flow
-
-| User says | Flow |
-|---|---|
-| "open rivet", "make a visual change to X" | **Visual editor** (below) |
-| "create variants of X", "show me 3-5 options for X", "explore approaches to X" | **Agent variants** |
-| "build me a settings page from scratch", "add a feature for Y" | **Agent variants** (no \`target\`) |
-| "create a new Vite todo app", "scaffold a Next.js dashboard" | **Agent variants** (\`projectContext.kind=fresh\`) |
+${shared_variants_protocol_1.PICKING_THE_FLOW_TABLE}
 
 ## Visual Editor flow
 
@@ -30,8 +33,8 @@ Two flows: the **visual editor** (point-and-click changes to a running web app)
 
 1. Call \`detect_project\` — returns project info including \`framework\` and \`projectPath\`
 2. Call \`open_visual_editor({ projectPath, framework })\` — do NOT pass \`startPort\` or any port; the tool handles port selection automatically
-4. Tell the user: "Rivet is ready — make your visual changes and click 'Send to Cursor'."
-5. Call \`watch_for_changes({ sessionId })\` to wait for the user's changes.
+3. Tell the user: "Rivet is ready — make your visual changes and click 'Send to Cursor'."
+4. Call \`watch_for_changes({ sessionId })\` to wait for the user's changes.
 
 ## Watching and applying
 
@@ -58,74 +61,6 @@ When the user says they're done, call \`close_visual_editor({ sessionId })\`.
 
 ---
 
-## Agent Variants flow
-
-For requests like *"create variants of X"*, *"show me 3-5 options for the dropdown"*, *"build me a settings page"*, or *"create a new Vite todo app"* — DO NOT generate variants natively via parallel tool calls. Use this protocol so the user reviews design directions in chat, sees the actual code variants render in parallel, and picks based on the rendered code.
-
-### Step-by-step
-
-1. **Call \`propose_variants\`** with:
-   - \`prompt\`: the user's request verbatim
-   - \`count\`: 3-5 (default 4)
-   - \`target\` (optional): \`{ type: 'element'|'file'|'route', ref }\` — set this for refinement requests pinned to a specific element/file/route
-   - \`projectContext\` (optional):
-     - For brand-new projects: \`{ kind: 'fresh', workspacePath: '/abs/path', framework: 'vite'|'next'|'astro'|'remix' }\`
-     - Otherwise omit (defaults to existing project)
-
-   Response: \`{ sessionId, briefWorkItem }\`. The brief work item carries an \`input\` blob; you must run it next.
-
-2. **Run the brief work item using YOUR own LLM** — generate \`count\` design briefs as \`{ briefId, label, body }\`. Label is short (≤ 4 words). Body is 1-2 sentences describing the design direction. Do NOT call any Rivet tool; this is your LLM doing creative work.
-
-3. **Call \`report_variant_briefs\`** with the briefs, plus the \`workItemId\` and \`attempt: 0\`.
-
-3.5. **Ensure the Rivet visual editor is open.** If you haven't already opened it in this session, call \`detect_project\` then \`open_visual_editor({ projectPath, framework })\` now — DON'T wait for the user to ask. The user will need the iframe open to see variants render. If a session is already active (\`open_visual_editor\` returns a friendly error), just continue. Once the editor opens, the chip at the bottom-center of the iframe will show generation progress.
-
-4. **Show the briefs to the user IN CHAT** as a numbered list. Ask "Look good or want me to adjust any of them?" — DO NOT ask which one to pick. The pick happens AFTER they've seen the actual code.
-   Example:
-   > Here are 4 directions:
-   > 1. **Spring blur** — Apple-style spring with ambient blur and soft edges
-   > 2. **Linear sharp** — Crisp, fast, minimal padding
-   > 3. **Notion soft** — Rounded, calm, neutral palette
-   > 4. **Monoline editorial** — Tight typography, single accent color
-   > Look good, or want me to adjust any of them?
-
-5. **Wait for the user's reply.** Affirmative ("looks good", "go", "yep") → proceed with all briefs. Tweak request ("make #2 feel more like Linear") → call \`approve_variant_briefs\` with \`selections\` containing \`bodyOverride\` per brief, OR re-run the brief work item with new framing. Reject all → call \`cancel_variants\` and start over.
-
-6. **Call \`approve_variant_briefs({ sessionId, briefIds: [all chosen briefs] })\`**. Response: \`{ stage: 'work_items_ready', codeGenWorkItemIds: [...] }\` — one work item per approved brief.
-
-7. **Lease the work** with \`continue_variants({ sessionId, action: 'request_work' })\`. Response has \`leaseId\`, \`leaseTtlMs\`, and \`leasedWorkItems[]\` — one per approved brief (plus a preceding \`scaffold_base\` for fresh-project; lease scaffold first, succeed it, then re-lease for the code-gens).
-
-8. **Run all leased code-gen items IN PARALLEL** via parallel tool calls in a single response. For each:
-   - Read \`input.briefBody\` and \`input.target\`
-   - Edit files in \`input.worktreePath\` (each variant has its own isolated worktree)
-   - Call \`report_variant_complete({ sessionId, workItemId, leaseId, attempt, status: 'succeeded' })\`. On failure, status \`'failed'\` with error description.
-
-9. **When all variants are done (\`stage: 'ready'\` or \`'degraded'\`), tell the user the variants are ready and explain how to compare them.** Each variant has its own dev server running in an isolated worktree. The Rivet iframe shows a chip at the bottom-center: prev/label/next/check/dismiss. The user cycles between the live, running variants by clicking prev/next (the iframe re-mounts onto the variant's dev server in ~50ms via proxy retarget). When they like one, they click the check on the chip — that commits the variant.
-   Example reply:
-   > Variants are ready — open the Rivet preview and use the chip at the bottom of the iframe to cycle between them. Click the checkmark on the one you want and I'll apply it.
-
-   You do NOT need to print diffs in chat. The user picks visually in the iframe.
-
-10. **Watch for the user's pick.** Either:
-    a) Use \`watch_for_changes({ sessionId })\` (existing tool) which blocks until the user clicks the check on the chip, OR
-    b) Poll \`get_pending_changes({ sessionId })\` periodically.
-    When \`hasChanges: true\`, you'll see a \`VariantChangeItem\` in \`changes[]\`.
-
-11. **Apply the variant.** From the \`VariantChangeItem\` payload:
-    - \`payload.kind === 'diff'\` → \`git apply\` the unified diff against the user's project root
-    - \`payload.kind === 'new-project'\` → copy the contents of \`payload.sourceWorktreePath\` to \`destinationPath\`
-    Tell the user which variant you applied (use \`variantLabel\` from the change item).
-
-   You can also call \`commit_variant({ sessionId, variantId })\` yourself if the user expressed their pick in chat instead of clicking the chip ("go with #2", "the spring one") — same effect, just routed through the agent rather than the chip.
-
-### Rules
-
-- **Never** generate variants natively (Task tool, parallel tool calls, your own creative process) without going through \`propose_variants\` first.
-- Always pass the user's prompt verbatim — don't paraphrase.
-- Briefs are shown as PLAIN TEXT in chat. Do not render UI, open a browser tab, or fabricate a URL.
-- The user picks AFTER seeing the variants render LIVE in the iframe, not before. Step 4 is "look good or adjust the briefs?"; step 9 hands off to the iframe chip for visual cycling + commit.
-- Don't dump diffs in chat by default. The iframe chip is the primary review surface. If the user explicitly asks "show me the diffs", then print them.
-- Step 8 (parallel code-gen) is the only step where you fan out — every other step is one tool call.
-- For fresh-project, \`scaffold_base\` runs first; only after it succeeds are the \`code_gen\` items leasable. Loop \`continue_variants(action='request_work')\` after each transition.
+${AGENT_VARIANTS_SECTION}
 `;
 //# sourceMappingURL=cursor-rules.js.map

package/dist/utils/skills/cursor-rules.js.map

@@ -1 +1 @@
-{"version":3,"file":"cursor-rules.js","sourceRoot":"","sources":["../../../src/utils/skills/cursor-rules.ts"],"names":[],"mappings":";;;AAAa,QAAA,oBAAoB,GAAG,EAAE,CAAC;AAC1B,QAAA,qBAAqB,GAAG,WAAW,CAAC;AACjD,MAAM,2BAA2B,GAAG,wBAAwB,4BAAoB,EAAE,CAAC;AAEtE,QAAA,oBAAoB,GAAG;;;;OAI7B,2BAA2B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAuHjC,CAAC"}
+{"version":3,"file":"cursor-rules.js","sourceRoot":"","sources":["../../../src/utils/skills/cursor-rules.ts"],"names":[],"mappings":";;;AAAA,yEAGoC;AAEvB,QAAA,oBAAoB,GAAG,EAAE,CAAC;AAC1B,QAAA,qBAAqB,GAAG,WAAW,CAAC;AACjD,MAAM,2BAA2B,GAAG,wBAAwB,4BAAoB,EAAE,CAAC;AAEnF,MAAM,sBAAsB,GAAG,IAAA,oDAAyB,EAAC;IACvD,cAAc,EAAE,SAAS;IACzB,KAAK,EAAE;;;iKAGwJ;IAC/J,YAAY,EAAE,iFAAiF;IAC/F,cAAc,EAAE,WAAW;CAC5B,CAAC,CAAC;AAEU,QAAA,oBAAoB,GAAG;;;;OAI7B,2BAA2B;;;;;;;EAOhC,iDAAsB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAoCtB,sBAAsB;CACvB,CAAC"}

package/dist/utils/skills/shared-variants-protocol.d.ts

@@ -0,0 +1,23 @@
+/**
+ * Canonical brief format instruction — single source of truth.
+ * Imported by claude-skill.ts, cursor-rules.ts, and tools.ts so the
+ * wording can never silently diverge between agents.
+ */
+export declare const BRIEF_FORMAT_INSTRUCTION: string;
+/** Routing table — identical in every agent skill file */
+export declare const PICKING_THE_FLOW_TABLE = "## Picking the flow\n\n| User says | Flow |\n|---|---|\n| \"open rivet\", \"make a visual change to X\" | **Visual editor** (below) |\n| \"create variants of X\", \"show me 3-5 options for X\", \"explore approaches to X\" | **Agent variants \u2014 existing project** (`start_variants`, `mode='existing'`) |\n| \"build me a settings page from scratch\", \"add a feature for Y\" | **Agent variants \u2014 existing project** (`start_variants`, no `target`) |\n| \"create a new Vite todo app\", \"scaffold a fresh dashboard\" | **Agent variants \u2014 fresh project** (`start_variants`, `mode='zero_to_one'`) |\n| \"build me a dashboard like stripe.com\", \"use this URL as inspiration\" | **Agent variants \u2014 fresh, source-grounded** (`extract_inspiration_context` \u2192 `start_variants`, `mode='zero_to_one'`) |";
+/**
+ * Builds the full Agent Variants flow section, parameterised on the small
+ * number of lines that differ between Claude Code and Cursor.
+ */
+export declare function buildAgentVariantsSection(opts: {
+    /** "IN THIS CHAT" for Claude Code, "in chat" for Cursor */
+    inChatEmphasis: string;
+    /** Full text of the parallel code-gen step (mechanism differs per agent) */
+    step9: string;
+    /** Closing sentence of the watch step (how changes are surfaced differs slightly) */
+    step11Suffix: string;
+    /** Label used in the "never generate natively" rule, e.g. "Task sub-agents" or "Task tool" */
+    nativeGenLabel: string;
+}): string;
+//# sourceMappingURL=shared-variants-protocol.d.ts.map

package/dist/utils/skills/shared-variants-protocol.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"shared-variants-protocol.d.ts","sourceRoot":"","sources":["../../../src/utils/skills/shared-variants-protocol.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AACH,eAAO,MAAM,wBAAwB,QAGgF,CAAC;AAEtH,0DAA0D;AAC1D,eAAO,MAAM,sBAAsB,mzBAQoK,CAAC;AAExM;;;GAGG;AACH,wBAAgB,yBAAyB,CAAC,IAAI,EAAE;IAC9C,2DAA2D;IAC3D,cAAc,EAAE,MAAM,CAAC;IACvB,4EAA4E;IAC5E,KAAK,EAAE,MAAM,CAAC;IACd,qFAAqF;IACrF,YAAY,EAAE,MAAM,CAAC;IACrB,8FAA8F;IAC9F,cAAc,EAAE,MAAM,CAAC;CACxB,GAAG,MAAM,CAsGT"}

package/dist/utils/skills/shared-variants-protocol.js

@@ -0,0 +1,130 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.PICKING_THE_FLOW_TABLE = exports.BRIEF_FORMAT_INSTRUCTION = void 0;
+exports.buildAgentVariantsSection = buildAgentVariantsSection;
+/**
+ * Canonical brief format instruction — single source of truth.
+ * Imported by claude-skill.ts, cursor-rules.ts, and tools.ts so the
+ * wording can never silently diverge between agents.
+ */
+exports.BRIEF_FORMAT_INSTRUCTION = 'Label: ≤ 4 words, clear and descriptive title (e.g. "Soft spring blur", "Crisp linear motion"). ' +
+    'Body: exactly ONE sentence, ≤ 12 words — a single evocative descriptor of the direction ' +
+    '(e.g. "Apple-style spring physics with ambient blur and soft edges"). No bullet points, no lists, no line breaks.';
+/** Routing table — identical in every agent skill file */
+exports.PICKING_THE_FLOW_TABLE = `## Picking the flow
+
+| User says | Flow |
+|---|---|
+| "open rivet", "make a visual change to X" | **Visual editor** (below) |
+| "create variants of X", "show me 3-5 options for X", "explore approaches to X" | **Agent variants — existing project** (\`start_variants\`, \`mode='existing'\`) |
+| "build me a settings page from scratch", "add a feature for Y" | **Agent variants — existing project** (\`start_variants\`, no \`target\`) |
+| "create a new Vite todo app", "scaffold a fresh dashboard" | **Agent variants — fresh project** (\`start_variants\`, \`mode='zero_to_one'\`) |
+| "build me a dashboard like stripe.com", "use this URL as inspiration" | **Agent variants — fresh, source-grounded** (\`extract_inspiration_context\` → \`start_variants\`, \`mode='zero_to_one'\`) |`;
+/**
+ * Builds the full Agent Variants flow section, parameterised on the small
+ * number of lines that differ between Claude Code and Cursor.
+ */
+function buildAgentVariantsSection(opts) {
+    return `## Agent Variants flow
+
+For requests like *"create variants of X"*, *"show me 3-5 options for the dropdown"*, *"build me a settings page"*, or *"create a new Vite todo app"* — DO NOT generate variants natively via the ${opts.nativeGenLabel} or parallel tool calls. Use this protocol so the user sees variants render in parallel and picks based on the rendered code, not text descriptions ${opts.inChatEmphasis}.
+
+There are three sub-flows. Pick by project state:
+
+- **Existing project** → \`start_variants({ mode: 'existing' })\` — single-call kickoff, no in-chat approval gate.
+- **Fresh project (prompt-only)** → \`start_variants({ mode: 'zero_to_one' })\` — same single-call kickoff, server derives the destination path and opens the editor. Use this when the user just describes the app ("build me a Vite todo app", "make a Pomodoro timer").
+- **Fresh project (source-grounded, inspiration URLs)** → call \`extract_inspiration_context\` first, then \`start_variants({ mode: 'zero_to_one' })\` with the returned \`designContext\` + \`sourceContext\` forwarded as-is. Same single-call kickoff, no in-chat approval gate. Use this when the user gives a URL to mimic, attaches design context, or asks for "something like \\<site\\>".
+
+---
+
+### Sub-flow A: Existing project — use \`start_variants({ mode: 'existing' })\`
+
+1. **Call \`start_variants\`** with:
+   - \`prompt\`: the user's request verbatim
+   - \`briefs\`: an array of N \`{ label, body }\` objects, one per variant. \`briefs.length\` sets the variant count (3-5, default 4) — do NOT also pass \`count\`. ${exports.BRIEF_FORMAT_INSTRUCTION} Each brief MUST describe a DIFFERENT direction; do NOT copy the user's prompt verbatim into bodies. The UI renders \`label\` as the variant card title and \`body\` as its description, so this is what the user sees and compares.
+   - \`mode\`: \`'existing'\`
+   - \`target\` (optional): \`{ type: 'element'|'file'|'route', ref }\` — set this for refinement requests pinned to a specific element/file/route
+   - \`projectPath\` (optional): defaults to the MCP server's cwd; pass explicitly if the variants target a different directory
+
+   Response: \`{ sessionId, stage: 'work_items_ready', mode: 'existing', leaseId, leaseTtlMs, variants: [{ variantId, briefId, label, workItem }], project: { projectPath, framework }, visualEditor? }\`. The server already detected the framework, opened the Rivet visual editor (share \`visualEditor.url\` with the user immediately), and leased every variant — you do NOT need to call \`detect_project\`, \`open_visual_editor\`, or \`continue_variants(request_work)\`. Each \`variants[i].workItem\` carries \`input.worktreePath\` (where to edit files) and \`attempt\`.
+
+2. ${opts.step9}
+
+   **The FIRST LINE of each variant's output stream MUST be a ≤4-word label** (matching the \`BRIEF_FORMAT_INSTRUCTION\` shape — e.g. "Spring blur", "Linear sharp") so the user recognises the direction as variants stream in. The code body follows. Use the \`leaseId\` from the start_variants response on every \`report_variant_complete\` call.
+
+3. **When all variants reach \`stage: 'ready'\` or \`'degraded'\`, tell the user the variants are ready** and explain how to compare them. Each variant has its own dev server running in an isolated worktree. The Rivet iframe shows a chip at the bottom-center: prev/label/next/check/dismiss. The user cycles between the live, running variants by clicking prev/next (the iframe re-mounts onto the variant's dev server in ~50ms via proxy retarget). When they like one, they click the check on the chip — that commits the variant.
+
+   You do NOT need to print diffs in chat. The user picks visually in the iframe. You also do NOT need to call \`cancel_variant\` yourself — the iframe surfaces a cancel button per variant card, and the UI calls \`cancel_variant\` directly when the user clicks it.
+
+4. **Watch for the user's pick.** Either:
+   a) Use \`watch_for_changes({ sessionId })\` which blocks until the user clicks the check on the chip, OR
+   b) Poll \`get_pending_changes({ sessionId })\` periodically.
+   ${opts.step11Suffix}
+
+5. **Apply the variant.** From the \`VariantChangeItem\` payload:
+   - \`payload.kind === 'diff-applied'\` → the server already \`git apply\`'d the unified diff to the user's working tree (uncommitted). DO NOT re-apply — just acknowledge the variant and let the user review.
+   - \`payload.kind === 'diff'\` → (legacy) \`git apply\` the unified diff against the user's project root
+   - \`payload.kind === 'project-created'\` → the server already materialized and committed the destination project; continue from \`destinationPath\` (optionally run \`npm install\`)
+
+   Tell the user which variant was applied (use \`variantLabel\` from the change item). You can also call \`commit_variant({ sessionId, variantId, confirmedByUser: true })\` yourself if the user expressed their pick in chat ("go with #2", "the spring one") — same effect, just routed through the agent rather than the chip.
+
+---
+
+### Sub-flow B: Fresh project (prompt-only) — use \`start_variants({ mode: 'zero_to_one' })\`
+
+For brand-new projects the user describes from scratch ("build me a Vite todo app", "make a Pomodoro timer", "scaffold a kanban board"), use the same single-call kickoff. The server derives the destination directory, opens the editor on it, leases all variants, and returns everything in one response. No in-chat approval gate.
+
+1. **Call \`start_variants\`** with:
+   - \`prompt\`: the user's request verbatim
+   - \`briefs\`: an array of N \`{ label, body }\` objects, one per variant. \`briefs.length\` sets the variant count (3-5, default 4) — do NOT also pass \`count\`. ${exports.BRIEF_FORMAT_INSTRUCTION} Each brief MUST describe a DIFFERENT direction; do NOT copy the user's prompt verbatim into bodies. The UI renders \`label\` as the variant card title and \`body\` as its description.
+   - \`mode\`: \`'zero_to_one'\`
+   - \`framework\` (optional, defaults to \`'vite'\`)
+   - \`destinationParent\` (optional, absolute path; defaults to the user's home dir)
+
+   Response: \`{ sessionId, stage: 'work_items_ready', mode: 'zero_to_one', leaseId, leaseTtlMs, variants: [...], scaffoldBaseWorkItemId, destinationPath, visualEditor? }\`. The server opened the editor for you if \`visualEditor\` is present — share \`visualEditor.url\` with the user immediately ("Generating variants — watch here: <url>"). Skip the manual \`detect_project\` / \`open_visual_editor\` step (the destination project doesn't exist yet, so \`detect_project\` would fail). Each \`variants[i].workItem\` carries \`input\` and \`attempt\`.
+
+2. **From here, follow Sub-flow A steps 2-5** (parallel code-gen with first-line label using each variant's \`workItem.input.worktreePath\` and the shared \`leaseId\`, then ready, watch, apply). The work items are \`static_preview\` for zero-to-one — agent output must be passed to \`report_variant_complete\` as a JSON **object** with shape \`{ html: string, css?: string, js?: string }\` (self-contained HTML, no React/Vite-only imports). Do NOT stringify it — pass \`output: { html: "<!doctype html>..." }\`, not \`output: "{\\"html\\": \\"...\\"}"\`. On commit, the apply payload is \`payload.kind === 'project-created'\` — the server materialized the chosen variant to \`destinationPath\`.
+
+---
+
+### Sub-flow C: Fresh project (source-grounded) — \`extract_inspiration_context\` → \`start_variants({ mode: 'zero_to_one' })\`
+
+For brand-new projects where the user provides inspiration URLs ("build me a dashboard like stripe.com"), reference designs, or custom design context. Two calls total — no in-chat approval gate, no multi-step brief protocol.
+
+1. **Call \`extract_inspiration_context\`** with:
+   - \`prompt\`: the user's request verbatim
+   - \`count\`: the same value you plan to pass to \`start_variants\`
+   - \`urls\`: every inspiration URL the user provided
+   - \`preserveBrand\` (optional): true when the user wants brand colors/type/voice preserved exactly
+   - \`sourceArtifacts\` (optional): pasted briefs, screenshot notes, or written design context
+
+   Rivet fetches each URL server-side, extracts per-slot design context, and returns \`{ designContext, warnings, sourceContext }\`. Surface any \`warnings\` to the user (e.g. "couldn't fetch site X — proceeding without it").
+
+2. **Call \`start_variants\`** with:
+   - \`prompt\`, \`mode: 'zero_to_one'\`
+   - \`briefs\`: an array of N \`{ label, body }\` objects, one per variant. \`briefs.length\` sets the variant count (3-5, default 4) — do NOT also pass \`count\`. ${exports.BRIEF_FORMAT_INSTRUCTION} Bodies should diverge per slot based on the \`designContext\` from step 1; do NOT copy the user's prompt verbatim.
+   - \`framework\` (optional, defaults to \`'vite'\`)
+   - \`destinationParent\` (optional)
+   - \`designContext\`: the array returned by step 1
+   - \`sourceContext\`: the object returned by step 1 (forward as-is)
+
+   Same response shape as Sub-flow B — \`{ sessionId, stage: 'work_items_ready', leaseId, variants, destinationPath, visualEditor? }\`. No \`awaiting_briefs\`/\`awaiting_approval\`, no in-chat approval gate.
+
+3. **From here, follow Sub-flow B step 2** (parallel code-gen with the shared \`leaseId\`, then ready, watch, apply). The work items are \`static_preview\`, output is self-contained HTML/CSS/JS, and the apply payload is \`payload.kind === 'project-created'\`.
+
+---
+
+### Rules
+
+- **Never** generate variants natively (${opts.nativeGenLabel}, parallel tool calls, your own creative process) without going through \`start_variants\` first.
+- Always pass the user's prompt verbatim — don't paraphrase.
+- Prefer \`start_variants\` (with the matching \`mode\`) over the older \`propose_variants\` → \`report_variant_briefs\` → \`approve_variant_briefs\` chain. The unified call also handles \`detect_project\`, \`open_visual_editor\`, and \`continue_variants(request_work)\` server-side. The older tools and standalone \`detect_project\` / \`open_visual_editor\` stay registered for the Visual Editor flow (point-and-click changes without variants).
+- For source-grounded fresh projects, run \`extract_inspiration_context\` FIRST and forward its output into \`start_variants\` — don't try to pack inspiration URLs into \`start_variants\` directly without extraction.
+- Briefs (when shown via \`propose_variants\` legacy flow) are PLAIN TEXT in chat. Do not render UI, open a browser tab, or fabricate a URL.
+- The user picks AFTER seeing the variants render LIVE in the iframe, not before. Hand off to the iframe chip for visual cycling + commit.
+- Don't dump diffs in chat by default. The iframe chip is the primary review surface. If the user explicitly asks "show me the diffs", then print them.
+- Parallel code-gen is the only step where you fan out — every other step is one tool call.
+- **Per-variant cancel** is handled by the iframe — the UI calls \`cancel_variant({ sessionId, variantId })\` when the user clicks the cancel button on a card. You do not need to call this from the agent side. Use \`cancel_variants\` (plural) only to kill an entire session.
+- Quality bar is mandatory: avoid generic hero-card pages; preserve source depth, realistic workflow detail, and responsive interaction states unless the user explicitly asks for a lighter build.`;
+}
+//# sourceMappingURL=shared-variants-protocol.js.map

package/dist/utils/skills/shared-variants-protocol.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"shared-variants-protocol.js","sourceRoot":"","sources":["../../../src/utils/skills/shared-variants-protocol.ts"],"names":[],"mappings":";;;AAyBA,8DA+GC;AAxID;;;;GAIG;AACU,QAAA,wBAAwB,GACnC,kGAAkG;IAClG,0FAA0F;IAC1F,mHAAmH,CAAC;AAEtH,0DAA0D;AAC7C,QAAA,sBAAsB,GAAG;;;;;;;;uMAQiK,CAAC;AAExM;;;GAGG;AACH,SAAgB,yBAAyB,CAAC,IASzC;IACC,OAAO;;oMAE2L,IAAI,CAAC,cAAc,uJAAuJ,IAAI,CAAC,cAAc;;;;;;;;;;;;;;uKAc1N,gCAAwB;;;;;;;KAO1L,IAAI,CAAC,KAAK;;;;;;;;;;;KAWV,IAAI,CAAC,YAAY;;;;;;;;;;;;;;;;;uKAiBiJ,gCAAwB;;;;;;;;;;;;;;;;;;;;;;;;;;uKA0BxB,gCAAwB;;;;;;;;;;;;;;0CAcrJ,IAAI,CAAC,cAAc;;;;;;;;;oMASuI,CAAC;AACrM,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rivet-design",
-  "version": "0.9.2",
+  "version": "0.9.4",
   "description": "Local visual web development tool with AI-powered code modification",
   "main": "dist/index.js",
   "workspaces": [
@@ -13,7 +13,8 @@
     "rivet": "./bin/rivet.js"
   },
   "scripts": {
-    "build": "tsc && npm run build:ui && npm run build:bin",
+    "build": "tsc && npm run build:assets && npm run build:ui && npm run build:bin",
+    "build:assets": "mkdir -p dist/services/templates/designmd && cp src/services/templates/designmd/*.md dist/services/templates/designmd/",
     "build:ui": "cd src/ui && vite build",
     "build:bin": "mkdir -p bin && cp src/bin-template.js bin/rivet.js && chmod +x bin/rivet.js",
     "dev": "tsc --watch",
@@ -37,9 +38,8 @@
     "ratchet": "tsx scripts/ratchet.ts",
     "bench": "tsx benchmarks/bench.ts",
     "bench:run": "tsx benchmarks/runner.ts",
-    "bench:annotate": "tsx benchmarks/annotator.ts",
-    "bench:progress": "tsx benchmarks/progress.ts",
-    "bench:improve": "tsx benchmarks/improve.ts",
+    "bench:review": "tsx benchmarks/review/server.ts",
+    "bench:list": "tsx benchmarks/list.ts",
     "check:pre-commit": "npx lint-staged && yarn build && cd src/ui && yarn typecheck && cd ../.. && cd src/proxy && yarn build && cd ../.. && cd desktop/renderer && yarn build && cd ../..",
     "check:pre-push": "yarn test",
     "desktop": "yarn build && cd desktop && yarn dev",
@@ -170,7 +170,7 @@
     "access": "public"
   },
   "engines": {
-    "node": ">=16.0.0"
+    "node": ">=24.0.0"
   },
   "prettier": {
     "printWidth": 80,