rivet-design 0.12.4 → 0.13.0

package/dist/types/editor-interface-types.d.ts

@@ -1,67 +0,0 @@
-export type ControlValue = string | number | boolean;
-/** A single CSS declaration a control resolves to when applied to the preview. */
-export type CssDecl = {
-    selector: string;
-    property: string;
-    value: string;
-};
-export type BindingStatus = 'resolved' | 'unresolved' | 'stale';
-/**
- * Where a selector-bound control writes. Carries a resolution status so the UI
- * can degrade gracefully when the selector no longer matches the live DOM
- * (validated client-side after generation and after HMR).
- */
-export type ControlBinding = {
-    selector: string;
-    property: string;
-    status: BindingStatus;
-};
-/**
- * A generated control. `kind` is an open string — the UI renderer/resolver
- * registry dispatches on it. `config` holds kind-specific data (validated on the
- * backend for known kinds). Selector-bound kinds (scoped-slider, swatch-set)
- * carry a `binding`; composite kinds (option-cards) keep their declarations in
- * `config`.
- */
-export type GeneratedControl = {
-    id: string;
-    kind: string;
-    label: string;
-    default?: ControlValue;
-    /** The project's real value before tuning (reset target). */
-    baseline?: ControlValue;
-    binding?: ControlBinding;
-    config: Record<string, unknown>;
-};
-export type InterfaceSection = {
-    id: string;
-    title: string;
-    controls: GeneratedControl[];
-};
-export type EditorInterface = {
-    version: number;
-    /** The natural-language intent that produced this interface. */
-    intent: string;
-    sections: InterfaceSection[];
-};
-/** The uncommitted local draft of control values for an interface. */
-export type InterfaceSession = {
-    values: Record<string, ControlValue>;
-};
-export type ScopedSliderConfig = {
-    min: number;
-    max: number;
-    step?: number;
-    unit?: string;
-};
-export type SwatchSetConfig = {
-    swatches: string[];
-};
-export type OptionCardsConfig = {
-    options: Array<{
-        id: string;
-        label: string;
-        declarations: CssDecl[];
-    }>;
-};
-//# sourceMappingURL=editor-interface-types.d.ts.map

package/dist/types/editor-interface-types.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"editor-interface-types.d.ts","sourceRoot":"","sources":["../../src/types/editor-interface-types.ts"],"names":[],"mappings":"AAUA,MAAM,MAAM,YAAY,GAAG,MAAM,GAAG,MAAM,GAAG,OAAO,CAAC;AAErD,kFAAkF;AAClF,MAAM,MAAM,OAAO,GAAG;IACpB,QAAQ,EAAE,MAAM,CAAC;IACjB,QAAQ,EAAE,MAAM,CAAC;IACjB,KAAK,EAAE,MAAM,CAAC;CACf,CAAC;AAEF,MAAM,MAAM,aAAa,GAAG,UAAU,GAAG,YAAY,GAAG,OAAO,CAAC;AAEhE;;;;GAIG;AACH,MAAM,MAAM,cAAc,GAAG;IAC3B,QAAQ,EAAE,MAAM,CAAC;IACjB,QAAQ,EAAE,MAAM,CAAC;IACjB,MAAM,EAAE,aAAa,CAAC;CACvB,CAAC;AAEF;;;;;;GAMG;AACH,MAAM,MAAM,gBAAgB,GAAG;IAC7B,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,CAAC,EAAE,YAAY,CAAC;IACvB,6DAA6D;IAC7D,QAAQ,CAAC,EAAE,YAAY,CAAC;IACxB,OAAO,CAAC,EAAE,cAAc,CAAC;IACzB,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;CACjC,CAAC;AAEF,MAAM,MAAM,gBAAgB,GAAG;IAC7B,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,MAAM,CAAC;IACd,QAAQ,EAAE,gBAAgB,EAAE,CAAC;CAC9B,CAAC;AAEF,MAAM,MAAM,eAAe,GAAG;IAC5B,OAAO,EAAE,MAAM,CAAC;IAChB,gEAAgE;IAChE,MAAM,EAAE,MAAM,CAAC;IACf,QAAQ,EAAE,gBAAgB,EAAE,CAAC;CAC9B,CAAC;AAEF,sEAAsE;AACtE,MAAM,MAAM,gBAAgB,GAAG;IAC7B,MAAM,EAAE,MAAM,CAAC,MAAM,EAAkB,YAAY,CAAC,CAAC;CACtD,CAAC;AAMF,MAAM,MAAM,kBAAkB,GAAG;IAC/B,GAAG,EAAE,MAAM,CAAC;IACZ,GAAG,EAAE,MAAM,CAAC;IACZ,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,IAAI,CAAC,EAAE,MAAM,CAAC;CACf,CAAC;AAEF,MAAM,MAAM,eAAe,GAAG;IAC5B,QAAQ,EAAE,MAAM,EAAE,CAAC;CACpB,CAAC;AAEF,MAAM,MAAM,iBAAiB,GAAG;IAC9B,OAAO,EAAE,KAAK,CAAC;QACb,EAAE,EAAE,MAAM,CAAC;QACX,KAAK,EAAE,MAAM,CAAC;QACd,YAAY,EAAE,OAAO,EAAE,CAAC;KACzB,CAAC,CAAC;CACJ,CAAC"}

package/dist/types/editor-interface-types.js

@@ -1,12 +0,0 @@
-"use strict";
-// Generative Editor Interfaces — the schema for an LLM-generated editing UI.
-// See docs/generative-editor-interfaces.md.
-//
-// The product is the *generation*: the user describes an editing task and the
-// model authors a bespoke interface (whatever affordances fit). The renderer is
-// generic and dispatches on `control.kind`, so the vocabulary is open and
-// forward-compatible — an unknown kind degrades to a labeled fallback rather
-// than breaking the spec. Shared between backend (generation) and UI
-// (rendering/binding) via @rivet/core/types.
-Object.defineProperty(exports, "__esModule", { value: true });
-//# sourceMappingURL=editor-interface-types.js.map

package/dist/types/editor-interface-types.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"editor-interface-types.js","sourceRoot":"","sources":["../../src/types/editor-interface-types.ts"],"names":[],"mappings":";AAAA,6EAA6E;AAC7E,4CAA4C;AAC5C,EAAE;AACF,8EAA8E;AAC9E,gFAAgF;AAChF,0EAA0E;AAC1E,6EAA6E;AAC7E,qEAAqE;AACrE,6CAA6C"}

package/dist/utils/elementRefToContext.d.ts

@@ -1,4 +0,0 @@
-import type { ElementContext } from '../types/change-types';
-import type { ElementRef } from '../types/change-request-types';
-export declare const elementRefToContext: (element: ElementRef) => ElementContext;
-//# sourceMappingURL=elementRefToContext.d.ts.map

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

