Quick Start

Start here when you have a fresh checkout and want to prove the source template still runs before you rename, restyle, or change product behavior.

Prerequisites

Node.js and pnpm available in the shell.
A clean enough working tree to distinguish your changes from generated output.
Cloudflare credentials only if you plan to deploy. Local source checks do not need secrets.

Install

pnpm install

Run The Local Gate

Use the full secret-free local gate before editing product behavior:

pnpm verify:local

This runs typecheck, unit tests, production build, browser E2E, smoke script syntax checks, and Worker target packaging assertions for staging and canary targets. It does not publish a Worker or call a real AI provider.

For a smaller loop while editing:

pnpm check
pnpm doctor:config
pnpm report:provider-matrix

Start The App

pnpm dev

Open the Vite URL printed by the command, normally:

http://localhost:5173

Then check the app shell:

/ renders the public product page.
The primary product workflow route loads.
The authenticated library or workspace route loads.
/ops shows only safe operational projections when enabled.
/api/health returns the configured app label and local binding status.

Local Runtime Expectations

Local development can prove route rendering, input validation, persistence, entitlement decisions, and UI handoff without real provider execution. Real AI or media execution requires the selected Cloudflare or provider target to be configured and enabled.

For local development, prefer these checks. Replace <web-package> with the web package filter used by the copied product.

pnpm test:e2e
pnpm --filter <web-package> build
pnpm --filter <web-package> exec wrangler deploy --dry-run

The dry-run validates Worker packaging only. It does not publish a URL and does not prove remote D1, R2, AI, custom domain, or Worker secret values.

Before Customization

Capture the current source posture:

pnpm report:release-status
pnpm template:scan-instance-markers
pnpm template:plan-adoption -- --manifest docs/template-adoption.manifest.example.json

In the source template, instance markers are expected because the repository still contains one concrete product implementation. In a copied product, strict marker scanning should pass only after replacement work is done.