Project Types — Fabric’s four independent pipelines

Fabric is a multi-project-type AI builder: the user explicitly picks the target platform when creating a project in the editor, and each target platform corresponds to an independent, technology-stack-optimal pipeline.

Companion doc: fabric-ux — how the 4 project types coexist inside a single editor for editing, previewing, and debugging (“editor as remote control” principle).

Project-creation contract

The Fabric authoring surface and the target runtime being created are independent dimensions. All five authoring clients—Web, Desktop, iOS, Android, and the WeChat Mini Program—can create and manage all four project types:

Shared interaction contract:

• GET /project-types is the only source for enabled types, the default, and display order. All five clients render the returned project_types array in order and keep no client-side fallback ordering.
• The server default is Web → WeChat MP → Mobile → Desktop, with Web selected by default. Operators can change both centrally through FABRIC_PROJECT_TYPES_ORDER and FABRIC_PROJECT_TYPES_DEFAULT; the default must be enabled.
• POST /project validates runtime against the same server catalog and uses the configured default when it is unspecified, so a disabled type cannot be created by bypassing the picker.
• A project type is immutable after creation; changing type means creating a new, independent project.
• When an authoring client cannot host a runtime natively, it still exposes that type and provides an appropriate preview or release path such as a WebView, Keel Go, QR code, or target-platform toolchain.
• Enterprise, Mortar, team size, and distribution channels are capabilities or configuration, not additional project types.

Core principle: one independent pipeline per platform

One independent pipeline per target platform, technology stack = the de facto standard for that platform, AI agent uses a system prompt specialized for that stack.

What the four project types share:

• Editor UI (Fabric itself)
• AI agent infrastructure (different system prompts; model / tool calling / context management are shared)
• Mortar BaaS (auth / data / files / realtime / compute / usage — orthogonal to the frontend stack)

What the four project types don’t share:

• Source code (one per project; the AI does NOT do “cross-platform code generation”)
• Build stack
• Deployment / distribution
• Runtime
• Testing / debugging methods

Overview of the four pipelines

                    Fabric (web)
                    User picks project type
                              │
       ┌──────────┬───────────┼───────────┬──────────┐
       │          │           │           │          │
       ▼          ▼           ▼           ▼          ▼
  ┌────────┐ ┌────────┐ ┌──────────┐ ┌──────────┐ ┌──────┐
  │ Mobile │ │  Web   │ │ Desktop  │ │  WeChat  │ │ Ent. │
  │  (RN)  │ │ (Vite  │ │(Electron │ │   Mini   │ │x-cut │
  │  Keel  │ │ React) │ │  wrap    │ │  (WXML)  │ │      │
  │        │ │        │ │  web)    │ │          │ │      │
  │        │ │        │ │          │ │          │ │      │
  └────────┘ └────────┘ └──────────┘ └──────────┘ └──────┘
       │          │           │           │
       ▼          ▼           ▼           ▼
   Cloud      Static      Electron      WeChat
   Build       Deploy       Build       DevTools CLI
   + Update   (CDN/edge)  + auto-       + miniprogram-ci
       │          │       updater          │
       ▼          ▼           ▼           ▼
   Keel Go    User domain  .app/.exe/    WeChat Open Platform
   QR / scan    + SSL      .deb/.rpm     appid + review
       │          │           │           │
       └──────────┴───────────┴───────────┘
                       │
                       ▼
            ┌──────────────────────────┐
            │  Mortar BaaS (shared)    │
            │  auth · data · files ·   │
            │  realtime · compute ·    │
            │  usage                    │
            └──────────────────────────┘

Mobile (RN / Keel)

Positioning: Appunvs’s initial launch product. The crucial junction of China’s mobile-native culture and an AI builder.

Stack:

• Source: React Native + TypeScript
• Build: KAS Build (metro + Hermes bytecode)
• Distribution:
  • Dev preview: Keel Go QR-scan (the host shell instantly loads a jsbundle without recompiling a native binary)
  • Production release: the user’s host shell app (embedding the Keel SDK) + KAS Update
