@hegemonart/get-design-done 1.36.3 → 1.37.1

package/.claude-plugin/marketplace.json

@@ -5,14 +5,14 @@
   },
   "metadata": {
     "description": "Get Design Done — 5-stage agent-orchestrated design pipeline with 9 connections, handoff-first workflow, bidirectional Figma write-back, 22+ specialized agents, queryable knowledge layer (intel store, dependency analysis, learnings extraction), and a self-improvement loop (reflector, frontmatter + budget feedback, global-skills layer). v1.20.0 ships the SDK foundation: gdd-state MCP server (11 typed tools), lockfile-safe STATE.md mutations, event stream, and resilience primitives (jittered-backoff, rate-guard, error-classifier, iteration-budget) for rate-limit + 429 + context-overflow recovery. Full CI/CD pipeline (Node 22/24 × Linux/macOS/Windows) and release automation (auto-tag + GitHub Release + release-time smoke test).",
-    "version": "1.36.3"
+    "version": "1.37.1"
   },
   "plugins": [
     {
       "name": "get-design-done",
       "source": "./",
       "description": "Agent-orchestrated 5-stage design pipeline: Brief → Explore → Plan → Design → Verify. 22+ specialized agents, 9 connections (Figma, Refero, Preview, Storybook, Chromatic, Figma Writer, Graphify, Pinterest, Claude Design), Claude Design handoff, bidirectional Figma write-back, and a queryable intel store (.design/intel/) for dependency and learnings queries. Standalone commands: style, darkmode, compare, figma-write, graphify, handoff, analyze-dependencies, skill-manifest, extract-learnings. Embeds NNG heuristics, WCAG thresholds, typographic systems, motion framework, and anti-pattern catalog. Ships with a full CI/CD pipeline (Node 22/24 × Linux/macOS/Windows) and release automation. Optimization layer (v1.0.4.1, retroactive): gdd-router + gdd-cache-manager skills, PreToolUse budget-enforcer hook, tier-aware agent frontmatter, lazy checker gates, streaming synthesizer, /gdd:warm-cache + /gdd:optimize commands, and cost telemetry at .design/telemetry/costs.jsonl — targeting 50-70% per-task token-cost reduction with no quality-floor regression. v1.20.0 SDK foundation: gdd-state MCP server (11 typed tools), lockfile-safe STATE.md mutations, event stream at .design/telemetry/events.jsonl, resilience primitives (jittered-backoff, rate-guard, error-classifier, iteration-budget) with rate-limit + 429 + context-overflow recovery, and TypeScript toolchain.",
-      "version": "1.36.3",
+      "version": "1.37.1",
       "author": {
         "name": "hegemonart"
       },

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "get-design-done",
   "short_name": "gdd",
-  "version": "1.36.3",
+  "version": "1.37.1",
   "description": "Agent-orchestrated 5-stage design pipeline: Brief → Explore → Plan → Design → Verify. 22+ specialized agents, 9 connections (Figma, Refero, Preview, Storybook, Chromatic, Figma Writer, Graphify, Pinterest, Claude Design), handoff-first workflow via Claude Design bundles, bidirectional Figma write-back (annotations, Code Connect), queryable intel store (`.design/intel/`) for O(1) design surface lookups, and self-improvement loop (reflector agent, frontmatter + budget feedback, global-skills layer at `~/.claude/gdd/global-skills/`). Standalone commands: style, darkmode, compare, figma-write, graphify, handoff, analyze-dependencies, skill-manifest, extract-learnings, reflect, apply-reflections. Embeds NNG heuristics, WCAG thresholds, typographic systems, motion framework, and anti-pattern catalog. Ships with a full CI/CD pipeline (Node 22/24 × Linux/macOS/Windows, lint + schema + frontmatter + stale-ref + shellcheck + gitleaks + injection-scan + blocking size-budget) and release automation (auto-tag + GitHub Release + release-time smoke test). Optimization layer (v1.0.4.1, retroactive): gdd-router + gdd-cache-manager skills, PreToolUse budget-enforcer hook, tier-aware agent frontmatter, lazy checker gates, streaming synthesizer, /gdd:warm-cache + /gdd:optimize commands, and cost telemetry at .design/telemetry/costs.jsonl — targeting 50-70% per-task token-cost reduction with no quality-floor regression. v1.20.0 SDK foundation: gdd-state MCP server (11 typed tools), lockfile-safe STATE.md mutations, event stream at .design/telemetry/events.jsonl, resilience primitives (jittered-backoff, rate-guard, error-classifier, iteration-budget) with rate-limit + 429 + context-overflow recovery, and TypeScript toolchain. v1.27.7 ships gdd-mcp (Phase 27.7): 12 read-only MCP tools for sub-3s priming. v1.28.0 (Phase 28): Foundational References Tier 2 — 5 new reference files (color-theory, composition, proportion-systems, i18n, contrast-advanced), 2 verifier i18n probes + 1 explore i18n-readiness probe, 12 additive cross-link insertions across 10 existing references, 2 orthogonal audit-scoring lens-tags (composition_alignment + i18n_readiness).",
   "author": {
     "name": "hegemonart",

package/CHANGELOG.md

@@ -4,6 +4,27 @@ All notable changes to get-design-done are documented here. Versions follow [sem
 
 ---
 
+## [1.37.1] - 2026-06-01
+
+### Phase 37.1 — AI-Native Tools Wave 2 (Framer + Penpot + Webflow + v0.dev + Plasmic + Builder.io)
+
+First sub-phase of the split **Phase 37**. Schedules Phase 14's explicit backlog: six AI-native design tools, each under the existing connection capability contract (canvas | generator | shared probe). **No new runtime dependency, no new egress** — each tool is an opt-in user-connected MCP/API, probed via ToolSearch/env; absent → degrade-to-code-only.
+
+### Added
+
+- **`connections/framer.md`** + **`penpot.md`** + **`webflow.md`** — canvas-category specs. Framer (read frames + write proposals), Penpot (open-source Figma alt; self-hosted-vs-cloud probe), Webflow (read site structure as a design-adaptation source — not CMS authoring). Contribute at the **design** stage.
+- **`connections/v0-dev.md`** + **`plasmic.md`** + **`builder-io.md`** — generator-category specs. v0.dev (MCP-first → REST + `V0_API_KEY`), Plasmic (dual: canvas read + code emission), Builder.io Visual Copilot (pull-only this phase). Drive the **generator** stage.
+- **`agents/design-component-generator.md`** — Step-0 detection + `--tool` flag extended to `v0|plasmic|builder-io`, plus compact `<!-- impl: v0 -->` / `<!-- impl: plasmic -->` / `<!-- impl: builder-io -->` sections that cross-link to the connection specs (231 → 259, under the LARGE budget). Priority: magic-patterns > 21st.dev > v0 > plasmic > builder-io; `--tool` overrides.
+- **`connections/connections.md`** + onboarding — 21 → 27 onboarded (6 Active rows + 6 capability-matrix rows: framer/penpot → canvas, webflow/v0/builder-io → generator, **Plasmic → canvas + generator dual**; probes + value-prop + setup matrix).
+
+### Notes
+
+- **No new runtime dependency, no new egress** — opt-in MCP/API connections; the generator never writes to `src/` without proposal→confirm.
+- 6-manifest lockstep at **v1.37.1** + `OFF_CADENCE_VERSIONS.add('1.37.1')` + the 26 live-pinned `manifests-version.txt` baselines forward-propagated 1.36.3 → 1.37.1 (opens the v1.37.x arc).
+- Inventory relock: connection-list 29 → 35 (+6), onboarding → 27, tarball golden 670 → 676 (+6). Registry unchanged (no `reference/` doc); no new skill/agent dir (the generator agent pre-exists).
+
+---
+
 ## [1.36.3] - 2026-06-01
 
 ### Phase 36.3 — Knowledge Tier-3: Conversational UI — completes Phase 36

package/README.md

@@ -162,6 +162,10 @@ GDD now opens the motion **exports** a project ships. The pure, dependency-free
 
 [`reference/conversational-ui.md`](reference/conversational-ui.md) closes a zero-coverage surface: voice flows + chatbots. It codifies voice-flow reprompts (no-input / no-match → human handoff), multi-turn dialogue (context carryover, slot-filling, repair), **prompt-as-UX** (the assistant's persona/tone/boundaries as a versioned design artifact), chatbot empty-states + suggested replies, voice-first onboarding, and error recovery + accessibility. [`design-context-builder`](agents/design-context-builder.md) detects a `conversational` project type (brief keywords + chatbot/voice deps like `botpress` / `dialogflow` / `actions-on-google` / `ask-sdk-core`) and loads the pack into context. **No new runtime dependency.** This is the **final sub-phase of Phase 36 — which is now complete** (domain packs + motion-tool verification + conversational UI).
 
+### AI-native tools — Wave 2 (v1.37.1)
+
+Six more AI-native design tools join the connection layer (Phase 14's backlog, now scheduled): **Framer**, **Penpot**, and **Webflow** (canvas-category — read frames/boards/structure as design sources) plus **v0.dev**, **Plasmic**, and **Builder.io** (generator-category — prompt→component, wired into [`design-component-generator`](agents/design-component-generator.md) as `<!-- impl: -->` sections). Plasmic is dual (canvas + generator). Onboarding grows 21 → 27. Each is an opt-in MCP/API connection that degrades to code-only when absent — **no new runtime dependency**. First sub-phase of Phase 37 (Greenfield DS Bootstrap follows).
+
 ### Previous releases
 
 - **v1.26.0** — Headless Model Resolver (per-runtime tier→model map, `resolved_models` router field, per-runtime price tables, `reasoning-class` runtime-neutral alias).

package/agents/design-component-generator.md

@@ -31,7 +31,11 @@ Read `.design/STATE.md` `<connections>` block. Check for:
 - `magic-patterns: available` → prefer magic-patterns (DS-aware + preview_url); use magic-patterns impl
 - `21st-dev: available` (and magic-patterns not available) → use 21st.dev impl
 - Both available → prefer magic-patterns (DS-aware + preview_url); 21st.dev as fallback
-- Neither available → Print: "No component generator configured. Set up 21st.dev or Magic Patterns per connections/21st-dev.md or connections/magic-patterns.md." STOP.
+- `v0-dev: available` → use the v0 impl (generator; MCP-first → REST + `V0_API_KEY`)
+- `plasmic: available` → use the plasmic impl (canvas read + code emission)
+- `builder-io: available` → use the builder-io impl (Visual Copilot; pull-only this phase)
+- Priority when several are available: magic-patterns > 21st.dev > v0 > plasmic > builder-io (DS-awareness + preview first); `--tool` overrides.
+- None available → Print: "No component generator configured. Set up 21st.dev / Magic Patterns / v0.dev / Plasmic / Builder.io per the matching `connections/<tool>.md`." STOP.
 
 ---
 
@@ -39,7 +43,7 @@ Read `.design/STATE.md` `<connections>` block. Check for:
 
 Parse flags:
 - `--dry-run` — emit proposal only, no writes
-- `--tool 21st|magic-patterns` — override generator selection
+- `--tool 21st|magic-patterns|v0|plasmic|builder-io` — override generator selection
 - `--ds <design-system>` — design system target: `shadcn | tailwind | mantine | chakra`
 - Component description (required positional arg): natural-language component spec
 
@@ -164,6 +168,30 @@ After generating, write `preview_url` to STATE.md `<generator>` block (see Step
 
 <!-- /impl: magic-patterns -->
 
+<!-- impl: v0 -->
+## v0.dev Implementation
+
+### Step 2D — v0.dev: Generate
+
+Probe per `connections/v0-dev.md` (MCP-first → REST + `V0_API_KEY`). Generate from the description + DS context: MCP available → call the v0 generate tool (verify the name via ToolSearch) with the spec + `--ds` target; REST fallback → POST the spec to the v0 Platform API with `V0_API_KEY`. v0 emits React + Tailwind + shadcn by default — reconcile to the project `--ds`. Carry into Step 3 (proposal); never write to `src/` without confirmation. Full tool catalogue + setup: `connections/v0-dev.md`.
+<!-- /impl: v0 -->
+
+<!-- impl: plasmic -->
+## Plasmic Implementation
+
+### Step 2E — Plasmic: Read canvas + emit code
+
+Probe per `connections/plasmic.md`. Plasmic is dual: **canvas read** → pull the Plasmic project's components as a design source (like Figma); **code emission** → emit the component code for the `--ds` target. Reconcile emitted code to the project DS; carry into Step 3 (proposal). Detail: `connections/plasmic.md`.
+<!-- /impl: plasmic -->
+
+<!-- impl: builder-io -->
+## Builder.io Implementation
+
+### Step 2F — Builder.io: Visual Copilot (pull-only)
+
+Probe per `connections/builder-io.md` (MCP-first → `BUILDER_API_KEY`). **Pull-only this phase**: generate / ingest patterns via Visual Copilot, reconcile to `--ds`, carry into Step 3 (proposal). NO write-back this phase. Detail: `connections/builder-io.md`.
+<!-- /impl: builder-io -->
+
 ---
 
 ## Step 3 — Build Proposal

package/connections/builder-io.md

@@ -0,0 +1,131 @@
+# Builder.io — Connection Specification
+
+This file is the connection specification for Builder.io Visual Copilot within the get-design-done pipeline. Builder.io Visual Copilot is an AI-native **generator-category** tool — it converts designs (Figma frames, imported layouts) into framework code and generates UI components from descriptions. It integrates via the Builder MCP / Visual Copilot or via a direct API key. See `connections/connections.md` for the full connection index and capability matrix.
+
+**Scope this phase: PULL-ONLY.** Builder.io is used to *ingest patterns* and *generate* code into the pipeline. Write-back (publishing components or content models back to Builder.io spaces) is **deferred** — not wired this phase. See [21st.dev](21st-dev.md) for the sibling generator-category spec.
+
+---
+
+## Setup
+
+### Prerequisites
+
+**Path A — Builder MCP / Visual Copilot (preferred):**
+- A [Builder.io](https://www.builder.io) account
+- The Builder MCP or Visual Copilot enabled in your Claude environment
+- No additional manual setup when the connector is enabled
+
+**Path B — API key fallback:**
+- A Builder.io account and API key (public/private key for your Builder space)
+- `BUILDER_API_KEY` environment variable set
+- MCP server install (example):
+  ```bash
+  claude mcp add builder-io --transport http https://mcp.builder.io/sse \
+    -e BUILDER_API_KEY=$BUILDER_API_KEY
+  ```
+
+### Verification
+
+```
+ToolSearch({ query: "builder", max_results: 5 })
+```
+
+Non-empty results including a Builder generate/figma-import tool → connector available (Path A).
+Empty → check `BUILDER_API_KEY`; if set, install Path B and restart the Claude Code session.
+
+---
+
+## Probe Pattern
+
+Builder.io uses a **MCP-first, env-fallback** probe. Check for Builder tools first; fall back to the API key env var.
+
+```
+ToolSearch({ query: "builder", max_results: 5 })
+→ Non-empty  → builder-io: available (MCP / Visual Copilot)
+→ Empty      → check BUILDER_API_KEY env var
+               set    → builder-io: available (API key path)
+               unset  → builder-io: not_configured
+```
+
+Three-value schema written to `.design/STATE.md` `<connections>`:
+
+| Value | Meaning |
+|-------|---------|
+| `available` | Builder MCP tools found, OR `BUILDER_API_KEY` is set |
+| `not_configured` | No Builder tools and no API key — skip all Builder.io steps |
+| `error` | Tools present but probe/auth failed — degrade, surface the error, never block |
+
+Write result to STATE.md `<connections>`: `builder-io: <status>`
+
+Fallback: when `not_configured`, the generator stage skips Builder.io and falls back to another generator (if available) or degrades to manual code-only build.
+
+---
+
+## Builder.io Tools
+
+Builder.io exposes Visual Copilot capabilities through MCP tools. Names and exact signatures vary by connector version — discover them via the probe (`ToolSearch({ query: "builder" })`) rather than hardcoding. Described generically, the relevant **pull-only** capabilities are:
+
+| Capability | Stage | Purpose |
+|------------|-------|---------|
+| Figma → code generate | generator | Convert a selected Figma frame/URL into framework code (React, Vue, Svelte, Angular, etc.) |
+| Describe → component generate | generator | Generate a UI component from a natural-language description |
+| Pull / ingest pattern | generator | Fetch an existing Builder block/pattern as a starting point for adaptation |
+
+### Typical generate inputs (generic)
+
+| Input | Values | Notes |
+|-------|--------|-------|
+| `source` | Figma frame URL / selection, or description | Pull-side input — the design or spec to convert |
+| `framework` | `"react" \| "vue" \| "svelte" \| "angular"` | Auto-detected from the project in the explore stage |
+| `styling` | `"tailwind" \| "css" \| "styled-components"` | Auto-detected; defaults to the project's active styling |
+
+Returns generated source code (and, where supported, a preview reference) for the generator stage to consume.
+
+---
+
+## Pipeline Integration
+
+Builder.io is wired as a **generator-category** connection: it feeds the **generator** stage only.
+
+| Stage | What Builder.io provides |
+|-------|--------------------------|
+| generator | Figma → code / describe → component generation via `agents/design-component-generator.md` |
+| generator | Pull / ingest an existing Builder pattern as adaptation source |
+
+### Generator wiring
+
+The generator stage dispatches to Builder.io through the `<!-- impl: builder-io -->` section of `agents/design-component-generator.md`. That agent:
+
+1. Reads `builder-io: available` from STATE.md `<connections>` before dispatching.
+2. Resolves the generate inputs (Figma source or description; `framework`; `styling`) from project context.
+3. Calls the Builder generate/pull capability and captures the returned source code.
+4. Writes the generated component into the project as a **proposal**, not a direct commit.
+
+### Pull-only scope (write-back deferred)
+
+This phase wires **ingest + generate only**:
+
+- **Ingest**: pull existing Builder patterns/blocks as adaptation sources.
+- **Generate**: Figma → code and describe → component into the pipeline.
+- **NO write-back**: the pipeline does **not** publish components, content models, or edits back to Builder.io spaces this phase. Write-back / roundtrip is explicitly **deferred** to a later phase.
+
+### Proposal → confirm
+
+Generated code is **never** auto-inserted. The generator surfaces the result as a proposal; the design-executor confirms adoption with the user before the code is written into the working tree. This mirrors the decision-gate pattern used by sibling generators (see [21st.dev](21st-dev.md)) — the agent surfaces candidates, the user/executor decides.
+
+---
+
+## Fallback Behavior
+
+When `builder-io: not_configured`:
+- Print: `Builder.io not configured — Visual Copilot generator skipped.`
+- Falls back to another generator-category connection if one is `available` (e.g. 21st.dev, Magic Patterns).
+- If no generator is configured, the generator stage **degrades to code-only**: the design-executor proceeds with a manual component build.
+- Builder.io **never blocks** the pipeline — a missing or errored connection only removes one generator option; the generator stage always has a code-only path.
+
+When `builder-io: error`:
+- Surface the probe/auth error to the user, mark the connection degraded, and fall back as above. Do not retry in a loop and do not block.
+
+---
+
+Do NOT edit the connection index here — the 37.1 wiring plan adds the Active-Connections row + matrix entry.

package/connections/connections.md

@@ -2,7 +2,7 @@
 
 This directory contains connection specifications for external tools and MCPs that the get-design-done pipeline integrates with. Each connection has its own spec file. This file is the index.
 
-**Getting started:** run `/gdd:connections` for the interactive onboarding wizard — it probes all 21 connections, recommends setup based on your project type, and walks you through installing each one (auto-run for reversible MCP adds, copy-command for everything else). You can also run `/gdd:connections list` for a read-only status check or `/gdd:connections <name>` to jump to a single connection's setup.
+**Getting started:** run `/gdd:connections` for the interactive onboarding wizard — it probes all 27 connections, recommends setup based on your project type, and walks you through installing each one (auto-run for reversible MCP adds, copy-command for everything else). You can also run `/gdd:connections list` for a read-only status check or `/gdd:connections <name>` to jump to a single connection's setup.
 
 ---
 
@@ -37,6 +37,12 @@ This directory contains connection specifications for external tools and MCPs th
 | Notion | Active | [`connections/notion.md`](connections/notion.md) | **Export** write-path (not a pipeline stage) — `mcp__notion__*` (ToolSearch probe); `/gdd:export --format notion`; redact + `GDD_DISABLE_NOTION` kill-switch; degrade-to-HTML |
 | Lottie | Active | [`connections/lottie.md`](connections/lottie.md) | **Optional** motion verify (Lottie JSON); static floor = `validate-motion.cjs` (MO-* warnings + perf budget); player opt-in; WARN-never-block, degrade-to-static/code-only (36.2, D-02/D-03) |
 | Rive | Active | [`connections/rive.md`](connections/rive.md) | **Optional** motion verify (Rive `.riv`); size + RIVE-header floor; deep state-machine graph via opt-in Rive runtime, else manual-review advisory; WARN-never-block (36.2, D-02/D-04) |
+| Framer | Active | [`connections/framer.md`](connections/framer.md) | **AI-native** (Wave 2, canvas) — read frames + write proposals; MCP probe; degrade-to-code-only (37.1) |
+| Penpot | Active | [`connections/penpot.md`](connections/penpot.md) | **AI-native** (Wave 2, canvas) — open-source Figma alt; self-hosted-vs-cloud probe; degrade-to-code-only (37.1) |
+| Webflow | Active | [`connections/webflow.md`](connections/webflow.md) | **AI-native** (Wave 2, generator) — read site structure as an adaptation source (not CMS authoring); degrade-to-code-only (37.1) |
+| v0.dev | Active | [`connections/v0-dev.md`](connections/v0-dev.md) | **AI-native** (Wave 2, generator) — Vercel v0; MCP-first → REST + `V0_API_KEY`; component-generator `v0` impl (37.1) |
+| Plasmic | Active | [`connections/plasmic.md`](connections/plasmic.md) | **AI-native** (Wave 2, dual) — canvas read + code emission; component-generator `plasmic` impl (37.1) |
+| Builder.io | Active | [`connections/builder-io.md`](connections/builder-io.md) | **AI-native** (Wave 2, generator) — Visual Copilot, pull-only this phase; component-generator `builder-io` impl (37.1) |
 
 ---
 
@@ -66,6 +72,12 @@ Each cell describes what the connection contributes at that pipeline stage, or `
 | Print-Renderer | — | — | — | print render-test target (pdf-executor) | rendered PDF/page evidence when the print-render is available, else degrade to the static print-CSS validator / code-only (D-03) | — | — | — | — |
 | Lottie | — | — | — | — | Lottie-export motion check: `validate-motion.cjs` (MO-FR/DUR/IMG/BUDGET) when present, WARN-never-block (D-02) | — | — | — | — |
 | Rive | — | — | — | — | Rive-export motion check: size + RIVE-header floor; state-machine graph via opt-in runtime, else manual-review advisory; WARN (D-02/D-04) | — | — | — | — |
+| Framer | — | — | — | canvas source (read frames, write proposals) | — | ✓ | — | — | — |
+| Penpot | — | — | — | canvas source (read boards/components) | — | ✓ | — | — | — |
+| Webflow | — | — | — | structure / adaptation source | — | — | ✓ | — | — |
+| v0.dev | — | — | — | component-generator (v0 impl) | — | — | ✓ | — | — |
+| Plasmic | — | — | — | component-generator (plasmic impl) + canvas read | — | ✓ | ✓ | — | — |
+| Builder.io | — | — | — | component-generator (builder-io impl) | — | — | ✓ | — | — |
 | Lazyweb | — | reference search via `lazyweb_search` (**Tier 1 — free, tried first**; D-01); complements refero/pinterest | — | — | — | — | — | — | — |
 | Mobbin | — | reference search via mobbin tools (**Tier 2 — paid, mobile/flow-level**; D-01); complements refero/lazyweb | — | — | — | — | — | — | — |
 | Slack | — | — | — | — | — | — | — | verify-fail/audit-pass/ship → Slack webhook (routed, redacted, degrade-to-noop; D-04/D-05) | — |

package/connections/framer.md

@@ -0,0 +1,126 @@
+# Framer — Connection Specification
+
+This file is the connection specification for **Framer** within the get-design-done pipeline. Framer is an AI-native canvas design tool (Wave 2). Like Figma, it is a **canvas-category** connection: GDD reads the current Framer selection/frames as a design source and writes annotated design proposals back. It is **not** a code generator — the pipeline never asks Framer to emit production components. See `connections/connections.md` for the full connection index and capability matrix.
+
+This is an **opt-in, user-connected** tool. There is no bundled dependency — GDD ships no Framer client. The connection only activates when the user has independently registered a Framer MCP (or plugin bridge) in their session.
+
+---
+
+## Setup
+
+### Prerequisites
+- A [Framer](https://www.framer.com) account with edit access to the target project.
+- A Framer API token (or plugin authorization) — generated from the Framer account/workspace settings and scoped to the projects GDD may read or propose against.
+- A Framer MCP server **or** the Framer plugin bridge registered in the Claude Code session. Framer's surface evolves quickly; resolve the exact transport at runtime via the probe below rather than hardcoding it.
+
+### How to connect
+
+**Option A — Framer MCP (preferred).** Register the Framer MCP over HTTP transport, supplying the API token via environment:
+
+```
+claude mcp add --transport http framer https://<framer-mcp-endpoint>
+```
+
+Set the token in the session environment (name as documented by the Framer MCP — commonly `FRAMER_API_TOKEN`). Restart the Claude Code session after registering. Auth prompts on first tool call.
+
+**Option B — Framer plugin bridge.** If Framer exposes a desktop/plugin bridge instead of a hosted MCP, install that plugin inside Framer and register its local endpoint as an MCP server named `framer`. This path mirrors Figma's desktop Dev Mode bridge: it serves the current open project to the session over local HTTP.
+
+The pipeline auto-detects any server whose name matches `/framer/i` (e.g., `framer`, `Framer`, UUID-prefixed instances) and records the resolved tool prefix in `STATE.md`. Exact tool names are **not** assumed — they are discovered at runtime.
+
+### Verification
+
+After session restart, run:
+
+```
+ToolSearch({ query: "framer", max_results: 10 })
+```
+
+Expect non-empty results under a `/framer/i` prefix, including at least one read tool (selection/frame reader) and, for write-back, a proposal/annotation tool. If empty, re-register the MCP and restart the session.
+
+---
+
+## Probe Pattern
+
+**MCP-first. Call `ToolSearch` before any Framer tool — always.** Framer tools are commonly in the deferred tool set and are not loaded into context at session start. Calling a deferred tool directly fails. `ToolSearch` loads the tools and confirms their presence in one call.
+
+```
+ToolSearch({ query: "framer", max_results: 10 })
+→ Empty       → framer: not_configured   (no Framer MCP registered; skip all Framer steps)
+→ Non-empty   → resolve prefix matching /framer/i, then live-probe a read tool:
+                 → read tool succeeds  → framer: available (prefix=mcp__<prefix>__)
+                 → read tool errors    → framer: unavailable (auth expired / no project open / rate-limited)
+```
+
+Three-value schema written to `.design/STATE.md` under `<connections>`:
+
+| Value | Meaning |
+|-------|---------|
+| `available` | A `/framer/i` read tool resolved and the live call succeeded. |
+| `unavailable` | A Framer tool is in the session but errored (auth expired, no project open, rate-limited). |
+| `not_configured` | No server matching `/framer/i` — MCP not registered. |
+
+Example STATE block:
+
+```xml
+<connections>
+framer: available (prefix=mcp__framer__)
+figma: not_configured
+</connections>
+```
+
+Re-probe at every stage entry, even if Framer was `available` previously — the resolved prefix and availability can change between sessions.
+
+---
+
+## Framer Tools
+
+Tool names take the form `mcp__<prefix>__<tool>` where `<prefix>` is the resolved server name from the probe (commonly `framer`). **Verify exact tool names via `ToolSearch` at runtime** — the table below describes capabilities generically, not literal identifiers.
+
+**Reads (design source):**
+
+| Capability | Returns | Pipeline use |
+|------------|---------|--------------|
+| Selection reader | The currently selected frame(s)/layer(s): node IDs, names, types, geometry | **In scope** — design source for the current selection; also the availability probe |
+| Frame / canvas reader | Frame tree for the open project or page: hierarchy, layout, component instances | **In scope** — reads frames as a design source for the design stage |
+| Token / style reader | Color, spacing, typography, and shared-style definitions used in the project | **In scope (when present)** — supplements token extraction, mirroring Figma `get_variable_defs` |
+| Screenshot / preview | Rendered image of the selected frame | **In scope (opt-in)** — visual reference capture; not invoked by default |
+
+**Writes (design proposals):**
+
+| Capability | Returns | Pipeline use |
+|------------|---------|--------------|
+| Annotation / proposal writer | Write operation result | **In scope** — writes annotated design proposals (notes, decision callouts) back onto frames |
+
+GDD only ever writes **annotated proposals** — design-decision notes and callouts attached to frames. It does not author production components or replace user content. Every write goes through a **proposal → confirm** UX: the agent builds a numbered operation list and the user confirms before any write tool is called. There is no auto-approve path.
+
+---
+
+## Pipeline Integration
+
+Framer is a **canvas-category** connection. It contributes at the **design** stage exactly as Figma and paper.design do (see `connections/figma.md`): read frames as a design source, write annotated proposals back. It does not participate in `scan`, `plan`, or `verify` as a code authority.
+
+| Stage | What Framer provides |
+|-------|----------------------|
+| design (read) | Read the current selection/frames as a **design source** — geometry, hierarchy, and (when present) token/style definitions feed the design proposal. |
+| design (write) | After the design proposal is built, offer to write **annotated proposals** back onto Framer frames via the proposal → confirm UX — only when `framer: available`. |
+| scan / plan / verify | Not used. Framer is a design-stage source, not a code authority. |
+
+The read path requires an open Framer project/selection. If nothing is selected, the frame reader is used for the open page; if no project is open, the live probe falls to `unavailable` and the stage continues on its non-Framer path. The write offer appears only when `framer: available` — never on `unavailable` or `not_configured`.
+
+---
+
+## Fallback Behavior
+
+When `framer` is `not_configured` or `unavailable`, the pipeline **degrades to code-only** and **never blocks**:
+
+- **design (read):** skip the Framer design-source step. Proceed with code-derived context and any other available canvas connection. No error is raised.
+- **design (write):** skip the proposal write-back offer entirely — no prompt, no output — on both `not_configured` and `unavailable`.
+- A standalone request to write proposals to Framer against `framer: not_configured` STOPs with a short install note (point the user at the Setup section above).
+
+Framer is an **enhancement, not a requirement**. Stages do not append a `<blocker>` for a missing Framer connection. Only if a `must_have` explicitly requires Framer data (reads or writes) should a blocker be appended.
+
+**Consumer contract.** Agents that call Framer tools MUST read the resolved prefix from `STATE.md` and construct tool names dynamically (`{prefix}<read_tool>`, `{prefix}<write_tool>`) rather than hardcoding `mcp__framer__`, and MUST treat `unavailable` and `not_configured` identically for the purpose of skipping Framer steps.
+
+---
+
+> ⚠︎ **Do NOT edit the connection index here** — the Active-Connections row and the capability-matrix entry in `connections/connections.md` are added by the **37.1 wiring plan**, not by this spec. This file documents the Framer connection in isolation; wiring it into the index is a separate, tracked step.

package/connections/penpot.md

@@ -0,0 +1,148 @@
+# Penpot — Connection Specification
+
+This file is the connection specification for **Penpot** within the get-design-done pipeline. Penpot is an open-source, self-hostable design and prototyping platform — an AI-native (Wave 2) alternative to Figma. It is a **canvas-category** tool: GDD reads boards and components, exports tokens, and writes design proposals back. See `connections/connections.md` for the full connection index and capability matrix, and `connections/figma.md` for the sibling canvas-category connection.
+
+GDD connects to **your** Penpot instance. It does **not** install, bundle, or host Penpot — there is no bundled dependency. You bring a running Penpot (self-hosted or cloud) plus an access token.
+
+---
+
+## Setup
+
+### Prerequisites
+
+- **A Penpot instance.** One of two deployment shapes:
+  - **Cloud** — the hosted service at [penpot.app](https://penpot.app). Base URL is `https://design.penpot.app`. No infrastructure to run.
+  - **Self-hosted** — a Penpot deployment you operate (Docker/Kubernetes), reachable at your own origin, e.g. `https://penpot.internal.example.com`. See [help.penpot.app](https://help.penpot.app) for deployment guidance.
+- **An access token.** Generated from your Penpot profile under **Settings → Access tokens**. Tokens are scoped to your account on whichever instance issued them — a cloud token does not authenticate against a self-hosted instance, and vice versa.
+- **One access path** — either:
+  - the **Penpot REST API / plugin** reached over `PENPOT_BASE_URL` + token (the env path), or
+  - a **Penpot MCP server** registered in the session (the MCP path).
+
+### Configuration
+
+The pipeline supports two interchangeable access paths. You only need one; if both are present, the probe resolves precedence (see **Probe Pattern**).
+
+**Env path (REST API / plugin).** Set two environment variables:
+
+```bash
+export PENPOT_BASE_URL="https://design.penpot.app"   # cloud
+# or, self-hosted:
+export PENPOT_BASE_URL="https://penpot.internal.example.com"
+export PENPOT_ACCESS_TOKEN="<your-penpot-access-token>"
+```
+
+`PENPOT_BASE_URL` is the **distinguishing signal** between cloud and self-hosted. The pipeline records the host so downstream stages know which deployment they are talking to.
+
+**MCP path.** Register a Penpot MCP server in Claude Code settings (`mcpServers.penpot`), passing `PENPOT_BASE_URL` and `PENPOT_ACCESS_TOKEN` through the server's `env`. Restart the session after install.
+
+### Verification
+
+```
+ToolSearch({ query: "penpot", max_results: 5 })
+```
+
+A non-empty result confirms the MCP path. For the env path, a `200` from `GET $PENPOT_BASE_URL/api/rpc/command/get-profile` (header `Authorization: Token $PENPOT_ACCESS_TOKEN`) confirms the credentials resolve. If the env path is unset and `ToolSearch` is empty, Penpot is `not_configured`.
+
+---
+
+## Probe Pattern
+
+Penpot exposes **two independent access paths**, and the probe checks **both** before resolving. This is the load-bearing distinction for this connection (SC#2): the env path additionally carries the **self-hosted-vs-cloud** signal, which downstream stages need.
+
+```
+Step 1 — Env probe (self-hosted vs cloud):
+  Read PENPOT_BASE_URL and PENPOT_ACCESS_TOKEN from the environment.
+    Both set    → env path present.
+                  Classify deployment from the host of PENPOT_BASE_URL:
+                    host == design.penpot.app   → deployment=cloud
+                    any other host              → deployment=self-hosted
+    Either unset → env path absent.
+
+Step 2 — MCP probe:
+  ToolSearch({ query: "penpot", max_results: 5 })
+    Non-empty → MCP path present (record resolved prefix mcp__<name>__).
+    Empty     → MCP path absent.
+
+Step 3 — Resolve which is present:
+  env + MCP   → available  (path=mcp, deployment=<cloud|self-hosted>)   # prefer MCP for tool calls; keep deployment from env
+  MCP only    → available  (path=mcp, deployment=unknown)              # deployment not derivable without PENPOT_BASE_URL
+  env only    → available  (path=api, deployment=<cloud|self-hosted>)
+  neither     → not_configured
+```
+
+Write the result to `.design/STATE.md` `<connections>` immediately after probing, using the **three-value schema** below:
+
+```xml
+<connections>
+penpot: available (path=mcp, deployment=self-hosted)
+figma: not_configured
+</connections>
+```
+
+Other valid values: `penpot: available (path=api, deployment=cloud)`, `penpot: available (path=mcp, deployment=unknown)`, `penpot: not_configured`.
+
+| Field | Values | Meaning |
+|-------|--------|---------|
+| status | `available` / `not_configured` | At least one access path resolved, or none did |
+| `path` | `mcp` / `api` | Which access path the stage should use for tool/REST calls |
+| `deployment` | `cloud` / `self-hosted` / `unknown` | Derived from `PENPOT_BASE_URL` host; `unknown` when only the MCP path is present and no base URL is exported |
+
+Consumers MUST read `path` to decide whether to call MCP tools (`mcp__<prefix>__*`) or REST endpoints, and SHOULD surface `deployment` when an operation differs by host (e.g. rate limits or shared-library scope on cloud vs self-hosted).
+
+---
+
+## Penpot Tools
+
+Tools are described generically — the concrete tool names depend on the resolved `path` (MCP tool names `mcp__<prefix>__<tool>`, or REST commands under `$PENPOT_BASE_URL/api/...`). All capabilities below exist on both cloud and self-hosted instances.
+
+| Capability | Stage | Purpose |
+|------------|-------|---------|
+| **List/read boards** | design | Enumerate projects, files, and boards (frames); read the node tree, names, and layout of a selected board |
+| **Read components** | design | Resolve components and component instances from the file's component library; read variants and overrides |
+| **Export tokens** | scan + discover | Read design tokens (color, spacing, typography) and library assets; Penpot's token format is W3C-style design tokens, so values export cleanly into DESIGN.md |
+| **Read prototype/flows** | design (secondary) | Inspect interactions and flows between boards for reference |
+| **Write proposals** | design (write) | Create or annotate boards/frames with proposed design changes; attach comments carrying D-XX decisions onto the relevant boards |
+
+Reads are the default. Writes are gated behind the same **proposal → confirm** UX used by the Figma connection (see `connections/figma.md`): the agent builds a numbered operation list and presents it before any write executes. No automatic insertion into the user's Penpot file.
+
+---
+
+## Pipeline Integration
+
+Penpot is a **canvas-category** connection. It feeds the **design** stage like Figma and paper.design — the same slot in the pipeline, a different backing tool.
+
+| Stage | What Penpot provides |
+|-------|----------------------|
+| scan | **Token augmentation**: export Penpot design tokens to supplement grep-based CSS token extraction. DESIGN.md notes `source: penpot-tokens` |
+| discover | **Decisions pre-population**: pre-fill D-XX color/spacing/typography decisions from exported tokens before the interview |
+| design | **Board/component reads** for design context; **write proposals** (boards, frames, comments) via the proposal→confirm path when `path` resolves |
+| plan | Not used |
+| verify | Not used |
+
+When multiple canvas-category connections are `available` (e.g. both `figma` and `penpot`), the design stage uses whichever the active design source points to; it does not merge them. The user's source-of-truth selection decides.
+
+---
+
+## Fallback Behavior
+
+When `penpot` is `not_configured`, stages **degrade to code-only** — Penpot is an enhancement, never a requirement, and a missing connection **never blocks** the pipeline.
+
+**scan stage:**
+
+- Skip Penpot token export.
+- Rely on grep-based CSS custom property extraction alone.
+- DESIGN.md token section uses `source: CSS custom properties` (not `source: penpot-tokens`).
+
+**discover stage:**
+
+- Skip token pre-population.
+- Populate D-XX decisions via interview only (manual elicitation from the user).
+
+**design stage:**
+
+- `penpot: not_configured` → skip the write-proposal offer entirely (no prompt, no output).
+- `penpot: available` → offer the opt-in proposal prompt after the design step completes.
+
+Stages do not append a `<blocker>` for a missing Penpot connection. Only if a `must_have` explicitly requires Penpot data (reads or writes) does a stage append a blocker. Always re-probe at stage entry — both the access `path` and the resolved MCP prefix can change between sessions.
+
+Do NOT edit the connection index here — the 37.1 wiring plan adds the Active-Connections row + matrix entry.

package/connections/plasmic.md

@@ -0,0 +1,112 @@
+# Plasmic — Connection Specification
+
+This file is the connection specification for Plasmic within the get-design-done pipeline. Plasmic is a **dual-category** tool: it is both a **visual canvas** (a hosted design/builder surface whose pages and components can be read as a design source, like Figma) **and** a **code generator** (it emits real component code via its codegen loader/API). Because of this, Plasmic earns entries in **both** the `canvas` column **and** the `generator` column of the capability matrix. It integrates via the Plasmic MCP (preferred) or via a project token + loader/codegen API. See `connections/connections.md` for the full connection index and capability matrix.
+
+---
+
+## Setup
+
+### Prerequisites
+
+**Path A — Plasmic MCP (preferred):**
+- The Plasmic MCP enabled in your Claude environment
+- A Plasmic project (the design lives at [plasmic.app](https://plasmic.app))
+- No additional manual setup when the MCP is present
+
+**Path B — Token + loader/codegen API fallback:**
+- A Plasmic account and a project at [plasmic.app](https://plasmic.app)
+- A project ID + API token (project tokens, found in the project's Code/Configure panel)
+- `PLASMIC_PROJECT_ID` and `PLASMIC_API_TOKEN` environment variables set
+- Loader/codegen access per the docs at [docs.plasmic.app](https://docs.plasmic.app)
+
+### Verification
+
+```
+ToolSearch({ query: "plasmic", max_results: 5 })
+```
+
+Non-empty results (canvas-read + codegen tools) → Plasmic MCP available (Path A).
+Empty → check `PLASMIC_PROJECT_ID` / `PLASMIC_API_TOKEN` and use Path B, then restart the Claude Code session.
+
+---
+
+## Probe Pattern
+
+Plasmic uses an MCP-first, two-path probe. Check the MCP first; fall back to the token env path.
+
+```
+ToolSearch({ query: "plasmic", max_results: 5 })
+→ Non-empty  → plasmic: available (mcp)
+→ Empty      → check PLASMIC_PROJECT_ID + PLASMIC_API_TOKEN env vars
+               both set → plasmic: available (token)
+               either unset → plasmic: not_configured
+```
+
+Write the three-value result to `.design/STATE.md` `<connections>`: `plasmic: <status>`
+where `<status>` ∈ { `available (mcp)`, `available (token)`, `not_configured` }.
+
+Because Plasmic is dual-category, a single `available` status enables **both** roles at once — the canvas read **and** the generator emit. The pipeline decides which role to invoke per stage (see Pipeline Integration); the probe does not split the status.
+
+---
+
+## Plasmic Tools
+
+Plasmic exposes tools spanning **both** capability columns. Describe them generically — exact tool names resolve at probe time via `ToolSearch`.
+
+| Tool (generic) | Column | Stage | Purpose |
+|----------------|--------|-------|---------|
+| `plasmic_list_projects` / `plasmic_get_project` | canvas | canvas | Enumerate Plasmic projects and read project/page/component metadata |
+| `plasmic_read_component` / `plasmic_get_design` | canvas | canvas | Read a page or component from the visual canvas as a design source (structure, props, tokens) |
+| `plasmic_get_tokens` | canvas | canvas | Extract design tokens (color, spacing, typography) defined in the Plasmic project |
+| `plasmic_generate_code` / `plasmic_emit_component` | generator | generator | Emit real component code for a canvas component (codegen / loader) |
+| `plasmic_sync` | generator | generator | Sync/regenerate emitted code after canvas changes (roundtrip) |
+
+Token-path equivalents: the loader/codegen API at [docs.plasmic.app](https://docs.plasmic.app) provides the same two roles — read the project (canvas) and pull generated component code (generator) — when the MCP is absent.
+
+---
+
+## Pipeline Integration
+
+Plasmic plugs into **two distinct stages**, one per capability column. This is the explicit dual-column behavior (SC#5): the same connection is a design **source** at the canvas stage and a code **emitter** at the generator stage.
+
+| Stage | Column | What Plasmic provides |
+|-------|--------|-----------------------|
+| canvas | canvas | **Read the Plasmic design as a source** — pages, components, and tokens, the same way Figma is read. Feeds DESIGN.md and `.design/STATE.md` `<design_system>` token blocks. |
+| generator | generator | **Emit component code** — via `agents/design-component-generator.md`'s `<!-- impl: plasmic -->` section. Returns component source the generator stage writes into the project. |
+
+### Canvas stage — design as source
+
+When `plasmic: available`, the canvas stage may treat a Plasmic project as a first-class design source (peer to Figma):
+
+1. `plasmic_list_projects` → resolve the target project (or read `PLASMIC_PROJECT_ID`).
+2. `plasmic_read_component` / `plasmic_get_design` → pull the page/component structure into the design read.
+3. `plasmic_get_tokens` → extract tokens into `.design/STATE.md` `<design_system>` for downstream generator targeting.
+
+This is a **read** — no code is emitted at this stage. The canvas read is what later stages reason about.
+
+### Generator stage — emit code
+
+The generator stage delegates to `agents/design-component-generator.md`. That agent's `<!-- impl: plasmic -->` section calls the Plasmic codegen path:
+
+1. The agent resolves the canvas component to emit (from the canvas-stage read).
+2. It calls `plasmic_generate_code` / `plasmic_emit_component` (or the loader/codegen API on the token path).
+3. The emitted source is surfaced as a **proposal**, not auto-inserted.
+
+### Proposal → Confirm
+
+Both roles are non-destructive. The canvas read is informational; the generator emit is a **proposal**. The design-executor surfaces the proposed component code to the user/executor, who confirms before any code is written into the project. No automatic insertion, no automatic overwrite of existing components.
+
+---
+
+## Fallback Behavior
+
+When `plasmic: not_configured`:
+- Print: `Plasmic not configured — canvas read and code emit skipped.`
+- **Canvas role** degrades gracefully: the canvas stage falls back to other available design sources (e.g. Figma); Plasmic is simply not offered as a source.
+- **Generator role** degrades to code-only: the generator stage falls back to other available generators (Magic Patterns if `magic-patterns: available`, then 21st.dev if `21st-dev: available` — see `connections/21st-dev.md`), and finally to a manual component build.
+
+Plasmic is **additive and never blocks**: with neither role configured, the pipeline proceeds on its existing canvas source and existing generators exactly as before.
+
+---
+
+Do NOT edit the connection index here — the 37.1 wiring plan adds the Active-Connections row + matrix entries (canvas + generator).

package/connections/v0-dev.md

@@ -0,0 +1,100 @@
+# v0.dev — Connection Specification
+
+This file is the connection specification for v0.dev within the get-design-done pipeline. v0.dev is Vercel's generative-UI tool (AI-native, Wave 2): prompt in, React/Tailwind/shadcn component code out. It is a **generator-category** connection — same family as [21st.dev](21st-dev.md) and [Magic Patterns](magic-patterns.md) — and plugs into the shared component-generator agent as a new implementation (Phase 14 pattern). See `connections/connections.md` for the full connection index and capability matrix.
+
+---
+
+## Setup
+
+### Prerequisites
+
+**Path A — MCP (preferred):**
+- A v0.dev MCP server reachable from your Claude environment (probe surfaces the tools).
+- No additional setup once the server is registered and the session is restarted.
+
+**Path B — REST + API key (fallback, phase default):**
+- A v0.dev account and API key from [v0.dev](https://v0.dev) (Vercel's **v0 Platform API**).
+- `V0_API_KEY` environment variable set.
+- Calls hit the v0 Platform API over HTTPS; no local server required.
+
+Per the phase default, **probe MCP first, then fall back to REST + `V0_API_KEY`**. The Platform API is the stable contract; MCP tool names may evolve, so treat MCP as the fast path and the key as the durable one.
+
+### Verification
+
+```
+ToolSearch({ query: "v0", max_results: 5 })
+```
+
+Non-empty results including a v0 generate tool → MCP available (Path A).
+Empty → check `V0_API_KEY`; if set, Path B is active. If unset, v0.dev is not configured.
+
+---
+
+## Probe Pattern
+
+v0.dev uses a two-path probe — MCP-first, then API key.
+
+```
+ToolSearch({ query: "v0", max_results: 5 })
+→ Non-empty  → v0: available (mcp)
+→ Empty      → check V0_API_KEY env var
+               set   → v0: available (api)
+               unset → v0: not_configured
+```
+
+This resolves to a **three-value** status. Write the result to `.design/STATE.md` `<connections>`:
+
+```
+v0: <not_configured | available (mcp) | available (api)>
+```
+
+The generator stage reads this value to decide whether the v0 implementation path is selectable.
+
+---
+
+## v0.dev Tools / API
+
+v0.dev contributes a single core capability at the generator stage: **generate a component from a prompt plus design-system context**. Exact tool/endpoint names are not pinned here — verify them at runtime via the probe (MCP) or the current Platform API docs (REST).
+
+| Capability | Stage | Purpose |
+|------------|-------|---------|
+| generate component | generator | Prompt + DS context → React/Tailwind/shadcn source; returns `{ code, preview_url }` (shape verified at runtime) |
+| iterate / refine | generator | Follow-up prompt against a prior generation to refine output before any write |
+
+**MCP path:** call the discovered generate tool with the DS-aware prompt; read code + preview from its response.
+**REST path:** POST the prompt to the v0 Platform API generate endpoint with `Authorization: Bearer ${V0_API_KEY}`; parse code + preview from the JSON response.
+
+Both paths return generated source plus (typically) a hosted preview URL. Field names differ by transport — resolve them at runtime, do not hardcode against this table.
+
+---
+
+## Pipeline Integration
+
+v0.dev is **generator-category**: it contributes at the **generator** stage only, as one implementation inside the shared generator agent. The agent's `<!-- impl: v0 -->` section in `agents/design-component-generator.md` holds the v0-specific prompt assembly and response handling.
+
+| Stage | What v0.dev provides |
+|-------|----------------------|
+| generator | Prompt + DS context → component source via the `<!-- impl: v0 -->` path in `agents/design-component-generator.md` |
+| generator | `preview_url` (when returned) written to `.design/STATE.md` `<generator>` block for the verify stage |
+
+### DS-Aware Prompting
+
+Before invoking v0.dev, the generator reads the detected design system from `.design/STATE.md` `<design_system>` (populated upstream — see [Magic Patterns](magic-patterns.md) for the shared DS-detection logic). The `<!-- impl: v0 -->` section folds that context into the prompt: target framework (React), styling (Tailwind), and component library (shadcn/ui when present), plus any token or convention notes. v0.dev is shadcn-native, so a shadcn target maps cleanly; other systems are passed as explicit prompt constraints.
+
+### Proposal → Confirm
+
+v0.dev output is **proposed, never auto-written**. The generator surfaces the generated code (and preview, if any) as a proposal; the executor confirms with the user before anything lands in `src/`. This matches the prior-art and proposal gates used by the sibling generator implementations — no automatic code insertion.
+
+---
+
+## Fallback Behavior
+
+When `v0: not_configured`:
+- Print: `v0.dev not configured — generator impl skipped.`
+- Falls back to another generator implementation if available: [21st.dev](21st-dev.md) or [Magic Patterns](magic-patterns.md).
+- If no generator is configured, the generator stage proceeds with a code-only manual build.
+- v0.dev **never blocks** the pipeline — it degrades to a sibling generator or to manual code, and the stage continues either way.
+
+---
+
+Do NOT edit the connection index here — the 37.1 wiring plan adds the Active-Connections row + matrix entry.

package/connections/webflow.md

@@ -0,0 +1,107 @@
+# Webflow — Connection Specification
+
+This file is the connection specification for Webflow within the get-design-done (GDD) pipeline. Webflow is an AI-native Wave 2 generator-category, code-capable canvas: GDD reads a Webflow site's structure and styles and uses them as a **design-adaptation source** — it reads the site's existing design language and emits it as a source for adaptation. GDD does **not** author Webflow CMS schemas, publish content, or write back to the site. See `connections/21st-dev.md` for the structural template this spec follows, and `connections/connections.md` for the full connection index and capability matrix.
+
+---
+
+## Setup
+
+### Prerequisites
+
+You need a Webflow site to read from, plus one read path:
+
+**Path A — Webflow MCP (preferred):**
+- The Webflow MCP server registered in your Claude environment (exposes the Webflow Data API as tools).
+- No additional env setup required once the connector is enabled.
+
+**Path B — API token fallback:**
+- A Webflow account with at least one site, at [webflow.com](https://webflow.com).
+- A Data API token (Site settings → Apps & integrations → API access) scoped read-only.
+- `WEBFLOW_API_TOKEN` environment variable set, used against the Data API at [developers.webflow.com](https://developers.webflow.com).
+
+### Verification
+
+```
+ToolSearch({ query: "webflow", max_results: 5 })
+```
+
+Non-empty results (e.g. a site-list / pages / styles read tool) → Webflow MCP available (Path A).
+Empty → check `WEBFLOW_API_TOKEN` and fall back to direct Data API reads (Path B), then restart the Claude Code session if you just registered the connector.
+
+---
+
+## Probe Pattern
+
+Webflow uses an MCP-first probe with an API-token env fallback. Resolve to one of three values and write it to `.design/STATE.md` `<connections>`.
+
+```
+ToolSearch({ query: "webflow", max_results: 5 })
+→ Non-empty  → webflow: available        (MCP path)
+→ Empty      → check WEBFLOW_API_TOKEN env var
+               set    → webflow: available     (API-token path)
+               unset  → webflow: not_configured
+```
+
+A separate `unavailable` status is reserved for the case where the MCP tool is present in the session but errors on probe (auth failure, site offline, rate-limited) — treat it the same as `not_configured` for gating (skip Webflow steps), but record it distinctly.
+
+Three-value status schema (mirrors `connections/connections.md`):
+
+| Status | Meaning |
+|--------|---------|
+| `available` | Webflow read path confirmed (MCP tool responsive, or `WEBFLOW_API_TOKEN` set) |
+| `unavailable` | MCP tool present but errored on probe (auth/site/rate-limit) |
+| `not_configured` | No MCP tool and no API token — Webflow not wired in this session |
+
+Write result to STATE.md `<connections>`: `webflow: <status>`
+
+---
+
+## Webflow Tools
+
+Tools are described generically — exact names depend on the registered MCP server (Path A) or are equivalent Data API read calls (Path B). All are **read-only** in GDD's usage.
+
+| Tool (generic) | Stage | Purpose |
+|----------------|-------|---------|
+| read site structure | design | Enumerate the site's pages and DOM/element hierarchy — the structural skeleton of the existing design |
+| read styles | design | Read style classes, typography, color, spacing, and breakpoint definitions — the site's existing design language |
+| read components | design | Read reusable components / symbols and their composition, for pattern adaptation |
+
+These reads supply raw material for adaptation. GDD never calls a Webflow write/publish/CMS-mutation tool, even when the registered MCP server exposes one.
+
+---
+
+## Pipeline Integration
+
+Webflow is a **generator-category** connection that contributes at the **design** stage as a structure/adaptation source.
+
+| Stage | What Webflow provides |
+|-------|------------------------|
+| design | **Adaptation source**: read the existing site's structure, styles, and components; emit the design language as a source the design stage adapts from |
+
+### Adaptation-source flow (design stage)
+
+1. Probe resolves `webflow: available`.
+2. Read site structure + styles (+ components) via the available path.
+3. Emit the extracted design language as an **adaptation source** for the design stage — structure and style become reference material the generator adapts, alongside other sources (e.g. the project design system, 21st.dev prior art).
+4. The design-executor produces GDD-native output (code / DESIGN.md) informed by that source. Nothing is written back to Webflow.
+
+This is a **read-and-adapt** integration, not a round trip. The Webflow site is treated as inspiration and structural reference; GDD owns the emitted output.
+
+### Explicitly out of scope
+
+- GDD reads structure; it does **not** author or mutate Webflow **CMS schemas** (collections, fields, items). It is a design-adaptation source, not a CMS authoring tool.
+- No publishing, no content writes, no site mutations of any kind.
+
+---
+
+## Fallback Behavior
+
+When `webflow: not_configured` (or `unavailable`):
+
+- Print: `Webflow not configured — adaptation source skipped, proceeding code-only.`
+- The design stage **degrades to code-only**: it proceeds from the project design system and any other available sources without the Webflow design language.
+- Webflow never blocks the pipeline. A missing Webflow connection only removes one optional adaptation source; the design stage continues normally.
+
+---
+
+Do NOT edit the connection index here — the 37.1 wiring plan adds the Active-Connections row + matrix entry.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hegemonart/get-design-done",
-  "version": "1.36.3",
+  "version": "1.37.1",
   "description": "A design-quality pipeline for AI coding agents: brief, plan, implement, and verify UI work against your design system.",
   "author": "Hegemon",
   "homepage": "https://github.com/hegemonart/get-design-done",

package/skills/connections/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gdd-connections
-description: "Interactive onboarding wizard for the 21 external integrations the pipeline supports — probes all (`figma`, `refero`, `preview`, `storybook`, `chromatic`, `graphify`, `pinterest`, `claude-design`, `paper-design`, `pencil-dev`, `21st-dev`, `magic-patterns`, `lazyweb`, `mobbin`, `slack`, `discord`, `linear`, `jira`, `notion`, `lottie`, `rive`), recommends based on project type, walks the user through setup (auto-run MCP install or copy-command fallback), writes results to `STATE.md <connections>`. Use after `/gdd:new-project` or whenever the user wants to add, inspect, or skip a connection. Re-runnable anytime."
+description: "Interactive onboarding wizard for the 27 external integrations the pipeline supports — probes all (`figma`, `refero`, `preview`, `storybook`, `chromatic`, `graphify`, `pinterest`, `claude-design`, `paper-design`, `pencil-dev`, `21st-dev`, `magic-patterns`, `lazyweb`, `mobbin`, `slack`, `discord`, `linear`, `jira`, `notion`, `lottie`, `rive`, `framer`, `penpot`, `webflow`, `v0-dev`, `plasmic`, `builder-io`), recommends based on project type, walks the user through setup (auto-run MCP install or copy-command fallback), writes results to `STATE.md <connections>`. Use after `/gdd:new-project` or whenever the user wants to add, inspect, or skip a connection. Re-runnable anytime."
 argument-hint: "[list | <connection-name> | --auto]"
 user-invocable: true
 tools: Read, Write, Bash, Glob, Grep, AskUserQuestion, ToolSearch
@@ -8,11 +8,11 @@ tools: Read, Write, Bash, Glob, Grep, AskUserQuestion, ToolSearch
 
 # /gdd:connections
 
-Interactive onboarding for the 21 external integrations the pipeline supports. Replaces "probe silently at scan entry and hope the user noticed" with an explicit "here is what can plug in, here is how."
+Interactive onboarding for the 27 external integrations the pipeline supports. Replaces "probe silently at scan entry and hope the user noticed" with an explicit "here is what can plug in, here is how."
 
 Canonical per-connection specs live in `../../connections/<name>.md` (one file per integration). The capability matrix + probe-pattern spec live in `../../connections/connections.md`. This skill is the **user-facing front end** for those specs.
 
-For the 21 probe scripts (MCP + HTTP + CLI + file probes), bucket categorization, per-connection setup screen, auto-run eligibility matrix, value-prop one-liners, and STATE.md / config.json write contracts, see `./connections-onboarding.md`. For the cross-skill probe pattern + connection-handshake summary, see `../../reference/shared-preamble.md#connection-handshake-summary`. For the cross-skill output discipline, see `../../reference/shared-preamble.md#output-contract-reminders`.
+For the 27 probe scripts (MCP + HTTP + CLI + file probes), bucket categorization, per-connection setup screen, auto-run eligibility matrix, value-prop one-liners, and STATE.md / config.json write contracts, see `./connections-onboarding.md`. For the cross-skill probe pattern + connection-handshake summary, see `../../reference/shared-preamble.md#connection-handshake-summary`. For the cross-skill output discipline, see `../../reference/shared-preamble.md#output-contract-reminders`.
 
 ---
 
@@ -38,7 +38,7 @@ For the 21 probe scripts (MCP + HTTP + CLI + file probes), bucket categorization
 
 ## Workflow
 
-1. **Probe all 21 connections** — run every probe script per `./connections-onboarding.md#step-1--probe-all-21-connections`. MCP probes use `ToolSearch` first; HTTP / CLI / file probes follow non-MCP patterns. Merge results into `STATE.md <connections>` with the three-value schema (`available | unavailable | not_configured`) — never add new values.
+1. **Probe all 27 connections** — run every probe script per `./connections-onboarding.md#step-1--probe-all-27-connections`. MCP probes use `ToolSearch` first; HTTP / CLI / file probes follow non-MCP patterns. Merge results into `STATE.md <connections>` with the three-value schema (`available | unavailable | not_configured`) — never add new values.
 2. **Categorize + build summary** — bucket each probe result (available / recommended / optional / skipped / unavailable) using project-hint detection. Detail + recommendation mapping: `./connections-onboarding.md#step-2--bucket-categorization`.
 3. **Print summary table** — show buckets + value-prop one-liners (verbatim from `./connections-onboarding.md#step-3--summary-table`).
 4. **Route by mode** — `list` / `--auto` exits after summary; `<name>` jumps straight to Step 5; default mode opens an AskUserQuestion (configure recommended / pick one by one / configure all optional / re-check specific / exit). Routing detail: `./connections-onboarding.md#step-4--route-by-mode`.

package/skills/connections/connections-onboarding.md

@@ -9,7 +9,7 @@ last_updated: 2026-05-18
 
 Source: extracted from `skills/connections/SKILL.md` (Phase 28.5 rework — D-10 extract-then-link).
 The skill's load-bearing routing + invocation-mode dispatch stays in `../skills/connections/SKILL.md`;
-this file holds the 21 probe scripts, bucket categorization, per-connection setup screen,
+this file holds the 27 probe scripts, bucket categorization, per-connection setup screen,
 auto-run eligibility matrix, value-prop one-liners, and STATE.md / config.json write contracts.
 
 # Connections Onboarding Procedure
@@ -27,7 +27,7 @@ this file does NOT duplicate them; it points at them by name.
 
 ---
 
-## Step 1 — Probe all 21 connections
+## Step 1 — Probe all 27 connections
 
 Run every probe below in order. MCP probes call `ToolSearch` first (deferred tools fail silently without it). Write every result to `STATE.md <connections>` when done.
 
@@ -196,7 +196,49 @@ Bash: find . -name "*.riv" -not -path "*/node_modules/*" 2>/dev/null | head
   → none                               → rive: not_configured
 ```
 
-After all 21 probes complete, merge results into `STATE.md <connections>`. Preserve the three-value schema verbatim (`available | unavailable | not_configured`). Do not add new values.
+**framer:** (AI-native Wave 2 — canvas; MCP or API token)
+```
+ToolSearch({ query: "framer", max_results: 5 })
+→ Empty → framer: not_configured
+→ Non-empty → framer: available
+```
+
+**penpot:** (AI-native Wave 2 — canvas; self-hosted URL/token or cloud)
+```
+ToolSearch({ query: "penpot", max_results: 5 })
+→ Empty → penpot: not_configured
+→ Non-empty → penpot: available
+```
+
+**webflow:** (AI-native Wave 2 — generator; MCP or WEBFLOW token)
+```
+ToolSearch({ query: "webflow", max_results: 5 })
+→ Empty → webflow: not_configured
+→ Non-empty → webflow: available
+```
+
+**v0-dev:** (AI-native Wave 2 — generator; MCP-first, else V0_API_KEY)
+```
+ToolSearch({ query: "v0", max_results: 5 })
+→ Empty → v0-dev: not_configured
+→ Non-empty → v0-dev: available
+```
+
+**plasmic:** (AI-native Wave 2 — generator+canvas; MCP or token)
+```
+ToolSearch({ query: "plasmic", max_results: 5 })
+→ Empty → plasmic: not_configured
+→ Non-empty → plasmic: available
+```
+
+**builder-io:** (AI-native Wave 2 — generator; MCP-first, else BUILDER_API_KEY)
+```
+ToolSearch({ query: "builder", max_results: 5 })
+→ Empty → builder-io: not_configured
+→ Non-empty → builder-io: available
+```
+
+After all 27 probes complete, merge results into `STATE.md <connections>`. Preserve the three-value schema verbatim (`available | unavailable | not_configured`). Do not add new values.
 
 ---
 
@@ -286,6 +328,12 @@ One-line value props (use verbatim):
 | notion | export — `/gdd:export --format notion` writes a stakeholder page (degrade-to-HTML) |
 | lottie | verify — Lottie JSON motion check (frame-rate / duration / bloat / perf-budget), WARN-never-block |
 | rive | verify — Rive `.riv` motion check (size + state-machine reachability via the opt-in runtime), WARN-never-block |
+| framer | design — read Framer frames + write proposals (canvas, Wave 2) |
+| penpot | design — open-source Figma alt; read boards (self-hosted or cloud) |
+| webflow | design — read site structure as an adaptation source (Wave 2) |
+| v0-dev | generator — Vercel v0 prompt→component (MCP-first → REST + V0_API_KEY) |
+| plasmic | generator + canvas — emit code + read the Plasmic canvas |
+| builder-io | generator — Builder.io Visual Copilot (pull-only this phase) |
 
 ---
 
@@ -313,7 +361,7 @@ options:
   - "Exit"                            → emit ## CONNECTIONS COMPLETE, exit
 ```
 
-If recommended bucket is empty, swap that option for "Show all 21 and pick."
+If recommended bucket is empty, swap that option for "Show all 27 and pick."
 
 ---
 
@@ -379,6 +427,12 @@ options:
 | notion | `claude mcp add notion ...` (Notion MCP) | ✓ yes | Reversible MCP add; OAuth on first call |
 | lottie | (file-based — no install; drop a Lottie `.json` export in the repo) | n/a | Detected from Lottie exports / a `lottie-web` dep; live player opt-in |
 | rive | (file-based — no install; add a `.riv` export / `@rive-app` dep) | n/a | Detected from `.riv` files / a `@rive-app` dep; Rive runtime opt-in |
+| framer | `claude mcp add framer ...` (or API token) | ✓ yes | Reversible MCP add; canvas-category |
+| penpot | `claude mcp add penpot ...` (self-hosted URL or cloud + token) | ✓ yes | Reversible; self-host vs cloud |
+| webflow | `claude mcp add webflow ...` (or WEBFLOW token) | ✓ yes | Reversible; reads structure, not CMS authoring |
+| v0-dev | `claude mcp add v0 ...` (or V0_API_KEY) | ✓ yes | Reversible; MCP-first → REST fallback |
+| plasmic | `claude mcp add plasmic ...` (or token) | ✓ yes | Reversible; dual canvas+generator |
+| builder-io | `claude mcp add builder ...` (or BUILDER_API_KEY) | ✓ yes | Reversible; pull-only this phase |
 
 For non-auto-run connections, hide the "Run install command now" option entirely in 5.3.