@@ -1 +0,0 @@
-{"version":3,"file":"elementRefToContext.d.ts","sourceRoot":"","sources":["../../src/utils/elementRefToContext.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAiB,cAAc,EAAE,MAAM,uBAAuB,CAAC;AAC3E,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAmChE,eAAO,MAAM,mBAAmB,GAAI,SAAS,UAAU,KAAG,cA6BxD,CAAC"}

package/dist/utils/elementRefToContext.js

@@ -1,63 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.elementRefToContext = void 0;
-const DEFAULT_BOUNDING_RECT = {
-    x: 0,
-    y: 0,
-    width: 0,
-    height: 0,
-    top: 0,
-    left: 0,
-    right: 0,
-    bottom: 0,
-};
-const COMPONENT_NODE_TYPES = new Set([
-    'function',
-    'class',
-    'memo',
-    'forwardRef',
-    'context',
-    'unknown',
-]);
-const toComponentNode = (node) => {
-    const type = COMPONENT_NODE_TYPES.has(node.type)
-        ? node.type
-        : 'unknown';
-    return {
-        name: node.name,
-        type,
-        depth: node.depth ?? 0,
-    };
-};
-const elementRefToContext = (element) => ({
-    xpath: element.xpath,
-    tagName: element.tagName,
-    className: element.className,
-    id: element.id,
-    textContent: element.textContent ?? '',
-    innerHTML: '',
-    attributes: element.attributes ?? {},
-    computedStyles: {},
-    boundingRect: DEFAULT_BOUNDING_RECT,
-    ...(element.rivetId ? { rivetId: element.rivetId } : {}),
-    ...(element.componentTree
-        ? { componentTree: element.componentTree.map(toComponentNode) }
-        : {}),
-    ...(element.filePaths.length > 0
-        ? {
-            filePaths: element.filePaths.map((filePath) => ({
-                filePath,
-            })),
-        }
-        : {}),
-    ...(element.parentElementSummary
-        ? {
-            parentElementSummary: {
-                ...element.parentElementSummary,
-                id: '',
-            },
-        }
-        : {}),
-});
-exports.elementRefToContext = elementRefToContext;
-//# sourceMappingURL=elementRefToContext.js.map

package/dist/utils/elementRefToContext.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"elementRefToContext.js","sourceRoot":"","sources":["../../src/utils/elementRefToContext.ts"],"names":[],"mappings":";;;AAGA,MAAM,qBAAqB,GAAG;IAC5B,CAAC,EAAE,CAAC;IACJ,CAAC,EAAE,CAAC;IACJ,KAAK,EAAE,CAAC;IACR,MAAM,EAAE,CAAC;IACT,GAAG,EAAE,CAAC;IACN,IAAI,EAAE,CAAC;IACP,KAAK,EAAE,CAAC;IACR,MAAM,EAAE,CAAC;CACV,CAAC;AAEF,MAAM,oBAAoB,GAAG,IAAI,GAAG,CAAwB;IAC1D,UAAU;IACV,OAAO;IACP,MAAM;IACN,YAAY;IACZ,SAAS;IACT,SAAS;CACV,CAAC,CAAC;AAEH,MAAM,eAAe,GAAG,CACtB,IAAsD,EACvC,EAAE;IACjB,MAAM,IAAI,GAAG,oBAAoB,CAAC,GAAG,CAAC,IAAI,CAAC,IAA6B,CAAC;QACvE,CAAC,CAAE,IAAI,CAAC,IAA8B;QACtC,CAAC,CAAC,SAAS,CAAC;IACd,OAAO;QACL,IAAI,EAAE,IAAI,CAAC,IAAI;QACf,IAAI;QACJ,KAAK,EAAE,IAAI,CAAC,KAAK,IAAI,CAAC;KACvB,CAAC;AACJ,CAAC,CAAC;AAEK,MAAM,mBAAmB,GAAG,CAAC,OAAmB,EAAkB,EAAE,CAAC,CAAC;IAC3E,KAAK,EAAE,OAAO,CAAC,KAAK;IACpB,OAAO,EAAE,OAAO,CAAC,OAAO;IACxB,SAAS,EAAE,OAAO,CAAC,SAAS;IAC5B,EAAE,EAAE,OAAO,CAAC,EAAE;IACd,WAAW,EAAE,OAAO,CAAC,WAAW,IAAI,EAAE;IACtC,SAAS,EAAE,EAAE;IACb,UAAU,EAAE,OAAO,CAAC,UAAU,IAAI,EAAE;IACpC,cAAc,EAAE,EAAE;IAClB,YAAY,EAAE,qBAAqB;IACnC,GAAG,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,OAAO,EAAE,OAAO,CAAC,OAAO,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;IACxD,GAAG,CAAC,OAAO,CAAC,aAAa;QACvB,CAAC,CAAC,EAAE,aAAa,EAAE,OAAO,CAAC,aAAa,CAAC,GAAG,CAAC,eAAe,CAAC,EAAE;QAC/D,CAAC,CAAC,EAAE,CAAC;IACP,GAAG,CAAC,OAAO,CAAC,SAAS,CAAC,MAAM,GAAG,CAAC;QAC9B,CAAC,CAAC;YACE,SAAS,EAAE,OAAO,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE,EAAE,CAAC,CAAC;gBAC9C,QAAQ;aACT,CAAC,CAAC;SACJ;QACH,CAAC,CAAC,EAAE,CAAC;IACP,GAAG,CAAC,OAAO,CAAC,oBAAoB;QAC9B,CAAC,CAAC;YACE,oBAAoB,EAAE;gBACpB,GAAG,OAAO,CAAC,oBAAoB;gBAC/B,EAAE,EAAE,EAAE;aACP;SACF;QACH,CAAC,CAAC,EAAE,CAAC;CACR,CAAC,CAAC;AA7BU,QAAA,mBAAmB,uBA6B7B"}

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

