first commit
This commit is contained in:
SinachPat
Binary file not shown.
@@ -0,0 +1,317 @@
|
|||||||
|
**ORIGINMAIN**
|
||||||
|
|
||||||
|
Business Development Document
|
||||||
|
|
||||||
|
*From Idea to Company: The Full Picture*
|
||||||
|
|
||||||
|
Version 1.0 \| April 2026 \| Patrick --- Founder \| Confidential
|
||||||
|
|
||||||
|
**1. Executive Summary**
|
||||||
|
|
||||||
|
Originmain is being built to capture a specific, high-value gap in the \$10B+ design tooling and AI developer tools markets: the persistent, expensive seam between design intent and production code. The design-to-code handoff costs modern product teams an estimated 30-40% of sprint capacity. Existing tools have nibbled at this problem from either side --- better design specs, better AI code generation --- but no tool has attacked the gap itself by making the design surface and the code surface the same thing.
|
||||||
|
|
||||||
|
This document covers the complete business development picture: market sizing, revenue model, funding strategy, team building, competitive moat, and the milestones that define the journey from founding to a sustainable, category-defining business.
|
||||||
|
|
||||||
|
----------------------------- ---------------------------------------------------------------------------------------------------------------
|
||||||
|
**Dimension** **Summary**
|
||||||
|
Market Opportunity \$2.8B serviceable market (design engineering teams on React/Next.js stacks globally)
|
||||||
|
Revenue Model SaaS, team-based pricing (\$49-\$149/mo per workspace), Enterprise (custom)
|
||||||
|
Target Year-1 ARR (post-GA) \$1.2M ARR from 800 paying teams at blended \$125/mo
|
||||||
|
Funding Target (Seed) \$2.5M --- 18 months runway to Phase 3 (public beta)
|
||||||
|
Target Funding (Series A) \$10M --- fuel GTM and enterprise sales post-GA, at Month 18+
|
||||||
|
Team at Launch 6 FTEs: Founder/CEO, 2 Engineers, 1 Design Engineer, 1 AI/Agent Engineer, 1 Growth
|
||||||
|
Moat Origin Graph + Agent Bridge + Design Language Runtime --- a data flywheel no competitor can replicate quickly
|
||||||
|
----------------------------- ---------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**2. Market Opportunity**
|
||||||
|
|
||||||
|
**2.1 Total Addressable Market (TAM)**
|
||||||
|
|
||||||
|
The TAM for Originmain spans three converging markets:
|
||||||
|
|
||||||
|
-------------------------- --------------- ----------------- ----------------------------------------------------------------------------
|
||||||
|
**Market** **2026 Size** **Growth Rate** **Basis**
|
||||||
|
Design Tools \$3.2B 18% CAGR Figma, Sketch, Framer, Adobe XD subscription revenue globally
|
||||||
|
AI Developer Tools \$4.8B 42% CAGR GitHub Copilot, Cursor, Claude Code, Tabnine subscription revenue globally
|
||||||
|
Design-Dev Collaboration \$1.1B 25% CAGR Zeplin, Abstract, Figma Dev Mode, InVision
|
||||||
|
Combined TAM \$9.1B --- ---
|
||||||
|
-------------------------- --------------- ----------------- ----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**2.2 Serviceable Addressable Market (SAM)**
|
||||||
|
|
||||||
|
Originmain\'s SAM is constrained to teams with: (a) a React or Next.js frontend, (b) at least one person in a design engineering or frontend developer role, and (c) an active design process (using Figma, Stitch, or similar). Based on developer survey data (Stack Overflow 2025, State of JS 2025), approximately 31% of professional frontend teams meet this profile.
|
||||||
|
|
||||||
|
-------------------------------------------------- ---------------------- --------------------------------------------------------------------------
|
||||||
|
**Estimate** **Value** **Method**
|
||||||
|
Professional product teams globally \~4.2M teams GitHub active org count x filter for frontend frameworks
|
||||||
|
Teams using React/Next.js \~1.3M teams 31% of 4.2M (State of JS 2025 data)
|
||||||
|
Teams with design process + design engineer role \~620,000 teams 47% of React teams (surveys indicate design maturity at post-Seed stage)
|
||||||
|
SAM (at \$49-149/mo per team) \$2.8B ARR potential 620,000 x \$375 blended ARPA (annual)
|
||||||
|
-------------------------------------------------- ---------------------- --------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**2.3 Serviceable Obtainable Market (SOM)**
|
||||||
|
|
||||||
|
Realistic market capture in Years 1--3, given current competitive dynamics, team size, and GTM strategy:
|
||||||
|
|
||||||
|
-------------------------- -------------- ----------------------- --------- -------------------------
|
||||||
|
**Year** **Teams** **Blended ARPA** **ARR** **Market Share of SAM**
|
||||||
|
Year 1 (GA to 12 months) 800 teams \$125/mo (\$1,500/yr) \$1.2M 0.13%
|
||||||
|
Year 2 4,000 teams \$150/mo (\$1,800/yr) \$7.2M 0.65%
|
||||||
|
Year 3 15,000 teams \$175/mo (\$2,100/yr) \$31.5M 2.4%
|
||||||
|
-------------------------- -------------- ----------------------- --------- -------------------------
|
||||||
|
|
||||||
|
------------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**THESIS** A 2.4% share of our SAM by Year 3 produces a \$31.5M ARR business. This is conservative. The design-to-code tool category is winner-take-most: the tool that becomes the default integration layer between design and AI coding captures disproportionate share.
|
||||||
|
------------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**3. Business Model**
|
||||||
|
|
||||||
|
**3.1 Revenue Streams**
|
||||||
|
|
||||||
|
-------------------------------------- ---------------------------------------- ------------------- -------------------------
|
||||||
|
**Revenue Stream** **Type** **Launch Timing** **Year 3 % of Revenue**
|
||||||
|
Pro & Team SaaS subscriptions Recurring SaaS Month 18 (GA) 55%
|
||||||
|
Enterprise contracts (custom) Recurring SaaS + professional services Month 18 (GA) 35%
|
||||||
|
AI usage overages (Completion Zones) Usage-based add-on Month 18 (GA) 7%
|
||||||
|
Agency / white-label licensing Annual licence + rev-share Month 24 3%
|
||||||
|
-------------------------------------- ---------------------------------------- ------------------- -------------------------
|
||||||
|
|
||||||
|
**3.2 Unit Economics Model**
|
||||||
|
|
||||||
|
Target unit economics at steady state (Year 3):
|
||||||
|
|
||||||
|
-------------------------------------- ----------------------- ---------------------------------------------------------------------------
|
||||||
|
**Metric** **Target** **Basis**
|
||||||
|
Gross Margin 82% SaaS with AI API costs passed through at 2x; infra costs \~8% at scale
|
||||||
|
Customer Acquisition Cost (CAC) \$180 blended Community-led growth dominant; paid search + content at scale
|
||||||
|
Annual Contract Value (ACV) --- Pro \$588/yr (\$49/mo) Single workspace, monthly billing
|
||||||
|
Annual Contract Value (ACV) --- Team \$1,788/yr (\$149/mo) Growing teams, annual billing discount applied
|
||||||
|
ACV --- Enterprise \$24,000/yr avg 10-50 seat equivalent, annual contracts, negotiated
|
||||||
|
Customer Lifetime (avg) 3.2 years Low churn expected: deep codebase integration creates high switching cost
|
||||||
|
LTV (blended) \$4,320 Blended ACV \$1,350 x 3.2 years
|
||||||
|
LTV:CAC Ratio 24:1 Target 3:1 minimum; community-led GTM achieves significantly better ratio
|
||||||
|
Payback Period 1.6 months Low CAC + relatively high ACV makes payback fast
|
||||||
|
-------------------------------------- ----------------------- ---------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**3.3 Pricing Rationale**
|
||||||
|
|
||||||
|
Originmain\'s pricing is anchored to the value it displaces, not to the cost of building it. The reference comparison: a 5-person product team spending 30% of sprint time on design-to-code reconciliation at an average \$85/hr blended rate loses \$5,440/month to the problem. Originmain\'s Team plan at \$149/month costs 2.7% of the problem it solves. This is the anchor used in sales conversations.
|
||||||
|
|
||||||
|
**4. Competitive Moat**
|
||||||
|
|
||||||
|
**4.1 Moat Architecture**
|
||||||
|
|
||||||
|
Originmain\'s defensibility is not a single feature --- it is an interlocking system of three compounding moats that become harder to replicate as adoption grows:
|
||||||
|
|
||||||
|
--------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------ -------------------------------------------------------------
|
||||||
|
**Moat** **Description** **Time to Replicate (est.)** **Compounds With**
|
||||||
|
Origin Graph A proprietary data graph of every design decision, its origin, its author, and its implementation outcome. Grows more valuable with every artboard, diff, and agent session added. No competitor has this data. 18--24 months (data moat --- cannot be copied, only accumulated) Agent Bridge feedback loop; Design Language drift detection
|
||||||
|
Agent Bridge Integrations First-party, bidirectional integrations with Cursor and Claude Code. Not a simple \'export to\' --- a two-way channel where coding agents communicate with design agents. Requires deep partnership with AI coding tool vendors. 12--18 months (partnership + protocol depth) Origin Graph enrichment from implementation feedback
|
||||||
|
Design Language Runtime A validated, team-specific runtime that constrains AI completions, visual edits, and drift detection. The longer a team uses it, the richer and more precise it becomes --- a flywheel other tools cannot access. 12 months to build; cannot replicate a specific team\'s DLF data Completion Zone quality; drift detection precision
|
||||||
|
--------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------ -------------------------------------------------------------
|
||||||
|
|
||||||
|
**4.2 Switching Cost Analysis**
|
||||||
|
|
||||||
|
Originmain\'s switching cost is unusually high for a design tool --- because it integrates deeply with both the design process AND the codebase:
|
||||||
|
|
||||||
|
- The Origin Graph contains the team\'s complete design decision history --- irreplaceable once built
|
||||||
|
|
||||||
|
- Design Language Files are custom-built and validated against the team\'s specific codebase --- not portable to other tools
|
||||||
|
|
||||||
|
- Agent Bridge integrations are configured per-team and per-codebase --- require re-setup if moving
|
||||||
|
|
||||||
|
- The team\'s workflow changes: designers stop using Figma, engineers stop receiving static specs. Reverting requires re-establishing the entire prior workflow.
|
||||||
|
|
||||||
|
--------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**MOAT NOTE** The switching cost is not just technical --- it is behavioural. Once a team has built its Origin Graph and Design Language File, those artefacts represent months of team knowledge encoded in the product. The tool becomes infrastructure, not software.
|
||||||
|
--------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**5. Team Building Plan**
|
||||||
|
|
||||||
|
**5.1 Founding Team (Month 0--4)**
|
||||||
|
|
||||||
|
-------------------------------- ------------------------------ -------------------------- -------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**Role** **Hire Type** **Compensation Model** **Critical Criteria**
|
||||||
|
Founder / CEO (Patrick) Founder Equity (founder) Product vision, community building, investor relationships
|
||||||
|
Lead Rendering / Diff Engineer Full-time hire \#1 Salary + 0.5-1.0% equity Expert in React internals, iframe sandboxing, Module Federation. Must have shipped a live-rendering system before.
|
||||||
|
Full-Stack / Data Engineer Full-time hire \#2 Salary + 0.5-1.0% equity PostgreSQL expert; Supabase experience preferred; strong TypeScript skills
|
||||||
|
Design Engineer (UI + DX) Full-time hire \#3 Salary + 0.3-0.7% equity Fluent 2 / Fluent UI experience highly desirable; must ship beautiful, accessible UIs without a designer alongside them
|
||||||
|
AI / Agent Engineer Full-time hire \#4 (Month 3) Salary + 0.3-0.7% equity Claude API + MCP experience; prompt engineering discipline; has built agentic workflows before
|
||||||
|
Growth / Community (Month 4) Part-time or fractional Salary or contract Design engineering community native; writes well; manages GTM execution, not strategy
|
||||||
|
-------------------------------- ------------------------------ -------------------------- -------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**5.2 Phase 2 Hires (Months 5--10)**
|
||||||
|
|
||||||
|
---------------------------------------- ----------------------- -------------------------------------------------------------------------------------------------
|
||||||
|
**Role** **Timing** **Rationale**
|
||||||
|
Second Rendering Engineer Month 6 Rendering Engine is the highest-risk component; needs a second brain
|
||||||
|
Product Designer (Fluent 2 specialist) Month 5 Originmain\'s own UI needs expert design attention as it scales; can\'t rely on engineers alone
|
||||||
|
Developer Relations / Technical Writer Month 8 Closed beta onboarding, documentation, community education at scale
|
||||||
|
Customer Success (first hire) Month 9 (beta launch) High-touch beta onboarding; feeds direct product feedback to engineering
|
||||||
|
---------------------------------------- ----------------------- -------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**5.3 Series A Team (Month 18+)**
|
||||||
|
|
||||||
|
Post Series A, the team scales to \~20 FTEs across product, engineering, GTM, and enterprise sales. Key additions:
|
||||||
|
|
||||||
|
- VP of Engineering --- to own the technical organisation as it scales beyond the founding team
|
||||||
|
|
||||||
|
- Head of Enterprise Sales --- to drive the enterprise and agency revenue stream
|
||||||
|
|
||||||
|
- 2-3 additional frontend engineers for multiplayer, plugin API, and multi-framework support
|
||||||
|
|
||||||
|
- Data Engineer --- to productise the Origin Graph analytics and drift detection features
|
||||||
|
|
||||||
|
- Marketing Lead --- to own content, brand, and paid channels post-GA
|
||||||
|
|
||||||
|
**6. Funding Strategy**
|
||||||
|
|
||||||
|
**6.1 Funding Stages**
|
||||||
|
|
||||||
|
------------------------- ------------------- ------------------------ --------------------------------------------------------------------------- -------------------------------------------------------------------
|
||||||
|
**Stage** **Target Amount** **Timing** **Use of Funds** **Target Investors**
|
||||||
|
Pre-Seed / Bootstrapped \$150K Month 0 (now) Founder living expenses, domain, minimal infra for 6 months Self-funded / angels
|
||||||
|
Seed Round \$2.5M Month 3--4 Hire founding team (4 FTEs), 18 months runway to Phase 3 / public beta Design tool investors, developer tool funds, AI-native SaaS funds
|
||||||
|
Series A \$10M Month 18--20 (post-GA) Scale GTM, enterprise sales team, infrastructure, international expansion Tier 1 SaaS / developer tools VCs
|
||||||
|
------------------------- ------------------- ------------------------ --------------------------------------------------------------------------- -------------------------------------------------------------------
|
||||||
|
|
||||||
|
**6.2 Seed Round Investor Profile**
|
||||||
|
|
||||||
|
Target seed investors are funds with a strong portfolio in developer tools, design tooling, or AI-native SaaS. The pitch works best for investors who: (a) have personal experience with the design-to-code problem, (b) have already bet on the AI coding tools space and see Originmain as a natural complement, or (c) have a thesis about the \'design layer\' of the AI software development stack.
|
||||||
|
|
||||||
|
----------------------------------- ------------------------------------------------------------------------------ -----------------------------------------------------------------------------------
|
||||||
|
**Investor Type** **Examples** **Why They Fit**
|
||||||
|
Developer tool-focused seed funds Heavybit, Boldstart Ventures, Amplify Partners Deep domain expertise; portfolio companies are Originmain\'s integration partners
|
||||||
|
Design tool investors General Catalyst (Figma), Accel (InVision) Understand the space; see the category shift happening
|
||||||
|
AI-native SaaS funds AIX Ventures, South Park Commons, a16z (SPEEDRUN) Active thesis on AI development tooling; see the coding agent layer as strategic
|
||||||
|
Strategic angels Design engineers and engineering leaders at Figma, Vercel, Linear, Anthropic Domain credibility; potential integration partnerships; community amplification
|
||||||
|
----------------------------------- ------------------------------------------------------------------------------ -----------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**6.3 Seed Round Milestones**
|
||||||
|
|
||||||
|
The seed round is raised against the following milestone trajectory. Investors should expect to see these milestones hit by the end of the seed period (Month 18):
|
||||||
|
|
||||||
|
--------------------------------------------- ----------------- ------------------------------------------------------------------------
|
||||||
|
**Milestone** **Target Date** **Signals Success**
|
||||||
|
Founding team hired (4 FTEs) Month 3 Team in place; engineering execution underway
|
||||||
|
First Live Artboard rendered from real app Month 4 Core technical thesis validated
|
||||||
|
20 Founding Design Partners active Month 6 Product-market fit early signal; qualitative feedback loop established
|
||||||
|
Waitlist: 2,000+ qualified signups Month 6 GTM resonance; audience built before launch
|
||||||
|
Closed beta: 100 teams, NPS \>= 50 Month 9 Retention signal; users find real workflow value
|
||||||
|
Agent Bridge live with Cursor + Claude Code Month 10 Differentiated technical moat established
|
||||||
|
Public beta live Month 12 Self-serve growth channel open; broader signal of product-market fit
|
||||||
|
1,000 active teams on public beta Month 14 Scale signal ahead of Series A
|
||||||
|
Series A fundraise kick-off Month 18 GA launched; paid plans active; initial revenue data
|
||||||
|
--------------------------------------------- ----------------- ------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**7. Financial Model**
|
||||||
|
|
||||||
|
**7.1 Seed Period Budget (\$2.5M over 18 months)**
|
||||||
|
|
||||||
|
-------------------------------------------------- ---------------------------- ------------------------ ----------------
|
||||||
|
**Category** **Monthly Budget** **18-Month Total** **% of Raise**
|
||||||
|
Salaries (5 FTEs avg \$145K/yr) \$60,400 \$1,087,200 43%
|
||||||
|
Founder compensation \$9,000 \$162,000 6%
|
||||||
|
Infrastructure (Vercel, Supabase, Railway, APIs) \$3,200 \$57,600 2%
|
||||||
|
AI API costs (Anthropic --- beta usage) \$2,000 → \$8,000 \$90,000 (est.) 4%
|
||||||
|
Legal (incorporation, IP, contracts) \$5,000 setup + \$1,000/mo \$23,000 1%
|
||||||
|
Marketing / GTM (pre-launch) \$2,500 \$45,000 2%
|
||||||
|
Marketing / GTM (launch + post) \$8,000 \$96,000 (months 8-18) 4%
|
||||||
|
Travel (investor meetings, conferences) \$1,500 \$27,000 1%
|
||||||
|
Office / co-working (optional, remote-first) \$1,200 \$21,600 1%
|
||||||
|
Buffer / contingency (15%) --- \$375,000 15%
|
||||||
|
TOTAL \$88,800 avg/mo \$2,500,000 (approx) 100%
|
||||||
|
-------------------------------------------------- ---------------------------- ------------------------ ----------------
|
||||||
|
|
||||||
|
**7.2 Revenue Projections (Post-GA)**
|
||||||
|
|
||||||
|
------------------------- ------------------ ---------------------------- ------------- ------------------
|
||||||
|
**Quarter** **Paying Teams** **Blended ARPA (monthly)** **MRR** **ARR Run Rate**
|
||||||
|
Month 18 (GA launch) 100 (early paid) \$95 \$9,500 \$114,000
|
||||||
|
Month 21 (Q1 post-GA) 350 \$110 \$38,500 \$462,000
|
||||||
|
Month 24 (Year 2 start) 800 \$125 \$100,000 \$1,200,000
|
||||||
|
Month 30 (mid Year 2) 2,000 \$140 \$280,000 \$3,360,000
|
||||||
|
Month 36 (Year 3 start) 4,000 \$150 \$600,000 \$7,200,000
|
||||||
|
Month 42 (mid Year 3) 8,000 \$160 \$1,280,000 \$15,360,000
|
||||||
|
Month 48 (Year 4 start) 15,000 \$175 \$2,625,000 \$31,500,000
|
||||||
|
------------------------- ------------------ ---------------------------- ------------- ------------------
|
||||||
|
|
||||||
|
---------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**NOTE** These projections assume: (1) paid conversion from public beta of 8% of active teams; (2) monthly churn of 1.5% (industry average for SaaS with high switching cost is 0.8--2.5%); (3) expansion revenue from Starter → Pro → Team upgrades contributing 30% of net new MRR after Month 24.
|
||||||
|
---------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**8. Business Risks & Mitigations**
|
||||||
|
|
||||||
|
-------------------------------------------------------- ---------------------------- ------------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**Risk** **Likelihood** **Impact** **Mitigation**
|
||||||
|
Figma acquires a competitor and ships live rendering Medium (18 mo horizon) High Accelerate Agent Bridge and Origin Graph moat --- Figma cannot replicate the bidirectional coding agent integration without becoming a code editor, which is not their business model.
|
||||||
|
Slow paid conversion --- users stay on free tier Medium High Gate the most high-value features (Agent Bridge, AI Completions) behind Pro; ensure free tier is genuinely useful but clearly limited. Analyse free-to-paid conversion weekly.
|
||||||
|
Rendering engine reliability issues slow adoption Medium High Invest heavily in rendering fidelity testing from Phase 1; set reliability SLA (99.5% render success rate) as a P0 engineering metric.
|
||||||
|
Google Stitch ships codebase-connected rendering Low-Medium (12 mo horizon) High Our moat is the Agent Bridge + Origin Graph, not rendering alone. Stitch would need to replicate 18 months of product depth to match Originmain at that point.
|
||||||
|
AI API costs exceed projections at scale Medium Medium Implement aggressive prompt caching; use Claude Haiku for low-stakes completions, Sonnet only for high-value tasks; pass overage costs to users via usage-based pricing.
|
||||||
|
Key hire failure (rendering engineer is irreplaceable) Low High Dual-hire strategy: hire 2 engineers with partial overlap in rendering skills so no single engineer is a SPOF. Build extensive documentation from Day 1.
|
||||||
|
MCP protocol maturity stalls Agent Bridge adoption Low-Medium Medium Ship a non-MCP fallback (file export + webhook) that covers 80% of the value; MCP becomes the premium path when it matures.
|
||||||
|
-------------------------------------------------------- ---------------------------- ------------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**9. Strategic Partnerships & Ecosystem**
|
||||||
|
|
||||||
|
**9.1 Tier 1 Strategic Partnerships (Existential Importance)**
|
||||||
|
|
||||||
|
These partnerships directly determine whether Originmain\'s core moat (the Agent Bridge) reaches its full potential:
|
||||||
|
|
||||||
|
------------------------- ---------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------
|
||||||
|
**Partner** **Goal** **Value Exchange** **Approach**
|
||||||
|
Anthropic (Claude Code) Official \'design layer\' partner for Claude Code; deep MCP integration; co-marketing Originmain gives Claude Code a visual context layer it cannot build itself; Anthropic gives Originmain distribution to the Claude Code user base (millions of developers) Direct outreach to Anthropic partnerships team; demonstrate the Agent Bridge integration; propose mutual case study
|
||||||
|
Cursor (Anysphere) First-party Cursor integration; Originmain featured in Cursor\'s integration ecosystem Originmain makes Cursor more powerful for design engineering workflows; Cursor gives Originmain access to its largest-in-class AI coding audience Partner with Cursor\'s ecosystem team; ship a polished Cursor extension before approaching for co-marketing
|
||||||
|
Linear Deep issue-to-artboard ingestion; integration listed in Linear\'s app directory Originmain makes Linear issues directly actionable on the design surface; Linear\'s design engineering audience is a near-perfect ICP match Linear has a published partner programme; apply formally; demo the issue-to-artboard flow
|
||||||
|
------------------------- ---------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**9.2 Tier 2 Ecosystem Partnerships**
|
||||||
|
|
||||||
|
---------------------------- -------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------
|
||||||
|
**Partner** **Goal** **Timing**
|
||||||
|
Microsoft (Fluent UI team) Originmain as a showcase for Fluent 2 in the design engineering space; potential co-marketing Month 6 (after canvas UI is polished)
|
||||||
|
Vercel Featured in Vercel\'s Next.js tooling ecosystem; joint webinars for Next.js design engineering audience Month 8 (when rendering engine is stable for Next.js apps)
|
||||||
|
GitHub Integration in GitHub\'s developer tooling marketplace; Originmain listed as a recommended design-code bridge tool Month 12 (when public beta is live)
|
||||||
|
Frontend Masters / Egghead Originmain featured in design engineering courses; co-created course content Month 14
|
||||||
|
---------------------------- -------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------
|
||||||
|
|
||||||
|
**10. Milestones & Decision Gates**
|
||||||
|
|
||||||
|
The following milestones serve as explicit decision gates. At each gate, the founding team evaluates whether to continue on the current trajectory, pivot a specific element, or accelerate based on the evidence.
|
||||||
|
|
||||||
|
------------------- ------------------------------------------------- ------------------------------------------------------------------- --------------------------------------------------------------- ----------------------------------------------------------------------------------
|
||||||
|
**Gate** **Milestone** **Green Outcome** **Yellow --- Investigate** **Red --- Pivot**
|
||||||
|
Gate 1 (Month 4) First Live Artboard from real app Renders React app reliably; component tree extracted Partial rendering; some components fail Rendering approach must change; consider alternative architecture
|
||||||
|
Gate 2 (Month 6) 20 Founding Partners active; qualitative signal Partners using Originmain weekly; clear \'aha moment\' documented Partners interested but not daily-active Re-examine the core loop; which part of the product drives the most value?
|
||||||
|
Gate 3 (Month 9) Closed beta NPS \>= 50 NPS 50+; clear retention; low churn from beta NPS 35--49; retention moderate NPS \< 35; product has fundamental usability or value gap requiring sprint reset
|
||||||
|
Gate 4 (Month 12) Public beta live; 1,000 active teams in 30 days Self-serve funnel working; referral loop emerging 500--999 active teams; acquisition strong but activation weak \< 500; re-examine onboarding and activation flow
|
||||||
|
Gate 5 (Month 18) GA launch; Series A process begins \$100K MRR; 10+ enterprise conversations; Series A term sheet \$50-100K MRR; investor interest but no term sheet \< \$50K MRR; re-evaluate pricing, segment, or positioning
|
||||||
|
------------------- ------------------------------------------------- ------------------------------------------------------------------- --------------------------------------------------------------- ----------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**11. Long-Term Vision (Year 5+)**
|
||||||
|
|
||||||
|
Originmain\'s 5-year ambition extends well beyond being a better design tool. The Origin Graph, at scale across thousands of teams, becomes one of the most valuable datasets in the software design industry --- a map of what design decisions are made, how they are implemented, and what outcomes they produce.
|
||||||
|
|
||||||
|
**11.1 The Platform Endgame**
|
||||||
|
|
||||||
|
By Year 5, Originmain aspires to be the platform layer that connects every design decision to every code change across the product development lifecycle. This means:
|
||||||
|
|
||||||
|
- The Origin Graph becomes queryable at industry scale: \'Show me how every B2B SaaS company has handled the onboarding flow over the last 3 years\'
|
||||||
|
|
||||||
|
- Design system drift detection becomes a standard part of the CI/CD pipeline, not a design tool feature
|
||||||
|
|
||||||
|
- The Agent Bridge becomes the standard protocol for design-code communication in the AI coding era --- every AI coding agent queries Originmain for design context before writing code
|
||||||
|
|
||||||
|
- White-label Originmain becomes the standard design-engineering platform for design agencies and digital consultancies globally
|
||||||
|
|
||||||
|
**11.2 Potential Exit Scenarios**
|
||||||
|
|
||||||
|
----------------------------------- ---------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**Scenario** **Acquirer Hypothesis** **Strategic Rationale**
|
||||||
|
Strategic acquisition (Year 5--7) Microsoft, Vercel, Figma, or Anthropic Originmain\'s Origin Graph and Agent Bridge are strategic infrastructure for any company building in the design-dev-AI stack. Microsoft (Fluent 2 alignment + GitHub Copilot complementarity) is the highest-probability strategic acquirer.
|
||||||
|
IPO (Year 8--10) Public market If Originmain reaches \$100M+ ARR with strong retention and a clear platform story, it is an IPO candidate in its own right --- a new category of AI-native design infrastructure.
|
||||||
|
Remain independent N/A The Origin Graph creates a defensible, compounding data asset that may be more valuable held independently than sold. This is the default plan until compelling acquisition terms materialise.
|
||||||
|
----------------------------------- ---------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
*End of Business Development Document --- Originmain v1.0*
|
||||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,552 @@
|
|||||||
|
---
|
||||||
|
name: originmain-frontend
|
||||||
|
description: "Use this skill for all frontend work on Originmain. It synthesises three design systems into a coherent implementation guide: Fluent 2 (@fluentui/react-components v9) for all application chrome and navigation UI, @pierre/diffs for code-level diff rendering in the export panel and Agent Bridge view, and @pierre/trees for the codebase file browser. The skill defines which library owns which surface, how to theme @pierre/* libraries using Fluent 2 tokens, critical constraints for each library, and component-level implementation patterns. Use when creating, editing, or reviewing any Originmain UI component."
|
||||||
|
---
|
||||||
|
|
||||||
|
# Originmain Frontend Design Skill
|
||||||
|
|
||||||
|
This skill governs all frontend work on Originmain. It is the definitive reference for which library owns which surface, how the three systems interoperate, and what constraints must never be violated.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## The Three-Library Architecture
|
||||||
|
|
||||||
|
Originmain's frontend is built on three libraries that cover distinct responsibilities. Understanding their boundaries is the most important thing in this skill.
|
||||||
|
|
||||||
|
### Library 1: Fluent 2 — Application Chrome & Navigation
|
||||||
|
|
||||||
|
**Package:** `@fluentui/react-components` v9
|
||||||
|
**License:** MIT
|
||||||
|
**Governs:** Everything in the application shell — toolbar, menus, panels, dialogs, inspector, inputs, feedback components, and the artboard navigator sidebar.
|
||||||
|
|
||||||
|
Fluent 2 is not a styling choice. It is the design language contract. Every Originmain-owned UI surface uses Fluent 2 components and Fluent 2 tokens. No exceptions. This ensures that the tool's own interface embodies the same systematic, accessible design language it helps teams produce.
|
||||||
|
|
||||||
|
### Library 2: @pierre/diffs — Code-Level Diff Rendering
|
||||||
|
|
||||||
|
**Package:** `@pierre/diffs`
|
||||||
|
**License:** Apache 2.0
|
||||||
|
**Governs:** The export panel (where a developer previews what code changes will be applied to their codebase) and the Agent Bridge communication view (where the coding agent's status is shown alongside design intent).
|
||||||
|
|
||||||
|
@pierre/diffs does NOT replace the custom AST differ in `packages/diff-engine`. The AST differ computes what changed. @pierre/diffs renders it. These are separate concerns.
|
||||||
|
|
||||||
|
### Library 3: @pierre/trees — Codebase File Browser
|
||||||
|
|
||||||
|
**Package:** `@pierre/trees`
|
||||||
|
**License:** Open source (The Pierre Computer Co.)
|
||||||
|
**Governs:** The codebase file browser panel — the panel that shows the connected application's repository file tree with git status indicators, search, and virtualization.
|
||||||
|
|
||||||
|
@pierre/trees does NOT replace Fluent 2's Tree component. Fluent 2 Tree governs the artboard navigator (workspace folders, artboard groups, project hierarchy). @pierre/trees governs the codebase file browser only.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Surface Ownership Map
|
||||||
|
|
||||||
|
This table is the definitive reference. When building any component, check which library owns the surface before writing a line of code.
|
||||||
|
|
||||||
|
| Surface | Library | Why |
|
||||||
|
|---|---|---|
|
||||||
|
| Root layout | Fluent 2 `FluentProvider` | Required wrapper for all Fluent 2 context |
|
||||||
|
| Canvas toolbar | Fluent 2 `Toolbar`, `ToolbarButton` | Chrome component — in-ecosystem |
|
||||||
|
| Top navigation | Fluent 2 `Tab`, `TabList`, `Menu` | Chrome component |
|
||||||
|
| **Artboard navigator** (left panel workspace tree) | Fluent 2 `Tree`, `TreeItem` | Navigates product metadata; small node count; must match chrome |
|
||||||
|
| **Codebase file browser** (repository tree) | `@pierre/trees` `FileTree` | Navigates code; thousands of nodes; needs git status + virtualization |
|
||||||
|
| Inspector panel | Fluent 2 `Card`, `Accordion`, `DataGrid` | Chrome component |
|
||||||
|
| Intent Diff inspector | Fluent 2 `Card`, `Accordion`, `Badge` | Structured semantic data, not code |
|
||||||
|
| **Export panel diff view** | `@pierre/diffs` `MultiFileDiff` | Code-level rendering with Shiki; split or stacked mode |
|
||||||
|
| **Agent Bridge diff view** | `@pierre/diffs` `FileDiff` | Stacked mode; lines of dialogue above diff |
|
||||||
|
| Completion Zone UI | Fluent 2 `Popover`, `Input`, `Button` | In-canvas control — chrome |
|
||||||
|
| Dialogs | Fluent 2 `Dialog`, `Drawer` | Chrome |
|
||||||
|
| Status & feedback | Fluent 2 `Toast`, `MessageBar`, `Spinner` | Chrome |
|
||||||
|
| Presence / multiplayer | Fluent 2 `Avatar`, `PresenceBadge` | Chrome |
|
||||||
|
| Artboard status badges | Fluent 2 `Badge`, `PresenceBadge` | Chrome |
|
||||||
|
| Form inputs | Fluent 2 `Input`, `Combobox`, `SearchBox` | Chrome |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fluent 2 — Rules and Patterns
|
||||||
|
|
||||||
|
### Setup
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
// packages/app/src/app/layout.tsx
|
||||||
|
import { FluentProvider } from '@fluentui/react-components';
|
||||||
|
import { originmainTheme } from '@originmain/ui';
|
||||||
|
|
||||||
|
export default function RootLayout({ children }: { children: React.ReactNode }) {
|
||||||
|
return (
|
||||||
|
<html lang="en">
|
||||||
|
<body>
|
||||||
|
<FluentProvider theme={originmainTheme}>
|
||||||
|
{children}
|
||||||
|
</FluentProvider>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Brand Theme
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
// packages/ui/src/themes/originmain-theme.ts
|
||||||
|
import { createLightTheme, createDarkTheme, type BrandVariants } from '@fluentui/react-components';
|
||||||
|
|
||||||
|
const originmainBrand: BrandVariants = {
|
||||||
|
10: '#f0f4fc',
|
||||||
|
20: '#d8e4f7',
|
||||||
|
30: '#b3c9ef',
|
||||||
|
40: '#8daee7',
|
||||||
|
50: '#6793df',
|
||||||
|
60: '#4178d7',
|
||||||
|
70: '#2563ce',
|
||||||
|
80: '#1655c0', // primary brand colour
|
||||||
|
90: '#0f52ba', // anchor — the Originmain blue
|
||||||
|
100: '#0d4aa8',
|
||||||
|
110: '#0b4096',
|
||||||
|
120: '#083680',
|
||||||
|
130: '#062c6a',
|
||||||
|
140: '#042254',
|
||||||
|
150: '#02183e',
|
||||||
|
160: '#010d28',
|
||||||
|
};
|
||||||
|
|
||||||
|
export const originmainTheme = createLightTheme(originmainBrand);
|
||||||
|
export const originmainDarkTheme = createDarkTheme(originmainBrand);
|
||||||
|
```
|
||||||
|
|
||||||
|
### Styling — Always Use makeStyles
|
||||||
|
|
||||||
|
Never use inline styles for Fluent 2 components except when projecting tokens into third-party libraries (see Theming Bridge below). Use `makeStyles` from `@fluentui/react-components` (Griffel CSS-in-JS).
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
import { makeStyles, tokens } from '@fluentui/react-components';
|
||||||
|
|
||||||
|
const useStyles = makeStyles({
|
||||||
|
panel: {
|
||||||
|
backgroundColor: tokens.colorNeutralBackground2,
|
||||||
|
borderRight: `1px solid ${tokens.colorNeutralStroke2}`,
|
||||||
|
padding: tokens.spacingHorizontalM,
|
||||||
|
},
|
||||||
|
heading: {
|
||||||
|
fontSize: tokens.fontSizeBase400,
|
||||||
|
fontWeight: tokens.fontWeightSemibold,
|
||||||
|
color: tokens.colorNeutralForeground1,
|
||||||
|
},
|
||||||
|
});
|
||||||
|
```
|
||||||
|
|
||||||
|
### Artboard Navigator (Fluent 2 Tree)
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
import { Tree, TreeItem, TreeItemLayout } from '@fluentui/react-components';
|
||||||
|
|
||||||
|
interface NavigatorNode {
|
||||||
|
id: string;
|
||||||
|
label: string;
|
||||||
|
type: 'workspace' | 'folder' | 'group' | 'artboard';
|
||||||
|
originType?: 'linear' | 'git' | 'feedback' | 'manual';
|
||||||
|
children?: NavigatorNode[];
|
||||||
|
}
|
||||||
|
|
||||||
|
function renderNode(node: NavigatorNode): React.ReactNode {
|
||||||
|
if (node.children?.length) {
|
||||||
|
return (
|
||||||
|
<TreeItem key={node.id} itemType="branch">
|
||||||
|
<TreeItemLayout iconBefore={<FolderIcon />}>{node.label}</TreeItemLayout>
|
||||||
|
<Tree>{node.children.map(renderNode)}</Tree>
|
||||||
|
</TreeItem>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
return (
|
||||||
|
<TreeItem key={node.id} itemType="leaf">
|
||||||
|
<TreeItemLayout iconBefore={<ArtboardIcon />}>{node.label}</TreeItemLayout>
|
||||||
|
</TreeItem>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Critical Fluent 2 Constraints
|
||||||
|
|
||||||
|
- **FluentProvider is required.** All Fluent 2 hooks, tokens, and components silently fail or throw outside it.
|
||||||
|
- **Never use `style` prop for colours.** Use `tokens.*` from `@fluentui/react-components` inside `makeStyles`.
|
||||||
|
- **Never import from `@fluentui/react-components/unstable`.** Unstable APIs are not covered by semver.
|
||||||
|
- **Use `tokens.colorBrandBackground` not `#0F52BA`** for brand colour references in Fluent 2 surfaces.
|
||||||
|
- **Heading hierarchy matters for accessibility.** Fluent 2's `Text` component does not enforce this — you must set the correct `as` prop (`h1`, `h2`, etc.) manually.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## @pierre/diffs — Rules and Patterns
|
||||||
|
|
||||||
|
### Setup
|
||||||
|
|
||||||
|
```bash
|
||||||
|
pnpm add @pierre/diffs
|
||||||
|
```
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
import { MultiFileDiff, FileDiff, PatchDiff } from '@pierre/diffs/react';
|
||||||
|
```
|
||||||
|
|
||||||
|
### Component Choices
|
||||||
|
|
||||||
|
| Situation | Component | Notes |
|
||||||
|
|---|---|---|
|
||||||
|
| Multiple files changed | `MultiFileDiff` | Export panel default |
|
||||||
|
| Single file comparison | `FileDiff` | Pass `before` and `after` file content strings |
|
||||||
|
| Raw git patch string | `PatchDiff` | Agent Bridge git-level view |
|
||||||
|
|
||||||
|
### Theming Bridge (Fluent 2 → @pierre/diffs)
|
||||||
|
|
||||||
|
@pierre/diffs is themed via CSS custom properties on its container element. Map Fluent 2 tokens to the properties @pierre/diffs exposes. Always use the `style` prop on the wrapper div — never hardcoded values. Note: `makeStyles` does not support arbitrary CSS custom properties, so this is the correct exception where inline `style` is used.
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
// packages/app/src/components/diff/CodeDiffPanel.tsx
|
||||||
|
import { MultiFileDiff } from '@pierre/diffs/react';
|
||||||
|
|
||||||
|
const diffThemeBridge = {
|
||||||
|
'--diff-background': 'var(--colorNeutralBackground1)',
|
||||||
|
'--diff-gutter-background': 'var(--colorNeutralBackground2)',
|
||||||
|
'--diff-added-line': 'var(--colorPaletteGreenBackground1)',
|
||||||
|
'--diff-removed-line': 'var(--colorPaletteRedBackground1)',
|
||||||
|
'--diff-added-gutter': 'var(--colorPaletteGreenBackground2)',
|
||||||
|
'--diff-removed-gutter': 'var(--colorPaletteRedBackground2)',
|
||||||
|
'--diff-border-color': 'var(--colorNeutralStroke2)',
|
||||||
|
'--diff-text-color': 'var(--colorNeutralForeground1)',
|
||||||
|
'--diff-annotation-color': 'var(--colorNeutralForeground3)',
|
||||||
|
'--diff-filename-color': 'var(--colorNeutralForeground2)',
|
||||||
|
'--diff-hunk-background': 'var(--colorNeutralBackground3)',
|
||||||
|
} as React.CSSProperties;
|
||||||
|
|
||||||
|
// Shiki theme selection based on Fluent 2 theme mode
|
||||||
|
function getShikiTheme(isDark: boolean): string {
|
||||||
|
return isDark ? 'github-dark-dimmed' : 'github-light';
|
||||||
|
}
|
||||||
|
|
||||||
|
function CodeDiffPanel({ diff, isDark }: { diff: IntentDiff; isDark: boolean }) {
|
||||||
|
return (
|
||||||
|
<div style={diffThemeBridge}>
|
||||||
|
<MultiFileDiff
|
||||||
|
diffs={mapIntentDiffToFileDiffs(diff)}
|
||||||
|
mode="split"
|
||||||
|
theme={getShikiTheme(isDark)}
|
||||||
|
annotations={buildDiffAnnotations(diff)}
|
||||||
|
/>
|
||||||
|
</div>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Annotation Pattern
|
||||||
|
|
||||||
|
The annotation system is @pierre/diffs' most valuable feature for Originmain. Anchor the `humanSummary` of each `ComponentChange` to the specific line it modifies. This creates the connected "design intent → code line" view that is Originmain's signature export experience.
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
// packages/app/src/components/diff/diff-mappers.ts
|
||||||
|
|
||||||
|
interface DiffAnnotation {
|
||||||
|
lineNumber: number;
|
||||||
|
content: string;
|
||||||
|
type: 'info' | 'warning' | 'success';
|
||||||
|
}
|
||||||
|
|
||||||
|
export function buildDiffAnnotations(diff: IntentDiff): DiffAnnotation[] {
|
||||||
|
return diff.changes
|
||||||
|
.filter(change => change.lineNumber !== undefined)
|
||||||
|
.map(change => ({
|
||||||
|
lineNumber: change.lineNumber!,
|
||||||
|
content: change.humanSummary,
|
||||||
|
type: change.changeType === 'removal' ? 'warning' : 'info',
|
||||||
|
}));
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mode Switching (Split vs Stacked)
|
||||||
|
|
||||||
|
The export panel uses split mode (side-by-side) at widths >= 640px and stacked (unified) mode below. The Agent Bridge communication view always uses stacked mode to maximise vertical information density alongside the chat-style dialogue.
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
const [mode, setMode] = React.useState<'split' | 'stacked'>('split');
|
||||||
|
const containerRef = React.useRef<HTMLDivElement>(null);
|
||||||
|
|
||||||
|
React.useEffect(() => {
|
||||||
|
if (!containerRef.current) return;
|
||||||
|
const observer = new ResizeObserver(([entry]) => {
|
||||||
|
setMode(entry.contentRect.width >= 640 ? 'split' : 'stacked');
|
||||||
|
});
|
||||||
|
observer.observe(containerRef.current);
|
||||||
|
return () => observer.disconnect();
|
||||||
|
}, []);
|
||||||
|
```
|
||||||
|
|
||||||
|
### Critical @pierre/diffs Constraints
|
||||||
|
|
||||||
|
- **Never use @pierre/diffs for the Intent Diff inspector sidebar.** That surface shows semantic component-level changes (Fluent 2 Card/Accordion). @pierre/diffs is for code-level line diffs only.
|
||||||
|
- **Always provide a Shiki theme.** Omitting `theme` falls back to an unstyled view that clashes with the Fluent 2 chrome.
|
||||||
|
- **Annotations only anchor to lines that exist in the rendered diff.** Validate that `lineNumber` is within range before creating an annotation — out-of-range line numbers are silently ignored.
|
||||||
|
- **Shadow DOM is used internally.** Do not attempt to style @pierre/diffs internals with global CSS selectors. The CSS custom properties API is the only supported theming interface.
|
||||||
|
- **Test both light and dark mode.** The Shiki theme must switch when the user toggles Fluent 2's dark mode.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## @pierre/trees — Rules and Patterns
|
||||||
|
|
||||||
|
### Setup
|
||||||
|
|
||||||
|
```bash
|
||||||
|
pnpm add @pierre/trees
|
||||||
|
```
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
import { FileTree } from '@pierre/trees';
|
||||||
|
import type { FileTreeNode } from '@pierre/trees';
|
||||||
|
```
|
||||||
|
|
||||||
|
### Component Usage
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
// packages/app/src/components/codebase/CodebaseFileTree.tsx
|
||||||
|
|
||||||
|
interface CodebaseFileTreeProps {
|
||||||
|
nodes: FileTreeNode[];
|
||||||
|
onFileSelect: (path: string) => void;
|
||||||
|
}
|
||||||
|
|
||||||
|
export function CodebaseFileTree({ nodes, onFileSelect }: CodebaseFileTreeProps) {
|
||||||
|
return (
|
||||||
|
<div style={{ ...treesThemeBridge, height: '100%' }}>
|
||||||
|
<FileTree
|
||||||
|
nodes={nodes}
|
||||||
|
gitStatus={true}
|
||||||
|
flattenEmptyDirectories={true}
|
||||||
|
fileTreeSearchMode="filter"
|
||||||
|
onSelect={(node) => {
|
||||||
|
if (node.type === 'file') onFileSelect(node.path);
|
||||||
|
}}
|
||||||
|
/>
|
||||||
|
</div>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### FileTreeNode Shape
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
interface FileTreeNode {
|
||||||
|
id: string;
|
||||||
|
name: string;
|
||||||
|
path: string;
|
||||||
|
type: 'file' | 'directory';
|
||||||
|
gitStatus?: 'added' | 'modified' | 'deleted' | 'renamed' | 'untracked' | 'ignored';
|
||||||
|
children?: FileTreeNode[];
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Build the `FileTreeNode[]` array from the component tree extracted by the renderer (`packages/renderer/src/fiber-injector.ts`). The renderer provides file paths via sourcemaps — use those to construct the tree structure.
|
||||||
|
|
||||||
|
### Theming Bridge (Fluent 2 → @pierre/trees)
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
const treesThemeBridge = {
|
||||||
|
'--tree-background': 'var(--colorNeutralBackground2)',
|
||||||
|
'--tree-item-hover': 'var(--colorNeutralBackground3)',
|
||||||
|
'--tree-item-selected': 'var(--colorBrandBackground2)',
|
||||||
|
'--tree-item-selected-text': 'var(--colorBrandForeground2)',
|
||||||
|
'--tree-text-color': 'var(--colorNeutralForeground1)',
|
||||||
|
'--tree-secondary-text': 'var(--colorNeutralForeground3)',
|
||||||
|
'--tree-border-color': 'var(--colorNeutralStroke2)',
|
||||||
|
'--tree-git-added': 'var(--colorPaletteGreenForeground1)',
|
||||||
|
'--tree-git-modified': 'var(--colorPaletteYellowForeground1)',
|
||||||
|
'--tree-git-deleted': 'var(--colorPaletteRedForeground1)',
|
||||||
|
'--tree-git-renamed': 'var(--colorPaletteBlueForeground2)',
|
||||||
|
'--tree-git-untracked': 'var(--colorNeutralForeground3)',
|
||||||
|
'--tree-git-ignored': 'var(--colorNeutralForegroundDisabled)',
|
||||||
|
} as React.CSSProperties;
|
||||||
|
```
|
||||||
|
|
||||||
|
### fileTreeSearchMode Options
|
||||||
|
|
||||||
|
| Mode | Behaviour | When to use |
|
||||||
|
|---|---|---|
|
||||||
|
| `"filter"` | Non-matching nodes are hidden | Default — cleaner search experience |
|
||||||
|
| `"highlight"` | Non-matching nodes are dimmed | When user needs spatial context |
|
||||||
|
| `"expand"` | Matching nodes' parents expand automatically | When browsing deep paths |
|
||||||
|
|
||||||
|
### Critical @pierre/trees Constraints
|
||||||
|
|
||||||
|
- **@pierre/trees is for the codebase file browser only.** Never use it in the artboard navigator. They serve different data with different requirements.
|
||||||
|
- **Virtualization is automatic.** Do not set a fixed height and then manually manage virtualization. Let @pierre/trees own its scroll container.
|
||||||
|
- **`gitStatus` prop must be boolean `true`**, not an object or function. Git status is read from the `gitStatus` field on each `FileTreeNode`.
|
||||||
|
- **The container div must have a defined height.** Set `height: '100%'` and ensure the parent has a constrained height. A tree inside a flex container with no height constraint will render zero rows.
|
||||||
|
- **Do not render @pierre/trees outside a Fluent 2 FluentProvider.** The theme bridge uses CSS variables emitted by Fluent 2's token system — those variables are undefined outside the provider.
|
||||||
|
- **Search is client-side.** Do not fire API calls on search input. All filtering happens in memory on the node array passed in.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Token Quick Reference
|
||||||
|
|
||||||
|
The most commonly needed Fluent 2 design tokens for Originmain surfaces:
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
// Backgrounds
|
||||||
|
tokens.colorNeutralBackground1 // primary surface (white in light / dark in dark)
|
||||||
|
tokens.colorNeutralBackground2 // secondary surface (panels, sidebars)
|
||||||
|
tokens.colorNeutralBackground3 // tertiary surface (hover states, tinted fills)
|
||||||
|
tokens.colorBrandBackground // brand blue fill
|
||||||
|
tokens.colorBrandBackground2 // selected item fill (lighter blue)
|
||||||
|
|
||||||
|
// Foregrounds
|
||||||
|
tokens.colorNeutralForeground1 // primary text
|
||||||
|
tokens.colorNeutralForeground2 // secondary text
|
||||||
|
tokens.colorNeutralForeground3 // tertiary / placeholder text
|
||||||
|
tokens.colorNeutralForegroundDisabled // disabled text
|
||||||
|
tokens.colorBrandForeground1 // brand blue text on neutral backgrounds
|
||||||
|
tokens.colorBrandForeground2 // brand blue text on brand backgrounds
|
||||||
|
|
||||||
|
// Strokes
|
||||||
|
tokens.colorNeutralStroke1 // default border
|
||||||
|
tokens.colorNeutralStroke2 // subtle border
|
||||||
|
tokens.colorBrandStroke1 // brand border / focus ring
|
||||||
|
|
||||||
|
// Status palette (use for git status, diff indicators, validation states)
|
||||||
|
tokens.colorPaletteGreenForeground1 // added / success
|
||||||
|
tokens.colorPaletteGreenBackground1 // added line highlight
|
||||||
|
tokens.colorPaletteYellowForeground1 // modified / warning
|
||||||
|
tokens.colorPaletteYellowBackground1 // modified line highlight
|
||||||
|
tokens.colorPaletteRedForeground1 // deleted / error
|
||||||
|
tokens.colorPaletteRedBackground1 // deleted line highlight
|
||||||
|
tokens.colorPaletteBlueForeground2 // renamed / info
|
||||||
|
|
||||||
|
// Spacing
|
||||||
|
tokens.spacingHorizontalXS // 4px
|
||||||
|
tokens.spacingHorizontalS // 8px
|
||||||
|
tokens.spacingHorizontalM // 12px
|
||||||
|
tokens.spacingHorizontalL // 16px
|
||||||
|
tokens.spacingHorizontalXL // 20px
|
||||||
|
tokens.spacingHorizontalXXL // 24px
|
||||||
|
tokens.spacingVerticalXS // 4px
|
||||||
|
tokens.spacingVerticalS // 8px
|
||||||
|
tokens.spacingVerticalM // 12px
|
||||||
|
tokens.spacingVerticalL // 16px
|
||||||
|
|
||||||
|
// Typography
|
||||||
|
tokens.fontSizeBase200 // 12px
|
||||||
|
tokens.fontSizeBase300 // 14px
|
||||||
|
tokens.fontSizeBase400 // 16px
|
||||||
|
tokens.fontSizeBase500 // 20px
|
||||||
|
tokens.fontWeightRegular // 400
|
||||||
|
tokens.fontWeightMedium // 500
|
||||||
|
tokens.fontWeightSemibold // 600
|
||||||
|
tokens.fontWeightBold // 700
|
||||||
|
|
||||||
|
// Motion
|
||||||
|
tokens.durationFast // 100ms
|
||||||
|
tokens.durationNormal // 200ms
|
||||||
|
tokens.durationSlow // 300ms
|
||||||
|
tokens.curveEasyEase // cubic-bezier(0.33, 0, 0.67, 1)
|
||||||
|
tokens.curveDecelerateMax // cubic-bezier(0, 0, 0, 1) — for panels entering
|
||||||
|
tokens.curveAccelerateMax // cubic-bezier(1, 0, 1, 1) — for panels leaving
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Common Patterns
|
||||||
|
|
||||||
|
### Dark Mode Toggle
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
import { FluentProvider } from '@fluentui/react-components';
|
||||||
|
import { originmainTheme, originmainDarkTheme } from '@originmain/ui';
|
||||||
|
|
||||||
|
function ThemedApp({ isDark, children }: { isDark: boolean; children: React.ReactNode }) {
|
||||||
|
return (
|
||||||
|
<FluentProvider theme={isDark ? originmainDarkTheme : originmainTheme}>
|
||||||
|
{children}
|
||||||
|
</FluentProvider>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Pass `isDark` into `CodeDiffPanel` and `CodebaseFileTree` so they switch their Shiki theme and CSS variable bridge values accordingly.
|
||||||
|
|
||||||
|
### Design System Violation Badge
|
||||||
|
|
||||||
|
When a visual edit sets a value not found in the team's Design Language File:
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
import { Badge } from '@fluentui/react-components';
|
||||||
|
|
||||||
|
<Badge appearance="filled" color="warning" size="small">
|
||||||
|
Not in design system
|
||||||
|
</Badge>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Artboard Status Badge (Agent Bridge Sync)
|
||||||
|
|
||||||
|
Coding agent implementation status shown on artboard cards:
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
import { PresenceBadge } from '@fluentui/react-components';
|
||||||
|
|
||||||
|
const statusMap: Record<IntentDiff['status'], React.ReactNode> = {
|
||||||
|
implemented: <PresenceBadge status="available" />,
|
||||||
|
blocked: <PresenceBadge status="busy" />,
|
||||||
|
needs_clarification: <PresenceBadge status="away" />,
|
||||||
|
exported: <PresenceBadge status="unknown" />,
|
||||||
|
acknowledged: <PresenceBadge status="unknown" />,
|
||||||
|
draft: null,
|
||||||
|
rejected: <PresenceBadge status="offline" />,
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
### Empty States
|
||||||
|
|
||||||
|
Every panel that can be empty must show a Fluent 2-styled empty state — never a blank white box:
|
||||||
|
|
||||||
|
```tsx
|
||||||
|
import { Body1, Caption1, makeStyles, tokens } from '@fluentui/react-components';
|
||||||
|
|
||||||
|
const useEmptyStyles = makeStyles({
|
||||||
|
container: {
|
||||||
|
display: 'flex',
|
||||||
|
flexDirection: 'column',
|
||||||
|
alignItems: 'center',
|
||||||
|
justifyContent: 'center',
|
||||||
|
gap: tokens.spacingVerticalM,
|
||||||
|
padding: tokens.spacingHorizontalXXL,
|
||||||
|
color: tokens.colorNeutralForeground3,
|
||||||
|
textAlign: 'center',
|
||||||
|
height: '100%',
|
||||||
|
},
|
||||||
|
});
|
||||||
|
|
||||||
|
function EmptyState({ title, description }: { title: string; description: string }) {
|
||||||
|
const styles = useEmptyStyles();
|
||||||
|
return (
|
||||||
|
<div className={styles.container}>
|
||||||
|
<Body1 weight="semibold">{title}</Body1>
|
||||||
|
<Caption1>{description}</Caption1>
|
||||||
|
</div>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Accessibility Checklist
|
||||||
|
|
||||||
|
Every component must satisfy this checklist before merge:
|
||||||
|
|
||||||
|
- [ ] Keyboard navigation works without a mouse (Tab, Arrow keys, Enter, Escape)
|
||||||
|
- [ ] ARIA roles are correct — do not override Fluent 2's built-in roles unnecessarily
|
||||||
|
- [ ] Focus is managed correctly when dialogs open and close (focus trap in `Dialog`, focus restore on close)
|
||||||
|
- [ ] Colour alone is never the only differentiator — use icons or labels alongside colour
|
||||||
|
- [ ] All interactive elements meet WCAG 2.1 AA contrast ratio (4.5:1 for text, 3:1 for UI components)
|
||||||
|
- [ ] All images and icons have `aria-label` or `alt` text (use `aria-hidden="true"` for decorative icons)
|
||||||
|
- [ ] `@pierre/trees` built-in ARIA (`tree`, `treeitem`, `aria-level`, `aria-posinset`, `aria-setsize`) is not suppressed
|
||||||
|
- [ ] `@pierre/diffs` built-in keyboard navigation for the diff view is not suppressed
|
||||||
|
- [ ] No `tabIndex` overrides without explicit justification in the PR description
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Originmain Frontend Design Skill — v1.0 — April 2026*
|
||||||
|
*Synthesises: Fluent 2 (@fluentui/react-components v9) · @pierre/diffs (diffs.com) · @pierre/trees (trees.software)*
|
||||||
Binary file not shown.
@@ -0,0 +1,297 @@
|
|||||||
|
**ORIGINMAIN**
|
||||||
|
|
||||||
|
Go-to-Market Strategy
|
||||||
|
|
||||||
|
*Building Momentum While We Build the Product*
|
||||||
|
|
||||||
|
Version 1.0 \| April 2026 \| Patrick --- Product Lead \| Confidential
|
||||||
|
|
||||||
|
**1. The Story We Tell While We Build**
|
||||||
|
|
||||||
|
Originmain\'s GTM strategy begins before the product ships. The design-to-code problem is a felt pain that every product team experiences daily --- which means we can build a genuine audience and community around the problem before the solution is ready. This section defines the narrative we use externally from Day 1, during development.
|
||||||
|
|
||||||
|
-- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
*The handoff is the leak in every modern product team. Designers ship intent. Engineers ship approximations. The gap between them is where quality dies, timelines extend, and frustration compounds. Originmain seals the gap --- not by improving the handoff, but by eliminating it.*
|
||||||
|
-- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**1.1 The Problem Narrative (Share-Ready Language)**
|
||||||
|
|
||||||
|
This is the copy used in all external communications during the development phase --- social posts, early landing page, waitlist emails, and conversations with prospective users:
|
||||||
|
|
||||||
|
-------------- --------------------------------------------------------------------------------
|
||||||
|
**HEADLINE** Your design tool and your codebase have never met. Originmain introduces them.
|
||||||
|
-------------- --------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Expanded narrative (for blog posts, LinkedIn, community threads):
|
||||||
|
|
||||||
|
-- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
*Every product team we have ever spoken to describes the same experience: a designer produces a beautiful, well-considered interface. An engineer implements their best interpretation of it. The result is close --- but close is not the same. What follows is a cycle of correction, clarification, and compromise that consumes 30-40% of sprint capacity without ever being counted as a formal task. It lives in the margins of Figma comments, in Slack threads, in the quiet resignation of designers who stop fighting for pixel-perfect and engineers who stop asking questions. Originmain was built because we believe this gap is not inevitable. It exists because the tools that design software and the tools that build software have always been separate --- and in that separation, intent is lost. We are building a canvas where your application lives, not just a picture of it. Where a visual change is a code change. Where context, provenance, and human intent travel with every artboard, not just the final export.*
|
||||||
|
-- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**1.2 The Three Problem Hooks**
|
||||||
|
|
||||||
|
Use these condensed problem framings depending on the audience and context:
|
||||||
|
|
||||||
|
--------------------------- ------------------ ----------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**Hook** **For Audience** **One-Line**
|
||||||
|
The Handoff Hook Designers \"You spend weeks designing it. It ships looking 70% like your work. Originmain makes the other 30% inevitable.\"
|
||||||
|
The Context Collapse Hook Engineers \"You implement a design with no idea why it was made, who made it, or what user problem it\'s solving. Originmain gives you that context.\"
|
||||||
|
The Blank Canvas Hook Design Engineers \"Every tool gives you a blank page and calls it freedom. Originmain gives you your actual product as the starting point.\"
|
||||||
|
--------------------------- ------------------ ----------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**2. Target Audience & Ideal Customer Profile**
|
||||||
|
|
||||||
|
**2.1 Ideal Customer Profile (ICP)**
|
||||||
|
|
||||||
|
The ICP for Originmain\'s initial launch is tight by design. Broad appeal will dilute the message and slow word-of-mouth adoption. We will expand the ICP in subsequent phases as the product matures.
|
||||||
|
|
||||||
|
------------------ -------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**Dimension** **ICP Description**
|
||||||
|
Company Size 15--200 person product companies; 2--8 person product/design teams within larger organisations
|
||||||
|
Industry B2B SaaS, developer tools, fintech, and health tech --- segments where product quality and UI precision drive retention
|
||||||
|
Tech Stack React or Next.js frontend; at least one person on the team who identifies as a Design Engineer, UI Engineer, or senior Frontend Developer with design sensibility
|
||||||
|
Tooling Today Figma for design; Cursor, Claude Code, or Copilot Workspace for AI coding; Linear for project management
|
||||||
|
Pain Level Actively frustrated by the design-to-code gap; has attempted and failed to solve it with Figma Dev Mode, Zeplin, or direct Figma MCP integration
|
||||||
|
Budget Indicator Already paying for Figma Organisation (\$75+/month) and at least one AI coding tool (\$20+/month per developer)
|
||||||
|
------------------ -------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**2.2 Buyer vs. User Map**
|
||||||
|
|
||||||
|
--------------------- ----------------------------- --------------------------------------------------------- ----------------------------------------------------------------
|
||||||
|
**Persona** **Role in Purchase** **Primary Motivation** **Channel to Reach**
|
||||||
|
Design Engineer Champion / Power User End the tool-switching; one surface for design and code Twitter/X, Bluesky, GitHub, design engineering Discord servers
|
||||||
|
Product Designer Power User / Influencer Their visual intent preserved through implementation Figma community, Design Twitter, UX newsletters
|
||||||
|
Engineering Manager Economic Buyer Reduce sprint cycle time on design-to-code tasks LinkedIn, CTO/EM newsletters, Hacker News
|
||||||
|
Product Manager Influencer / Sponsor Faster iteration from user feedback to shipped feature ProductHunt, Product Management Slack groups
|
||||||
|
CTO / VP Eng Final Approver (Enterprise) AI coding ROI; codify design intent in the AI pipeline Direct outreach, conference talks, thought leadership
|
||||||
|
--------------------- ----------------------------- --------------------------------------------------------- ----------------------------------------------------------------
|
||||||
|
|
||||||
|
**3. Positioning & Messaging**
|
||||||
|
|
||||||
|
**3.1 Positioning Statement**
|
||||||
|
|
||||||
|
-------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**POSITION** For design engineering teams who are frustrated by the gap between design intent and production code, Originmain is the AI-native design platform that renders your actual application as an editable canvas --- so that every visual change is a structured code diff, not a request for one. Unlike Figma (which produces static specs) or AI code generators (which start from nothing), Originmain starts from your real codebase and bridges the gap permanently.
|
||||||
|
-------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**3.2 Message Architecture**
|
||||||
|
|
||||||
|
Messages are structured in three tiers: Tier 1 is used everywhere (website hero, social bios, pitch decks). Tier 2 is used in product pages and longer content. Tier 3 is used in deep-dive posts and documentation.
|
||||||
|
|
||||||
|
--------------------------- -------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------
|
||||||
|
**Tier** **Message** **Where Used**
|
||||||
|
Tier 1 --- Core Value Design and code --- finally, the same surface. Website hero, social bios, elevator pitch
|
||||||
|
Tier 1 --- Differentiator Your artboard IS your application. Not a picture of it. Product page above-fold, demo video opener
|
||||||
|
Tier 2 --- Problem The design-to-code handoff consumes 30-40% of every sprint. Originmain eliminates it by making a visual change identical to a code change. Long-form copy, investor decks, email sequences
|
||||||
|
Tier 2 --- Solution Render any screen from your live app. Edit it visually. Export the diff to your coding agent. Done. How It Works section, onboarding copy
|
||||||
|
Tier 3 --- Technical Intent Diffs: component-level structured changes that coding agents (Cursor, Claude Code) can execute directly against your codebase. Technical blog posts, GitHub README, developer documentation
|
||||||
|
--------------------------- -------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------
|
||||||
|
|
||||||
|
**3.3 Competitive Messaging**
|
||||||
|
|
||||||
|
How to position against each major competitive threat:
|
||||||
|
|
||||||
|
-------------------- --------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**Competitor** **Their Claim** **Originmain\'s Counter**
|
||||||
|
Figma \"The collaborative design platform\" Figma designs are pictures of your app. Originmain IS your app. Edits in Figma create new work; edits in Originmain create code.
|
||||||
|
Google Stitch \"Design any product, anywhere\" Stitch generates screens from AI prompts. Originmain renders your actual components. When Stitch generates a button, it\'s a generic button. When Originmain shows you a button, it\'s your Button.tsx.
|
||||||
|
v0 (Vercel) \"Ship polished UIs in seconds\" v0 starts from a chat prompt and builds something new. Originmain starts from your existing product and evolves it --- preserving 100% of your design system and codebase context.
|
||||||
|
Cursor + Figma MCP \"AI coding with design context\" Cursor reads from Figma. Originmain writes to Cursor. The direction of information flow is reversed --- and that reversal is everything.
|
||||||
|
-------------------- --------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**4. Pre-Launch Strategy (Months 1--6)**
|
||||||
|
|
||||||
|
The pre-launch period runs from now until the closed beta. Its goal is to build a waiting list of 2,000+ qualified design engineering teams, establish Originmain as a credible voice in the design-engineering conversation, and recruit 20 founding design partners who will shape the product and provide social proof at launch.
|
||||||
|
|
||||||
|
**4.1 The Problem-First Content Strategy**
|
||||||
|
|
||||||
|
We publish before we have a product to show. All pre-launch content focuses on the problem, not the solution. This positions Originmain as a thoughtful voice in the space and attracts exactly the users who feel this pain most acutely.
|
||||||
|
|
||||||
|
------------------- --------------- --------------------------------------------------------------------------- -----------------------------------------------------
|
||||||
|
**Content Type** **Cadence** **Topic Focus** **Distribution**
|
||||||
|
Long-form article Every 2 weeks The handoff gap, blank canvas problem, design engineering as a discipline Personal LinkedIn, Substack, cross-post to Medium
|
||||||
|
Twitter/X thread 3x per week Behind-the-build updates, problem framing, design system hot takes Patrick\'s personal account (@), Originmain account
|
||||||
|
Bluesky Daily Design engineering community engagement, short observations Originmain account + Patrick personal
|
||||||
|
GitHub Monthly Open-source tooling (Intent Diff schema spec, Design Language File spec) GitHub releases, Hacker News Show HN
|
||||||
|
Video (Loom) Every 3 weeks \"Building in public\" --- raw demos of the product in progress YouTube, embedded in email newsletter
|
||||||
|
Newsletter Every 2 weeks Curated design engineering news + Originmain build update Email (ConvertKit), cross-posted to Substack
|
||||||
|
------------------- --------------- --------------------------------------------------------------------------- -----------------------------------------------------
|
||||||
|
|
||||||
|
**4.2 Founding Design Partner Programme**
|
||||||
|
|
||||||
|
The Founding Design Partner Programme recruits 20 teams who will use Originmain throughout development, provide weekly feedback, and become the product\'s most vocal early advocates at launch. Each Founding Partner receives:
|
||||||
|
|
||||||
|
- Free Originmain Pro access for 12 months post-launch
|
||||||
|
|
||||||
|
- Direct Slack channel with the founding team
|
||||||
|
|
||||||
|
- Monthly 1:1 with Patrick (product lead) for feedback and roadmap input
|
||||||
|
|
||||||
|
- Named acknowledgement in the product (Founding Partner badge and credits page)
|
||||||
|
|
||||||
|
- Co-authorship opportunity on Originmain blog posts and launch content
|
||||||
|
|
||||||
|
Target Partner Profile: 2--8 person design/engineering teams at post-Series A SaaS companies who use React/Next.js, Figma, and at least one AI coding tool. The goal is diversity of team size, industry, and use-case.
|
||||||
|
|
||||||
|
**4.3 Waitlist & Landing Page**
|
||||||
|
|
||||||
|
The waitlist landing page launches in Month 1, before any product is ready to show. It communicates:
|
||||||
|
|
||||||
|
- The problem in vivid, specific terms (not marketing speak)
|
||||||
|
|
||||||
|
- The Originmain vision with a 60-second animated concept video
|
||||||
|
|
||||||
|
- Social proof from the founding team\'s credibility and early partner conversations
|
||||||
|
|
||||||
|
- A simple, frictionless waitlist form (email only, with optional LinkedIn)
|
||||||
|
|
||||||
|
------------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**TARGET** 2,000 qualified signups by end of Month 4. Qualified = job title matches one of the three primary personas (Design Engineer, Product Designer, Frontend Developer). Conversion from landing page visitor to signup: target 15%+.
|
||||||
|
------------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**5. Closed Beta Launch (Month 8)**
|
||||||
|
|
||||||
|
**5.1 Beta Cohort Selection**
|
||||||
|
|
||||||
|
The closed beta opens to 100 teams, selected from the waitlist and Founding Partner programme. Selection criteria:
|
||||||
|
|
||||||
|
---------------------------------------- ------------ -----------------------------------------------------------------------------------------
|
||||||
|
**Criterion** **Weight** **How Assessed**
|
||||||
|
Pain intensity 30% Application question: describe your current design-to-code workflow and where it breaks
|
||||||
|
Technical fit (React/Next.js) 25% Application question: what is your frontend stack?
|
||||||
|
Team composition (has Design Engineer) 20% LinkedIn verification of applicant\'s role
|
||||||
|
Engagement in pre-launch content 15% Email open rate, social engagement, waitlist source
|
||||||
|
Reference from Founding Partner 10% Direct referral from an existing Founding Partner
|
||||||
|
---------------------------------------- ------------ -----------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**5.2 Beta Onboarding Programme**
|
||||||
|
|
||||||
|
Each beta team goes through a structured onboarding sequence designed to reach the product\'s \'aha moment\' (first Live Artboard rendered from their actual app) within 30 minutes of first login:
|
||||||
|
|
||||||
|
- Day 0: Welcome email with Slack invite, setup guide, and 15-minute onboarding call booking
|
||||||
|
|
||||||
|
- Day 1: Onboarding call: screen share, connect their app, render first artboard together
|
||||||
|
|
||||||
|
- Day 7: Check-in email with usage analytics shared back to the team (\"you\'ve rendered X artboards and generated Y diffs\")
|
||||||
|
|
||||||
|
- Day 14: Feedback survey (NPS + 3 open questions: what\'s working, what\'s broken, what\'s missing)
|
||||||
|
|
||||||
|
- Day 30: Full beta retrospective call; product roadmap preview for Phase 3 features
|
||||||
|
|
||||||
|
**5.3 Beta Success Metrics**
|
||||||
|
|
||||||
|
------------------------------------------------------- ---------------------------------------------
|
||||||
|
**Metric** **Target**
|
||||||
|
Teams completing onboarding (first artboard rendered) \>= 85% within 7 days of signup
|
||||||
|
Weekly Active Teams in beta \>= 60% of beta cohort after 30 days
|
||||||
|
Net Promoter Score (NPS) \>= 50 at Day 30 survey
|
||||||
|
Intent Diffs exported per active team per week \>= 5 (indicates real workflow integration)
|
||||||
|
Qualitative testimonials secured for launch \>= 15 from beta teams
|
||||||
|
------------------------------------------------------- ---------------------------------------------
|
||||||
|
|
||||||
|
**6. Public Beta Launch (Month 12)**
|
||||||
|
|
||||||
|
**6.1 Launch Sequence**
|
||||||
|
|
||||||
|
The public beta launch is a coordinated multi-channel event compressed into a 72-hour window. It is designed for maximum surface area, not a single spike.
|
||||||
|
|
||||||
|
---------------- ------------------------------------------------------------------------------------------- --------------------------------------- -------------------------------------------------------
|
||||||
|
**Day** **Action** **Owned By** **Expected Reach**
|
||||||
|
Day -7 Teaser campaign: \"Something is coming for design engineers.\" Countdown on landing page. Marketing Existing waitlist (2,000+), social followers
|
||||||
|
Day -3 Founding Partner embargo lift: partners publish their own case studies and testimonials Founding Partners Each partner\'s network (est. 500--5,000 per partner)
|
||||||
|
Day 0, 12:01am ProductHunt launch (scheduled) Patrick + team upvoting support PH daily users (\~50,000 design/dev audience)
|
||||||
|
Day 0, 9:00am Long-form launch article: \'Why we built Originmain\' Patrick (LinkedIn + Substack) LinkedIn network + Substack subscribers
|
||||||
|
Day 0, 10:00am Demo video release (YouTube, embedded on landing page) Originmain YouTube Organic + waitlist email blast
|
||||||
|
Day 0, 12:00pm Twitter/X thread: the full Originmain story in 20 tweets Patrick personal + Originmain account Twitter Design Engineering community
|
||||||
|
Day 0, 2:00pm Hacker News \'Show HN\' post with technical deep-dive on the Intent Diff architecture Patrick HN developer audience
|
||||||
|
Day 1--3 Designer and engineer newsletter placements (pre-booked) Paid/barter placements Dense (2,500--10,000 per newsletter)
|
||||||
|
Day 3 Founder AMA on Design Engineering Discord (30,000+ members) Patrick Core ICP community
|
||||||
|
---------------- ------------------------------------------------------------------------------------------- --------------------------------------- -------------------------------------------------------
|
||||||
|
|
||||||
|
**6.2 Launch KPIs**
|
||||||
|
|
||||||
|
--------------------------------------------- ----------------------------------- ----------------------------------
|
||||||
|
**KPI** **Target (72 hours post-launch)** **Target (30 days post-launch)**
|
||||||
|
New signups 1,000 5,000
|
||||||
|
ProductHunt rank Top 5 product of the day Featured in PH newsletter
|
||||||
|
Self-serve teams activated (first artboard) 200 1,000
|
||||||
|
MRR from paid conversions \$0 (beta is free) \$25,000
|
||||||
|
Press / media coverage 3 original pieces 10 original pieces
|
||||||
|
Demo video views 5,000 20,000
|
||||||
|
--------------------------------------------- ----------------------------------- ----------------------------------
|
||||||
|
|
||||||
|
**7. Pricing Strategy**
|
||||||
|
|
||||||
|
**7.1 Pricing Philosophy**
|
||||||
|
|
||||||
|
Originmain\'s pricing is designed around the team as the billing unit, not the individual seat --- because the value of the product compounds with every team member who uses it. Pricing should be opaque enough to justify discovery and transparent enough to feel fair. We anchor against the cost of the status quo: a 30% sprint waste on design-to-code reconciliation costs a 10-person team \~\$8,000/month in labour. Our pricing should feel trivially cheap by comparison.
|
||||||
|
|
||||||
|
------------ ------------------------ ------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------
|
||||||
|
**Tier** **Price** **Includes** **Target**
|
||||||
|
Starter Free forever 1 workspace, 3 artboards, 1 app connection, unlimited exports Individual design engineers, students, side projects
|
||||||
|
Pro \$49/mo per workspace Unlimited artboards, 3 app connections, AI Completion Zones (100/mo), Agent Bridge (Cursor + Claude Code) Small product teams (2--10 people)
|
||||||
|
Team \$149/mo per workspace Everything in Pro + unlimited AI completions, all integrations (Linear, Slack, GitHub), multiplayer, cross-artboard querying, priority support Growing product companies (10--50 people)
|
||||||
|
Enterprise Custom Everything in Team + SSO, SCIM, audit logs, white-label, SLA, dedicated onboarding, custom integrations, unlimited app connections Companies 50+ people, agencies, design studios
|
||||||
|
------------ ------------------------ ------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------
|
||||||
|
|
||||||
|
---------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**NOTE** Beta pricing: all closed and public beta users get Team tier free for their full beta period. Paid plans launch with General Availability (Month 18). This removes price as a barrier to adoption and feedback quality during the critical early phase.
|
||||||
|
---------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**8. Channel Strategy**
|
||||||
|
|
||||||
|
**8.1 Owned Channels**
|
||||||
|
|
||||||
|
------------------------------------- --------------------------------------------------------------- --------------------------------------------------------
|
||||||
|
**Channel** **Goal** **KPI**
|
||||||
|
originmain.com (landing/product) Convert visitors to signups and activations Visitor-to-signup: 15%; signup-to-active: 60%
|
||||||
|
Email newsletter (ConvertKit) Nurture pre-launch audience; retain and re-engage post-launch Open rate: 40%+; CTR: 8%+
|
||||||
|
YouTube (product demos) Discovery for bottom-of-funnel search; demo library for sales Demo watch completion: 50%+; 500 subscribers by launch
|
||||||
|
GitHub (Intent Diff spec, DLF spec) Developer credibility; top-of-funnel for technical audience Stars on public repos: 500+ by launch
|
||||||
|
------------------------------------- --------------------------------------------------------------- --------------------------------------------------------
|
||||||
|
|
||||||
|
**8.2 Earned Channels**
|
||||||
|
|
||||||
|
------------------------------ --------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------
|
||||||
|
**Channel** **Strategy** **Target**
|
||||||
|
Design Engineering Twitter/X Participate in the community; don\'t broadcast, converse. Build Patrick\'s personal brand alongside the product brand. 5,000 engaged followers (Patrick) by launch; 1,000 for \@originmain
|
||||||
|
Hacker News Technical deep-dives on the Intent Diff architecture, rendering engine challenges, and AI agent communication. \'Show HN\' at launch. 3 front-page posts pre-launch; launch \'Show HN\' in top 5
|
||||||
|
Bluesky Design Community Growing design engineering presence; early adopter community for technical designers. Active presence; 500+ followers by launch
|
||||||
|
Product Hunt Coordinated launch with Founding Partner support and community upvoting. Top 5 product of the day; \#1 product of the week target
|
||||||
|
Design Engineering Discords Genuine community participation; no spam. Answer questions, share the problem narrative, invite feedback on early concepts. Active presence in 5+ communities pre-launch
|
||||||
|
------------------------------ --------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------
|
||||||
|
|
||||||
|
**8.3 Paid Channels (Post-GA Only)**
|
||||||
|
|
||||||
|
Paid acquisition is deferred until General Availability (Month 18). Pre-GA growth is entirely organic and community-driven. This is intentional: paid acquisition before product-market fit accelerates churn, not growth. The paid channel strategy will be defined based on what the organic data reveals about highest-converting sources.
|
||||||
|
|
||||||
|
**9. Partnership Strategy**
|
||||||
|
|
||||||
|
------------------------------ ------------------------------------------------------ ------------------------------------------------------------------------------------------------ ----------------------
|
||||||
|
**Partner Type** **Target Partners** **Integration Value** **Timing**
|
||||||
|
AI Coding Tools Cursor, Anthropic (Claude Code) First-party Agent Bridge adapters; co-marketing as the \'design layer\' for their coding tools Phase 2 --- Month 6+
|
||||||
|
Design Community Figma Community plugins, Fluent UI team at Microsoft Import path from Figma; Microsoft design ecosystem alignment Phase 1-2
|
||||||
|
Project Management Linear (primary), Jira (secondary) Deep issue-to-artboard ingestion; co-marketing to Linear\'s design engineering audience Phase 2
|
||||||
|
Design Engineering Education Frontend Masters, Egghead.io, Scrimba Course integrations; Originmain as the design tool in design engineering curricula Phase 3
|
||||||
|
Design Agencies Top 10 React-focused digital agencies White-label access; agency case studies; enterprise sales referrals Phase 4
|
||||||
|
------------------------------ ------------------------------------------------------ ------------------------------------------------------------------------------------------------ ----------------------
|
||||||
|
|
||||||
|
**10. GTM Metrics Dashboard**
|
||||||
|
|
||||||
|
The following metrics are tracked weekly during pre-launch and daily during launch week. All metrics are available in PostHog (product analytics) and a shared Notion dashboard visible to the full founding team.
|
||||||
|
|
||||||
|
--------------------- ------------------------------------------- ------------------- ------------------------------------------------------
|
||||||
|
**Phase** **Metric** **Target** **Green / Yellow / Red Thresholds**
|
||||||
|
Pre-launch Waitlist signups (cumulative) 2,000 by Month 4 G: on pace / Y: 20% behind pace / R: 40% behind pace
|
||||||
|
Pre-launch Founding Partners onboarded 20 by Month 6 G: 20+ / Y: 15-19 / R: \<15
|
||||||
|
Pre-launch Newsletter subscribers 1,000 by Month 4 G: 1,000+ / Y: 700-999 / R: \<700
|
||||||
|
Pre-launch LinkedIn article impressions (cumulative) 50,000 by Month 6 G: 50K+ / Y: 30-50K / R: \<30K
|
||||||
|
Beta Beta teams activated (first artboard) \>85% in 7 days G: 85%+ / Y: 70-84% / R: \<70%
|
||||||
|
Beta Weekly active beta teams \>60% at Day 30 G: 60%+ / Y: 45-59% / R: \<45%
|
||||||
|
Beta NPS (Day 30 survey) \>=50 G: 50+ / Y: 35-49 / R: \<35
|
||||||
|
Launch Day-1 signups 1,000 G: 1,000+ / Y: 600-999 / R: \<600
|
||||||
|
Launch ProductHunt rank (end of day) Top 5 G: Top 5 / Y: Top 10 / R: Below 10
|
||||||
|
30-days post-launch Teams actively using product 1,000 G: 1,000+ / Y: 700-999 / R: \<700
|
||||||
|
--------------------- ------------------------------------------- ------------------- ------------------------------------------------------
|
||||||
|
|
||||||
|
*End of Go-to-Market Strategy --- Originmain v1.0*
|
||||||
Binary file not shown.
@@ -0,0 +1,551 @@
|
|||||||
|
**ORIGINMAIN**
|
||||||
|
|
||||||
|
Implementation Guide
|
||||||
|
|
||||||
|
*AI-Native Design Engineering Platform*
|
||||||
|
|
||||||
|
Version 1.0 \| April 2026 \| Patrick --- Product Lead \| Confidential
|
||||||
|
|
||||||
|
**1. Executive Overview**
|
||||||
|
|
||||||
|
This Implementation Guide translates the Originmain PRD into a concrete, layer-by-layer engineering blueprint. It is the primary technical reference for every developer who will build, integrate, test, or deploy the product. It covers the full stack --- from infrastructure provisioning to AI pipeline design --- and is structured as a progressive sequence of implementation layers, each of which must be stable before the next begins.
|
||||||
|
|
||||||
|
The guide follows Originmain\'s phased roadmap (Phases 1--4 from the PRD) and maps each feature requirement to a specific layer, technology choice, and implementation approach. Where trade-offs exist, the rationale for the selected approach is documented explicitly.
|
||||||
|
|
||||||
|
--------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**PRINCIPLE** Every architectural decision in this guide is subordinate to one constraint: the design surface and the code diff must be the same continuous action. Any trade-off that creates a perceptible gap between a visual edit and a code change is unacceptable.
|
||||||
|
--------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
----------- ------------------------------ ------------------------------------------------ -----------
|
||||||
|
**Layer** **Name** **Primary Technology** **Phase**
|
||||||
|
0 Infrastructure & DevOps Vercel, Supabase, Render, GitHub Actions 1
|
||||||
|
1 Canvas UI Shell React 19, Fluent UI v9, Griffel 1
|
||||||
|
2 Live Rendering Engine Sandboxed iframe, Module Federation, Webpack 5 1
|
||||||
|
3 Visual Editing & Diff Engine Custom AST, TypeScript, react-fiber-utils 1
|
||||||
|
4 Origin Graph & Data Store PostgreSQL, pg\_graphql, Supabase Realtime 1
|
||||||
|
5 Design Language Runtime JSON Schema, Zod, custom validator 1
|
||||||
|
6 AI Completion Layer Claude Sonnet 4 API, Anthropic SDK 2
|
||||||
|
7 Agent Bridge (MCP) Model Context Protocol, WebSocket, tRPC 2
|
||||||
|
8 Multi-Origin Ingestion Linear SDK, Slack API, GitHub REST 2
|
||||||
|
9 Multiplayer & Presence Liveblocks, CRDT, Yjs 3
|
||||||
|
10 Platform & Extensions Plugin API, SSO, SCIM, audit logs 4
|
||||||
|
----------- ------------------------------ ------------------------------------------------ -----------
|
||||||
|
|
||||||
|
**2. Development Prerequisites**
|
||||||
|
|
||||||
|
**2.1 Required Team Roles**
|
||||||
|
|
||||||
|
Before a single line is written, the following roles must be staffed. The product has a high degree of complexity in its rendering and diffing subsystems; under-resourcing these areas is the leading cause of scope collapse in similar products.
|
||||||
|
|
||||||
|
--------------------------------- ----------- ------------------------------------------------------------------
|
||||||
|
**Role** **Count** **Critical Responsibility**
|
||||||
|
Lead Frontend / Design Engineer 1 Canvas UI, component palette, Fluent 2 integration
|
||||||
|
Rendering Engine Engineer 1--2 Sandboxed iframe renderer, Module Federation, hot reload
|
||||||
|
Diff Engine Engineer 1 AST diffing, Intent Diff schema, component-level change tracking
|
||||||
|
Backend / Data Engineer 1 PostgreSQL schema, pg\_graphql, Origin Graph, Supabase setup
|
||||||
|
AI / Agent Engineer 1 Claude API integration, Completion Zones, Agent Bridge (MCP)
|
||||||
|
DevOps / Platform Engineer 0.5 CI/CD, infra provisioning, environment management
|
||||||
|
Product Designer (Fluent 2) 1 Originmain\'s own UI, design token system, interaction design
|
||||||
|
--------------------------------- ----------- ------------------------------------------------------------------
|
||||||
|
|
||||||
|
**2.2 Local Development Environment**
|
||||||
|
|
||||||
|
- Node.js 22 LTS (use nvm for version management)
|
||||||
|
|
||||||
|
- pnpm 9+ as the package manager (workspaces enabled for monorepo)
|
||||||
|
|
||||||
|
- Docker Desktop for local PostgreSQL and Redis
|
||||||
|
|
||||||
|
- Supabase CLI for local database branching and migrations
|
||||||
|
|
||||||
|
- Vercel CLI for local preview deployments
|
||||||
|
|
||||||
|
- GitHub CLI (gh) for PR automation and Actions triggers
|
||||||
|
|
||||||
|
**2.3 Repository Structure**
|
||||||
|
|
||||||
|
Originmain is a pnpm monorepo with the following top-level packages:
|
||||||
|
|
||||||
|
----------------- -------------------------- -----------------------------------------------------------------------
|
||||||
|
**Package** **Path** **Description**
|
||||||
|
app packages/app Main canvas application (React 19, Next.js 15 App Router)
|
||||||
|
renderer packages/renderer Sandboxed iframe rendering engine and Module Federation host
|
||||||
|
diff-engine packages/diff-engine AST differ, Intent Diff schema, change tracker
|
||||||
|
origin-graph packages/origin-graph PostgreSQL schema, Supabase migrations, pg\_graphql resolvers
|
||||||
|
ai-layer packages/ai-layer Claude API client, Completion Zone processor, prompt library
|
||||||
|
agent-bridge packages/agent-bridge MCP server, WebSocket protocol, coding agent adapters
|
||||||
|
design-language packages/design-language JSON Schema validator, token pipeline, guidance file runtime
|
||||||
|
ui packages/ui Shared Fluent 2 component wrappers and Originmain-specific components
|
||||||
|
integrations packages/integrations Linear, Slack, GitHub ingestion connectors
|
||||||
|
e2e packages/e2e Playwright end-to-end test suites
|
||||||
|
----------------- -------------------------- -----------------------------------------------------------------------
|
||||||
|
|
||||||
|
**3. Layer 0 --- Infrastructure & DevOps**
|
||||||
|
|
||||||
|
**3.1 Cloud Architecture**
|
||||||
|
|
||||||
|
Originmain\'s infrastructure is built on three primary cloud providers, selected for complementary strengths: Vercel for edge-first frontend delivery, Supabase for managed PostgreSQL with real-time and GraphQL, and Render for long-running backend services (Agent Bridge, rendering workers).
|
||||||
|
|
||||||
|
----------------------- --------------------- -------------------------------------------------- -----------------------
|
||||||
|
**Service** **Provider** **Purpose** **Tier (Launch)**
|
||||||
|
Frontend App Vercel (Pro) Next.js 15 app, edge functions, ISR Pro --- \$20/mo
|
||||||
|
Primary Database Supabase (Pro) PostgreSQL, Origin Graph, auth, realtime Pro --- \$25/mo
|
||||||
|
Redis Cache Upstash Redis Session cache, rate limiting, queue Pay-per-use
|
||||||
|
Agent Bridge Server Render Long-running MCP WebSocket server Hobby --- \$5/mo
|
||||||
|
Object Storage Supabase Storage Artboard screenshots, design language files Included in Pro
|
||||||
|
CDN / Edge Vercel Edge Network Static assets, API edge caching Included in Pro
|
||||||
|
Email (Transactional) Resend Auth emails, notifications Free tier
|
||||||
|
Error Monitoring Sentry Frontend and backend error tracking Team --- \$26/mo
|
||||||
|
Analytics PostHog Product analytics, session replay, feature flags Free tier (1M events)
|
||||||
|
----------------------- --------------------- -------------------------------------------------- -----------------------
|
||||||
|
|
||||||
|
**3.2 CI/CD Pipeline**
|
||||||
|
|
||||||
|
Every pull request triggers a full pipeline via GitHub Actions. The pipeline is defined as code in .github/workflows/ and enforces quality gates that cannot be bypassed. No code reaches production without passing all gates.
|
||||||
|
|
||||||
|
1. Lint & type-check (ESLint, TypeScript strict mode) --- must pass with zero errors
|
||||||
|
|
||||||
|
2. Unit tests (Vitest) --- must maintain 80%+ coverage on diff-engine and origin-graph packages
|
||||||
|
|
||||||
|
3. Build verification --- all packages must build cleanly
|
||||||
|
|
||||||
|
4. Visual regression (Playwright + Percy) --- no unreviewed visual diffs
|
||||||
|
|
||||||
|
5. Supabase migration dry-run --- schema changes validated against production snapshot
|
||||||
|
|
||||||
|
6. Preview deployment to Vercel --- every PR gets a unique preview URL
|
||||||
|
|
||||||
|
7. Production deployment on merge to main --- gated by all above steps
|
||||||
|
|
||||||
|
**3.3 Environment Strategy**
|
||||||
|
|
||||||
|
Three environments run in parallel: local (developer machine), staging (auto-deployed from main branch), and production. Each environment has an isolated Supabase project and Vercel deployment. Staging uses production data snapshots (anonymized) refreshed weekly.
|
||||||
|
|
||||||
|
-------------- -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**CRITICAL** The sandboxed rendering iframe communicates with the host app via postMessage. CSP headers must be configured precisely: the frame\'s origin must be explicitly whitelisted in the host app\'s Content-Security-Policy. A misconfigured CSP is the single most common rendering failure mode.
|
||||||
|
-------------- -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**4. Layer 1 --- Canvas UI Shell**
|
||||||
|
|
||||||
|
**4.1 Framework & Technology**
|
||||||
|
|
||||||
|
The canvas application is built with Next.js 15 (App Router) and React 19. The infinite canvas is implemented using a combination of CSS transforms and a custom viewport state manager --- NOT a third-party canvas library like react-flow or Konva, which lack the semantic structure required for component-level interaction.
|
||||||
|
|
||||||
|
------------------- -------------------------------- ----------------------------------------------------------
|
||||||
|
**Concern** **Technology** **Rationale**
|
||||||
|
Framework Next.js 15 App Router RSC for meta-layer content, client components for canvas
|
||||||
|
Component Library \@fluentui/react-components v9 PRD mandate; Fluent 2 is the design system
|
||||||
|
CSS-in-JS Griffel (via Fluent 2) Fluent 2\'s native styling system; zero runtime overhead
|
||||||
|
Canvas Primitives Custom React + CSS transform Full control over hit testing, selection, and Z-order
|
||||||
|
State Management Zustand + Immer Lightweight, performant; supports undo/redo middleware
|
||||||
|
Data Fetching TanStack Query v5 Cache management, optimistic updates, background sync
|
||||||
|
Routing Next.js App Router Workspace / artboard URL structure
|
||||||
|
Auth Clerk Team-aware auth, org management, RBAC
|
||||||
|
------------------- -------------------------------- ----------------------------------------------------------
|
||||||
|
|
||||||
|
**4.2 Canvas Architecture**
|
||||||
|
|
||||||
|
The canvas is a full-viewport React tree with three stacked layers, managed by absolute positioning and pointer-events toggling:
|
||||||
|
|
||||||
|
- Background Layer: Grid, guides, rulers --- purely decorative, rendered on a canvas element for performance
|
||||||
|
|
||||||
|
- Artboard Layer: The collection of Live Artboards, each an absolutely positioned iframe wrapper with overlay controls
|
||||||
|
|
||||||
|
- UI Chrome Layer: Toolbars, inspectors, panels --- all Fluent 2 components, rendered above the canvas
|
||||||
|
|
||||||
|
Viewport state (pan offset, zoom level) is managed in a single Zustand store and applied via a CSS transform matrix to the Artboard Layer. This approach enables smooth 60fps panning and zooming without re-rendering the artboard content.
|
||||||
|
|
||||||
|
**4.3 Fluent 2 Integration**
|
||||||
|
|
||||||
|
Originmain\'s own UI uses the following Fluent 2 pattern as its root structure. This must be established before any other UI work begins:
|
||||||
|
|
||||||
|
// packages/app/src/app/layout.tsx
|
||||||
|
|
||||||
|
import { FluentProvider, webLightTheme } from \'\@fluentui/react-components\';
|
||||||
|
|
||||||
|
export default function RootLayout({ children }) {
|
||||||
|
|
||||||
|
return \<FluentProvider theme={webLightTheme}\>{children}\</FluentProvider\>;
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
---------- -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**NOTE** Custom brand theming is achieved via createLightTheme(brandVariants) where brandVariants maps Originmain\'s \#0F52BA palette to the 16 BrandVariants slots. Store the custom theme in packages/ui/src/themes/originmain-theme.ts.
|
||||||
|
---------- -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**4.4 Codebase File Browser (\@pierre/trees)**
|
||||||
|
|
||||||
|
Originmain exposes two tree-based navigation surfaces with different requirements, and they are served by different libraries. This distinction is architectural, not cosmetic.
|
||||||
|
|
||||||
|
**Artboard Navigator (Fluent 2 Tree + TreeItem).** The left-panel tree that shows workspace hierarchy, artboard groups, and project folders. This surface is UX-first: it navigates product metadata, never grows beyond a few hundred nodes, and must visually match the Fluent 2 design language that governs the rest of the chrome. Fluent 2's Tree and TreeItem components are the correct choice here --- they carry built-in ARIA roles, keyboard navigation, and Fluent token integration at zero additional cost. Implementation path: packages/app/src/components/navigator/ArtboardTree.tsx.
|
||||||
|
|
||||||
|
**Codebase File Browser (\@pierre/trees).** When Originmain connects to a React or Next.js repository, a separate file browser panel renders the connected codebase's file tree. This surface has categorically different requirements: real codebases contain thousands of files, git status indicators are essential (added, modified, deleted, renamed, untracked, ignored), path-aware search is required, and virtualization is not optional --- it is the baseline. \@pierre/trees (Apache 2.0, from The Pierre Computer Co.) is built precisely for this use case. It renders trees of 5,000+ files instantly via automatic row virtualization (only visible rows mount), shows git status badges natively via the gitStatus prop, supports three fileTreeSearchMode options for filtering, and collapses single-child directory chains via the flattenEmptyDirectories option. Its ARIA compliance (tree, treeitem, aria-level, aria-posinset, aria-setsize) matches Fluent 2's accessibility standards. Implementation path: packages/app/src/components/codebase/CodebaseFileTree.tsx.
|
||||||
|
|
||||||
|
Install: pnpm add \@pierre/trees. The library ships a React component as its primary API. Pass the file tree data structure (nodes with name, path, type, children, and optional gitStatus fields), and the component handles all rendering, virtualization, and keyboard interaction. Theming is applied via CSS custom properties on the container element, which allows Fluent 2 token values to be projected into the tree's visual layer without adopting the Pierre design language wholesale.
|
||||||
|
|
||||||
|
**5. Layer 2 --- Live Rendering Engine**
|
||||||
|
|
||||||
|
**5.1 Architecture Overview**
|
||||||
|
|
||||||
|
The Rendering Engine is the technical heart of Originmain and its most differentiated component. It renders a connected application\'s actual React component tree inside a sandboxed iframe, preserving full interactivity, state, and design token fidelity. This is fundamentally different from screenshot-based rendering (which produces a static image) or Figma-style rendering (which draws components from a spec, not the actual code).
|
||||||
|
|
||||||
|
**5.2 Module Federation Setup**
|
||||||
|
|
||||||
|
The rendering approach uses Webpack 5 Module Federation to share the connected application\'s components into the Originmain renderer without bundling them directly. The connected app exposes a Module Federation remote; the Originmain renderer host imports from it at runtime.
|
||||||
|
|
||||||
|
---------- ----------------------- -------------------------------------------------------------------------------------------------
|
||||||
|
**Role** **Party** **Configuration**
|
||||||
|
Remote Connected Application Exposes component routes via ModuleFederationPlugin; runs on localhost:3001 (dev) or CDN (prod)
|
||||||
|
Host Originmain Renderer Consumes remote components; renders them in sandboxed iframes with injected design context
|
||||||
|
Shared React, React-DOM Singleton shared to prevent duplicate React instances across host and remote
|
||||||
|
---------- ----------------------- -------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**5.3 Sandboxing Model**
|
||||||
|
|
||||||
|
Each Live Artboard renders inside an iframe with a carefully scoped sandbox attribute. The sandboxing serves two purposes: security isolation (the rendered app cannot access the host\'s DOM or cookies) and visual isolation (the rendered app\'s global CSS cannot leak into the canvas chrome).
|
||||||
|
|
||||||
|
- iframe sandbox attribute: allow-scripts allow-same-origin allow-forms
|
||||||
|
|
||||||
|
- Communication protocol: window.postMessage with structured message types defined in packages/renderer/src/protocol.ts
|
||||||
|
|
||||||
|
- Component tree extraction: a lightweight React DevTools hook injected into the iframe reads the Fiber tree and posts it to the host via the protocol
|
||||||
|
|
||||||
|
- Design token injection: Originmain injects a script before the remote app initialises that patches the Fluent 2 FluentProvider with the team\'s custom brand theme
|
||||||
|
|
||||||
|
**5.4 Rendering Triggers**
|
||||||
|
|
||||||
|
A Live Artboard can be created from any of the following origins, each handled by a distinct ingestion path:
|
||||||
|
|
||||||
|
----------------- ------------------------------------------------------------- ------------------------------------------------------
|
||||||
|
**Origin Type** **Ingestion Path** **Metadata Captured**
|
||||||
|
App Route URL User pastes URL; renderer navigates iframe to route Route path, component tree, design tokens, timestamp
|
||||||
|
Linear Issue Linear SDK fetches issue; linked screenshot or URL rendered Issue ID, title, reporter, linked PR/commit
|
||||||
|
Slack Message Slack API fetches message; screenshot or URL rendered Channel, author, timestamp, thread context
|
||||||
|
Git Commit Hash GitHub API fetches commit; checks out and renders that tree Commit SHA, author, branch, diff from HEAD
|
||||||
|
Manual Fork User duplicates an existing artboard Parent artboard ID, fork timestamp, author
|
||||||
|
----------------- ------------------------------------------------------------- ------------------------------------------------------
|
||||||
|
|
||||||
|
**6. Layer 3 --- Visual Editing & Diff Engine**
|
||||||
|
|
||||||
|
**6.1 Intent Diff Schema**
|
||||||
|
|
||||||
|
The Intent Diff is the core data structure of Originmain. It is the contract between the design surface and the code agent. Unlike a pixel diff (which compares images) or a DOM diff (which compares HTML), an Intent Diff operates at the component level --- it describes changes in terms of the React component tree, props, and design tokens.
|
||||||
|
|
||||||
|
The Intent Diff schema (TypeScript):
|
||||||
|
|
||||||
|
interface IntentDiff {
|
||||||
|
|
||||||
|
artboardId: string;
|
||||||
|
|
||||||
|
timestamp: ISODateString;
|
||||||
|
|
||||||
|
author: UserId;
|
||||||
|
|
||||||
|
changes: ComponentChange\[\];
|
||||||
|
|
||||||
|
summary: string; // AI-generated natural language summary
|
||||||
|
|
||||||
|
beforeScreenshot: StorageUrl;
|
||||||
|
|
||||||
|
afterScreenshot: StorageUrl;
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
**6.2 Visual Editing Implementation**
|
||||||
|
|
||||||
|
Visual editing is implemented as an overlay system: a transparent interaction layer sits above the rendered iframe and intercepts mouse events. When a user clicks a component, the renderer identifies it via the Fiber tree map and renders selection handles. Drag operations are translated into prop changes (position, size, padding) and appended to the current Intent Diff.
|
||||||
|
|
||||||
|
-------------------- --------------------------------------------------------------------- ----------------------------------------------
|
||||||
|
**Edit Operation** **Component-Level Change Produced** **Coding Agent Target**
|
||||||
|
Resize component width/height prop or className token change Inline style or Tailwind/Fluent token update
|
||||||
|
Reposition element CSS position/margin/padding change Layout class or inline style update
|
||||||
|
Swap component Component reference change (e.g. SecondaryButton -\> PrimaryButton) Import statement + JSX element replacement
|
||||||
|
Edit text children prop text node change JSX text node replacement
|
||||||
|
Change colour Design token reassignment (colorBrandBackground, etc.) Token variable update in theme file
|
||||||
|
Add/remove element Insertion/deletion in component subtree JSX child addition or removal
|
||||||
|
-------------------- --------------------------------------------------------------------- ----------------------------------------------
|
||||||
|
|
||||||
|
**6.3 Undo/Redo & Branch Exploration**
|
||||||
|
|
||||||
|
Undo/redo is implemented via a Zustand middleware that maintains a linear history stack per artboard. Branch exploration (fork an artboard and try both directions) is implemented at the data model level: forking creates a new artboard record in the Origin Graph with a parent reference, both sharing the same rendering origin but accumulating independent change histories.
|
||||||
|
|
||||||
|
**6.4 Code-Level Diff Rendering (\@pierre/diffs)**
|
||||||
|
|
||||||
|
The Diff Engine (Section 6.1) computes Intent Diffs at the AST and component-prop level --- this is the logic layer and is custom TypeScript. A separate concern is the visual rendering of code-level diffs in two specific surfaces: the export panel (where a developer previews what code changes will be applied to their codebase before accepting), and the Agent Bridge communication view (where the coding agent's implementation status is shown alongside the design intent). For these surfaces, \@pierre/diffs (Apache 2.0, from The Pierre Computer Co.) is the designated renderer.
|
||||||
|
|
||||||
|
\@pierre/diffs is built on Shiki for syntax highlighting, uses CSS Grid and Shadow DOM for layout (resulting in fewer DOM nodes and faster paint than DOM-heavy alternatives), and ships three React components: MultiFileDiff (multiple changed files in one panel), PatchDiff (a git patch string rendered directly), and FileDiff (two arbitrary file contents compared). All three share a common prop set for configuration, annotations, and styling. The annotation framework is the critical capability for Originmain: it allows line-level context to be injected inline --- specifically, the natural-language summary phrases from the Intent Diff can be anchored to the exact lines they describe, giving developers a directly connected view of design intent and code change simultaneously.
|
||||||
|
|
||||||
|
The library supports both stacked (unified) and split (side-by-side) rendering modes. The export panel uses split mode by default (showing the before state in one column and the proposed after state in the other) and falls back to stacked on narrower drawer widths. The Agent Bridge communication view uses stacked mode to prioritise vertical information density alongside the chat-style agent dialogue.
|
||||||
|
|
||||||
|
Theming: \@pierre/diffs uses Shiki themes for syntax colouring. Map Fluent 2's webLightTheme and webDarkTheme to appropriate Shiki themes (github-light and github-dark-dimmed are the recommended defaults) and override the diff gutter and background colours via CSS custom properties on the container element to match Fluent 2 surface tokens (colorNeutralBackground1, colorNeutralBackground2). This produces a visually coherent diff panel without requiring the Pierre colour palette. Install: pnpm add \@pierre/diffs. Primary implementation path: packages/app/src/components/diff/CodeDiffPanel.tsx.
|
||||||
|
|
||||||
|
**7. Layer 4 --- Origin Graph & Data Store**
|
||||||
|
|
||||||
|
**7.1 PostgreSQL Schema**
|
||||||
|
|
||||||
|
The Origin Graph is stored in PostgreSQL (Supabase) as a directed acyclic graph. The core entities are Workspaces, Artboards, Origins, Diffs, and Agents. All tables use UUIDs as primary keys and include created\_at / updated\_at timestamps.
|
||||||
|
|
||||||
|
------------------------- ---------------------------------------------------------------------------- ----------------------------------------------------------------------------
|
||||||
|
**Table** **Key Columns** **Description**
|
||||||
|
workspaces id, name, owner\_id, plan, settings\_jsonb Top-level tenant boundary; one per team
|
||||||
|
artboards id, workspace\_id, name, origin\_id, parent\_artboard\_id, metadata\_jsonb The core canvas unit; tracks lineage via parent\_artboard\_id
|
||||||
|
origins id, type (ENUM), source\_ref, source\_metadata\_jsonb Typed origin record: GIT\_COMMIT, LINEAR\_ISSUE, SLACK\_MESSAGE, URL, FORK
|
||||||
|
intent\_diffs id, artboard\_id, author\_id, changes\_jsonb, summary, status (ENUM) Each saved change set; status: DRAFT, EXPORTED, IMPLEMENTED, BLOCKED
|
||||||
|
agent\_sessions id, artboard\_id, diff\_id, agent\_type, messages\_jsonb, status Bidirectional Agent Bridge conversation log
|
||||||
|
design\_language\_files id, workspace\_id, name, schema\_jsonb, version Uploaded design language JSON/YAML, validated and stored
|
||||||
|
team\_members id, workspace\_id, user\_id, role (ENUM) Role: OWNER, DESIGNER, ENGINEER, PM, VIEWER
|
||||||
|
------------------------- ---------------------------------------------------------------------------- ----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**7.2 pg\_graphql API**
|
||||||
|
|
||||||
|
Supabase\'s pg\_graphql extension auto-generates a GraphQL API from the PostgreSQL schema. Originmain uses this as the primary data API for the frontend, supplemented by tRPC endpoints for write-heavy operations (diff creation, agent sessions) that require complex server-side logic.
|
||||||
|
|
||||||
|
---------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**PERF** The most expensive query is the Origin Graph traversal (finding all ancestors or descendants of an artboard). Pre-compute and cache ancestry paths in a materialised view (artboard\_ancestry) updated by a trigger on INSERT to artboards. This avoids recursive CTEs at query time.
|
||||||
|
---------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**8. Layer 5 --- Design Language Runtime**
|
||||||
|
|
||||||
|
**8.1 Design Language File Format**
|
||||||
|
|
||||||
|
A Design Language File is a JSON document that defines a team\'s design system rules. It is validated against a JSON Schema on upload and stored in the design\_language\_files table. The runtime loads it into memory for use by the AI layer, visual editing constraints, and Completion Zone validation.
|
||||||
|
|
||||||
|
The file structure:
|
||||||
|
|
||||||
|
- tokens: Colour, typography, spacing, and motion tokens (maps to Fluent 2 token names where applicable)
|
||||||
|
|
||||||
|
- components: Per-component usage rules (allowed props, forbidden variants, required ARIA attributes)
|
||||||
|
|
||||||
|
- screens: Screen-level rules (which components are allowed, mandatory sections, layout constraints)
|
||||||
|
|
||||||
|
- voice: Tone-of-voice rules for AI-generated text content
|
||||||
|
|
||||||
|
- accessibility: Global WCAG requirements and custom accessibility rules
|
||||||
|
|
||||||
|
**8.2 Validation Pipeline**
|
||||||
|
|
||||||
|
Every AI completion and every visual edit that changes a design token is validated against the active Design Language File in real time. Violations are shown as inline annotations on the artboard --- not blocking errors, but visible warnings that require explicit acknowledgement before exporting a diff.
|
||||||
|
|
||||||
|
**9. Layer 6 --- AI Completion Layer**
|
||||||
|
|
||||||
|
**9.1 Claude API Integration**
|
||||||
|
|
||||||
|
The AI layer is built on Claude Sonnet 4 via the Anthropic SDK. All AI features route through a single AI gateway service (packages/ai-layer) which manages API key rotation, rate limiting, cost tracking, and prompt versioning. No AI calls are made directly from the frontend.
|
||||||
|
|
||||||
|
---------------------------- ----------------- ------------------------------------------------------------ -----------------------------------------------
|
||||||
|
**AI Feature** **Model** **Input** **Output**
|
||||||
|
Completion Zone fill Claude Sonnet 4 Zone context, design language file, surrounding components Structured component tree or content JSON
|
||||||
|
Diff summary generation Claude Sonnet 4 Raw component-level changes (JSON) Natural language summary for human review
|
||||||
|
Cross-artboard query Claude Sonnet 4 Natural language query + Origin Graph metadata Filtered artboard list with reasoning
|
||||||
|
Design system drift report Claude Sonnet 4 Live app screenshot + design language file Drift violations with corrective Intent Diffs
|
||||||
|
Agent Bridge Q&A Claude Sonnet 4 Coding agent question + artboard context Design agent answer with visual reference
|
||||||
|
---------------------------- ----------------- ------------------------------------------------------------ -----------------------------------------------
|
||||||
|
|
||||||
|
**9.2 Completion Zone Implementation**
|
||||||
|
|
||||||
|
A Completion Zone is a React component rendered in the UI chrome layer over the relevant region of an artboard. The zone UI (Fluent 2 Card with intent selector and submit button) communicates with the AI layer via tRPC. The AI response is rendered as a proposed overlay on the artboard; the designer accepts, modifies, or rejects it before it is committed to the Intent Diff history.
|
||||||
|
|
||||||
|
**9.3 Prompt Engineering Guidelines**
|
||||||
|
|
||||||
|
- Every prompt includes: the team\'s design language file as a system constraint, the component tree context of the target region, and before/after screenshots of the artboard
|
||||||
|
|
||||||
|
- Prompts are versioned in packages/ai-layer/src/prompts/ and tested with an evaluation harness before deployment
|
||||||
|
|
||||||
|
- Temperature is set to 0.3 for completion tasks (deterministic quality) and 0.7 for generative variation tasks (creative alternatives)
|
||||||
|
|
||||||
|
- All AI outputs are validated against the Design Language File schema before being presented to the user; invalid outputs are silently regenerated up to 3 times before surfacing an error
|
||||||
|
|
||||||
|
**10. Layer 7 --- Agent Bridge (MCP)**
|
||||||
|
|
||||||
|
**10.1 Protocol Architecture**
|
||||||
|
|
||||||
|
The Agent Bridge is an MCP (Model Context Protocol) server that exposes Originmain\'s design context to external coding agents. It runs as a long-lived WebSocket server (Render) alongside a REST endpoint for polling-based agents. The bridge is bidirectional: it pushes diffs to coding agents and receives implementation status updates in return.
|
||||||
|
|
||||||
|
**10.2 MCP Server Tools**
|
||||||
|
|
||||||
|
The Originmain MCP server exposes the following tools to connected coding agents:
|
||||||
|
|
||||||
|
------------------------ ---------------------------------------- ----------------------------------------------------------------------------------------
|
||||||
|
**MCP Tool** **Input** **Output**
|
||||||
|
get\_pending\_diffs workspace\_id, artboard\_id (optional) Array of IntentDiff objects with status EXPORTED
|
||||||
|
get\_artboard\_context artboard\_id Full artboard metadata, component tree, design language file, before/after screenshots
|
||||||
|
ask\_design\_agent diff\_id, question: string Claude-generated answer from the design agent with visual reference
|
||||||
|
update\_diff\_status diff\_id, status, notes Acknowledges implementation; updates diff record in Origin Graph
|
||||||
|
get\_design\_language workspace\_id The team\'s active design language file for local validation
|
||||||
|
------------------------ ---------------------------------------- ----------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**10.3 Coding Agent Adapters**
|
||||||
|
|
||||||
|
Phase 2 ships with first-party adapters for Cursor and Claude Code. Each adapter wraps the MCP protocol in the coding agent\'s native integration format:
|
||||||
|
|
||||||
|
- Cursor: .cursorrules file + MCP server config in cursor\_settings.json; adapter translates IntentDiff to Cursor\'s \'edit plan\' format
|
||||||
|
|
||||||
|
- Claude Code: CLAUDE.md auto-generation + MCP server declaration; adapter streams IntentDiff as a structured task to the Claude Code session
|
||||||
|
|
||||||
|
- Generic: Raw MCP JSON-RPC over WebSocket for custom integrations
|
||||||
|
|
||||||
|
**11. Layers 8--10 --- Integrations, Multiplayer & Platform**
|
||||||
|
|
||||||
|
**11.1 Layer 8: Multi-Origin Ingestion**
|
||||||
|
|
||||||
|
Each integration is an isolated connector in packages/integrations that implements the OriginIngester interface: ingest(source) =\> Origin. Connectors run as serverless functions (Vercel Edge Functions) to minimise latency on the ingestion path.
|
||||||
|
|
||||||
|
----------------- ------------------- ----------------------------------------------------------------------------------------------------------------
|
||||||
|
**Integration** **SDK / API** **Ingestion Flow**
|
||||||
|
Linear \@linear/sdk v2 Webhook on issue update -\> fetch issue + attachments -\> render linked URL or screenshot as artboard
|
||||||
|
Slack \@slack/bolt v4 Event API on message\_posted -\> parse URL or attachment -\> render as artboard with Slack thread context
|
||||||
|
GitHub \@octokit/rest Webhook on PR open/push -\> render affected routes at commit SHA -\> diff against base branch artboard
|
||||||
|
Intercom Intercom REST API Inbound webhook on user report -\> extract annotated screenshot -\> create artboard with user context metadata
|
||||||
|
----------------- ------------------- ----------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**11.2 Layer 9: Multiplayer & Presence**
|
||||||
|
|
||||||
|
Real-time multiplayer is implemented using Liveblocks, which provides CRDT-based shared state, presence, and conflict resolution. The Liveblocks room maps 1:1 to a Workspace. Each artboard is a Liveblocks Storage object. Presence (cursor positions, active artboard, selection state) uses Liveblocks Presence API with a 50ms update throttle.
|
||||||
|
|
||||||
|
--------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**IMPORTANT** Multiplayer is a Phase 3 feature. Design the data model and state management for eventual multiplayer from Phase 1 (use Zustand stores that can be swapped for Liveblocks storage without API changes), but do not integrate Liveblocks until Phase 3 to avoid complexity creep.
|
||||||
|
--------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**11.3 Layer 10: Platform & Extensions**
|
||||||
|
|
||||||
|
The Plugin API (Phase 4) is a sandboxed JavaScript execution environment (based on the Figma Plugin API model) that allows third parties to:
|
||||||
|
|
||||||
|
- Read artboard metadata and Intent Diffs via a read-only API
|
||||||
|
|
||||||
|
- Write new artboards and origins via a write API (requires approval)
|
||||||
|
|
||||||
|
- Register custom Completion Zone types with custom AI prompts
|
||||||
|
|
||||||
|
- Add custom ingestion connectors beyond the first-party set
|
||||||
|
|
||||||
|
Enterprise features (Phase 4) include: SSO via SAML 2.0 (Clerk Enterprise), SCIM user provisioning, workspace-level audit logs (Supabase audit log extension), and white-label theming via the Fluent 2 createLightTheme API.
|
||||||
|
|
||||||
|
**12. Testing Strategy**
|
||||||
|
|
||||||
|
------------------------- ------------------- ----------------------------------------- -------------------------------------------
|
||||||
|
**Layer** **Test Type** **Tooling** **Coverage Target**
|
||||||
|
Diff Engine Unit Vitest 95% --- this is the most critical package
|
||||||
|
Origin Graph Integration Vitest + Supabase local 80% on all query paths
|
||||||
|
Design Language Runtime Unit Vitest 90% on validator logic
|
||||||
|
AI Layer Eval harness Custom eval framework + Anthropic evals 80% acceptance rate on completions
|
||||||
|
Agent Bridge Contract Pact (consumer-driven contracts) All MCP tools covered
|
||||||
|
Canvas UI Component Storybook + Chromatic All Fluent 2 wrapper components
|
||||||
|
Rendering Engine Visual regression Playwright + Percy All route renders covered
|
||||||
|
Full product E2E Playwright 10 critical user journeys
|
||||||
|
------------------------- ------------------- ----------------------------------------- -------------------------------------------
|
||||||
|
|
||||||
|
**12.1 The 10 Critical E2E Journeys**
|
||||||
|
|
||||||
|
8. Connect an app and render its first Live Artboard from a route URL
|
||||||
|
|
||||||
|
9. Make a visual edit and verify the correct Intent Diff is generated
|
||||||
|
|
||||||
|
10. Export a diff to Cursor via the Agent Bridge and verify receipt
|
||||||
|
|
||||||
|
11. Upload a Design Language File and verify AI completion respects its constraints
|
||||||
|
|
||||||
|
12. Ingest a Linear issue and render its linked screen as an artboard
|
||||||
|
|
||||||
|
13. Fork an artboard and verify independent change histories
|
||||||
|
|
||||||
|
14. Use the Cross-artboard Query to find all artboards matching a natural language filter
|
||||||
|
|
||||||
|
15. Complete a Completion Zone and accept the AI-generated content
|
||||||
|
|
||||||
|
16. Verify multiplayer presence shows correct cursor positions for two users
|
||||||
|
|
||||||
|
17. Generate a Design System Drift report and verify corrective diffs are accurate
|
||||||
|
|
||||||
|
**13. Security Considerations**
|
||||||
|
|
||||||
|
------------------------------------------ -----------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
**Risk** **Mitigation**
|
||||||
|
Sandboxed iframe XSS Strict CSP, sandbox attribute, postMessage origin validation, no allow-same-origin + allow-scripts combined for untrusted content
|
||||||
|
Design Language File injection JSON Schema validation on upload, Zod runtime parsing, no eval() of file contents
|
||||||
|
AI prompt injection via artboard content Sanitise all user-generated content before including in AI prompts; use Anthropic\'s system prompt boundary strictly
|
||||||
|
API key exposure All Anthropic API calls server-side only; Clerk JWT required on all tRPC routes; environment variables never in client bundle
|
||||||
|
Origin Graph data leakage Row-level security (RLS) in Supabase on all tables; workspace\_id checked on every query; Clerk JWT verified server-side
|
||||||
|
Agent Bridge abuse MCP connections require a signed workspace token; rate-limited to 100 diff exports per hour per workspace; all sessions logged
|
||||||
|
Module Federation supply chain Pin remote versions; validate module hashes on load; disallow dynamic remote URLs from untrusted sources
|
||||||
|
------------------------------------------ -----------------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**14. Phase-by-Phase Build Plan**
|
||||||
|
|
||||||
|
**Phase 1: Foundation (Months 1--4)**
|
||||||
|
|
||||||
|
Deliverables at the end of Phase 1 constitute the Minimum Viable Product for internal use:
|
||||||
|
|
||||||
|
---------- ---------------------------------------------------- ---------------------------------------------------------------------------
|
||||||
|
**Week** **Milestone** **Acceptance Criteria**
|
||||||
|
1--2 Monorepo scaffold, CI/CD, Supabase setup All packages build; GitHub Actions pipeline green; Supabase local running
|
||||||
|
3--4 Fluent 2 canvas shell (Layout, Toolbar, Inspector) Canvas chrome renders; pan/zoom works; Fluent 2 tokens applied
|
||||||
|
5--7 Rendering Engine v1 (iframe + Module Federation) Connected Next.js app renders inside canvas artboard
|
||||||
|
8--10 Visual editing + Diff Engine v1 Click-to-select, drag-to-resize; Intent Diff generated on every edit
|
||||||
|
11--12 Origin Graph v1 (PostgreSQL + pg\_graphql) Artboard CRUD; metadata stored; basic query API working
|
||||||
|
13--14 Design Language File upload + validation File uploaded; AI and editing constrained to its rules
|
||||||
|
15--16 Diff export (JSON + NL summary) Intent Diff exported to clipboard and file; summary generated by Claude
|
||||||
|
---------- ---------------------------------------------------- ---------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**Phase 2: Intelligence (Months 5--8)**
|
||||||
|
|
||||||
|
---------- ---------------------------------------------------- ------------------------------------------------------------------------
|
||||||
|
**Week** **Milestone** **Acceptance Criteria**
|
||||||
|
17--18 AI Completion Zones v1 Designer draws zone; Claude generates completion; accepted or rejected
|
||||||
|
19--21 Agent Bridge v1 (MCP server + Cursor adapter) Cursor receives IntentDiff; status update flows back to artboard
|
||||||
|
22--23 Linear + Slack ingestion Linear issue renders as artboard; Slack screenshot renders as artboard
|
||||||
|
24--26 Claude Code adapter + bidirectional Q&A Claude Code receives diff; design agent answers coding agent questions
|
||||||
|
27--28 Closed beta preparation: onboarding, docs, support 100 design engineering teams onboarded to closed beta
|
||||||
|
---------- ---------------------------------------------------- ------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**Phase 3: Scale (Months 9--12)**
|
||||||
|
|
||||||
|
---------- ------------------------------------------ ------------------------------------------------------------------------------
|
||||||
|
**Week** **Milestone** **Acceptance Criteria**
|
||||||
|
29--32 Liveblocks multiplayer integration Two users edit simultaneously; presence cursors visible; no data conflicts
|
||||||
|
33--35 Cross-artboard natural language querying Query returns correct artboard set; Origin Graph traversal \< 200ms
|
||||||
|
36--38 Design system drift detection Drift report generated; corrective diffs exported; coding agent applies them
|
||||||
|
39--40 Vue + Svelte rendering support Vue and Svelte routes render as Live Artboards
|
||||||
|
41--44 Public beta preparation and launch Public beta live; self-serve onboarding; pricing page active
|
||||||
|
---------- ------------------------------------------ ------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
**15. Performance Targets**
|
||||||
|
|
||||||
|
-------------------------------- -------------------- ----------------------------------------------------------------------
|
||||||
|
**Operation** **Target** **Measurement**
|
||||||
|
Artboard initial render (cold) \< 3 seconds Playwright performance.timing from navigation to iframe loaded
|
||||||
|
Artboard re-render after edit \< 500ms Time from mouse-up on drag to updated visual feedback
|
||||||
|
Intent Diff generation \< 100ms Time from edit commit to diff appearing in inspector panel
|
||||||
|
Diff export to coding agent \< 2 seconds Time from export button click to coding agent receiving payload
|
||||||
|
AI Completion Zone fill \< 8 seconds (P90) Time from zone submission to completion rendered in artboard
|
||||||
|
Canvas pan/zoom 60fps sustained Chrome DevTools frame rate monitor during continuous pan gesture
|
||||||
|
Origin Graph query (complex) \< 500ms p95 query time in production (measured via Supabase Query Analytics)
|
||||||
|
Cross-artboard NL query \< 5 seconds Time from query submission to results rendered
|
||||||
|
-------------------------------- -------------------- ----------------------------------------------------------------------
|
||||||
|
|
||||||
|
**Appendix: Key Dependencies**
|
||||||
|
|
||||||
|
------------------------------- -------------- --------------------------------------------------------------
|
||||||
|
**Package** **Version** **Purpose**
|
||||||
|
react 19.x Core UI framework
|
||||||
|
next 15.x App framework, routing, RSC
|
||||||
|
\@fluentui/react-components 9.x Design system and component library
|
||||||
|
\@griffel/react 1.x CSS-in-JS (included with Fluent 2)
|
||||||
|
zustand 5.x Canvas state management
|
||||||
|
\@tanstack/react-query 5.x Server state and caching
|
||||||
|
\@trpc/server + \@trpc/client 11.x Type-safe API layer
|
||||||
|
\@anthropic-ai/sdk 0.x (latest) Claude API client
|
||||||
|
\@modelcontextprotocol/sdk latest MCP server and client
|
||||||
|
\@supabase/supabase-js 2.x Database, auth, storage, realtime
|
||||||
|
\@liveblocks/client 2.x Multiplayer CRDT (Phase 3)
|
||||||
|
\@linear/sdk 2.x Linear integration
|
||||||
|
\@slack/bolt 4.x Slack integration
|
||||||
|
\@octokit/rest 20.x GitHub integration
|
||||||
|
zod 3.x Runtime schema validation
|
||||||
|
vitest 2.x Unit and integration testing
|
||||||
|
playwright 1.x E2E and visual regression testing
|
||||||
|
yjs 13.x CRDT underlying Liveblocks (Phase 3)
|
||||||
|
\@pierre/diffs 1.x (latest) Code-level diff rendering (export panel & Agent Bridge view)
|
||||||
|
\@pierre/trees latest Codebase file browser (git status, virtualization, search)
|
||||||
|
------------------------------- -------------- --------------------------------------------------------------
|
||||||
|
|
||||||
|
*End of Implementation Guide --- Originmain v1.0*
|
||||||
@@ -0,0 +1,456 @@
|
|||||||
|
|
||||||
|
|
||||||
|
PRODUCT REQUIREMENTS DOCUMENT
|
||||||
|
|
||||||
|
**Originmain**
|
||||||
|
|
||||||
|
The AI-Native Design Engineering Platform
|
||||||
|
|
||||||
|
*Where design intent becomes production code, on a single canvas.*
|
||||||
|
|
||||||
|
| Version | 1.0 |
|
||||||
|
| :---- | :---- |
|
||||||
|
| **Date** | April 20, 2026 |
|
||||||
|
| **Author** | Patrick (Product Lead) |
|
||||||
|
| **Status** | Draft — Internal Review |
|
||||||
|
| **Design System** | Microsoft Fluent 2 (@fluentui/react-components v9) |
|
||||||
|
| **Classification** | Confidential |
|
||||||
|
|
||||||
|
# **Table of Contents**
|
||||||
|
|
||||||
|
**1\. Executive Summary**
|
||||||
|
|
||||||
|
**2\. Problem Statement**
|
||||||
|
|
||||||
|
**3\. Vision & Opportunity**
|
||||||
|
|
||||||
|
**4\. Target Users & Personas**
|
||||||
|
|
||||||
|
**5\. Product Principles**
|
||||||
|
|
||||||
|
**6\. Core Concepts & Mental Model**
|
||||||
|
|
||||||
|
**7\. Feature Requirements (P0–P2)**
|
||||||
|
|
||||||
|
**8\. Architecture & System Design**
|
||||||
|
|
||||||
|
**9\. Design System: Fluent 2 Integration**
|
||||||
|
|
||||||
|
**10\. Competitive Landscape**
|
||||||
|
|
||||||
|
**11\. Metrics & Success Criteria**
|
||||||
|
|
||||||
|
**12\. Phased Roadmap**
|
||||||
|
|
||||||
|
**13\. Risks & Mitigations**
|
||||||
|
|
||||||
|
**14\. Appendices**
|
||||||
|
|
||||||
|
# **1\. Executive Summary**
|
||||||
|
|
||||||
|
Originmain is an AI-native design engineering platform that collapses the distance between design intent and production code into a single, continuous workflow. It is a canvas where every artboard is a live, editable render of your actual application — not a static mockup — and every visual change produces a structured diff that a coding agent can execute against your real codebase.
|
||||||
|
|
||||||
|
The product synthesises two converging insights. The first, articulated by practitioners building modern product teams, is that the ideal design tool is a canvas where any view of your application can be rendered, explored, duplicated, and modified visually — where user feedback from tools like Linear can be ingested as a starting-point screen, where design language files guide AI-assisted completion, where every artboard carries metadata about its origin, author, and change history, and where edits export as executable plans for coding agents. The second insight, drawn from the concept of **designing for creation**, is that the most powerful creative tools do not present a blank canvas — they provide structured starting points, contextual scaffolding, and opinionated defaults that transform the intimidating emptiness of possibility into a launchpad for exploration. Originmain embeds this philosophy at every layer: you never start from nothing.
|
||||||
|
|
||||||
|
Originmain is built entirely on Microsoft’s Fluent 2 Design System, using @fluentui/react-components v9 as its component foundation. This is not merely a styling decision — it ensures that the tool’s own interface embodies the same systematic, accessible, and cross-platform design language it helps teams produce.
|
||||||
|
|
||||||
|
# **2\. Problem Statement**
|
||||||
|
|
||||||
|
**The 2026 design-to-code landscape is fragmented across three broken seams:**
|
||||||
|
|
||||||
|
## **2.1 The Handoff Gap**
|
||||||
|
|
||||||
|
Design tools produce static mockups. Code tools produce running software. The translation between them — the handoff — destroys intent. Pixel-perfect Figma files become “close enough” implementations, creating technical debt from day one. Industry reports show that even with modern AI-assisted design-to-code tools, the handoff between design and code still breaks, with teams spending 30–40% of sprint cycles on design-to-code reconciliation.
|
||||||
|
|
||||||
|
## **2.2 The Context Collapse**
|
||||||
|
|
||||||
|
Current tools silo context. A designer’s artboard knows nothing about the user feedback that prompted it, the engineer who will implement it, or the design system constraints that should govern it. Metadata — who created a view, what changed, when, and why — lives in Jira tickets, Slack threads, and people’s heads, not in the design artifact itself.
|
||||||
|
|
||||||
|
## **2.3 The Blank Canvas Problem**
|
||||||
|
|
||||||
|
Most creation tools start you at zero. A blank canvas is freedom, but it is also friction. Studies and practitioner experience confirm that adding even a single structured prompt to a blank canvas jumpstarts creative output. The most powerful tools do not offer infinite possibility — they offer curated starting points that channel creative energy. As one design leader observed, most people don’t want a blank canvas; they want a format, a prompt, a structure. If the tool doesn’t offer that scaffolding, the feed will.
|
||||||
|
|
||||||
|
# **3\. Vision & Opportunity**
|
||||||
|
|
||||||
|
**Originmain occupies the space where three previously separate categories converge:**
|
||||||
|
|
||||||
|
| Category | Current Tools | Originmain Approach |
|
||||||
|
| :---- | :---- | :---- |
|
||||||
|
| Visual Design | Figma, Stitch, Figma Make | Canvas renders live app views, not static frames |
|
||||||
|
| AI Code Generation | v0, Bolt, Lovable, Cursor | Diffs export as structured plans for coding agents |
|
||||||
|
| Design-Dev Collaboration | Zeplin, Figma Dev Mode, MCP | Metadata, provenance, and change history are native to every artboard |
|
||||||
|
|
||||||
|
**The opportunity is to build the first tool where a design change IS a code change — not a request for one.**
|
||||||
|
|
||||||
|
# **4\. Target Users & Personas**
|
||||||
|
|
||||||
|
## **4.1 Primary: The Design Engineer**
|
||||||
|
|
||||||
|
A hybrid practitioner who thinks in components and ships in code. They are frustrated by the false separation between design tools and code editors. They want a single surface where visual exploration and code-backed iteration are the same action. Role titles include Design Engineer, UI Engineer, Creative Technologist, and Frontend Developer with design sensibility.
|
||||||
|
|
||||||
|
## **4.2 Secondary: The Product Designer**
|
||||||
|
|
||||||
|
A designer who creates high-fidelity mockups but lacks the engineering skill to implement them. They want their visual intent to be preserved faithfully through implementation without learning to code. They are tired of handing off Figma files and seeing the result diverge from their vision.
|
||||||
|
|
||||||
|
## **4.3 Tertiary: The Product Manager**
|
||||||
|
|
||||||
|
A PM who receives user feedback (via Linear, Jira, Intercom, or direct user reports) and needs to communicate the required changes to design and engineering. They want to render the screen a user is complaining about, annotate it, and have that annotation flow directly into the build pipeline.
|
||||||
|
|
||||||
|
# **5\. Product Principles**
|
||||||
|
|
||||||
|
## **5.1 Never Start from Nothing**
|
||||||
|
|
||||||
|
Every interaction begins with structured context. A new artboard is pre-populated from a live app render, a user feedback screenshot, a design system template, or a team’s most recent work. The blank canvas is not the default — it is the exception. This principle is core to Originmain’s identity and draws directly from the insight that constraints catalyse creativity, while pure openness creates paralysis.
|
||||||
|
|
||||||
|
## **5.2 Design IS Code, Code IS Design**
|
||||||
|
|
||||||
|
There is no handoff because there is no gap. Every visual element on the canvas maps to a component in the codebase. Every visual edit produces a structured diff. The design tool and the code editor are the same surface viewed through different lenses.
|
||||||
|
|
||||||
|
## **5.3 Metadata is a First-Class Citizen**
|
||||||
|
|
||||||
|
Every artboard carries provenance: its origin (which screen, which commit, which user report), its author, its change history, and its relationship to other artboards. This metadata is queryable across the entire team’s workspace, enabling questions like “show me every artboard that originated from a user complaint in the last sprint.”
|
||||||
|
|
||||||
|
## **5.4 AI Fills, Humans Direct**
|
||||||
|
|
||||||
|
AI is a completion engine, not a replacement engine. Designers define zones, boundaries, and intent. AI completes lists, generates data-realistic content, fills layout regions, and suggests alternatives — always within the constraints the human has established. The tool has a point of view: it provides opinionated defaults informed by the team’s design language, product guidance files, and historical patterns.
|
||||||
|
|
||||||
|
## **5.5 Agents Communicate, Not Just Execute**
|
||||||
|
|
||||||
|
The design tool’s AI agents maintain check-ins with the coding agent. They do not simply hand over a spec — they communicate the nuances of the design: the spatial relationships, the motion intent, the edge cases, the “this should feel fast” qualitative judgements that a static spec cannot convey.
|
||||||
|
|
||||||
|
# **6\. Core Concepts & Mental Model**
|
||||||
|
|
||||||
|
## **6.1 The Live Artboard**
|
||||||
|
|
||||||
|
The fundamental unit of Originmain is the Live Artboard — a visual surface that renders a real view from your application. Unlike a Figma frame, a Live Artboard is aware of the component tree, state, props, and routing context of the screen it represents. You can fork an artboard, make visual changes, and those changes are tracked as a structured diff against the source.
|
||||||
|
|
||||||
|
## **6.2 The Origin Graph**
|
||||||
|
|
||||||
|
Every Live Artboard is a node in the Origin Graph, a directed acyclic graph that traces the provenance of every design decision. An artboard’s origin might be a Git commit, a Linear issue, a user feedback screenshot, or another artboard. The graph enables questions like: “Where did this design decision come from?” “Who changed this and when?” “Which user feedback led to this artboard?”
|
||||||
|
|
||||||
|
## **6.3 The Intent Diff**
|
||||||
|
|
||||||
|
When a designer modifies a Live Artboard, Originmain produces an Intent Diff — a structured representation of what changed, expressed at the component level (not the pixel level). An Intent Diff might say: “Replace the secondary button with a primary button in the checkout footer; increase the padding of the card container by 8px; add a loading skeleton to the product list.” This diff is the contract between design and code.
|
||||||
|
|
||||||
|
## **6.4 The Completion Zone**
|
||||||
|
|
||||||
|
A Completion Zone is a region on the canvas that the designer marks as “AI should fill this.” It might be a data table that needs realistic rows, a navigation menu that needs items generated from the sitemap, or an empty layout region that should be completed in a style consistent with the surrounding design. Completion Zones respect the team’s design language files and product guidance.
|
||||||
|
|
||||||
|
## **6.5 The Agent Bridge**
|
||||||
|
|
||||||
|
The Agent Bridge is the communication layer between Originmain’s design agents and external coding agents (Cursor, Claude Code, Copilot Workspace, or custom agents). The bridge does not simply export a spec — it maintains a bidirectional channel where the design agent can answer the coding agent’s questions, resolve ambiguities, and verify that the implementation matches intent.
|
||||||
|
|
||||||
|
# **7\. Feature Requirements**
|
||||||
|
|
||||||
|
Features are classified by priority: P0 (launch-blocking), P1 (launch-critical, can ship within 30 days post-launch), and P2 (strategic, scheduled for subsequent releases).
|
||||||
|
|
||||||
|
## **7.1 P0 — Launch Blocking**
|
||||||
|
|
||||||
|
### **7.1.1 Live App Rendering Engine**
|
||||||
|
|
||||||
|
* Render any route/view from a connected React or Next.js application as a Live Artboard on the canvas.
|
||||||
|
|
||||||
|
* Support importing component trees via an MCP server or direct codebase integration.
|
||||||
|
|
||||||
|
* Preserve component hierarchy, props, state, and design tokens in the rendered artboard.
|
||||||
|
|
||||||
|
* Enable rendering from external triggers: Linear issues, Slack messages, or pasted URLs.
|
||||||
|
|
||||||
|
### **7.1.2 Visual Editing with Structured Diffs**
|
||||||
|
|
||||||
|
* Allow direct visual manipulation of rendered components: resizing, repositioning, recolouring, swapping components, editing text content.
|
||||||
|
|
||||||
|
* Track every edit as a component-level Intent Diff, not a pixel-level change.
|
||||||
|
|
||||||
|
* Display Intent Diffs in the inspector sidebar as structured, human-readable component-level change summaries (rendered via Fluent 2 Card and Accordion components).
|
||||||
|
|
||||||
|
* Render code-level diffs in the export panel and Agent Bridge view using @pierre/diffs — stacked (unified) or split (side-by-side) mode, with Intent Diff annotation phrases anchored to the specific lines they describe.
|
||||||
|
|
||||||
|
* Support undo/redo with full history and branch-based exploration (fork an artboard, try both directions).
|
||||||
|
|
||||||
|
### **7.1.3 Design Language & Guidance Files**
|
||||||
|
|
||||||
|
* Allow teams to upload design language files (JSON/YAML) defining colour palettes, typography scales, spacing systems, component usage rules, and tone-of-voice guidelines.
|
||||||
|
|
||||||
|
* AI agents use these files as hard constraints when completing zones or suggesting alternatives.
|
||||||
|
|
||||||
|
* Build out a design language file/storybook document from a github repo
|
||||||
|
|
||||||
|
* Product guidance files define screen-level rules: which components are allowed on which screen types, mandatory accessibility patterns, and layout constraints.
|
||||||
|
|
||||||
|
### **7.1.4 Artboard Metadata & Origin Tracking**
|
||||||
|
|
||||||
|
* Every artboard stores: origin source, creator identity, creation timestamp, full change history, linked issues/tickets, and relationships to other artboards.
|
||||||
|
|
||||||
|
* Metadata is queryable via a search/filter interface: “Show me all artboards created by Sarah this week” or “Show me artboards linked to Linear issue LIN-4521.”
|
||||||
|
|
||||||
|
### **7.1.5 Diff Export to Coding Agents**
|
||||||
|
|
||||||
|
* Export Intent Diffs as structured plans (JSON \+ natural-language summary) compatible with Cursor, Claude Code, and GitHub Copilot Workspace.
|
||||||
|
|
||||||
|
* Include component references, file paths, prop changes, and visual context (before/after screenshots).
|
||||||
|
|
||||||
|
* Support MCP-based export for real-time streaming to connected coding agents.
|
||||||
|
|
||||||
|
### **7.1.6 Fluent 2 Component Library**
|
||||||
|
|
||||||
|
* Ship with the full @fluentui/react-components v9 library pre-loaded as the default component palette.
|
||||||
|
|
||||||
|
* All Originmain’s own UI surfaces are built using Fluent 2 components: FluentProvider, Button, Input, Dialog, Menu, Card, Tree, DataGrid, Toolbar, Tab, Badge, Avatar, Tooltip, and all 60+ components.
|
||||||
|
|
||||||
|
* Theming via Fluent 2 token system: webLightTheme, webDarkTheme, and custom brand themes via createLightTheme/createDarkTheme.
|
||||||
|
|
||||||
|
## **7.2 P1 — Launch Critical (Within 30 Days)**
|
||||||
|
|
||||||
|
### **7.2.1 AI Completion Zones**
|
||||||
|
|
||||||
|
* Designer draws a region and assigns an intent: “fill this table with realistic customer data,” “complete this navigation from the sitemap,” “generate 3 layout variations for this hero section.”
|
||||||
|
|
||||||
|
* AI respects design language files and product guidance.
|
||||||
|
|
||||||
|
* Support image-based completion: “use this screenshot as reference for the visual style of this zone.”
|
||||||
|
|
||||||
|
### **7.2.2 Agent Bridge (Design ↔ Code)**
|
||||||
|
|
||||||
|
* Bidirectional communication protocol between Originmain design agents and external coding agents.
|
||||||
|
|
||||||
|
* Design agent responds to coding agent queries: “What should this component look like in the error state?” “Is 16px or 24px padding intended here?”
|
||||||
|
|
||||||
|
* Coding agent reports implementation status back to the artboard: “Implemented,” “Blocked,” “Needs clarification.”
|
||||||
|
|
||||||
|
* Status sync visible on the canvas as component-level badges.
|
||||||
|
|
||||||
|
### **7.2.3 Multi-Origin Ingestion**
|
||||||
|
|
||||||
|
* Linear: Import issues as artboard starting points, with issue context embedded in metadata.
|
||||||
|
|
||||||
|
* Slack: Render a screen from a shared screenshot or URL, attributed to the sender.
|
||||||
|
|
||||||
|
* User Feedback Platforms: Ingest annotated screenshots from Intercom, Hotjar, or FullStory as artboard origins.
|
||||||
|
|
||||||
|
* Git: Render the UI at any commit hash to compare visual changes over time.
|
||||||
|
|
||||||
|
## **7.3 P2 — Strategic**
|
||||||
|
|
||||||
|
### **7.3.1 Cross-Artboard Querying**
|
||||||
|
|
||||||
|
* Natural-language queries across the entire team’s artboard workspace: “Which screens have changed the most in the last quarter?” “Show me every use of the legacy button component.”
|
||||||
|
|
||||||
|
* Powered by the Origin Graph and structured metadata.
|
||||||
|
|
||||||
|
### **7.3.2 Multi-Framework Support**
|
||||||
|
|
||||||
|
* Extend the rendering engine beyond React/Next.js to Vue, Svelte, Angular, and Flutter web.
|
||||||
|
|
||||||
|
* Framework-specific diff exporters that produce idiomatic code plans for each framework.
|
||||||
|
|
||||||
|
### **7.3.3 Collaborative Multiplayer Canvas**
|
||||||
|
|
||||||
|
* Real-time collaborative editing with presence indicators, cursors, and conflict resolution.
|
||||||
|
|
||||||
|
* Role-based permissions: designers edit visuals, engineers view diffs, PMs annotate and comment.
|
||||||
|
|
||||||
|
### **7.3.4 Design System Drift Detection**
|
||||||
|
|
||||||
|
* Continuously compare the live application against the design language files.
|
||||||
|
|
||||||
|
* Flag components that have drifted from the design system: wrong tokens, deprecated components, inconsistent spacing.
|
||||||
|
|
||||||
|
* Generate corrective Intent Diffs that a coding agent can apply to bring the codebase back into compliance.
|
||||||
|
|
||||||
|
# **8\. Architecture & System Design**
|
||||||
|
|
||||||
|
## **8.1 High-Level Architecture**
|
||||||
|
|
||||||
|
| Layer | Technology | Responsibility |
|
||||||
|
| :---- | :---- | :---- |
|
||||||
|
| Canvas UI | React 19 \+ Fluent UI v9 \+ Griffel CSS-in-JS | Infinite canvas, component palette, artboard rendering, visual editing tools |
|
||||||
|
| Artboard Navigator | Fluent 2 Tree \+ TreeItem | Left-panel workspace and artboard hierarchy — in-ecosystem, Fluent-token-native |
|
||||||
|
| Codebase File Browser | @pierre/trees (Apache 2.0) | Connected-repo file tree — git status badges, automatic virtualization, path search |
|
||||||
|
| Rendering Engine | Sandboxed iframe \+ Module Federation | Safely render connected app components with full interactivity |
|
||||||
|
| Diff Engine | Custom AST differ (TypeScript) | Compute component-level Intent Diffs from visual edits |
|
||||||
|
| Diff Renderer | @pierre/diffs (Apache 2.0) | Code-level diff display in export panel and Agent Bridge view — Shiki-powered, annotatable |
|
||||||
|
| Origin Graph | PostgreSQL \+ pg\_graphql | Store and query artboard provenance, metadata, and relationships |
|
||||||
|
| AI Layer | Claude Sonnet 4 via Anthropic API | Completion Zones, design guidance enforcement, natural-language querying |
|
||||||
|
| Agent Bridge | MCP (Model Context Protocol) | Bidirectional communication with external coding agents |
|
||||||
|
| Integrations | Linear SDK, Slack API, Git providers | Multi-origin ingestion and status sync |
|
||||||
|
| Auth & Collab | Clerk \+ Liveblocks | Authentication, multiplayer, presence, and permissions |
|
||||||
|
|
||||||
|
## **8.2 Data Flow**
|
||||||
|
|
||||||
|
The core data flow follows five stages:
|
||||||
|
|
||||||
|
* **Ingest:** A screen origin is received (app route, Linear issue, user screenshot, Git commit). The Rendering Engine produces a Live Artboard with full component-tree metadata.
|
||||||
|
|
||||||
|
* **Edit:** The designer modifies the artboard visually. Each edit is captured by the Diff Engine as a component-level Intent Diff and written to the Origin Graph.
|
||||||
|
|
||||||
|
* **Complete:** AI fills Completion Zones using the team’s design language files and the Claude API. Completions are tracked as diffs with AI attribution.
|
||||||
|
|
||||||
|
* **Export:** Intent Diffs are packaged as a structured plan (JSON \+ natural language) and sent to a coding agent via the Agent Bridge (MCP protocol).
|
||||||
|
|
||||||
|
* **Verify:** The coding agent reports implementation status back through the Agent Bridge. The artboard updates to show build progress, and the design agent answers clarifying questions.
|
||||||
|
|
||||||
|
# **9\. Design System: Fluent 2 Integration**
|
||||||
|
|
||||||
|
Originmain is built on Fluent 2 at every layer. This section defines how Fluent 2 is used in the product’s own interface and how it enables the design-to-code workflow.
|
||||||
|
|
||||||
|
## **9.1 Originmain’s Own UI**
|
||||||
|
|
||||||
|
* Root: FluentProvider wraps the entire application with webLightTheme (default) and webDarkTheme (toggled via settings). Custom brand theme available for white-labelling.
|
||||||
|
|
||||||
|
* Canvas Chrome: Toolbar, Menu, MenuButton, and Tab components for tool selection, view switching, and workspace navigation.
|
||||||
|
|
||||||
|
* Artboard Inspector: Card, Accordion, and DataGrid for displaying metadata, diffs, and component properties.
|
||||||
|
|
||||||
|
* Dialogs & Modals: Dialog, DialogSurface, and Drawer for settings, export flows, and agent communication.
|
||||||
|
|
||||||
|
* Input Surfaces: Input, Textarea, Combobox, Dropdown, and SearchBox for querying, filtering, and naming.
|
||||||
|
|
||||||
|
* Status & Feedback: Badge, Toast, Spinner, ProgressBar, and MessageBar for agent status, build progress, and system notifications.
|
||||||
|
|
||||||
|
* Navigation (workspace): Tree and TreeItem (Fluent 2) for the artboard navigator sidebar — workspace folders, artboard groups, and project hierarchy. Breadcrumb and Nav for top-level workspace routing.
|
||||||
|
|
||||||
|
* Navigation (codebase): @pierre/trees for the codebase file browser panel — renders the connected application's repository file tree with automatic virtualization (suitable for monorepos with thousands of files), git status badges (added, modified, deleted, renamed, untracked, ignored), path/filename search, and single-child directory chain flattening. Theming is projected via CSS custom properties mapped to Fluent 2 surface tokens.
|
||||||
|
|
||||||
|
## **9.2 Design Token Pipeline**
|
||||||
|
|
||||||
|
Fluent 2’s token system (colorBrandBackground, fontSizeBase300, spacingHorizontalM, etc.) is the backbone of Originmain’s theming. Teams can create custom brand themes using createLightTheme and createDarkTheme, which map to Fluent 2’s BrandVariants palette. These tokens flow through the rendering engine so that artboards produced by Originmain are automatically Fluent 2-compliant.
|
||||||
|
|
||||||
|
## **9.3 Accessibility**
|
||||||
|
|
||||||
|
Fluent 2 components ship with built-in WCAG 2.1 AA compliance: keyboard navigation, screen reader support, high-contrast mode, and focus management. Originmain inherits these capabilities without additional work. The Completion Zone AI is further constrained to produce only layouts that pass automated accessibility checks (colour contrast, touch target size, heading hierarchy).
|
||||||
|
|
||||||
|
# **10\. Competitive Landscape**
|
||||||
|
|
||||||
|
| Tool | What It Does Well | What Originmain Does Differently |
|
||||||
|
| :---- | :---- | :---- |
|
||||||
|
| Figma \+ Figma Make | Industry-standard design tool; AI-assisted layout generation; massive plugin ecosystem | Originmain artboards are live app renders, not static frames; edits produce code diffs, not design specs |
|
||||||
|
| Google Stitch | Multi-screen AI generation; infinite canvas; voice input; free; code export to 7 frameworks | Originmain starts from YOUR app’s actual components, not generic AI-generated screens; diffs map to your codebase |
|
||||||
|
| v0 (Vercel) | Production-quality React component generation; Git-native workflows; Next.js ecosystem | Originmain is a visual canvas first, not a chat-first code generator; supports bidirectional design-code sync |
|
||||||
|
| Lovable / Bolt | Full-stack app generation from prompts; deployment included | Originmain is for teams with existing codebases, not greenfield apps; design intent preservation is the priority |
|
||||||
|
| Cursor \+ MCP | AI-powered code editor with design context via Figma MCP; reads design tokens | Originmain IS the design surface that generates the context; it doesn’t read from a separate design tool |
|
||||||
|
| Anima | Figma-to-code conversion; design-aware AI; playground for prototyping | Originmain eliminates Figma as a dependency; the artboard is the source of truth, not a Figma file |
|
||||||
|
|
||||||
|
**Originmain’s core differentiation: it is the only tool where the design surface, the code diff, the metadata graph, and the AI completion engine are a single integrated system — not a pipeline of separate tools stitched together with exports and plugins.**
|
||||||
|
|
||||||
|
# **11\. Metrics & Success Criteria**
|
||||||
|
|
||||||
|
| Metric | Target (6 months post-launch) | Measurement |
|
||||||
|
| :---- | :---- | :---- |
|
||||||
|
| Design-to-Code Cycle Time | ≤50% reduction vs. Figma \+ handoff baseline | Time from first artboard creation to PR merge, measured via Git integration |
|
||||||
|
| Intent Fidelity Score | ≥90% of Intent Diffs implemented without manual correction | Automated comparison of exported diff vs. committed code changes |
|
||||||
|
| Blank Canvas Bypass Rate | ≥80% of new artboards start from a structured origin (not blank) | Origin Graph analytics: proportion of artboards with non-null origin |
|
||||||
|
| Agent Bridge Resolution Rate | ≥70% of coding agent queries resolved by design agent without human intervention | Agent Bridge conversation logs |
|
||||||
|
| Completion Zone Acceptance Rate | ≥75% of AI completions accepted without modification | Edit history on Completion Zone outputs |
|
||||||
|
| Weekly Active Teams | 500+ teams in closed beta | Auth \+ workspace analytics |
|
||||||
|
|
||||||
|
# **12\. Phased Roadmap**
|
||||||
|
|
||||||
|
## **Phase 1: Foundation (Months 1–4)**
|
||||||
|
|
||||||
|
* Canvas infrastructure: infinite canvas with pan/zoom, artboard CRUD, and Fluent 2-based chrome.
|
||||||
|
|
||||||
|
* Rendering Engine v1: render React/Next.js routes as Live Artboards via sandboxed iframes.
|
||||||
|
|
||||||
|
* Visual editing: direct manipulation of rendered components with Intent Diff generation.
|
||||||
|
|
||||||
|
* Design language file upload and enforcement.
|
||||||
|
|
||||||
|
* Artboard metadata and Origin Graph (PostgreSQL backend).
|
||||||
|
|
||||||
|
* Diff export to clipboard and file (JSON \+ natural language summary).
|
||||||
|
|
||||||
|
## **Phase 2: Intelligence (Months 5–8)**
|
||||||
|
|
||||||
|
* AI Completion Zones powered by Claude Sonnet 4\.
|
||||||
|
|
||||||
|
* Agent Bridge v1: MCP-based export to Cursor and Claude Code.
|
||||||
|
|
||||||
|
* Multi-origin ingestion: Linear, Slack, Git commit rendering.
|
||||||
|
|
||||||
|
* Agent check-in protocol: design agent communicates nuances to coding agent.
|
||||||
|
|
||||||
|
* Closed beta launch with 100 design engineering teams.
|
||||||
|
|
||||||
|
## **Phase 3: Scale (Months 9–12)**
|
||||||
|
|
||||||
|
* Collaborative multiplayer canvas (Liveblocks integration).
|
||||||
|
|
||||||
|
* Cross-artboard querying via natural language.
|
||||||
|
|
||||||
|
* Design system drift detection.
|
||||||
|
|
||||||
|
* Multi-framework rendering (Vue, Svelte).
|
||||||
|
|
||||||
|
* Public beta launch.
|
||||||
|
|
||||||
|
## **Phase 4: Platform (Months 13–18)**
|
||||||
|
|
||||||
|
* Plugin/extension API for custom integrations.
|
||||||
|
|
||||||
|
* Enterprise features: SSO, audit logs, workspace administration.
|
||||||
|
|
||||||
|
* White-label theming for agencies and design studios.
|
||||||
|
|
||||||
|
* Flutter web and Angular rendering support.
|
||||||
|
|
||||||
|
* General availability.
|
||||||
|
|
||||||
|
# **13\. Risks & Mitigations**
|
||||||
|
|
||||||
|
| Risk | Impact | Mitigation |
|
||||||
|
| :---- | :---- | :---- |
|
||||||
|
| Rendering fidelity: sandboxed rendering may not perfectly match production environments | High — trust in the tool depends on visual accuracy | Use Module Federation for component sharing; automated visual regression testing against production screenshots |
|
||||||
|
| AI hallucination in Completion Zones | Medium — incorrect completions erode trust | Hard-constrain AI output to design language files; human approval gate before completion is committed; confidence scoring |
|
||||||
|
| MCP protocol maturity: Agent Bridge depends on MCP ecosystem adoption | Medium — limited coding agent compatibility | Ship with first-party Cursor and Claude Code adapters; abstract over protocol layer to support future alternatives |
|
||||||
|
| Fluent 2 dependency: tightly coupling to Fluent 2 may limit appeal for non-Microsoft teams | Medium — addressable market concern | Originmain’s own UI uses Fluent 2, but the rendering engine is design-system agnostic; teams render THEIR components, not Fluent components |
|
||||||
|
| Competitive response from Figma/Google | High — both have AI canvas initiatives | Originmain’s moat is the bidirectional Agent Bridge and Origin Graph — features that require deep codebase integration, not just AI generation |
|
||||||
|
| Team adoption inertia: designers resistant to leaving Figma | High — user acquisition challenge | Figma import tool (convert Figma frames to Live Artboards); gradual adoption path where Originmain reads from Figma via MCP before fully replacing it |
|
||||||
|
|
||||||
|
# **14\. Appendices**
|
||||||
|
|
||||||
|
## **Appendix A: Glossary**
|
||||||
|
|
||||||
|
| Term | Definition |
|
||||||
|
| :---- | :---- |
|
||||||
|
| Live Artboard | A canvas surface that renders a live view from a connected application, carrying full component-tree metadata |
|
||||||
|
| Origin Graph | A directed acyclic graph tracking the provenance of every artboard and design decision |
|
||||||
|
| Intent Diff | A structured, component-level representation of design changes, expressed as props/layout/component mutations |
|
||||||
|
| Completion Zone | A designer-defined region on the canvas where AI generates or completes content within design-system constraints |
|
||||||
|
| Agent Bridge | The MCP-based bidirectional communication layer between Originmain’s design agents and external coding agents |
|
||||||
|
| Design Language File | A JSON/YAML configuration defining a team’s design system rules: tokens, component usage, accessibility requirements |
|
||||||
|
| Product Guidance File | A configuration defining screen-level design rules: which components are permitted on which screen types |
|
||||||
|
|
||||||
|
## **Appendix B: Key References**
|
||||||
|
|
||||||
|
* Microsoft Fluent 2 Design System: https://fluent2.microsoft.design
|
||||||
|
|
||||||
|
* Fluent UI React Components v9: https://react.fluentui.dev
|
||||||
|
|
||||||
|
* Model Context Protocol (MCP): https://modelcontextprotocol.io
|
||||||
|
|
||||||
|
* Daniel Bezos, “Designing for Creation” (2025): Principles on structured starting points and the blank-canvas problem
|
||||||
|
|
||||||
|
* Figma MCP Server and AI Agent Canvas: Design-code bridging via MCP (April 2026\)
|
||||||
|
|
||||||
|
* Google Stitch 2.0 (March 2026): AI-native infinite canvas with multi-screen generation
|
||||||
|
|
||||||
|
* NxCode Vibe Design Tools Report (2026): Industry analysis of AI design tool adoption
|
||||||
|
|
||||||
|
## **Appendix C: Fluent 2 Component Inventory for Originmain UI**
|
||||||
|
|
||||||
|
The following Fluent 2 components are used in Originmain’s own interface:
|
||||||
|
|
||||||
|
| Surface | Components | Library |
|
||||||
|
| :---- | :---- | :---- |
|
||||||
|
| Canvas Chrome | Toolbar, ToolbarButton, Menu, MenuButton, MenuList, MenuItem, Tab, TabList, Divider | Fluent 2 |
|
||||||
|
| Artboard Inspector | Card, CardHeader, Accordion, AccordionItem, DataGrid, DataGridRow, DataGridCell, Badge | Fluent 2 |
|
||||||
|
| Dialogs & Overlays | Dialog, DialogSurface, DialogTitle, DialogBody, DialogActions, Drawer, Popover, Tooltip | Fluent 2 |
|
||||||
|
| Inputs & Search | Input, Textarea, Combobox, Dropdown, Option, SearchBox, Switch, Checkbox, RadioGroup, Slider | Fluent 2 |
|
||||||
|
| Artboard Navigator | Tree, TreeItem, Breadcrumb, BreadcrumbItem, Nav, NavItem, Link | Fluent 2 |
|
||||||
|
| Status & Feedback | Toast, Toaster, MessageBar, Spinner, ProgressBar, Skeleton, PresenceBadge | Fluent 2 |
|
||||||
|
| Data & Layout | Table, TableHeader, TableRow, TableCell, Avatar, AvatarGroup, CounterBadge, Tag, InteractionTag | Fluent 2 |
|
||||||
|
| Codebase File Browser | FileTree (root component), git status indicators, search, virtualized list | @pierre/trees |
|
||||||
|
| Export Panel / Agent Bridge | MultiFileDiff, FileDiff (split and stacked modes), line annotations | @pierre/diffs |
|
||||||
|
|
||||||
|
*End of Document*
|
||||||
Reference in New Issue
Block a user