Course Video Manager

A tool for managing course video publishing workflows — editing metadata, generating descriptions, creating thumbnails, and posting to social platforms.

Repository layout

A Turborepo monorepo over the pnpm workspace:

Directory	What it is
apps/local	The application as it runs on the author's machine: the React Router app, the Video Editor, the Diagram Playground, the Publish flow, ffmpeg, the recorder service, and the cvm CLI
packages/core	The domain database — the Drizzle schema, the DrizzleService and every db-* operations service. Every piece of SQL in the repo lives here
packages/overlay-renderer	The standalone Remotion renderer for every overlay content-kind — subtitles, Chat Cards, Calls to Action and Definition Cards — with its own toolchain

packages/core has no filesystem access, no child_process and no git coupling, so it can be deployed as well as run locally. pnpm lint:boundaries enforces that — anything that needs a machine is injected from apps/local (see packages/core/services/diagram-thumbnail-store.ts for the shape).

.env lives at the workspace root: one file for the whole monorepo, which is also where cvm looks for it (apps/local/app/cli/env.ts).

Commands

Run these from the workspace root; Turborepo fans them out and re-runs only what changed.

Script	Description
pnpm typecheck	Typecheck every package
pnpm test	Run every suite once
pnpm test:watch	Run every suite in watch mode
pnpm lint:boundaries	Enforce the package boundaries
pnpm dev	Start the local application
pnpm build	Build the local application

Each of these filters out @cvm/overlay-renderer: it ships its own toolchain (Remotion, and a Chromium download) and has never been part of the application's checks. Run it with pnpm --filter @cvm/overlay-renderer.

Deploys

Vercel gets one project per deployable directory, each with its own Root Directory, and relies on Vercel's built-in unaffected-project skipping to decide what to deploy. There is deliberately no Ignored Build Step: turbo-ignore is deprecated, and native skipping does not consume a concurrent build slot. If a custom step is ever needed it is turbo query affected.

Only main deploys. apps/remote/vercel.json sets git.deploymentEnabled to { "**": false, "main": true }, so a push to any other branch builds nothing: no Preview Deployment for an open PR. Production still deploys on a merge to main, because a branch that matches two rules deploys if either one is true. The pattern is ** and not *, as * does not match a slash and a feat/thing branch would still deploy. This is the supported per-branch control — Vercel's dashboard has no equivalent, and the repo takes no Ignored Build Step.

Database migrations

Schema changes are managed with drizzle-kit generate / migrate (versioned SQL files), not push. The schema, the migrations and the drizzle config all live in packages/core.

Making a schema change

1. Edit packages/core/db/schema.ts.
2. pnpm db:generate — creates a new numbered .sql file under packages/core/db/migrations/.
3. Commit it and open a PR. Matt merges it, and merging runs it: the apps/remote production build backs production up on PlanetScale, waits, then migrates (#2655). Preview builds never migrate. See apps/remote/README.md and ADR 0026.

Against any non-local host, pnpm db:migrate (and drizzle-kit push) refuses unless you are on a clean main at exactly origin/main — an unmerged branch once migrated production out of order. Merge first, then migrate from the main checkout. Local databases are never checked. See the ADR 0026 addendum.

Migrations are additive-only: no dropped or renamed columns without a two-step release. A cvm invocation may be in flight while a deploy lands, and it is the additive rule — not the version gate — that keeps that from breaking. The version gate refuses the box's next command, naming both migration counts and telling it to pull (packages/core/rpc/schema-version.ts).

First-time setup on an existing database

If the database was originally created via drizzle-kit push and has never run migrations:

pnpm db:baseline

This registers the 0000 baseline migration as already-applied so the next pnpm db:migrate won't replay the initial CREATE TABLE statements.

This is the beginning of the README. Read the rest at the original. Read the full README ↗