rivet-design 0.8.7 → 0.9.2

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

@@ -1,20 +1,31 @@
 "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 = 7;
+exports.CURSOR_RULES_VERSION = 12;
 exports.CURSOR_RULES_FILENAME = 'rivet.mdc';
 const CURSOR_RULES_VERSION_MARKER = `rivet-rules-version: ${exports.CURSOR_RULES_VERSION}`;
 exports.CURSOR_RULES_CONTENT = `---
-description: Rivet visual editor — apply when the user says "open rivet", "open the visual editor", or wants to make visual/UI changes to their web app
+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
 ---
 <!-- ${CURSOR_RULES_VERSION_MARKER} -->
-# Rivet Visual Editor
+# Rivet
 
-Use these tools to make visual changes to a running web app and apply them to source code.
+Two flows: the **visual editor** (point-and-click changes to a running web app) and the **agent-variants flow** (explore N parallel design directions before committing).
 
 > 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\`) |
+
+## Visual Editor flow
+
 ## Starting a session
 
 1. Call \`detect_project\` — returns project info including \`framework\` and \`projectPath\`
@@ -44,5 +55,77 @@ When the user says they're done, call \`close_visual_editor({ sessionId })\`.
 - **Never auto-commit** after applying visual changes — let the user decide
 - Always stop and ask before re-entering the watch loop
 - The dev server stays running after \`close_visual_editor\`
+
+---
+
+## 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.
 `;
 //# 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,CAAC,CAAC;AACzB,QAAA,qBAAqB,GAAG,WAAW,CAAC;AACjD,MAAM,2BAA2B,GAAG,wBAAwB,4BAAoB,EAAE,CAAC;AAEtE,QAAA,oBAAoB,GAAG;;;;OAI7B,2BAA2B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoCjC,CAAC"}
+{"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"}

package/dist/utils/variantPreviewPort.d.ts

@@ -0,0 +1,18 @@
+export type PreviewPortResolution = {
+    ok: true;
+    port: number | null;
+} | {
+    ok: false;
+    status: number;
+    error: string;
+};
+type VariantPreviewSessionGate = {
+    isActive(): boolean;
+    isVariantPortAllowed(port: number): boolean;
+};
+/**
+ * Validate a requested preview port against the active MCP variant session.
+ */
+export declare const resolveVariantPreviewPort: (rawPort: unknown, sessionGate: VariantPreviewSessionGate) => PreviewPortResolution;
+export {};
+//# sourceMappingURL=variantPreviewPort.d.ts.map

package/dist/utils/variantPreviewPort.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"variantPreviewPort.d.ts","sourceRoot":"","sources":["../../src/utils/variantPreviewPort.ts"],"names":[],"mappings":"AAAA,MAAM,MAAM,qBAAqB,GAC7B;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,IAAI,EAAE,MAAM,GAAG,IAAI,CAAA;CAAE,GACjC;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,CAAC;AAEjD,KAAK,yBAAyB,GAAG;IAC/B,QAAQ,IAAI,OAAO,CAAC;IACpB,oBAAoB,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC;CAC7C,CAAC;AAEF;;GAEG;AACH,eAAO,MAAM,yBAAyB,GACpC,SAAS,OAAO,EAChB,aAAa,yBAAyB,KACrC,qBAmBF,CAAC"}

package/dist/utils/variantPreviewPort.js

@@ -0,0 +1,28 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.resolveVariantPreviewPort = void 0;
+/**
+ * Validate a requested preview port against the active MCP variant session.
+ */
+const resolveVariantPreviewPort = (rawPort, sessionGate) => {
+    if (rawPort === null || rawPort === undefined) {
+        return { ok: true, port: null };
+    }
+    if (!Number.isInteger(rawPort) || rawPort <= 0) {
+        return { ok: false, status: 400, error: 'Invalid preview port' };
+    }
+    if (!sessionGate.isActive()) {
+        return { ok: false, status: 400, error: 'No active MCP session' };
+    }
+    const port = rawPort;
+    if (!sessionGate.isVariantPortAllowed(port)) {
+        return {
+            ok: false,
+            status: 403,
+            error: `Preview port ${port} is not registered for this variant session`,
+        };
+    }
+    return { ok: true, port };
+};
+exports.resolveVariantPreviewPort = resolveVariantPreviewPort;
+//# sourceMappingURL=variantPreviewPort.js.map

package/dist/utils/variantPreviewPort.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"variantPreviewPort.js","sourceRoot":"","sources":["../../src/utils/variantPreviewPort.ts"],"names":[],"mappings":";;;AASA;;GAEG;AACI,MAAM,yBAAyB,GAAG,CACvC,OAAgB,EAChB,WAAsC,EACf,EAAE;IACzB,IAAI,OAAO,KAAK,IAAI,IAAI,OAAO,KAAK,SAAS,EAAE,CAAC;QAC9C,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,CAAC;IAClC,CAAC;IACD,IAAI,CAAC,MAAM,CAAC,SAAS,CAAC,OAAO,CAAC,IAAK,OAAkB,IAAI,CAAC,EAAE,CAAC;QAC3D,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,GAAG,EAAE,KAAK,EAAE,sBAAsB,EAAE,CAAC;IACnE,CAAC;IACD,IAAI,CAAC,WAAW,CAAC,QAAQ,EAAE,EAAE,CAAC;QAC5B,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,GAAG,EAAE,KAAK,EAAE,uBAAuB,EAAE,CAAC;IACpE,CAAC;IACD,MAAM,IAAI,GAAG,OAAiB,CAAC;IAC/B,IAAI,CAAC,WAAW,CAAC,oBAAoB,CAAC,IAAI,CAAC,EAAE,CAAC;QAC5C,OAAO;YACL,EAAE,EAAE,KAAK;YACT,MAAM,EAAE,GAAG;YACX,KAAK,EAAE,gBAAgB,IAAI,6CAA6C;SACzE,CAAC;IACJ,CAAC;IACD,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,IAAI,EAAE,CAAC;AAC5B,CAAC,CAAC;AAtBW,QAAA,yBAAyB,6BAsBpC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rivet-design",
-  "version": "0.8.7",
+  "version": "0.9.2",
   "description": "Local visual web development tool with AI-powered code modification",
   "main": "dist/index.js",
   "workspaces": [