Run v0-Class Pipelines with an Explicit Ownership Boundary

Tier: Foundation · Workflow area: Design-to-code & design systems · Tools: v0 (Figma import), v0 Git panel, your design system

pb-01 used these tools as throwaway explorers. This playbook covers the other legitimate mode: letting a managed pipeline own real, shipping surfaces — marketing pages, internal tools, low-risk product screens — under an explicit contract. The failure mode isn't using v0 in production; it's using it without deciding what it may own, so its output metastasizes into core product code nobody can maintain.

When to use

• Peripheral surfaces with real deadlineslanding pages, campaign pages, internal dashboards, admin CRUD — where design capacity is thin and iteration speed dominates.
• A Figma design exists and v0's Figma import gets you 80% of the way in an afternoon.
• The team can state the boundarysomeone with authority will sign off on the "v0 may own / may never own" lists below.
• Design-system binding is possibleyour components are importable (public or registry-published) so output can land on-system.

When NOT to use

• Core product surfacescheckout, editors, data-heavy flows with complex state: the pipeline's iteration model fights real state management, and regenerated code tramples hand-tuned logic.
• Strict design-system governance without bindingif v0 can't be conditioned onto your components, its output creates a parallel visual dialect you'll pay to unify later.
• Compliance-sensitive code pathsanything with authz logic, PII handling, or audit requirements gets hand-owned code and full review, full stop.

The recipe

1. 1.

   Write the ownership contract first — one page, agreed, committed. This is the playbook's deliverable; everything else is mechanics:

   Copy

   V0 PIPELINE CONTRACT — acme-web, agreed 2026-08-05
   MAY OWN (v0 is source of truth; edit via v0, export via Git panel):
   - /marketing/** pages, /internal/tools/** dashboards
   - Presentational components under src/v0/** only
   MAY NEVER OWN:
   - Anything under src/features/** (product code)
   - Auth, payments, data mutations beyond form-post to existing APIs
   - Shared primitives (@acme/ui) — v0 CONSUMES these, never redefines
   BOUNDARY MECHANICS:
   - v0 output lands in src/v0/** via PR only, never direct push
   - Graduating a surface out of src/v0/** = rewrite PR onto @acme/ui
     with tests (the pb-01 re-implementation rule applies)
   GATES (same as human code, no exemptions):
   - typecheck, lint, axe scan, Lighthouse >= 90 perf on marketing pages
   OWNER: web-platform team. Review quarterly.
   

2. 2.

   Bind v0 to your design system before the first real surface. In v0's project settings, wire your registry/theme so generation starts on-system: point it at your published shadcn-style registry (pb-03), or at minimum upload your tokens (Tailwind config) and forbid its defaults in the project system prompt:

   Copy

   Project rules: use the @acme registry components for all primitives
   (Button, Card, Input, Badge). Tailwind config is attached — use its
   semantic color and spacing tokens only. Never use default shadcn
   colors, never invent gradient heroes, follow src/v0/CONVENTIONS.md.
   

3. 3.

   Import the Figma frame and iterate by prompt — in v0, not in the repo. Paste the Figma frame link into v0 (or use the Figma import), then iterate conversationally: Tighten the pricing tier cards to match the frame — 24px internal padding, align CTAs to the card bottom. Add the FAQ accordion below, collapsed by default, first item open. The discipline: while a surface is v0-owned, all edits go through v0. Hand-editing exported files forks the source of truth — the classic pipeline failure.

4. 4.

   Export through the Git panel into the boundary directory. Connect the repo in v0's Git panel and export as a PR targeting src/v0/marketing-pricing/. Then run the same gates as any PR:

   Copy

   npx tsc --noEmit && npx eslint src/v0/marketing-pricing
   npx playwright test e2e/pricing.smoke.spec.ts
   npx lighthouse http://localhost:3000/pricing \
     --only-categories=performance,accessibility --quiet
   

   Review the PR for boundary violations specifically: no imports from src/v0/** into src/features/**, no redefined primitives, no secret env usage. An ESLint no-restricted-imports rule makes the first check automatic:

   Copy

   { "no-restricted-imports": ["error", { "patterns": [
     { "group": ["**/v0/**"], "message": "Product code may not import v0-owned surfaces" }
   ] }] }
   

5. 5.

   Run the fidelity and review loops like any AI output. The managed pipeline doesn't exempt the result: multimodal fidelity diff against the Figma frame (pb-11), provenance checklist on the PR (pb-28), axe scan in CI. A good exported surface passes all three with at most minor findings — if it repeatedly can't, that surface class belongs on the "may never own" list.

6. 6.

   Graduate or retire deliberately. Quarterly, per the contract review: surfaces that grew product logic get rewritten onto the design system and moved out of src/v0/** (a scheduled, budgeted rewrite — not a panic); dead campaign pages get deleted. The boundary directory should trend toward small.

Make it yours

• Next.js + Tailwind shopsthe native fit: v0 emits your stack directly, registry binding works today, and the Git panel targets your repo; the recipe as written.
• Vue / Angular shopsv0's React output can't land in-repo; use the pipeline only to the design boundary (iterate visually, agree the direction) and re-implement per pb-01, or adopt a same-ecosystem equivalent tool and apply this contract verbatim to it.
• Design-system-first orgsinvert the flow: publish your registry first (pb-03), then evaluate v0-class tools by one criterion — "does output compose our registry components?" — and only grant may-own surfaces to tools that pass.
• Mobile teamsno v0-equivalent maturity yet; the contract concept still applies to any managed generation tool (Figma Make-class): boundary directory, gates, graduation rule.

Quality check

• The contract exists, is committed, and names an ownernot a Slack agreement; a file in the repo with a review date.
• Boundary enforced mechanicallythe lint rule fails product-code imports of v0 surfaces; spot-check git log src/v0/ for direct-push commits (there should be none).
• All gates ran on the latest exporttypecheck, lint, axe, Lighthouse evidence in the PR.
• No hand-edits inside v0-owned directoriesdiff the v0 project's latest export against the repo; they should match.
• Quarterly review happenedgraduation/retirement decisions logged, "may own" list still matches reality.