• Debugging: the user opens Keel Go on their own phone → scans the QR Fabric shows → second-level on-device preview
• Libraries: Tier 1 list (see keel/MODULES.md)

Why RN is irreplaceable here (not because of cross-platform, but because of host-shell instant preview):

• Native Swift/Kotlin: every code change requires recompiling a binary; App Store review is minutes-to-hours → UX collapses
• Flutter: hot reload requires an IDE attach; not a user-level “scan-and-preview” experience
• WebView wrapping a mobile webapp: not truly “debugging a mobile app inside a mobile app”
• RN + host shell (Expo Go pattern) is the only stack that achieves “AI generates code → user pulls out phone, scans QR → instant on-device debug”

Implementation status:

• ✅ host shell (iOS Swift / Android Kotlin) embeds Keel SDK
• ✅ KAS Build (metro + Docker pipeline)
• ✅ Update server (Go, includes bsdiff4 patch generation)
• ✅ Keel Go (free tester app) + Dev Client (project-specific)
• ✅ Update client SDK (TS / iOS Swift / Android Kotlin all three done)
• 🟨 Update productionized (CDN / custom domains / staged rollout, planned)

Web (Vite + React + Tailwind + shadcn/ui)

Positioning: Same battlefield as Lovable / v0 / Bolt — a web AI builder.

Three stack picks (settled):

Decided later (not in this doc’s scope — decide before Web implementation to avoid premature commitment): form library (react-hook-form / @tanstack/form), state management (Zustand / Jotai / Redux), data fetching (@tanstack/query / SWR), animation (Framer Motion), icons (lucide-react)

Deployment: vite build → dist/ static tree → Aliyun OSS + Aliyun CDN (GA mainland-focused; overseas later adds Cloudflare R2 / Fastly); preview / dev uses vite

Database / Auth / Files: connect to Mortar Cloud directly via @mortar-ai/client SDK (shares the same Mortar workspace shape as Mobile)

Libraries: the React ecosystem is fully open (npm install anything)

Implementation status: not started (kicks off after Mobile completes)

Desktop (Electron wrapping Web)

Positioning: Let Web users choose “distribute as a desktop app”.

Stack: Electron wrapping the dist/ static output from vite build.

Why Electron, not Tauri:

Tauri uses the system webview (Windows WebView2 / macOS WebKit / Linux WebKitGTK), and the three webviews behave inconsistently —

For human engineers: Tauri’s ~10 MB binary advantage over Electron’s ~150 MB is worth it; engineers can manually test on each platform and write compatibility code.

For an AI builder: the lethal problem is the AI can write code, can compile, but can’t verify.

• Tauri lacks mature cross-webview automated rendering comparison test infrastructure
• WebKitGTK silently fails on certain modern web APIs (CSS Container Queries, :has(), newer Intl APIs); the AI can’t see “silent breakage”
• Forcing the AI to write code that “works on three webviews” = writing 2–3-year-old web code, a UX regression
• LLM training corpora are heavily skewed toward Chromium-consistent cases

Electron trades ~140 MB for “one Chromium, AI-written code is trustworthy” — for an AI-generated product that’s the core trade. Tauri is fine for projects with human engineers manually testing each platform; not fine for an AI builder.

Future reversal condition: if Tauri switches to servo (the Rust browser engine Mozilla restarted in 2024) as a single-engine option, this trade-off flips. But servo is at least 2–3 years from production-ready — too long to wait.

Implementation status: not started (kicks off after Web completes; ~2–3 weeks to add Electron wrapper + auto-updater + code signing)

WeChat Mini Program (native WXML)

Reason: after Mobile / Web / Desktop cover the three mainstream forms, WeChat MP is another unavoidable pipeline for the China market — restaurant / retail / O2O merchants’ demand intensity for mini programs even exceeds native apps. Enterprise is a cross-cutting feature that can be sold on top of any Mobile / Web / Desktop / WeChat MP project type and doesn’t block WeChat MP.

Positioning: Capture China’s “use-and-go” Mini Program user base (WeChat ~1B MAU), competing in a totally different segment from Lovable / v0. Primary customer segment: Chinese ToB merchants (restaurant / retail / O2O).

