docs(product): commit design references under docs/product/reference/
Copy the founder's design handoff bundle (.proto/design/) into docs/product/reference/ byte-for-byte so dispatch agents running in git worktrees can read the HTML prototypes, veect-codebase/ prototype, upload PNGs, and remaining bundle files (ADR-029: reference only, never vendored into packages/). Ignore-list entries so whole-codebase auditors and formatters skip reference material: .prettierignore (byte preservation through lint-staged), .fallowrc.json ignorePatterns, root ESLint ignores, and the coverage:diff allowlist in scripts/coverage/diff.mjs (+ unit test). .DS_Store files skipped. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016j8z4VHjedXDTjEDNg7qHK
This commit is contained in:
83
docs/product/reference/project/uploads/company-context.md
Normal file
83
docs/product/reference/project/uploads/company-context.md
Normal file
@@ -0,0 +1,83 @@
|
||||
# Company Context — "Weave" (working name)
|
||||
|
||||
_Living strategy doc · Founder OS · last updated 2026-07-09_
|
||||
_Status: Phases 1–5 **compressed** at the founder's request to jump to Phase 6. Confidence tags: 🟢 verified · 🟡 reasoned · 🔴 assumed / needs validation._
|
||||
|
||||
> **Working name only.** "Weave" is a placeholder so the docs read cleanly — not a naming decision. Real naming/trademark is a separate exercise. 🔴
|
||||
|
||||
---
|
||||
|
||||
## One-liner
|
||||
A **design-system-native canvas** that turns your own tokens and components into **real, production-ready React**, held to a **craft standard (Impeccable)** so output is on-brand *and* genuinely well-designed — so what a designer composes is exactly what ships.
|
||||
|
||||
## Problem
|
||||
Product designers who already have a design system still can't ship on-brand UI without waiting on engineering. Today's AI design/code tools (v0, Lovable, Bolt, Figma Make) re-invent **generic** UI instead of using the team's own components and tokens — so the output is off-brand and thrown away, and the design→code handoff stays lossy.
|
||||
- 🟢 92% of designers and 91% of developers say the handoff process needs improvement (Figma, *State of the Designer*).
|
||||
- 🟢 Figma Make users report it "won't use my library components" / "created new ones that just looked like mine"; v0 "treats the Figma file as a screenshot" (Figma forum; user teardowns).
|
||||
- 🟢 The market has already conceded the pain — Bolt, Lovable and Figma all bolted on "use your design system" features in 2025 because generic output was the #1 designer complaint.
|
||||
|
||||
## Beachhead ICP
|
||||
Product/UI designers and design-system / design-engineer leads at startups & scale-ups (~10–200 people) that **already have a design system** (tokens + component library) and ship a **React** web product. 🟡
|
||||
- **User (feels pain):** product designer · design-system designer · design engineer.
|
||||
- **Champion:** Head of Design / Design Systems lead. 🟡
|
||||
- **Economic buyer:** design leadership budget; escalates to VP/Eng at team tier. 🟡
|
||||
- **Veto:** Engineering ("will the emitted code meet our repo standards?") and Security at enterprise. 🟢
|
||||
|
||||
## Top Jobs-to-be-Done (from discovery research)
|
||||
1. When I finish a design, I want the built UI to match it exactly without policing every pixel, so I can stop redlining.
|
||||
2. When our design system changes, I want Figma and code components to stay in lockstep, so "the library" means one thing everywhere.
|
||||
3. When I need a screen shipped, I want to produce it myself without an eng sprint slot, so I can move at the speed of the idea.
|
||||
4. When I use AI to generate UI, I want it built from **my** components/tokens (not a generic theme), so I get on-brand output I don't throw away.
|
||||
|
||||
## Wedge / Positioning (April Dunford frame)
|
||||
- **For** product designers who have a design system but can't ship on-brand code without engineering,
|
||||
- **Weave is** a design-system-native canvas that emits real, production React from your own tokens + components,
|
||||
- **unlike** v0 / Lovable / Bolt / Figma Make, which are developer/prompt-first and generate generic, throwaway UI,
|
||||
- **so that** what you design is what gets built — on-brand, high-craft, with zero translation loss.
|
||||
- **Category:** "design-system-native design-to-code" — a wedge inside the crowded AI-builder space. 🟡
|
||||
|
||||
**Two things deepen the wedge (added after review):**
|
||||
- **Real-component mapping** — export emits the team's *real* coded components (their import paths + prop names), not Weave-internal clones. Without this the output never clears the engineer's merge bar and the wedge collapses to "v0 with theming." 🟢 (this was the single biggest gap the red-team found)
|
||||
- **Craft layer (Impeccable)** — beyond "constrained to your system," a Polish pass holds output to a craft ruleset (impeccable.style — an open-source anti-"AI-slop" design language for AI harnesses). On-brand **and** high-craft is a sharper position than either alone. 🟡
|
||||
|
||||
## Why now
|
||||
AI codegen is finally good enough for *constrained* composition; design-token standardization (W3C DTCG) is maturing; "design engineering" is rising as a role; Figma Dev Mode's per-seat pricing backlash has opened a door. 🟡
|
||||
|
||||
## Competitive frame (from existing knowledge — deep teardown deferred)
|
||||
| Cluster | Players | Why they don't own the wedge |
|
||||
|---|---|---|
|
||||
| Prompt/dev-first app builders | v0, Lovable, Bolt | Fast but generic output; prompt-first not canvas-first; not BYO-design-system-first |
|
||||
| Visual design-to-code | **Subframe** (closest), Builder.io Fusion, Anima, Locofy | Subframe is strong but leans "design in browser → code"; others are dev-first imports or Figma-plugin exporters with fidelity issues |
|
||||
| Site builders | Framer, Webflow | Own proprietary runtime; you don't get *your* React components/code |
|
||||
| Incumbent | Figma (Dev Mode, Make) | Enormous stickiness, but generic AI output and a handoff "tax"; not designer-owned code from your system |
|
||||
|
||||
**White space (the bet):** a **designer-first** canvas where a **bring-your-own design system is the source of truth** and AI is **constrained to it**. 🟡 *(Subframe is the nearest competitor; a real teardown is still owed to harden the "unowned" claim — see 🔴 A4.)*
|
||||
|
||||
## North Star Metric
|
||||
**Weekly shipped screens** — screens whose code is exported and actually used, per active designer. No repo integration yet, so **proxy** it via an explicit "mark as shipped" + design-partner check-ins. 🟡
|
||||
- **Activation:** first screen composed from the user's *own* tokens + components and exported. 🟡
|
||||
- **Trust bar (primary, engineer-judged):** real PRs at design partners — merge rate + % LOC changed pre-merge. The right judge is the engineer, not the designer's self-report. 🟢
|
||||
- **Wedge-usage guardrail:** % of exported screens composed *majority* from the user's mapped/real components (not stock base kit) — so we can't "pass" by validating a re-themed generic kit. 🟡
|
||||
|
||||
## Business model (compressed — full Phase 5 deferred)
|
||||
Per-seat SaaS for designers with a usage component on AI compose; land bottom-up with individual designers, expand to design teams. Not yet modeled. 🔴
|
||||
|
||||
---
|
||||
|
||||
## Validation gate status (Phase 1) — **NOT formally cleared**
|
||||
The pain is real and well-sourced 🟢, but the core belief rests on unvalidated assumptions. Per Founder OS discipline, the MVP in the PRD is scoped as **the cheapest way to test the core bet**, not a green-lit build. Run the validation experiment (see PRD §Risks/Validation) in parallel with any build.
|
||||
|
||||
### Riskiest assumptions to validate
|
||||
- 🔴 **A1 — Designers want to compose/own real code.** Many want the *outcome* (their design shipped faithfully, fast), not to own a codebase. Evidence is genuinely mixed; some designers report AI codegen is *slower* than just designing.
|
||||
- 🔴 **A2 — Designers will adopt a new canvas.** Figma stickiness is structural (libraries, network effects, org process); real-world switching is usually *additive / per-phase*, not a replacement.
|
||||
- 🔴 **A3 — The bottleneck is tooling, not governance.** Practitioners repeatedly say design-system drift/sync is a people-and-process problem a tool alone won't fix.
|
||||
- 🔴 **A4 — "BYO design system → real code" is genuinely unowned.** Competitive teardown was deferred this pass; Subframe is close. Harden before fundraising claims.
|
||||
|
||||
### Validation gate (sequenced, with kill criteria — run before/at the start of build)
|
||||
1. **Concierge real-PRs (primary):** hand-build 5 partners' screens from their own systems and open **real PRs** against their repos. **Pass** ≥3/5 merged with <10% LOC changed; **kill/rethink** if <2/5 or reviews are structural. Tests A1 *and* the trust bar with the correct judge, with zero product code.
|
||||
2. **Clickable-mock task test:** 5 designers complete the core task on a Figma prototype of the editor. **Pass** ≥4/5 unaided. Tests A2 (will they adopt a new canvas) before the canvas is built.
|
||||
3. **Fake-door demo** vs. a v0-style generic control: **pass** waitlist conversion ≥2× control.
|
||||
4. **Competitor teardown** (Subframe et al. — owed from Phase 2) to harden A4. No code needed.
|
||||
5. **10 problem interviews** with design-system leads probing A1 and A3.
|
||||
|
||||
> Founder OS discipline: only the token-engine + shared-runtime spike should run concurrently with these. "Build in parallel with validation" is how the gate gets quietly bypassed — the red-team flagged exactly this.
|
||||
Reference in New Issue
Block a user