@@ -1,69 +0,0 @@
-/**
- * Watch → lease → act flow shared by apply and variant batches.
- * Imported by agent skill files so MCP semantics stay aligned with the bridge.
- */
-export declare const DURABLE_BATCH_HANDOFF_SECTION = "## Durable batch handoff (apply + variant)\n\nBoth point-and-click **apply** batches and in-editor **variant** batches use the same bridge pickup pipeline: **queued \u2192 leased \u2192 acted on**. Apply leases are released by an explicit apply ack; generated variant work is released by `report_work_item` (kind `status`) when every tracked work item reaches a terminal state. The host agent must keep this loop alive whenever the visual editor is open.\n\n**One loop for both kinds:**\n\n1. `watch_for_changes({ sessionId })` \u2014 blocks until work exists. While blocked with no lease yet, bridge status is `WATCHING` (this is **not** round complete).\n2. Pickup returns `{ leaseId, requestId, kind: 'apply' | 'variant', mergedRequestIds?, \u2026 }`. Re-polling the same `requestId` is idempotent \u2014 you get the same lease back.\n3. **Act** on the leased payload:\n   - `kind: 'apply'` \u2192 edit files from `sourceFiles` / `changes[]`\n   - `kind: 'variant'` \u2192 `start_variants` / static refine / `continue_variants` per the batch shape\n4. **Release** the leased work only after acting:\n   - apply leases \u2192 `get_pending_changes({ sessionId, message, refresh_git: true })`\n   - UI-originated `variant_request` / `static_preview_refine` leases \u2192 process via `start_variants` or scoped `continue_variants({ action: 'request_work', workItemIds })`, call `report_work_item(kind='status')` for every generated item, and let the server release the bridge lease after all tracked items finish\n   - Do NOT use `ack_batch` to skip or finish generated variant work; unclaimed or unfinished variant leases return a structured `variant_ack_blocked` error\n5. Immediately call `watch_for_changes` again while `hasUnfinishedWork` / `pendingVariantRequests` is non-zero.\n\n**Status semantics (do not confuse with batch lifecycle):**\n\n| Status | Meaning |\n|---|---|\n| `WATCHING` | Watch loop blocked, nothing leased yet \u2014 **keep waiting** |\n| `APPLYING` | Apply lease active, agent working |\n| `READY` | **Only after explicit apply ack** \u2014 safe for Rivet UI to clear markers |\n\n`READY` before `refresh_git` was a spurious idle pulse \u2014 ignore it. Never treat `WATCHING` as completion.\n\n**Queue-time merge:** several Sends may merge into one apply lease (`mergedRequestIds`). One agent pass + one `refresh_git` clears markers for **all** merged request ids.";
-/**
- * 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;
-/**
- * User-facing overview — what to tell the user when they ask what Rivet does
- * or when the agent first opens the editor.
- */
-export declare const RIVET_OVERVIEW = "## What Rivet does\n\nRivet helps you **explore multiple design directions** for your web app. It generates parallel variants you can compare side by side, refine with precision, and share or implement.\n\n### How to use Rivet\n\n1. **Start from your coding agent.** Use `/rivet` in Claude Code, or tell your agent \"Use Rivet variants\" or \"Explore with Rivet\" along with your design request.\n2. **Connect design references** (optional). Click **Connect design references** in the editor to link your Pinterest or Are.na account. Include relevant pins or boards and Rivet will extract design context from them to inform the variants it generates.\n3. **Refine with the comment tool.** Select any part of the UI and use the comment tool to make more precise variants of that section, or leave comments describing what you'd like to change within a variant.\n4. **Share or implement.** When you're happy, click the **Share** button to get a shareable link you can send to a collaborator \u2014 or share it back to your coding agent to implement the chosen direction.";
-/** 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| \"/rivet\", \"use rivet variants\", \"explore with rivet\", \"show me design options for X\", \"create variants of X\", \"show me 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** (`start_variants`, `mode='zero_to_one'`, with `userContext`) |\n| \"make a visual change to X\", \"tweak this button\", \"open the editor so I can click around\" \u2014 **including in an empty or HTML-only folder** | **Visual editor** (below). An empty / HTML-only directory is a valid target \u2014 it opens in **static mode** (no dev server). Do NOT reroute to variants or refuse just because there's no app/dev server yet. |\n| \"open rivet\", \"use rivet here\" \u2014 with **no** specific change described yet, **and** the server instructions include the first-run onboarding block | **Proactive first directions** (below) \u2014 orient on the project, propose 3 distinct directions, and open the editor already generating once the user picks. Without that first-run block, a bare open goes to the **Visual editor** instead. |";
-/**
- * First-run onboarding flow. When the user opens Rivet without describing a
- * change, lead with a proposal instead of a blank editor: orient cheaply on the
- * project, propose 3 distinct directions in chat, and only open the editor once
- * the user picks — so it opens already generating, never empty.
- *
- * This is the one entry flow that PAUSES for confirmation before generating
- * (everywhere else reporting briefs starts directions immediately). It reuses
- * the on-demand brief logic + `start_variants({ mode: 'existing' })` — the only
- * new behaviour is the proactive trigger, a bounded orientation read, and the
- * text proposal + confirmation gate.
- */
-export declare const PROACTIVE_FIRST_DIRECTIONS_SECTION = "## Proactive first directions\n\n**Only do this when the connect-time server instructions include the first-run onboarding block** (\"First Rivet session \u2014 lead with a proposal\"). That block appears only until the user has run variants once; on later sessions (or if it is absent) a bare open goes straight to the **Visual Editor flow** \u2014 do NOT propose.\n\n**Also skip it once the user has kicked off any variants run in this session.** The onboarding block is injected once at connect and is not refreshed mid-session, so it can linger after the user's first run \u2014 if you have already started variants (or just did), treat the block as spent and route a later bare open to the Visual Editor flow instead of proposing again.\n\nWhen the user opens Rivet with **no change or direction described yet** \u2014 a bare \"open rivet\" / \"use rivet here\" on that first session \u2014 do NOT open an empty editor and tell them to go type a request. Lead with a concrete proposal: glance at their project, suggest **3 distinct directions** for one surface, and open the editor only once they pick (so it opens with variants already streaming, never blank).\n\nThis is the ONE entry flow that pauses for confirmation before generating. Everywhere else in the variants flow, reporting briefs starts the directions immediately \u2014 here you propose first and wait.\n\n### 1. Orient cheaply \u2014 do NOT crawl the repo\n\nRead only enough to name ONE surface and describe its current visual character. There is no fixed file list and no file count to hit \u2014 there is a goal and a budget:\n\n- **Goal:** be able to state what the main surface is (framework, layout, key sections) and its current design character (light/dark, palette, density, mood).\n- **Cheapest high-signal reads first:** `package.json` (framework), a top-level glance at the `app`/`pages`/`src` or routes directory (candidate surfaces), and the theme \u2014 `tailwind.config`, the `:root` CSS variables, or `globals.css`. The theme is usually ONE file and reveals almost the entire design character.\n- **Then** read the single surface you'll propose for \u2014 the route/page/component the editor would render at its entry. Usually one file.\n- **Stop the moment you can name the surface + its character.** Do NOT follow imports down the tree, and do NOT read `node_modules`, tests, build output, or config beyond `package.json`. A handful of files, seconds not minutes.\n- If you genuinely cannot characterize a surface (empty / HTML-only folder, or an unreadable project), skip the deep read and propose along generic design levers (typography, color/mood, layout/density) \u2014 say that's what you did rather than over-reading to compensate.\n\n### 2. Draft 3 distinct directions\n\nUse the same brief discipline as the on-demand flow, framed to NAME the change (clearer for a first-time user than vibe words):\n- **Label:** a plain \u2264 4-word title that names what the direction changes (e.g. \"Editorial serif type\", \"Warm light theme\", \"Dense command layout\"). No em-dash / en-dash / colon compounds; not a vibe word.\n- **Body:** exactly ONE sentence, \u2264 12 words, describing the direction and any scope it respects.\n- **Each direction MUST lead with a DIFFERENT dominant lever** \u2014 e.g. one leads with typography, one with color/mood, one with layout/density \u2014 so the three render as visibly different results, not three flavors of \"nicer.\" Adapt every label and body to what you actually read; generic copy that could apply to any project is a failure.\n\n### 3. Propose in chat and NAME your assumption\n\nPresent the 3 directions as PLAIN TEXT (no fabricated UI, no browser tab, no URL). State which surface you looked at so a wrong guess is a one-line correction, and offer the escape hatches:\n\n> I looked at your home screen (`app/page.tsx`). Here are 3 directions I'd explore:\n> \u2022 **<label>** \u2014 <body>\n> \u2022 **<label>** \u2014 <body>\n> \u2022 **<label>** \u2014 <body>\n> Want me to run all 3? (Or point me at a different screen, or just open the editor so you can click around.)\n\nHandle the reply:\n- **\"run them\" / \"yes\" / picks a subset** \u2192 go to step 4 (drop any directions they didn't want).\n- **\"no, the <other> screen\"** \u2192 re-orient on that surface (cheap) and re-propose.\n- **\"just let me click around\" / any point-and-click request** \u2192 this is the Visual Editor flow: call `open_visual_editor` and follow it. Do NOT force a variants kickoff.\n\n### 4. On confirm \u2014 kick off; the editor opens already generating\n\nCall `start_variants({ mode: 'existing', briefs })` with the confirmed directions. There is no user prompt to pass verbatim here, so synthesize a short `prompt` from the surface you proposed for (e.g. \"Explore 3 directions for the home screen\"). `start_variants` detects the framework, opens the editor, and starts every direction \u2014 so the editor appears with variants already streaming, never empty. From here, follow **Agent Variants flow \u2192 Sub-flow A** from step 2 onward (parallel code-gen, ready, watch, apply), and keep the `watch_for_changes` loop alive per `editorNextAction`.";
-/**
- * Coordinator + elastic-worker protocol for handling the user's IN-EDITOR
- * changes (comments / "Apply" tweaks / "Vary" requests) concurrently, instead
- * of one batch at a time. The server already owns the work-model (per-batch
- * `workItemIds` leases, same-variant fold, FIFO backpressure, abort signalling)
- * — this section tells the agent how to orchestrate against it so several
- * changes render in parallel and the UI's instant placeholders resolve fast.
- *
- * Parameterised on the one thing that differs per agent: how a worker is
- * dispatched (Claude Code = a real background `Task` sub-agent; Cursor = inline
- * parallel tool calls, since it has no backgroundable sub-agents).
- */
-export declare function buildConcurrentRefineSection(opts: {
-    /** How the coordinator dispatches a worker for one batch (mechanism differs). */
-    dispatchWorker: string;
-    /** Loop-back timing sentence — immediate (Claude background) vs after the
-     *  batch is generated (Cursor inline). */
-    loopBack: string;
-    /** Per-agent bullet list of the specific mistakes that break parallelism for
-     *  THIS agent (background sub-agents vs inline), rendered under the shared
-     *  "Common mistakes" sub-block. */
-    commonMistakes: string;
-}): string;
-/**
- * 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

@@ -1 +0,0 @@
-{"version":3,"file":"shared-variants-protocol.d.ts","sourceRoot":"","sources":["../../../src/utils/skills/shared-variants-protocol.ts"],"names":[],"mappings":"AAEA;;;GAGG;AACH,eAAO,MAAM,6BAA6B,61EA2BqI,CAAC;AAEhL;;;;GAIG;AACH,eAAO,MAAM,wBAAwB,QAIgF,CAAC;AAEtH;;;GAGG;AACH,eAAO,MAAM,cAAc,ijCASgL,CAAC;AAE5M,0DAA0D;AAC1D,eAAO,MAAM,sBAAsB,8iDASkW,CAAC;AAEtY;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,kCAAkC,6kKA4CoiB,CAAC;AAEplB;;;;;;;;;;;GAWG;AACH,wBAAgB,4BAA4B,CAAC,IAAI,EAAE;IACjD,iFAAiF;IACjF,cAAc,EAAE,MAAM,CAAC;IACvB;8CAC0C;IAC1C,QAAQ,EAAE,MAAM,CAAC;IACjB;;uCAEmC;IACnC,cAAc,EAAE,MAAM,CAAC;CACxB,GAAG,MAAM,CA8BT;AAED;;;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,CAkHT"}

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

@@ -1,292 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.PROACTIVE_FIRST_DIRECTIONS_SECTION = exports.PICKING_THE_FLOW_TABLE = exports.RIVET_OVERVIEW = exports.BRIEF_FORMAT_INSTRUCTION = exports.DURABLE_BATCH_HANDOFF_SECTION = void 0;
-exports.buildConcurrentRefineSection = buildConcurrentRefineSection;
-exports.buildAgentVariantsSection = buildAgentVariantsSection;
-const describe_motion_protocol_1 = require("./describe-motion-protocol");
-/**
- * Watch → lease → act flow shared by apply and variant batches.
- * Imported by agent skill files so MCP semantics stay aligned with the bridge.
- */
-exports.DURABLE_BATCH_HANDOFF_SECTION = `## Durable batch handoff (apply + variant)
-
-Both point-and-click **apply** batches and in-editor **variant** batches use the same bridge pickup pipeline: **queued → leased → acted on**. Apply leases are released by an explicit apply ack; generated variant work is released by \`report_work_item\` (kind \`status\`) when every tracked work item reaches a terminal state. The host agent must keep this loop alive whenever the visual editor is open.
-
-**One loop for both kinds:**
-
-1. \`watch_for_changes({ sessionId })\` — blocks until work exists. While blocked with no lease yet, bridge status is \`WATCHING\` (this is **not** round complete).
-2. Pickup returns \`{ leaseId, requestId, kind: 'apply' | 'variant', mergedRequestIds?, … }\`. Re-polling the same \`requestId\` is idempotent — you get the same lease back.
-3. **Act** on the leased payload:
-   - \`kind: 'apply'\` → edit files from \`sourceFiles\` / \`changes[]\`
-   - \`kind: 'variant'\` → \`start_variants\` / static refine / \`continue_variants\` per the batch shape
-4. **Release** the leased work only after acting:
-   - apply leases → \`get_pending_changes({ sessionId, message, refresh_git: true })\`
-   - UI-originated \`variant_request\` / \`static_preview_refine\` leases → process via \`start_variants\` or scoped \`continue_variants({ action: 'request_work', workItemIds })\`, call \`report_work_item(kind='status')\` for every generated item, and let the server release the bridge lease after all tracked items finish
-   - Do NOT use \`ack_batch\` to skip or finish generated variant work; unclaimed or unfinished variant leases return a structured \`variant_ack_blocked\` error
-5. Immediately call \`watch_for_changes\` again while \`hasUnfinishedWork\` / \`pendingVariantRequests\` is non-zero.
-
-**Status semantics (do not confuse with batch lifecycle):**
-
-| Status | Meaning |
-|---|---|
-| \`WATCHING\` | Watch loop blocked, nothing leased yet — **keep waiting** |
-| \`APPLYING\` | Apply lease active, agent working |
-| \`READY\` | **Only after explicit apply ack** — safe for Rivet UI to clear markers |
-
-\`READY\` before \`refresh_git\` was a spurious idle pulse — ignore it. Never treat \`WATCHING\` as completion.
-
-**Queue-time merge:** several Sends may merge into one apply lease (\`mergedRequestIds\`). One agent pass + one \`refresh_git\` clears markers for **all** merged request ids.`;
-/**
- * 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, a plain standalone title (e.g. "Soft spring blur", "Crisp linear motion"). ' +
-    'NEVER a "Title — descriptor" compound: no em dashes, en dashes, or colons in the label — any descriptor belongs in the body. ' +
-    '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.';
-/**
- * User-facing overview — what to tell the user when they ask what Rivet does
- * or when the agent first opens the editor.
- */
-exports.RIVET_OVERVIEW = `## What Rivet does
-
-Rivet helps you **explore multiple design directions** for your web app. It generates parallel variants you can compare side by side, refine with precision, and share or implement.
-
-### How to use Rivet
-
-1. **Start from your coding agent.** Use \`/rivet\` in Claude Code, or tell your agent "Use Rivet variants" or "Explore with Rivet" along with your design request.
-2. **Connect design references** (optional). Click **Connect design references** in the editor to link your Pinterest or Are.na account. Include relevant pins or boards and Rivet will extract design context from them to inform the variants it generates.
-3. **Refine with the comment tool.** Select any part of the UI and use the comment tool to make more precise variants of that section, or leave comments describing what you'd like to change within a variant.
-4. **Share or implement.** When you're happy, click the **Share** button to get a shareable link you can send to a collaborator — or share it back to your coding agent to implement the chosen direction.`;
-/** Routing table — identical in every agent skill file */
-exports.PICKING_THE_FLOW_TABLE = `## Picking the flow
-
-| User says | Flow |
-|---|---|
-| "/rivet", "use rivet variants", "explore with rivet", "show me design options for X", "create variants of X", "show me 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** (\`start_variants\`, \`mode='zero_to_one'\`, with \`userContext\`) |
-| "make a visual change to X", "tweak this button", "open the editor so I can click around" — **including in an empty or HTML-only folder** | **Visual editor** (below). An empty / HTML-only directory is a valid target — it opens in **static mode** (no dev server). Do NOT reroute to variants or refuse just because there's no app/dev server yet. |
-| "open rivet", "use rivet here" — with **no** specific change described yet, **and** the server instructions include the first-run onboarding block | **Proactive first directions** (below) — orient on the project, propose 3 distinct directions, and open the editor already generating once the user picks. Without that first-run block, a bare open goes to the **Visual editor** instead. |`;
-/**
- * First-run onboarding flow. When the user opens Rivet without describing a
- * change, lead with a proposal instead of a blank editor: orient cheaply on the
- * project, propose 3 distinct directions in chat, and only open the editor once
- * the user picks — so it opens already generating, never empty.
- *
- * This is the one entry flow that PAUSES for confirmation before generating
- * (everywhere else reporting briefs starts directions immediately). It reuses
- * the on-demand brief logic + `start_variants({ mode: 'existing' })` — the only
- * new behaviour is the proactive trigger, a bounded orientation read, and the
- * text proposal + confirmation gate.
- */
-exports.PROACTIVE_FIRST_DIRECTIONS_SECTION = `## Proactive first directions
-
-**Only do this when the connect-time server instructions include the first-run onboarding block** ("First Rivet session — lead with a proposal"). That block appears only until the user has run variants once; on later sessions (or if it is absent) a bare open goes straight to the **Visual Editor flow** — do NOT propose.
-
-**Also skip it once the user has kicked off any variants run in this session.** The onboarding block is injected once at connect and is not refreshed mid-session, so it can linger after the user's first run — if you have already started variants (or just did), treat the block as spent and route a later bare open to the Visual Editor flow instead of proposing again.
-
-When the user opens Rivet with **no change or direction described yet** — a bare "open rivet" / "use rivet here" on that first session — do NOT open an empty editor and tell them to go type a request. Lead with a concrete proposal: glance at their project, suggest **3 distinct directions** for one surface, and open the editor only once they pick (so it opens with variants already streaming, never blank).
-
-This is the ONE entry flow that pauses for confirmation before generating. Everywhere else in the variants flow, reporting briefs starts the directions immediately — here you propose first and wait.
-
-### 1. Orient cheaply — do NOT crawl the repo
-
-Read only enough to name ONE surface and describe its current visual character. There is no fixed file list and no file count to hit — there is a goal and a budget:
-
-- **Goal:** be able to state what the main surface is (framework, layout, key sections) and its current design character (light/dark, palette, density, mood).
-- **Cheapest high-signal reads first:** \`package.json\` (framework), a top-level glance at the \`app\`/\`pages\`/\`src\` or routes directory (candidate surfaces), and the theme — \`tailwind.config\`, the \`:root\` CSS variables, or \`globals.css\`. The theme is usually ONE file and reveals almost the entire design character.
-- **Then** read the single surface you'll propose for — the route/page/component the editor would render at its entry. Usually one file.
-- **Stop the moment you can name the surface + its character.** Do NOT follow imports down the tree, and do NOT read \`node_modules\`, tests, build output, or config beyond \`package.json\`. A handful of files, seconds not minutes.
-- If you genuinely cannot characterize a surface (empty / HTML-only folder, or an unreadable project), skip the deep read and propose along generic design levers (typography, color/mood, layout/density) — say that's what you did rather than over-reading to compensate.
-
-### 2. Draft 3 distinct directions
-
-Use the same brief discipline as the on-demand flow, framed to NAME the change (clearer for a first-time user than vibe words):
-- **Label:** a plain ≤ 4-word title that names what the direction changes (e.g. "Editorial serif type", "Warm light theme", "Dense command layout"). No em-dash / en-dash / colon compounds; not a vibe word.
-- **Body:** exactly ONE sentence, ≤ 12 words, describing the direction and any scope it respects.
-- **Each direction MUST lead with a DIFFERENT dominant lever** — e.g. one leads with typography, one with color/mood, one with layout/density — so the three render as visibly different results, not three flavors of "nicer." Adapt every label and body to what you actually read; generic copy that could apply to any project is a failure.
-
-### 3. Propose in chat and NAME your assumption
-
-Present the 3 directions as PLAIN TEXT (no fabricated UI, no browser tab, no URL). State which surface you looked at so a wrong guess is a one-line correction, and offer the escape hatches:
-
-> I looked at your home screen (\`app/page.tsx\`). Here are 3 directions I'd explore:
-> • **<label>** — <body>
-> • **<label>** — <body>
-> • **<label>** — <body>
-> Want me to run all 3? (Or point me at a different screen, or just open the editor so you can click around.)
-
-Handle the reply:
-- **"run them" / "yes" / picks a subset** → go to step 4 (drop any directions they didn't want).
-- **"no, the <other> screen"** → re-orient on that surface (cheap) and re-propose.
-- **"just let me click around" / any point-and-click request** → this is the Visual Editor flow: call \`open_visual_editor\` and follow it. Do NOT force a variants kickoff.
-
-### 4. On confirm — kick off; the editor opens already generating
-
-Call \`start_variants({ mode: 'existing', briefs })\` with the confirmed directions. There is no user prompt to pass verbatim here, so synthesize a short \`prompt\` from the surface you proposed for (e.g. "Explore 3 directions for the home screen"). \`start_variants\` detects the framework, opens the editor, and starts every direction — so the editor appears with variants already streaming, never empty. From here, follow **Agent Variants flow → Sub-flow A** from step 2 onward (parallel code-gen, ready, watch, apply), and keep the \`watch_for_changes\` loop alive per \`editorNextAction\`.`;
-/**
- * Coordinator + elastic-worker protocol for handling the user's IN-EDITOR
- * changes (comments / "Apply" tweaks / "Vary" requests) concurrently, instead
- * of one batch at a time. The server already owns the work-model (per-batch
- * `workItemIds` leases, same-variant fold, FIFO backpressure, abort signalling)
- * — this section tells the agent how to orchestrate against it so several
- * changes render in parallel and the UI's instant placeholders resolve fast.
- *
- * Parameterised on the one thing that differs per agent: how a worker is
- * dispatched (Claude Code = a real background `Task` sub-agent; Cursor = inline
- * parallel tool calls, since it has no backgroundable sub-agents).
- */
-function buildConcurrentRefineSection(opts) {
-    return `## Handling in-editor changes concurrently (Coordinator + workers)
-
-Once variants are live in the editor, the user fires changes as they go — an "Apply" tweak to one card, a "Vary" on another, a comment on a third — often **several before the first finishes**. Handle them **concurrently**, never one-at-a-time, so each change starts rendering the moment it's sent (the panel already shows instant placeholders for it).
-
-**You are the Coordinator.** In hosts with background workers, dispatch variant work and loop without generating in the coordinator. In hosts without background workers, process the scoped batch inline, then immediately re-enter the watch loop.
-
-1. Call \`watch_for_changes({ sessionId })\` — it blocks until the user sends a change batch, then returns \`{ leaseId, kind, … }\` directly (no separate \`get_pending_changes\` pickup for these).
-2. When the response is \`kind: 'static_preview_refine'\`, read **\`response.workItemIds\`** — the exact work items the server created for THIS batch — and \`response.applyGuide\` (fork vs in-place).
-3. ${opts.dispatchWorker} ${opts.loopBack}
-4. Keep a bounded pool — at most \`MAX_WORKERS\` (≈4) in flight — and a \`worker → workItemIds\` map. When the pool is full, just keep calling \`watch_for_changes\`; the extra batches wait in the server's FIFO (backpressure is enforced server-side, cap 16) and you dispatch them as workers free up.
-5. After each worker finishes, do **not** call \`ack_batch\`. Each worker's \`report_work_item\` (kind \`status\`) calls are the completion signal; once all tracked work items finish, the server releases the bridge lease. Then re-watch.
-
-**Worker (one per batch):**
-- Calls \`continue_variants({ action: 'request_work', workItemIds })\` with EXACTLY its batch's ids — this leases only those, so workers never steal each other's work. Use the \`leaseId\` from this response on every \`report_work_item(kind='status')\`.
-- For each leased item, follows \`applyGuide\`: **fork** → generate a NEW sibling variation of \`input.currentHtml\` applying \`input.instruction\` (with a synthesized \`title\`/\`description\`); **in-place** → edit \`input.currentHtml\` to apply \`input.instruction\` and keep the variant's name. Then \`report_work_item(kind='status')\` with the full updated \`output.html\`.
-- Sends \`status: 'running'\` heartbeats for slow items, and on \`{ aborted: true }\` from any report it stops that item immediately (no retry) and exits.
-
-**Coalescing — dispatch exactly what the server gives you, never split or merge:**
-- Repeated "Apply" tweaks to the SAME variant are **folded server-side** into ONE in-place refine work item, so N tweaks to one card arrive as ONE \`workItemId\` → ONE worker. Distinct variants and "Vary" forks arrive as separate ids → separate workers in parallel. Don't second-guess this; one worker per \`workItemIds\` batch is always correct.
-
-**Cancellation ("clipping" a superseded change):**
-- The iframe calls \`cancel_variants\` (with the card's \`variantId\`) itself when the user cancels a card — you don't. The affected worker's next heartbeat / report then returns \`{ aborted: true }\` and it stops. \`response.rejectedRefinements\` lists targets the server dropped (already sent / no longer editable) — tell the user those were skipped; never retry them.
-
-**Do NOT stop and ask "keep watching?" in this flow** — keep the coordinator loop alive so every change is picked up instantly. (That stop-and-ask handshake is only for the plain point-and-click diff-apply path.)
-
-**Resuming — never go deaf.** The coordinator loop is the ONLY thing draining the queue; the server holds queued changes in a FIFO (cap 16) with NO auto-drain. The moment a variants session is live, START the watch loop — don't wait to be asked. On ANY new turn while a session is active — including after an interruption, a hand-off, or context compaction — your FIRST action is to call \`watch_for_changes\` again and drain anything pending before doing other work. \`start_variants\` / \`continue_variants\` / \`watch_for_changes\` responses include a **\`pendingVariantRequests\`** field (integer: how many change batches are still queued). If it is \`> 0\` you have stranded work — keep draining (call \`watch_for_changes\`) until it reaches \`0\`. A non-zero count after you stopped watching means changes are silently waiting.
-
-**Common mistakes that break parallelism (do NOT do these):**
-${opts.commonMistakes}`;
-}
-/**
- * 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 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, raw references)** → \`start_variants({ mode: 'zero_to_one' })\` with a \`userContext\` array (inspiration URLs, local images/videos, directories, or pasted text). start_variants runs the source-research (\`source_plan\`) flow so you can inspect the raw sources and report design/motion metadata before briefs. Use this when the user gives a URL to mimic, attaches an image/video, references a file, 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 — default 3. Honor the user's intent: an explicit number ("give me 5"), a relative ask ("more options", "a few extra"), or a qualitative cue ("lots of variety") should all adjust the count up or down from the default. Only use 3 when the user gives no count signal at all. 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. When \`input.target\` is present, scope the change to that element/file/route and its immediate section — do not restyle the rest of the page.
-   - \`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?, editorNextAction? }\`. The server already detected the framework, opened the Rivet visual editor (share \`visualEditor.url\` with the user immediately), and started every variant — you do NOT need to call \`open_visual_editor\` or \`continue_variants(request_work)\` for the initial generation lease. If \`editorNextAction\` is present, keep that structured \`watch_for_changes\` loop alive on \`visualEditor.sessionId\`; the variants \`sessionId\` and visual-editor \`sessionId\` can differ. Each \`variants[i].workItem\` carries \`input.worktreePath\` (where to edit files) and \`attempt\`.
-
-2. ${opts.step9}
-
-   **Verify CSS or markup changes before reporting success.** For existing-project \`code_gen\` work items, inspect the worktree diff and only call \`report_work_item\` (kind \`status\`) with \`status: 'succeeded'\` once the diff adds styling, components, or structured markup. Empty or deletion-only diffs fail QA; Rivet re-leases the work item once with \`input.qaRetry\` so you can regenerate.
-
-   **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_work_item(kind='status')\` 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_variants\` yourself — the iframe surfaces a cancel button per variant card, and the UI calls \`cancel_variants({ sessionId, variantId })\` directly when the user clicks it.
-
-4. **Watch for the user's pick.** Use the structured \`editorNextAction\` when present; otherwise use the active visual-editor session returned by \`open_visual_editor\`. That \`watch_for_changes\` call blocks until the user clicks the check on the chip. Poll \`get_pending_changes\` only as a manual fallback for hosts that cannot block.
-   ${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, starts 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 — default 3. Honor the user's intent: an explicit number ("give me 5"), a relative ask ("more options", "a few extra"), or a qualitative cue ("lots of variety") should all adjust the count up or down from the default. Only use 3 when the user gives no count signal at all. 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?, editorNextAction? }\`. 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 \`open_visual_editor\` step here because the zero-to-one destination is a brand-new directory the server derives. If \`editorNextAction\` is present, keep that structured \`watch_for_changes\` loop alive on \`visualEditor.sessionId\`. This applies ONLY to the not-yet-created zero-to-one destination. An **existing** empty or HTML-only folder is a perfectly valid \`open_visual_editor\` target (it opens in static mode) — do not generalize this skip to "empty dirs can't be opened." 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_work_item(kind='status')\` 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) — \`start_variants\`
-
-**Trigger:** the user provided inspiration URLs ("like stripe.com"), attached an image in chat (pasted screenshot/mockup), attached a video/gif/screen recording ("match this animation", "build the hover from this clip"), referenced an image or video file path (e.g. \`~/Desktop/mockup.png\`, \`~/Desktop/hover.mov\`), referenced a directory, or supplied written design context. Image-only and video-only requests with no URLs are valid and belong in this sub-flow — do not fall back to Sub-flow B.
-
-Use the same \`start_variants({ mode: 'zero_to_one' })\` entry point as Sub-flow B, but pass a \`userContext\` array of raw sources. Any \`userContext\` switches start_variants into the source-research flow — returning \`stage: 'awaiting_source_plan'\` instead of the prompt-only single-call \`work_items_ready\`. Rivet stores the raw sources read-only; you inspect them natively during source planning and report what metadata to derive. start_variants is the single fresh-project entry point — there is no separate source-grounded kickoff tool.
-
-1. **Call \`start_variants\`** with:
-   - \`prompt\`: the user's request verbatim
-   - \`mode\`: \`'zero_to_one'\`
-   - \`framework\` (optional, defaults to \`'vite'\`)
-   - \`destinationParent\` (optional, absolute path)
-   - \`userContext\`: one entry per raw source the user supplied. Do NOT pre-summarize — pass the raw reference:
-     - inspiration URL → \`{ transport: 'url', url, label?, userIntent? }\`
-     - local image / video / file → \`{ transport: 'file_path', path, mimeType?, label?, userIntent? }\`
-     - directory → \`{ transport: 'directory_path', path, label?, userIntent? }\`
-     - pasted brief / written design context → \`{ transport: 'text', content, label?, userIntent? }\`
-     Image-only and video-only calls (no URLs) are supported. Do not invent a URL for a local file.
-
-   Response (source-grounded): \`{ sessionId, stage: 'awaiting_source_plan', mode: 'zero_to_one', sourcePlanWorkItem, nextAction: 'continue_variants', destinationPath, visualEditor?, editorNextAction? }\`. Share \`visualEditor.url\` with the user immediately. If \`editorNextAction\` is present, keep that structured \`watch_for_changes\` loop alive on \`visualEditor.sessionId\` while you drive source planning and generation.
-
-2. **Process the source_plan work item.** Inspect the raw \`input.userContext\` natively (open URLs, \`Read\` images, run the Describe Motion protocol on videos), choose actions from \`input.availableActions\`, and report the metadata they produce:
-   - For visual references, report an \`extract_design_system\` action with linked \`design_system\` metadata. Use the existing **extract_inspiration_context** / design-context capability named in \`availableActions\`. Provide \`data.designMarkdown\` (a DESIGN.md matching the bundled catalog shape under \`src/services/templates/designmd/*.md\`: Visual Theme & Atmosphere → Color Palette & Roles → Typography Rules → Component Stylings → Layout Principles → Depth & Elevation → Do's & Don'ts → Responsive Behavior → Agent Prompt Guide; write \`Not observed\` for sections you cannot determine) or the structured observations Rivet synthesizes DESIGN.md from.
-   - For motion references, report a \`describe_motion\` action with linked \`motion_guidance\` metadata (run the **Describe Motion protocol** below; the spec becomes \`data.motionMarkdown\`). One \`describe_motion\` action per distinct interaction. Treat motion guidance as authoritative timing/easing/choreography — visual styling can diverge per variant, motion fidelity should not.
-   - Every reported action MUST have matching metadata linked by \`actionId\`; otherwise Rivet rejects the report. Use the stable \`id\` values from \`input.userContext\` as \`sourceIds\`.
-   - \`executionPlan.mode\`: \`vite_app\` for requests needing large assets / Three.js / package dependencies / routing; \`static_preview\` for self-contained HTML/CSS/JS prototypes. If ambiguous, set \`executionPlan.userQuestion\` instead of guessing — Rivet surfaces it as a clarification blocker.
-
-3. **Call \`report_work_item\`** with \`{ kind: 'source_plan', sessionId, workItemId, leaseId, attempt, sourcePlan: { actions, metadata, executionPlan, bindings? } }\`. Response: \`{ stage: 'awaiting_briefs', briefWorkItem, executionPlan, nextAction: 'report_work_item' }\`.
-
-4. **Report briefs and start generating — no approval gate.** Call \`report_work_item(kind='brief')\` with N briefs; the server starts every direction immediately and returns \`stage: 'work_items_ready'\`. Do NOT pause to ask the user to approve the briefs first. Then call \`continue_variants({ action: 'request_work' })\` and follow Sub-flow A steps 2-5. Work items are \`static_preview\` or \`code_gen\` depending on \`executionPlan.mode\`. On commit, the apply payload is \`payload.kind === 'project-created'\` — the server materialized the chosen variant to \`destinationPath\`.
-
----
-
-${describe_motion_protocol_1.DESCRIBE_MOTION_PROTOCOL}
-
----
-
-### Rules
-
-- **Never** generate variants natively (${opts.nativeGenLabel}, parallel tool calls, your own creative process) without going through \`start_variants\` first.
-- **Sequential Varys accumulate — never orphan the earlier batch.** For an existing project, calling \`start_variants\` again while a session is live APPENDS the new directions to that SAME active session, so every batch renders side-by-side in the editor (Rivet keeps one active session per project and never supersedes it). Just call \`start_variants\` per Vary with distinct \`briefs\`; do not pass a prior \`sessionId\` or try to manage accumulation yourself. When a variant-request batch hands you a \`requestId\`, pass it straight through to \`start_variants\` so the editor maps its loading placeholders to the new cards.
-- Always pass the user's prompt verbatim — don't paraphrase.
-- Prefer \`start_variants\` (with the matching \`mode\`); it replaces the older multi-call kickoff and also handles project detection, \`open_visual_editor\`, and \`continue_variants(request_work)\` server-side for kickoff, but it is not a durable watcher. When it returns \`editorNextAction\`, the host agent must keep the \`watch_for_changes\` loop active. The standalone \`open_visual_editor\` stays registered for the Visual Editor flow (point-and-click changes without variants).
-- For source-grounded fresh projects, pass the raw references as \`userContext\` to \`start_variants\` and do the design/motion extraction DURING source planning (report \`extract_design_system\` / \`describe_motion\` actions with metadata) — don't pre-summarize references before kickoff.
-- Briefs are never an approval gate — reporting them starts the directions immediately. Do not pause to ask the user "do these look good?" before generating. If you mention briefs in chat at all they are PLAIN TEXT; 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_variants({ sessionId, variantId })\` when the user clicks the cancel button on a card. You do not need to call this from the agent side. Call \`cancel_variants\` without a \`variantId\` to kill the entire session.
-- **Honor aborts mid-generation.** When the user removes or cancels a direction while it is still generating, the very next \`report_work_item(kind='status')\` for that work item returns \`{ aborted: true }\`. Treat that as a hard stop for that one direction: abandon it immediately, do NOT retry or re-report it, and keep going on the rest. For directions that take a while to build, send periodic \`status: 'running'\` heartbeats through \`report_work_item(kind='status')\` so an abort is caught early instead of after you have spent the work — a cleared lease surfacing as \`{ aborted: true }\` (rather than an error) is the signal to drop it.
-- 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. This whole-page bar applies when there is NO \`target\`; when the request targets a specific element/file/route, scope the change to that element and its immediate section instead and leave the rest of the page intact.
-- **QA re-lease**: an existing-project \`code_gen\` work item re-surfaced by \`request_work\` with \`input.qaRetry\` failed the diff task-fit QA gate — its diff added no styling, components, or structured markup for the requested design. Read the QA notes, regenerate that variant so the diff implements the design, then re-report — at most one retry per variant. After the retry a still-empty diff fails the variant terminally rather than looping.`;
-}
-//# sourceMappingURL=shared-variants-protocol.js.map

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

@@ -1 +0,0 @@
-{"version":3,"file":"shared-variants-protocol.js","sourceRoot":"","sources":["../../../src/utils/skills/shared-variants-protocol.ts"],"names":[],"mappings":";;;AA+IA,oEAwCC;AAMD,8DA2HC;AAxTD,yEAAsE;AAEtE;;;GAGG;AACU,QAAA,6BAA6B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;+KA2BkI,CAAC;AAEhL;;;;GAIG;AACU,QAAA,wBAAwB,GACnC,+FAA+F;IAC/F,+HAA+H;IAC/H,0FAA0F;IAC1F,mHAAmH,CAAC;AAEtH;;;GAGG;AACU,QAAA,cAAc,GAAG;;;;;;;;;2MAS6K,CAAC;AAE5M,0DAA0D;AAC7C,QAAA,sBAAsB,GAAG;;;;;;;;;qYAS+V,CAAC;AAEtY;;;;;;;;;;;GAWG;AACU,QAAA,kCAAkC,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mlBA4CiiB,CAAC;AAEplB;;;;;;;;;;;GAWG;AACH,SAAgB,4BAA4B,CAAC,IAU5C;IACC,OAAO;;;;;;;;KAQJ,IAAI,CAAC,cAAc,IAAI,IAAI,CAAC,QAAQ;;;;;;;;;;;;;;;;;;;;EAoBvC,IAAI,CAAC,cAAc,EAAE,CAAC;AACxB,CAAC;AAED;;;GAGG;AACH,SAAgB,yBAAyB,CAAC,IASzC;IACC,OAAO;;gMAEuL,IAAI,CAAC,cAAc,uJAAuJ,IAAI,CAAC,cAAc;;;;;;;;;;;;;;qaAcwC,gCAAwB;;;;;;;KAOxb,IAAI,CAAC,KAAK;;;;;;;;;;;KAWV,IAAI,CAAC,YAAY;;;;;;;;;;;;;;;;;qaAiB+Y,gCAAwB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA2C3b,mDAAwB;;;;;;0CAMgB,IAAI,CAAC,cAAc;;;;;;;;;;;;icAYoY,CAAC;AAClc,CAAC"}