# OpenCut Tech Reader Brief

> A fast, source-grounded read of OpenCut’s ground-up rewrite: a moonrepo monorepo with web, API, and Rust desktop surfaces, still early in scaffold relative to its editor roadmap.

## Context Links

- [Agent index](https://grok-wiki.com/public/wiki/opencut-app-opencut-2bfee888b2cd/llms.txt)
- [Human interactive wiki](https://grok-wiki.com/public/wiki/opencut-app-opencut-2bfee888b2cd)
- [GitHub repository](https://github.com/OpenCut-app/OpenCut)

## Repository Metadata

- Repository: OpenCut-app/OpenCut

- Generated: 2026-07-13T22:25:54.609Z
- Updated: 2026-07-13T22:26:26.131Z
- Runtime: Grok CLI
- Format: Tech Reader Brief
- Pages: 3

## Page Index

- 01. [Why This Repo Matters](https://grok-wiki.com/public/wiki/opencut-app-opencut-2bfee888b2cd/pages/01-why-this-repo-matters.md) - OpenCut is rebuilding a free, MIT-licensed video editor for web, desktop, and mobile. This page separates the product story from what the tree actually contains today: a multi-app monorepo shell, not a finished editor core.
- 02. [Web, API, and GPUI Desktop Under Moon](https://grok-wiki.com/public/wiki/opencut-app-opencut-2bfee888b2cd/pages/02-web-api-and-gpui-desktop-under-moon.md) - How the monorepo is wired: Vite and TanStack-style routing on web, a thin TypeScript API with health and echo routes, a Rust desktop entry on gpui, and moon/proto task orchestration across apps.
- 03. [What Builders Should Notice](https://grok-wiki.com/public/wiki/opencut-app-opencut-2bfee888b2cd/pages/03-what-builders-should-notice.md) - The surprising density of the shadcn-style UI kit versus sparse editor logic, generated route trees, Bun CI, and the real constraints: architecture still in design, classic vs rewrite split, and what is worth watching as the Rust core and plugin surface appear.

## Source File Index

- `.github/workflows/bun-ci.yml`
- `.moon/toolchains.yml`
- `.moon/workspace.yml`
- `apps/api/src/index.ts`
- `apps/desktop/Cargo.toml`
- `apps/desktop/src/main.rs`
- `apps/web/components.json`
- `apps/web/moon.yml`
- `apps/web/src/lib/utils.ts`
- `apps/web/src/router.tsx`
- `apps/web/src/routes/__root.tsx`
- `apps/web/src/routeTree.gen.ts`
- `apps/web/vite.config.ts`
- `Cargo.toml`
- `README.md`

---

## 01. Why This Repo Matters

> OpenCut is rebuilding a free, MIT-licensed video editor for web, desktop, and mobile. This page separates the product story from what the tree actually contains today: a multi-app monorepo shell, not a finished editor core.

- Page Markdown: https://grok-wiki.com/public/wiki/opencut-app-opencut-2bfee888b2cd/pages/01-why-this-repo-matters.md
- Generated: 2026-07-13T22:25:54.603Z

### Source Files

- `README.md`
- `Cargo.toml`
- `apps/web/src/router.tsx`
- `apps/api/src/index.ts`
- `apps/desktop/src/main.rs`

<details>
<summary>Relevant source files</summary>

The following files were used as context for generating this wiki page:

- [README.md](README.md)
- [Cargo.toml](Cargo.toml)
- [apps/api/src/index.ts](apps/api/src/index.ts)
- [apps/desktop/src/main.rs](apps/desktop/src/main.rs)
- [apps/web/src/router.tsx](apps/web/src/router.tsx)

</details>

# Why This Repo Matters

OpenCut’s public story is a free, MIT-licensed video editor aimed at web, desktop, and mobile. This page separates that product intent from what the tree shows today: a multi-app monorepo shell—API health endpoints, a desktop GPUI window, and a web router—while the rewrite is still being designed.

That gap is the useful signal for maintainers and observers. Classic OpenCut still ships for users; this repository is scaffolding for a ground-up rewrite, not a finished editor core.

Sources: [README.md:7-28](), [README.md:63-64](), [Cargo.toml:1-13](), [apps/api/src/index.ts:1-15](), [apps/desktop/src/main.rs:31-50](), [apps/web/src/router.tsx:1-13]()

## The product story (what the project says it is)

The README frames OpenCut as:

> A free and open source video editor for web, desktop, and mobile.

Licensing is MIT (workspace package metadata and the license badge both say so). The project states it is **being rewritten from the ground up**, with a roadmap that includes:

| Stated direction | What the README claims |
| --- | --- |
| Editor API | Coming as part of the rewrite |
| Plugins | First-class third-party plugins via a plugin-first architecture |
| Multi-platform | Desktop, mobile, and browser from one codebase (Rust core) |
| AI agents | MCP server |
| Automation | Headless mode (batch rendering) |
| In-editor scripting | A scripting tab in the editor |

Until that rewrite is ready, users are pointed at the previous product surface:

- **Classic code:** [opencut-app/opencut-classic](https://github.com/opencut-app/opencut-classic) — “the one to reach for today”
- **Production site:** [opencut.app](https://opencut.app) still runs classic
- **Rewrite preview host:** [new.opencut.app](https://new.opencut.app) until the rewrite takes over

Outside contributions are explicitly paused while architecture is designed; Discord and issues are the stated ways to follow along.

Sources: [README.md:7-28](), [README.md:51-52](), [README.md:63-64](), [Cargo.toml:7-10]()

## What the tree actually contains today

The evidence is not an editor implementation. It is a thin multi-surface shell with three runnable app shapes and a minimal Rust workspace.

```text
OpenCut monorepo (evidence snapshot)
├── Product claim: free FOSS editor (web / desktop / mobile)
│
├── apps/web     → TanStack Router bootstrap
├── apps/api     → Elysia + Cloudflare Worker (health / echo)
├── apps/desktop → GPUI window: "desktop shell scaffold"
│
└── Cargo.toml   → workspace members: apps/desktop only
                    gpui 0.2.2; package version 0.1.0; MIT
```

### Development surface

Root tooling expects [proto](https://moonrepo.dev/proto) and moon targets:

| Command | Role (as documented) |
| --- | --- |
| `proto use` | Install tools pinned in `.prototools` |
| `moon run web:dev` | Web app on localhost:5173 |
| `moon run api:dev` | API on localhost:8787 |
| `moon run desktop:dev` | Desktop app (see `apps/desktop/README.md`) |

Those commands describe how to run the shells; they do not imply editor features exist in the sources below.

Sources: [README.md:31-48]()

### Web: router shell

`apps/web` evidence is a TanStack React Router factory: route tree import, scroll restoration, intent preload. There is no timeline, media pipeline, or editor UI in this file—only app routing infrastructure.

```4:12:apps/web/src/router.tsx
export function getRouter() {
  const router = createTanStackRouter({
    routeTree,
    scrollRestoration: true,
    defaultPreload: 'intent',
    defaultPreloadStaleTime: 0,
  })

  return router
}
```

Sources: [apps/web/src/router.tsx:1-19]()

### API: health and echo only

`apps/api` is an Elysia app on the Cloudflare Workers adapter. Endpoints are:

- `GET /` → `{ status: "ok" }`
- `GET /health` → healthy flag + ISO timestamp
- `POST /echo` → body echo with a typed `{ message: string }`

There is no media upload, project API, auth, or render job surface in this file—only a compile-ready worker scaffold.

Sources: [apps/api/src/index.ts:1-15]()

### Desktop: GPUI placeholder window

The Rust workspace lists a single member, `apps/desktop`, with workspace dependency `gpui = "0.2.2"`, package version `0.1.0`, edition `2024`, license MIT.

The desktop binary opens a 960×600 window titled “OpenCut” and renders a centered label plus status text **`"desktop shell scaffold"`**—an explicit admission that this is a shell, not the editor.

```31:50:apps/desktop/src/main.rs
fn main() {
    Application::new().run(|cx: &mut App| {
        // ...
                cx.new(|_| Root {
                    status: "desktop shell scaffold".into(),
                })
        // ...
    });
}
```

Sources: [Cargo.toml:1-13](), [apps/desktop/src/main.rs:6-50]()

## Vision vs. implementation gap

```text
README roadmap                          Evidence in this snapshot
─────────────────                       ─────────────────────────
Editor API                              API: / , /health , /echo
Plugin-first architecture               Not present in supplied sources
Rust core, multi-platform               Cargo workspace: desktop only
MCP server                              Not present
Headless / batch rendering              Not present
In-editor scripting tab                 Not present
Working video editor for users today    Classic repo / opencut.app (external)
```

The monorepo’s value today is **layout and tooling**: named `web`, `api`, and `desktop` surfaces, moon/proto workflow, MIT metadata, and a GPUI desktop entry point. It is not evidence of a shared media engine, plugin host, or MCP layer—those remain stated goals, not inspected code.

Sources: [README.md:17-28](), [apps/api/src/index.ts:4-15](), [Cargo.toml:1-5](), [apps/desktop/src/main.rs:44-46]()

## Why this still matters

1. **Honest rewrite posture.** The project does not pretend the new tree is production-ready; classic stays the daily driver while architecture is designed.
2. **License and scope clarity.** MIT + multi-app layout signal an intended open, multi-surface product—even while contribution gates are closed during design.
3. **Scaffold as architecture signal.** Separate web (TanStack), API (Elysia/Cloudflare), and desktop (GPUI/Rust) targets match the “one product, many surfaces” story without yet proving a shared Rust editor core across all of them (Cargo members only list desktop).
4. **Builder takeaway.** Treat this repo as **infrastructure for a future core**, not as a drop-in CapCut/Premiere alternative. For shipping behavior today, the README itself points elsewhere (classic).

Sources: [README.md:17-28](), [README.md:51-52](), [Cargo.toml:1-10]()

## What remains unknown (from this evidence alone)

The supplied sources do not show: timeline/media engines, shared packages beyond the desktop workspace member list, mobile targets, plugin interfaces, MCP handlers, headless render paths, auth/data models, or how `web`/`api`/`desktop` will share a Rust core. Those are open design questions, not established facts here.

## Summary

OpenCut matters as an MIT-licensed, multi-platform video-editor *ambition* with a clear rewrite narrative and a classic product still serving users. In the tree captured by this evidence, it is a monorepo shell: moon-driven `web`/`api`/`desktop` apps, a minimal Cloudflare/Elysia API, a GPUI desktop window labeled as scaffold, and a Cargo workspace that currently owns only the desktop app. Read the README for product direction; read `apps/*` and `Cargo.toml` for what exists—and keep those two layers separate when reasoning about readiness or contributions.

Sources: [README.md:7-28](), [Cargo.toml:1-13](), [apps/api/src/index.ts:1-15](), [apps/desktop/src/main.rs:31-50](), [apps/web/src/router.tsx:1-13]()

---

## 02. Web, API, and GPUI Desktop Under Moon

> How the monorepo is wired: Vite and TanStack-style routing on web, a thin TypeScript API with health and echo routes, a Rust desktop entry on gpui, and moon/proto task orchestration across apps.

- Page Markdown: https://grok-wiki.com/public/wiki/opencut-app-opencut-2bfee888b2cd/pages/02-web-api-and-gpui-desktop-under-moon.md
- Generated: 2026-07-13T22:25:29.665Z

### Source Files

- `apps/web/src/routes/__root.tsx`
- `apps/web/vite.config.ts`
- `apps/api/src/index.ts`
- `apps/desktop/src/main.rs`
- `apps/desktop/Cargo.toml`
- `.moon/workspace.yml`

<details>
<summary>Relevant source files</summary>

The following files were used as context for generating this wiki page:

- [.moon/workspace.yml](.moon/workspace.yml)
- [apps/api/src/index.ts](apps/api/src/index.ts)
- [apps/desktop/Cargo.toml](apps/desktop/Cargo.toml)
- [apps/desktop/src/main.rs](apps/desktop/src/main.rs)
- [apps/web/src/routes/__root.tsx](apps/web/src/routes/__root.tsx)
- [apps/web/vite.config.ts](apps/web/vite.config.ts)

</details>

# Web, API, and GPUI Desktop Under Moon

OpenCut’s monorepo is not one fat app—it is three thin runtimes under a shared workspace root. Moon discovers projects under `apps/*`. The web client is a Vite + TanStack Start stack aimed at Cloudflare SSR. The API is a small Elysia service with health and echo routes. The desktop binary is a GPUI “shell scaffold” that opens a window and paints a title. Understanding that split is the difference between hunting for features that do not exist yet and reading the wiring as it actually is.

This page maps how those pieces are declared and connected: workspace discovery, web plugins and root route shell, API surface, and the desktop entrypoint. It stays on what the source shows—no assumed product depth, auth model, or shared library layer beyond what is present.

Sources: [.moon/workspace.yml:1-6](), [apps/web/vite.config.ts:1-21](), [apps/api/src/index.ts:1-15](), [apps/desktop/src/main.rs:31-50]()

## Page shape

| Aspect | Value |
|--------|--------|
| Classification | Architecture pattern (monorepo app surfaces + orchestration) |
| Scope | Workspace discovery, web/API/desktop entry wiring |
| Non-goals | Feature inventory of the editor, deployment runbooks, CI, shared crates (not in evidence) |
| Source of truth | Repository files listed above |

## Why the monorepo layout matters

Moon’s workspace config is deliberately minimal: discover every project under `apps/*`. A comment leaves room for a future `crates/*` glob when shared Rust crates appear—those are not registered today. That means the current “system” is three app packages side by side, not a deep crate graph.

```text
.moon/workspace.yml
        │
        ▼  projects: apps/*
┌───────────────┬───────────────┬────────────────┐
│  apps/web     │  apps/api     │  apps/desktop  │
│  Vite/TanStack│  Elysia + CF  │  GPUI binary   │
│  React Start  │  Worker adapter│  opencut-desktop│
└───────────────┴───────────────┴────────────────┘
```

Sources: [.moon/workspace.yml:1-6]()

## System map

```mermaid
flowchart TB
  subgraph moon_ws["Moon workspace"]
    WS[".moon/workspace.yml<br/>projects: apps/*"]
  end

  subgraph web_layer["apps/web"]
    VITE["vite.config.ts"]
    ROOT["routes/__root.tsx"]
    VITE --> ROOT
  end

  subgraph api_layer["apps/api"]
    API["src/index.ts<br/>Elysia + CloudflareAdapter"]
  end

  subgraph desktop_layer["apps/desktop"]
    CARGO["Cargo.toml<br/>opencut-desktop"]
    MAIN["src/main.rs<br/>GPUI Application"]
    CARGO --> MAIN
  end

  WS --> web_layer
  WS --> api_layer
  WS --> desktop_layer
```

Sources: [.moon/workspace.yml:3-6](), [apps/web/vite.config.ts:10-18](), [apps/api/src/index.ts:1-5](), [apps/desktop/Cargo.toml:1-13]()

---

## Moon workspace discovery

`.moon/workspace.yml` points at the Moon schema and lists a single project glob:

| Setting | Value | Notes |
|---------|--------|--------|
| Schema | `https://moonrepo.dev/schemas/workspace.json` | Declared at top of file |
| Projects | `apps/*` | Auto-discover apps |
| Future | `crates/*` | Mentioned in comment only; not configured |

There is no further task graph, toolchain pin, or proto config in this evidence block. Orchestration *around* apps is implied by Moon’s role as workspace root; the concrete app behavior lives in each `apps/*` tree.

Sources: [.moon/workspace.yml:1-6]()

---

## Web: Vite, Cloudflare SSR, TanStack Start

### Build and plugin stack

`apps/web/vite.config.ts` composes a Cloudflare-oriented Start app:

| Plugin / option | Role in config |
|-----------------|----------------|
| `resolve.tsconfigPaths: true` | Path resolution via tsconfig |
| `@tanstack/devtools-vite` (`devtools()`) | Devtools Vite integration |
| `@cloudflare/vite-plugin` with `viteEnvironment: { name: 'ssr' }` | Cloudflare SSR environment |
| `@tailwindcss/vite` | Tailwind |
| `@tanstack/react-start/plugin/vite` (`tanstackStart()`) | TanStack Start |
| `@vitejs/plugin-react` (`viteReact()`) | React |

Order in source: `devtools` → `cloudflare` → `tailwindcss` → `tanstackStart` → `viteReact`.

Sources: [apps/web/vite.config.ts:1-21]()

### Root route and document shell

The TanStack root route (`createRootRoute`) owns document head and the HTML shell:

- **Meta:** `utf-8`, viewport, title `OpenCut rewrite | beta.opencut.app`
- **Links:** favicon, Google Fonts preconnects, Playfair Display stylesheet, app CSS via `../styles.css?url`
- **Shell:** `RootDocument` renders `<html lang="en">`, `HeadContent`, body with `TooltipProvider` wrapping `{children}`, TanStack Devtools (bottom-right, Router panel), and `Scripts`

That is a classic Start/router pattern: root route defines the document chrome; child routes (not shown in evidence) would render inside `{children}`.

```tsx
// apps/web/src/routes/__root.tsx (excerpt)
export const Route = createRootRoute({
  head: () => ({
    meta: [
      { charSet: 'utf-8' },
      { name: 'viewport', content: 'width=device-width, initial-scale=1' },
      { title: 'OpenCut rewrite | beta.opencut.app' },
    ],
    // links: favicon, fonts, appCss ...
  }),
  shellComponent: RootDocument,
})
```

Sources: [apps/web/src/routes/__root.tsx:1-75]()

### What builders should notice (web)

- The stack is **TanStack Start + React + Tailwind + Cloudflare SSR**, not a plain CRA or Next.js layout.
- Document title and font choices are already product-branded in the root route; CSS enters as a Vite `?url` stylesheet link.
- Devtools are first-class (Vite plugin + in-page TanStack Devtools with Router panel).

Sources: [apps/web/vite.config.ts:10-18](), [apps/web/src/routes/__root.tsx:8-70]()

---

## API: thin Elysia surface on Cloudflare Workers

`apps/api/src/index.ts` exports a single Elysia app with `CloudflareAdapter`. Routes are intentionally small:

| Method | Path | Behavior |
|--------|------|----------|
| `GET` | `/` | `{ status: "ok" }` |
| `GET` | `/health` | `{ healthy: true, timestamp: <ISO string> }` |
| `POST` | `/echo` | Echoes validated body; body schema `{ message: string }` |

The file ends with `.compile()`, with a comment that compile is required and triggers AoT compilation at startup.

```ts
// apps/api/src/index.ts (structure)
export default new Elysia({ adapter: CloudflareAdapter })
  .get("/", () => ({ status: "ok" }))
  .get("/health", () => ({ healthy: true, timestamp: new Date().toISOString() }))
  .post("/echo", ({ body }) => body, {
    body: t.Object({ message: t.String() }),
  })
  .compile();
```

There is no auth middleware, database client, or OpenCut domain model in this file—only health-style and echo endpoints suitable as a Worker skeleton.

Sources: [apps/api/src/index.ts:1-15]()

---

## Desktop: GPUI binary shell

### Package and binary

`apps/desktop/Cargo.toml` defines package `opencut-desktop` (“OpenCut desktop app, built with GPUI”), workspace-inherited `version` / `edition` / `license`, binary name `opencut-desktop` at `src/main.rs`, and a single dependency: `gpui` from the workspace.

Sources: [apps/desktop/Cargo.toml:1-13]()

### Window and UI scaffold

`main.rs` runs a GPUI `Application`, opens a centered windowed bounds of **960×600**, titlebar title **OpenCut**, and mounts a `Root` view whose status string is **`desktop shell scaffold`**.

`Root` implements `Render`: full-size flex column, centered, background `0x111111`, white title text “OpenCut”, secondary gray status line.

```rust
// apps/desktop/src/main.rs (excerpt)
cx.new(|_| Root {
    status: "desktop shell scaffold".into(),
})
```

This is an empty product shell: no editor canvas, no IPC to the API or web app, no feature UI beyond branding and status text.

Sources: [apps/desktop/src/main.rs:1-51]()

---

## Cross-surface comparison

| Surface | Runtime / stack | Entry | Maturity signal in evidence |
|---------|-----------------|-------|------------------------------|
| Web | Vite, TanStack Start/React Router, Tailwind, Cloudflare SSR | `vite.config.ts` + `routes/__root.tsx` | Document shell, fonts, devtools, rewrite title |
| API | Elysia + Cloudflare Worker adapter | `src/index.ts` default export | Health + typed echo only |
| Desktop | Rust GPUI | `opencut-desktop` → `main.rs` | Explicit “shell scaffold” status |
| Workspace | Moon | `projects: apps/*` | Apps only; crates glob deferred |

Shared theme: **Cloudflare appears on web (Vite plugin) and API (Worker adapter)**; desktop is native GPUI and does not share that path in the evidence.

Sources: [apps/web/vite.config.ts:8-16](), [apps/api/src/index.ts:1-5](), [apps/desktop/Cargo.toml:8-13](), [.moon/workspace.yml:5-6]()

---

## Tradeoffs and open questions

**What the layout buys you**

- Clear ownership boundaries: web UI, edge API stub, desktop binary can evolve on different cadences under one Moon discovery rule.
- Edge-oriented TypeScript (Elysia + Cloudflare adapter; Vite Cloudflare SSR) pairs with a separate native GPUI experiment rather than forcing one UI kit everywhere.

**What the evidence does not show**

- Moon task definitions, proto toolchains, or how `moon run` invokes each app
- Shared packages/crates (the workspace comment anticipates `crates/*` later)
- Any HTTP client from web/desktop to the API, or auth/CORS/env config
- Child web routes, editor UI, or desktop features beyond the scaffold window

Treat those as unknown until other wiki pages or files supply them—not as implied architecture.

---

## Plan sketch for extenders

If you are adding a surface feature without inventing structure outside this wiring:

| Concern | Guidance grounded in current layout |
|---------|-------------------------------------|
| Scope | Touch one of `apps/web`, `apps/api`, or `apps/desktop` unless you intentionally introduce shared crates (would require workspace glob changes per the comment) |
| Non-goals | Do not assume the API is a full backend; it is health/echo today |
| Risks | Coupling web and API only on Cloudflare assumptions without shared contracts; desktop remains isolated GPUI |
| Smoke checks | Web root title/devtools shell loads; `GET /` and `/health`, `POST /echo` with `{ "message": "..." }`; desktop opens titled window with scaffold status |

Sources: [.moon/workspace.yml:3-6](), [apps/api/src/index.ts:4-13](), [apps/desktop/src/main.rs:44-46]()

---

## Summary

Under Moon, OpenCut is three apps: a **Vite + TanStack Start** web shell with Cloudflare SSR and a document root at `__root.tsx`; a **thin Elysia API** on `CloudflareAdapter` with `/`, `/health`, and typed `/echo`; and a **GPUI desktop** binary that only claims to be a shell scaffold. The workspace discovers `apps/*` and leaves room for future `crates/*`. Builders should read this as orchestration of entrypoints, not as a finished multi-platform product stack—and extend from those files rather than from assumptions about unlisted layers.

---

## 03. What Builders Should Notice

> The surprising density of the shadcn-style UI kit versus sparse editor logic, generated route trees, Bun CI, and the real constraints: architecture still in design, classic vs rewrite split, and what is worth watching as the Rust core and plugin surface appear.

- Page Markdown: https://grok-wiki.com/public/wiki/opencut-app-opencut-2bfee888b2cd/pages/03-what-builders-should-notice.md
- Generated: 2026-07-13T22:25:26.380Z

### Source Files

- `apps/web/src/lib/utils.ts`
- `apps/web/components.json`
- `apps/web/src/routeTree.gen.ts`
- `.github/workflows/bun-ci.yml`
- `apps/web/moon.yml`
- `.moon/toolchains.yml`

<details>
<summary>Relevant source files</summary>

The following files were used as context for generating this wiki page:

- [.github/workflows/bun-ci.yml](.github/workflows/bun-ci.yml)
- [.moon/toolchains.yml](.moon/toolchains.yml)
- [apps/web/components.json](apps/web/components.json)
- [apps/web/moon.yml](apps/web/moon.yml)
- [apps/web/src/lib/utils.ts](apps/web/src/lib/utils.ts)
- [apps/web/src/routeTree.gen.ts](apps/web/src/routeTree.gen.ts)

</details>

# What Builders Should Notice

OpenCut’s web surface looks product-ready at the edges and thin in the middle. The repo already wires a full shadcn-style UI kit, TanStack-generated routing, Bun under moon, multi-OS CI, and a declared Rust toolchain—yet the generated route tree still only exposes `/`. That contrast is the useful signal: tooling and design system density are ahead of application surface area.

This page is for builders skimming the repo for leverage points. It separates what is already concrete (UI kit config, route generation, CI, toolchains) from what is only scaffolded or absent in the evidence (editor depth, multi-page product routes, a visible Rust core). The goal is accurate expectations, not a roadmap claim.

## The density mismatch: UI kit vs app surface

### A complete shadcn-style kit configuration

`apps/web/components.json` is not a stub. It pins style (`base-mira`), TSX, Tailwind CSS variables on neutral, Hugeicons, path aliases for components/utils/ui/lib/hooks, and menu accent settings. That is the full shadcn registry shape: enough structure to grow a large component library without re-deciding layout conventions.

```json
{
  "style": "base-mira",
  "rsc": false,
  "tsx": true,
  "tailwind": {
    "css": "src/styles.css",
    "baseColor": "neutral",
    "cssVariables": true
  },
  "iconLibrary": "hugeicons",
  "aliases": {
    "components": "#/components",
    "utils": "#/lib/utils",
    "ui": "#/components/ui",
    "lib": "#/lib",
    "hooks": "#/hooks"
  }
}
```

Sources: [apps/web/components.json:1-25]()

The classic `cn` helper is present—`clsx` + `tailwind-merge`—the standard glue for conditional Tailwind class composition in this stack.

Sources: [apps/web/src/lib/utils.ts:1-6]()

### Sparse product routing

By contrast, TanStack Router’s generated tree is minimal. `routeTree.gen.ts` is machine-owned (“you should NOT make any changes”) and currently wires only the index route under root:

| Route id | Path | Role in generated tree |
| --- | --- | --- |
| `__root__` | (parent) | Root route import |
| `/` | `/` | Sole file child |

`FileRoutesByFullPath`, `fullPaths`, and `to` all resolve to `'/'` only. The module also registers SSR and the app router with `@tanstack/react-start` (`ssr: true`). That is real stack commitment; it is not a multi-screen editor shell in the generated graph.

Sources: [apps/web/src/routeTree.gen.ts:7-18](), [apps/web/src/routeTree.gen.ts:20-37](), [apps/web/src/routeTree.gen.ts:57-68]()

```text
UI kit config (components.json + cn)
        dense: style, aliases, icons, CSS vars
                    │
                    ▼
        apps/web application layer
                    │
        routeTree.gen.ts ── only '/' + __root__
                    │
        (editor / multi-route product logic:
         not shown in this evidence set)
```

**Builder takeaway:** do not equate “shadcn + TanStack Start wired” with “editor architecture is settled.” The kit can absorb many components while the route graph stays a single page.

## Tooling that is already production-shaped

### Bun + moon as the web project contract

`apps/web` is a TypeScript **application** layer project under moon. Tasks map straight to Bun scripts:

| Task | Command | CI / cache notes |
| --- | --- | --- |
| `dev` | `bun run dev` | `runInCI: false` — skipped in CI, not cached as a server |
| `build` | `bun run build` | Inputs: `src/**/*`, `public/**/*`, Vite/TS configs; output `dist` |
| `test` | `bun run test` | Inputs: `src/**/*`, `tsconfig.json` |
| `deploy` | `bun run deploy` | Depends on `~:build` |

Sources: [apps/web/moon.yml:1-32]()

### Repo-level toolchains

Moon enables JavaScript alongside Bun (version **1.3.11**, auto-install deps on lockfile/manifest change) and declares an empty Rust toolchain block whose version is inherited from `.prototools` (referenced in comment only; that file is not in this evidence).

Sources: [.moon/toolchains.yml:1-12]()

### Bun CI matrix

GitHub Actions workflow **Bun CI** runs on `main` pushes and PRs, ignores `*.md` path changes, uses a concurrency group per ref with cancel-in-progress, checks out with full history (`fetch-depth: 0`), sets up moonrepo’s toolchain installer, and runs `moon ci` on **ubuntu-latest**, **windows-latest**, and **macos-latest**.

Sources: [.github/workflows/bun-ci.yml:1-37]()

```text
push/PR → main (ignore *.md)
              │
              ▼
     matrix: Linux / Windows / macOS
              │
     moonrepo/setup-toolchain
              │
           moon ci
              │
     (web tasks per moon.yml; rust toolchain declared)
```

**Builder takeaway:** CI and package-manager story are not experimental side scripts. Cross-OS `moon ci` is the gate; Markdown-only changes skip it.

## What the evidence does *not* settle

Stay honest about absences. In this evidence set you **cannot** verify:

- A multi-route product or editor workspace layout (generated routes stop at `/`)
- Implementation of a Rust media/editor core (only `rust: {}` in toolchains)
- A classic-vs-rewrite code split, plugin API, or architecture decision docs
- Security, performance, or shipping status of deploy beyond the task wiring

Those may exist elsewhere in the monorepo; they are simply not part of the record used for this page. Treat “architecture still in design” as a reading of **sparsity in app surface relative to tooling**, not as a quoted project status.

## What is worth watching next

| Signal | Why it matters | Where it would show up first |
| --- | --- | --- |
| Route tree growth | Product surface expanding beyond a single index | New entries in `routeTree.gen.ts` / `routes/*` |
| UI components under aliases | Kit filling out vs remaining config-only | `#/components/ui` and related paths from `components.json` |
| Rust projects in moon | Core leaving “toolchain declared” | moon projects + non-empty Rust tasks (not in this evidence) |
| CI task composition | What `moon ci` actually enforces as the app grows | Workflow stays thin; project `moon.yml` tasks are the real surface |
| Deploy dependency chain | Ship path remains build-then-deploy | `deploy` → `~:build` in `apps/web/moon.yml` |

For integration work (e.g. wiki or agent skill packs against this repo), keep the design **provider-neutral**: treat skill packs and docs as portable file/repo/catalog inputs; use repository code (`moon.yml`, toolchains, generated routes, UI config) as the source of truth for implementation claims.

## Summary

Builders should notice the **asymmetric maturity**: shadcn-style kit config and `cn` utility, TanStack Start SSR registration, Bun 1.3.11 under moon, and three-OS Bun CI are already in place, while the generated route tree remains a single `/` and Rust appears only as a toolchain declaration. Read density in tooling and UI conventions as readiness to grow a frontend; do not read it as proof of a finished editor core or multi-surface product graph until those show up in code the same way the kit and CI already do.

---