Stack:

• Source: native WXML + WXSS + restricted JS (write wx.* APIs directly)
• Build: WeChat DevTools CLI + the official miniprogram-ci npm package
• Distribution: developer registers an appid → submits to WeChat review → publishes

Upload auth mechanism (miniprogram-ci official flow; Appunvs doesn’t reinvent the wheel):

1. User registers an appid on mp.weixin.qq.com (real-name / enterprise verification)
2. User goes to Development → Development Settings → Mini Program Code Upload
   • Downloads the upload key (.key private-key file, similar to an SSH key)
   • Configures an IP allowlist (must include the Appunvs build worker egress IPs)
3. User uploads appid + .key to Appunvs (encrypted at rest; only the build worker can use it)
4. Appunvs calls miniprogram-ci: signs with the .key + uploads to that appid
5. WeChat review / release flow on the WeChat Open Platform is user-triggered (Appunvs can’t intervene)

No WeChat OAuth / cookies path — WeChat Open Platform’s OAuth is for “user login” (@keel-ai/wechat), unrelated to developer permissions. Appunvs must hold the .key on the user’s behalf; there is no third-party-authorization shortcut. This matches how Aliyun / Tencent Cloud Functions and other third-parties integrate with WeChat Mini Programs.

Why not Taro / uni-app:

• Taro / uni-app are for “small/medium companies who want to take a shortcut”: write one React/Vue codebase that compiles to many platforms
• An AI builder doesn’t need shortcuts; the AI doesn’t get tired writing code, so it should produce optimal output for each platform
• Taro’s compilation is lossy, AI training data is sparse, output quality has a low ceiling

Why only WeChat for now, not Alipay / Douyin / Baidu:

• User-count order of magnitude: WeChat ~1B vs others ~500–700M
• Each Mini Program platform added = an independent pipeline + an independent AI prompt + an independent review process
• WeChat first validates as a single-platform feasibility study; expansion is a later decision

Implementation status (2026-07): GA-ready (code side). WeChat is its own authoring type types.ProjectTypeWechat (WXML/TypeScript prompt + JSON/page/tsc check_build + templates/wechatapp scaffold); miniprogram-ci runs in the harness (runner-wechat / wechat-ci.js, upload|preview) via cloudbuild.HarnessWeChatBuilder (the old WeChatMPDockerBuilder + cloud-build-wechat were retired). Publish, dev-version preview (QR), appid/.key via the unified Publish Config, and test-connectivity ship on web/iOS/Android; review is manual (self-managed model — see wechat-mp-architecture.md). The create picker now offers WeChat. The one non-code GA prerequisite is ICP filing for the Mortar API domain.

Enterprise (cross-cutting)

Positioning: a enterprise capability overlay that crosses all 4 project pipelines — NOT a new project type. Customer base: mid-to-large enterprises (restaurant / retail chains, government / enterprise customers, SaaS companies with compliance requirements).

Feature set (sold as an add-on on any Mobile / Web / Desktop / WeChat MP project type):

Why after WeChat MP, not bringing it forward: private deploy / SSO / audit log are sales tools, not product differentiators — you have to ship Mobile / Web / Desktop / WeChat MP first to prove “what an AI builder can do”, and only then is there an enterprise package worth selling. The counter-intuitive “do enterprise before mini programs” version was rejected: enterprise is cross-cutting and sold against an existing product; without WeChat MP (mini programs), you lose half the Chinese ToB market.

Implementation status: not started. Kicks off after WeChat MP; expected ~3–4 months of sustained investment.

The official websites (appunvs.com / mortar.appunvs.com / keel.appunvs.com / docs.appunvs.com) are NOT a separate project type. They’re built directly as Web projects: there are 4 special Web projects inside Fabric, each bound to one of the above domains, going through exactly the same build / deploy pipeline as any other user’s Web project. This is the purest form of dogfood. The required “custom domain → Web deploy URL” mapping is planned in a later Web iteration (B5 custom domains).

Roadmap

