"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.PICKING_THE_FLOW_TABLE = exports.BRIEF_FORMAT_INSTRUCTION = void 0;
exports.buildAgentVariantsSection = buildAgentVariantsSection;
const describe_motion_protocol_1 = require("./describe-motion-protocol");
/**
 * 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", "use rivet here", "make a visual change to X" — **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. |
| "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 started 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, 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 (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 here because the zero-to-one destination is a brand-new directory the server derives — it doesn't exist on disk yet, so \`detect_project\` on it would fail. 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_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) — \`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\`), 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 \`sourceContext\`. When \`sourceContext\` carries \`sourceUrls\`, \`sourceArtifacts\`, or \`sourceIntent\`, start_variants detects the source-grounded input and runs the source-research flow automatically — returning \`stage: 'awaiting_source_plan'\` instead of the prompt-only single-call \`work_items_ready\`. 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)
   - \`sourceContext\`:
     - \`sourceUrls\` (optional): 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, written design context, **agent-described images**, OR **agent-described videos**. If the user attached one or more images in chat OR referenced an image file path: for path references, open the file with your \`Read\` tool first; then in both cases describe what you see — layout, colour palette, typography, component patterns, voice — and pass each image as a \`sourceArtifacts\` entry with \`kind: 'visualBrief'\` (overall design system) or \`kind: 'screenshotNotes'\` (specific screen). If the user attached a video, gif, screen recording, or frame sequence OR referenced a video file path: run the **Describe Motion protocol** (see section below) to extract a structured motion spec, and pass each spec as a \`sourceArtifacts\` entry with \`kind: 'motionBrief'\`. One \`motionBrief\` per distinct interaction in the video — do not merge multiple interactions into one entry. Do not invent a URL for an image or video. \`sourceArtifacts\` can fully replace \`sourceUrls\` — image-only and video-only calls (no URLs) are supported.

   Response (source-grounded): \`{ sessionId, stage: 'awaiting_source_plan', mode: 'zero_to_one', sourcePlanWorkItem, nextAction: 'continue_variants', destinationPath, visualEditor? }\`. Share \`visualEditor.url\` with the user immediately.

2. **Process the source_plan work item.** Classify the inspiration sources, produce per-slot DESIGN.md, and choose \`executionPlan.mode\`:
   - DESIGN.md per slot matches 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). For sections you cannot determine from the source, write \`Not observed\` rather than inventing values.
   - When a \`motionBrief\` is present, fold its timing / easing / choreography into the **Component Stylings** and any motion-related guidance sections of the matching DESIGN.md slot, and treat the motionBrief as authoritative for those properties — visual styling can diverge per variant, motion fidelity should not.
   - \`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_source_plan\`** with \`{ sessionId, workItemId, leaseId, attempt, sourcePlan }\`. Response: \`{ stage: 'awaiting_briefs', briefWorkItem, executionPlan, nextAction: 'report_variant_briefs' }\`.

4. **Report briefs and start generating — no approval gate.** Call \`report_variant_briefs\` 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.
- 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 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_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.
- **Honor aborts mid-generation.** When the user removes or cancels a direction while it is still generating, the very next \`report_variant_complete\` 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_variant_complete\` 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.`;
}
//# sourceMappingURL=shared-variants-protocol.js.map