vp development, test and build commands, and Void targets the
emitted application at Cloudflare Workers. @tuturuuu/start-bridge adapts retained
Next App Router source to that runtime.
The active migration targets each satellite separately. apps/web continues to
serve its existing Next.js routes; its separately scheduled candidate does not
change that ownership. Do not use the retired apps/tanstack-web tree or the
paused Rust backend as a template. See the
active runtime policy.
Locate the source contract
Read these files together before changing an app:
For a concrete native example, inspect Shortener’s
package scripts,
Vite configuration,
Void configuration
and owning workflow.
Its Vite configuration composes
voidPlugin(), tanstackStart(...), React and
Tailwind through the shared bridge preset. Its Void configuration selects a
Cloudflare profile, points at cloudflare/worker.ts, and binds dist/client as
ASSETS. These files are an example to read, not a universal configuration to copy.
The bridge owns next/* compatibility. Keep portable domain logic free of
Next, React Router and Cloudflare runtime imports; inject identity, storage,
navigation and localization at adapters. Keep shared data access in
packages/internal-api and client queries on TanStack Query. The
bridge contract documents aliases, request context,
API forwarding and mount behavior.
Start with an existing app or a conversion preview
For an existing native app, read its scripts before selecting a command. From the repository root, Shortener exposes these finite source checks:dev:app script invokes vp dev through the repository’s development banner;
its build and build:cloudflare scripts invoke vp build. Development servers
run only when needed for requested runtime verification. Release builds run in CI,
not on the contributor machine governed by this repository’s local build hold.
For a Next satellite conversion, inspect the generator before writing a scaffold:
--apply operation writes generated files
and installs pinned dependencies through the package manager; coordinate it with
the app’s single integration writer. Conversion creates a staging candidate and
does not authorize publication. Follow the
conversion guide for supported pages,
server actions, generated registries and unsupported route exceptions.
Preserve both mounts
A native satellite must support its subdomain andtuturuuu.com/<app>. The
migration runbook specifies TUTURUUU_BASE_PATH=/<app> for the path-mounted build.
Use bridge URL helpers and route-aware API ownership rather than hard-coding
root-relative app paths or prefixing every central API call.
The shared apex session has one writer. Mounted satellites read the session and
must not mint, refresh or clear session cookies. Treat authentication changes as
a separate reviewed task; conversion is not permission to replace identity or
data adapters. See shared session and
the mount contract.
Separate build evidence from release authority
A successfulvp build establishes that source can emit an artifact. It does
not establish provider configuration, staging acceptance or production readiness.
The reusable
native workflow
validates the exact source, checks registries, tests and types, builds the app,
validates emitted configuration, and exercises sealed and restored artifacts.
A Wrangler deploy --dry-run in validation does not publish a Worker.
Before cutover, the owning lane needs exact-commit CI, sealed emitted-Worker
acceptance, staging acceptance for primary flows and both mounts, and an immutable
rollback target with captured routing. Production publication remains governed
by the app’s explicit policy and cutover authorization. DNS, zone, canonical-route
and staging-provider changes require release-authority approval; database
migrations require explicit user approval. Never infer either from a green build.
Use the native migration runbook for the
release gates, direct cutover, one-step rollback and post-deploy watch. Consult
the app’s own runbook for its artifact helper and provider operations; there is
no single deploy command that is safe to apply to every app.
Validate a documentation contribution
Run these build-free checks from the repository root:apps/docs/docs.json, through
the current navigation owner when that file is shared. The docs wrapper selects
the pinned Mintlify and Node versions; it does not depend on an app-local docs
package. Strict Mintlify validation compiles documentation and belongs in CI.
See documenting for the complete checks
and the distinction between source validation and hosted behavior.