Each project type ships independently: mobile going live enables mobile, web going live enables web — no interdependency. Enterprise overlays on any of Mobile / Web / Desktop / WeChat MP.

Why WeChat MP comes before Enterprise

Reasons:

1. WeChat MP is the unavoidable form for the China market — restaurant / retail / O2O merchants almost exclusively ship mini programs, not native apps. Skipping WeChat MP to do Enterprise = losing half the Chinese ToB market.
2. Enterprise is a cross-cutting feature, not a new project type — Mobile / Web / Desktop / WeChat MP must first land “what an AI builder can do”; only then is there a sellable enterprise SKU. Doing Enterprise before WeChat MP = selling air.
3. After WeChat MP, enterprise customers get mobile + web + desktop + MP four project types at once, completing the sales narrative: one enterprise purchase, four shipping endpoints.
4. WeChat MP customer base highly overlaps with the enterprise customer base — having WeChat MP first gives enterprise reps an “AI can also generate mini programs” talking point, making Enterprise deals close faster.

Shared layer

What the four project types share:

1. AI agent infrastructure

• Model layer: Claude / GPT / etc. multi-provider abstraction (see fabric/server/internal/ai)
• Tool calling: generic tools like fs_write / publish_project / run_test reusable across project types
• Context management / message compaction / streaming protocol

Each project type has its own system-prompt set:

• Mobile prompt: expert in RN / Tier 1 modules / Hermes constraints / mobile UX patterns
• Web prompt: expert in Vite + React / Tailwind / shadcn/ui / web UX patterns
• Desktop prompt: expert in Electron main/renderer process separation / IPC / system integration APIs
• WeChat prompt: expert in WXML / wx.* API / mini program lifecycle / Chinese-specific UX patterns

2. Mortar BaaS

• auth / data / files / realtime / compute / usage — six capabilities common across platforms
• Each project type calls Mortar via the platform’s SDK (@mortar-ai/client for web/desktop, Mortar Swift/Kotlin SDK for mobile, wx-mortar-sdk for WeChat)
• Pricing / billing / quota dimensions are unified at the Mortar layer

3. Fabric

• Project management / Project concept / git workspace
• User accounts / billing / collaboration
• AI conversation UI

Hosting / distribution responsibility split

Where do each project type’s build artifacts get deployed? Who owns it? This is the key clarification of the two product boundaries (Appunvs vs Keel):

Key clarification: Keel has no Hosting layer (keel/docs/architecture.md top notes: Keel doesn’t target web). But Appunvs DOES have Hosting responsibility because Appunvs is broader than Keel and has to manage web/desktop project type deployments.

See architecture § Appunvs self-run hosting infrastructure.

Analogy:

• Keel ≈ Expo + EAS (mobile RN platform + 5-layer SaaS: SDK / CLI / Build / Update / Submit)
• Appunvs ≈ Lovable / v0 / Bolt (AI builder + user-app deployment hosting) — but Appunvs adds mobile / desktop / mini-program three additional project types

The two are adjacent but cleanly split: Keel owns the Mobile pipeline end-to-end (from build to OTA distribution); Appunvs owns web / desktop hosting + the cross-project-type editor + AI agent + billing.

Relationship to Keel’s positioning

Keel is the only product component Mobile uses. Keel itself remains an independent product (Apache 2.0 open source), and can be sold to any company building an RN-based mobile builder — not just Appunvs.

Web / Desktop / WeChat MP / Enterprise don’t depend on Keel:

• Web uses Vite + React + static hosting; nothing to do with Keel
• Desktop uses Electron wrapping Web; nothing to do with Keel
• WeChat uses WXML + miniprogram-ci; nothing to do with Keel
• Enterprise is cross-cutting; not tied to a specific project type
• The official websites (appunvs.com / mortar.appunvs.com / keel.appunvs.com) exist as Web projects and don’t need an independent pipeline

Keel’s market = companies in China building RN mobile builders (Appunvs as a self-user + external sales). Appunvs’s market = full-stack AI builder (consumes Keel itself for mobile, self-builds web/desktop/WeChat pipelines for the rest).

The two are decoupled, neither locks in the other.