@mediamonks/canopy-cli 0.7.11 → 0.7.12

package/dist/docs/platform-feedback.md

@@ -1,114 +0,0 @@
----
-title: Feedback & bug reports
-description: A built-in feedback widget on every project, a ticket-lite inbox behind it, and a CLI that lets agents work the backlog.
----
-
-Every Canopy project gets an in-app feedback channel without writing a line of
-code: signed-in Monks see a small floating button on the live app, pick **Bug**
-or **Feedback**, type what happened, and send. The report lands in the
-project's **Feedback tab** on the dashboard, with everything an investigator
-needs captured automatically — page URL, the deploy version that served it,
-viewport, and recent console errors.
-
-It is deliberately **not** a ticketing product: an item has a status, an
-append-only comment trail, and nothing else. No assignees, priorities, or
-boards.
-
-## The widget
-
-- Appears only for **signed-in Monks**. Client-password visitors never see it —
-  the platform doesn't even send them the script.
-- On by default for every project. Turn it off per project in
-  **Settings → Feedback widget**; the change applies on the next page load.
-- Submissions are always identified (your company sign-in), so there's no
-  anonymous spam and no reporter field to fill in.
-- The widget also shows your own previous reports for that project with their
-  current status.
-- A page can reshape the chooser with meta tags — this docs site does exactly
-  that: `<meta name="canopy-feedback-kinds" content="docs,feedback">` swaps
-  "Bug" for "Docs issue", and `canopy-feedback-prompt` replaces the textarea
-  placeholder. Kinds are limited to `bug`, `feedback`, `docs`.
-
-## Screenshots
-
-A screenshot is often the whole report, so you can attach up to six to any
-report:
-
-- **In the widget:** click **Attach screenshot**, or paste one straight from
-  the clipboard into the message box, or drop an image on the panel. Thumbnails
-  show what will be sent, and each one can be removed before you hit Send.
-- **On the dashboard:** the same three ways, from the report itself — so you can
-  add a picture to a report after filing it, or to a comment as you write it
-  ("here's what it looks like after the fix"). Click any thumbnail for the full
-  image, then use the arrow keys to page through the rest.
-- **From the CLI:** `canopy feedback report "…" --attach ./shot.png`, or
-  `canopy feedback attach <id> ./after-fix.png` for a report that already
-  exists. `canopy feedback show <id> --download <dir>` saves a report's
-  screenshots so an agent can look at them.
-
-PNG, JPEG, WebP and GIF, up to 5 MB each. Large screenshots are scaled down in
-your browser before they're sent, so a full-screen retina capture goes up small
-without you doing anything. Screenshots are visible to the same people as the
-report itself, and are deleted with it.
-
-## The inbox
-
-Project members triage reports on the **Feedback tab**:
-
-- Statuses: `investigate → investigated → accepted → in_progress → resolved`,
-  plus `declined`.
-- Everything arrives as **investigate** — nobody has looked at it yet. An agent
-  can pick those up, work out what is actually going on, and write the findings
-  on the report as **investigated**.
-- **`accepted` means a person said "build this."** It is the one status an
-  agent should never reach for on its own.
-- The order is a suggestion, not a track. Accept something straight away, skip
-  the investigation, or decline it at any point.
-- Every status change and comment is recorded on the item's trail.
-- Reporters follow their submissions on the **Reports page** (dashboard
-  header) and can comment on or withdraw their own items; only project
-  members change statuses.
-
-## Working the backlog with an agent
-
-Because the CLI exposes the inbox, "look into the new reports" and "work
-through the accepted feedback" are both prompts, not processes:
-
-```bash
-canopy feedback list --status investigate      # what nobody has looked at yet
-canopy feedback show <id>                      # body + captured context + trail
-canopy feedback status <id> investigated \
-  --comment "root cause: the upload grant expires too early"
-canopy feedback list --status accepted         # what a person asked for
-canopy feedback status <id> resolved --comment "fixed in v42"
-```
-
-`investigated` always carries the findings — the note is required, because a
-report that claims someone looked into it and shows nothing is worse than an
-untouched one. Then it waits: **accepting is the person's call**, so an agent
-sets `accepted` only when the person it is working with says to build the
-thing.
-
-`show` includes the deploy version that served the page when the bug was
-reported — reproduce against that, not whatever is live now. A report worth
-pushing back on gets `status <id> declined` with a comment saying why.
-
-## Reporting problems with Canopy itself
-
-When a `canopy` command fails while you (or your agent) are building a
-project, file it against the **platform inbox** — not your own project:
-
-```bash
-canopy feedback report "deploy failed after upload" \
-  --command "canopy deploy --staging" --error "upload_grant_expired …"
-```
-
-With no `--project`, the report goes to the platform team automatically, with
-your CLI version, site, and the project you were working on attached. Before
-filing: rule out user error first (`canopy docs troubleshooting`,
-`vp env doctor` for toolchain issues), and skim `canopy feedback mine` to
-avoid filing the same issue twice.
-
-## CLI reference
-
-See [canopy feedback](https://docs.canopy.website/cli/feedback) for every subcommand and flag.

package/dist/docs/platform-members-and-access.md

@@ -1,71 +0,0 @@
----
-title: Members & access
-description: Everything on Canopy sits behind Monks sign-in. Collaborators manage a project; other Monks can view the live app — unless you tighten it.
----
-
-Nothing on Canopy is reachable by the anonymous internet. Every project URL
-and the dashboard itself sit behind Monks OneLogin — visitors sign in with
-their company account before they see anything. On top of that wall, each
-project has its own roster that decides who can _manage_ it and, optionally,
-who can _view_ it.
-
-## The default: any Monk can look, members can manage
-
-Out of the box:
-
-- **Any signed-in Monk** can open a project's live URL and see the app. The
-  project also appears in the company-wide list on the dashboard.
-- **Only the project's members** (and platform admins) can open its
-  management pages — deploy history, data browser, usage, and settings.
-
-That default fits most internal work: colleagues can try what you built, but
-nobody outside the team can touch its data or settings.
-
-## Roles
-
-- **Owner** — the person who created the project. Owners govern it: they
-  invite and remove collaborators, change access settings, and can delete
-  the project.
-- **Collaborator** — invited teammates. They can do day-to-day work — deploy,
-  roll back, browse and edit data, manage schedules and secrets — but not
-  delete the project or manage its roster.
-- **Platform admin** — can manage any project from the dashboard. Admins keep
-  governance access, but they do not silently bypass a collaborators-only
-  live app (see below).
-
-## Inviting collaborators
-
-Open the project's **Settings** tab and use the **Collaborators** card. A
-searchable people picker finds anyone who has signed in to Canopy; adding
-them takes effect immediately. Owners (and admins) can also remove people
-from the same card.
-
-## Collaborators-only mode
-
-Sometimes "any Monk can look" is too open — payroll prototypes, sensitive
-client work, unfinished things you'd rather not demo by accident. Flip on
-**Settings → Who at Monks can open it → Restrict to collaborators** and the
-live app is limited to the project's roster:
-
-- Other Monks who open the URL get a clear "limited to its collaborators"
-  page instead of the app.
-- The project still appears in the company list — it isn't hidden, just
-  closed.
-- Platform admins can still manage the project in the dashboard, but they
-  must add themselves as collaborators if they need to open the live app.
-- [Client password access](https://docs.canopy.website/platform/client-access), if you've enabled
-  it, is unaffected — the two controls are independent.
-
-Turning it off again is the same toggle.
-
-> **Note:** Collaborators-only gates the **live app**. Management access (settings, data, deploys) is always
-> members-only, regardless of this toggle.
-
-## Platform admins and the Users page
-
-Platform admins get an extra **Users** page in the dashboard listing everyone
-on Canopy — name, email, and when they first signed in — with a one-click way
-to grant or remove admin. Accounts are created automatically on first
-OneLogin sign-in; there is nothing to provision.
-
-- [Client access](https://docs.canopy.website/platform/client-access) — Share work-in-progress with clients who don't have a Monks account.

package/dist/docs/platform-project-data.md

@@ -1,76 +0,0 @@
----
-title: Project data
-description: Every project gets its own private database and file storage — browse it in the dashboard, snapshot it before risky changes, and pull it locally.
----
-
-Every Canopy project comes with its own private database and file storage,
-created automatically the moment the project exists. There are no connection
-strings to configure and no servers to run — your app reads and writes through
-the Canopy SDK, and no other project can ever see your data.
-
-## The Data tab and the data explorer
-
-Open a project in the dashboard and the **Data** tab shows what your app has
-stored — every collection and table at a glance — plus the door into the
-**data explorer**, a full-page workspace for actually digging in:
-
-- **Schema sidebar** — collections and tables, each expandable to its
-  columns (types, primary keys) and indexes.
-- **Browse** — click any table or collection to page through it with real
-  totals, sort by any column, and stack filters (equals, contains,
-  comparisons, null checks) without writing SQL. Click a row for the full
-  record, JSON pretty-printed. Export the current page as CSV or JSON.
-- **SQL console** — a real editor with syntax highlighting and autocomplete
-  fed by your schema. Run with <kbd>⌘⏎</kbd>, see row counts and timing,
-  recall earlier queries from history, and hit **Explain** to see the query
-  plan.
-
-The console is **read-only by default** — the platform rejects anything but
-reads until you flip the writes toggle, so exploring production data is safe
-by design. The explorer is fixed to the channel (live or staging) you opened
-it from; to look at the other one, go back to the Data tab and switch there.
-
-The **Files** tab next to it lists the project's blob storage — the uploads
-and files your app has saved.
-
-## Snapshots and restores
-
-The Data tab's **Data safety** card is your undo button for data:
-
-- **Snapshot** stores a full dump of the database on the platform. Take one
-  before a risky change — a big import, a cleanup script, letting an agent
-  loose on production data.
-- **Restore** replaces the project's current data with a snapshot. This is
-  destructive by design (that's the point), so the dashboard asks you to
-  confirm.
-- **Export** downloads a dump to your machine.
-
-Snapshots live server-side and stay available until you delete the project,
-so you can restore from days ago, not just from your last session.
-
-> **Warning:** Restoring replaces **all** current data with the snapshot's contents. Take a fresh snapshot first
-> if there's anything recent you might want back.
-
-## The same tools from the terminal
-
-Everything above is also available to you (and your coding agent) via the CLI:
-
-```bash
-canopy db pull        # download a fresh SQL dump
-canopy db snapshot    # store a dump server-side
-canopy db snapshots   # list stored snapshots
-canopy db restore     # replace project data with a snapshot
-```
-
-`canopy db pull` is also how you develop against realistic data: pull a dump,
-then run `canopy dev --local --pull` for a throwaway sandbox seeded with it.
-
-## Portable by default, SQL when you need it
-
-The SDK's document API (`canopy.db.collection(...)`) behaves the same
-everywhere Canopy runs. Raw SQL via `canopy.db.sql()` passes straight through
-to the underlying database — SQLite on the Cloudflare sites, Postgres on the
-GCP pilot — so anything that database supports works. Your code can ask
-`canopy.db.dialect()` which one it's talking to.
-
-- [Working with project data](https://docs.canopy.website/guides/data) — Collection naming rules, dialects and raw SQL, dumps, and restore workflows in depth.

package/dist/docs/platform-schedules.md

@@ -1,90 +0,0 @@
----
-title: Schedules
-description: Run named cron jobs in your project's backend — configured in the dashboard, so you can change the cadence without redeploying.
----
-
-Schedules let a project do things on a clock: send a daily digest, refresh a
-cache every hour, tick a counter every minute. You define **named jobs** in
-the dashboard, and the platform wakes your project's backend at the right
-times — your code only decides what each job does.
-
-> **Note:** Schedules need a project with a custom backend. Per-project backends run on the **main** site and
-> the **GCP pilot** site. On sites without backend support the Schedules section doesn't appear in
-> Settings, and the API answers `not_supported_on_target`.
-
-## Defining a schedule
-
-In the dashboard, open the project's **Settings → Schedules**. Each schedule
-has:
-
-- a **name** (like `daily-digest`) — this is what your code switches on;
-- a **cron expression** — standard 5-field cron, always in **UTC**;
-- an **enabled** toggle, so you can pause a job without deleting it.
-
-A project can have up to **5 schedules**, and the shortest interval is one
-minute. Each row also shows its last run and, if it failed, the error — so
-you can see at a glance whether a job is healthy.
-
-You can also trigger a schedule manually from the dashboard, which is the
-quickest way to test a handler without waiting for the clock.
-
-## Handling schedules in your code
-
-Your project's worker exports a `scheduled` handler next to its normal
-`fetch` handler, and switches on the job's name:
-
-```ts
-export default {
-  async fetch(request, env, ctx) {
-    return app.fetch(request, env, ctx);
-  },
-
-  async scheduled(event, env, ctx) {
-    switch (event.name) {
-      case "daily-digest":
-        await sendDigest(env);
-        break;
-      default:
-        console.warn("unknown schedule", event.name);
-    }
-  },
-};
-```
-
-`event.name` is the name you gave the schedule in the dashboard, `event.cron`
-is the expression that fired, and `event.scheduledTime` is when it fired.
-Inside the handler your code has the same environment as an HTTP request —
-secrets, the project database, and blob storage all work the same way.
-
-## Data access without a signed-in user
-
-A scheduled run has no browser session attached, but `canopy.db`, `canopy.blob`
-and `canopy.ai` still work: the platform seals a **project-scoped worker
-token** into your backend on every deploy, and calls through the platform
-fall back to it whenever the request carries no user credential. You don't
-configure or see this token — it's minted, rotated (every deploy replaces
-it), and revoked with the project automatically, and it only ever reaches
-your own project's data.
-
-The one thing that behaves differently is identity: `canopy.auth.user()`
-resolves with `kind: "worker"` and empty `id`/`email`/`name` — there is no
-one signed in during a cron tick, and your code should treat that as "no
-user", not as an error.
-
-## Why the name matters
-
-Switch on `event.name`, not on the cron string. The dashboard is the source
-of truth for _when_ a job runs, so you can change `daily-digest` from 6:00 to
-7:30 — or pause it — without touching code or redeploying. The name is the
-stable contract between the dashboard and your handler.
-
-## Things to know
-
-- **Cron runs as the project, not as a person.** Data access works (see
-  above), but there is no signed-in user — `auth.user()` answers with
-  `kind: "worker"` and no identity.
-- **All times are UTC.** `0 6 * * *` is 6:00 UTC, not local time.
-- **Failures are visible.** A run that throws records its error on the
-  schedule row in Settings, so silent breakage doesn't stay silent.
-
-- [Infrastructure](https://docs.canopy.website/guides/infrastructure) — What runs where — assets, backends, databases — across the Canopy sites.

package/dist/docs/platform-sites-and-profiles.md

@@ -1,61 +0,0 @@
----
-title: Sites & profiles
-description: Canopy runs as more than one installation. Most people only ever use main — here's what the others are and how the CLI keeps them straight.
----
-
-Canopy isn't a single installation: the same platform runs as a few separate
-**sites**, each with its own domain, its own projects, and its own data.
-Unless someone told you otherwise, **you're on `main` and can stop reading
-here** — the rest of this page explains what the other sites are for and how
-the CLI targets them.
-
-## The sites
-
-| Site        | Project URLs          | What it's for                                     |
-| ----------- | --------------------- | ------------------------------------------------- |
-| `main`      | `*.canopy.website`    | The real platform. Your projects live here.       |
-| `staging`   | `*.thanarie.dev`      | The platform team's testbed for platform changes. |
-| `gcp-pilot` | `*.canopy.monks.zone` | A pilot running on Google Cloud.                  |
-
-Sites are fully separate: a project on `main` doesn't exist on `staging`, and
-signing in to one doesn't create anything on another. They can also differ in
-what they support — the dashboard simply hides features a site can't honor,
-and the API says `not_supported_on_target` if asked directly.
-
-## What a profile is
-
-A **profile** is the CLI's name for a site. `canopy login` signs you in once
-via OneLogin and stores a credential for every site in one go; the profile
-just picks which one a command talks to.
-
-Three things decide the effective profile, in order:
-
-1. `--profile <id>` on the command (or the `CANOPY_PROFILE` environment
-   variable) — one-off override.
-2. The `"profile"` pinned in the project's `canopy.json` — set when the
-   project was created, so a checkout always targets the site it belongs to.
-3. Your default active profile — `main` unless you chose otherwise at login.
-
-Every command prints the site it's talking to in its header line, and
-`canopy whoami` shows your email, active profile, and API host — so there's
-never a mystery about where a deploy just went.
-
-```bash
-canopy whoami                          # who am I, on which site?
-canopy --profile gcp-pilot deploy      # one command against the pilot
-```
-
-## When you'd actually care
-
-- **Never, usually.** Day-to-day work on your own projects is all `main`,
-  and the `canopy.json` pin keeps it that way without any flags.
-- **Trying backend features.** Custom backends and
-  [schedules](https://docs.canopy.website/platform/schedules) currently run on `gcp-pilot`, so
-  experiments with those happen there.
-- **Helping test platform changes.** If the platform team asks you to check
-  something on `staging`, `--profile staging` points any command at it.
-
-> **Note:** Deploying to a different site publishes a **separate copy** of the project there — it doesn't move
-> or mirror the one on `main`. Each site keeps its own versions, data, and members.
-
-- [CLI reference](https://docs.canopy.website/guides/cli) — Every canopy command, including login, whoami, and the --profile flag.

package/dist/docs/porting-nextjs.md

@@ -1,233 +0,0 @@
----
-title: Porting a Next.js app
-description: How to restructure a Next.js (App Router) project so it runs on Canopy.
----
-
-Canopy can host a project that started life as a Next.js app — but not by
-running Next.js's server. This guide explains why, and walks through the
-restructuring: a **static frontend** plus an optional **backend worker on
-`/api/*`**, with the platform taking over auth, data, files, and AI.
-
-If your app barely uses Next's server side, the port is a day or two of work.
-If it leans heavily on server components, server actions, or ISR, read
-[When not to port](#when-not-to-port) first.
-
-## Why a lift-and-shift doesn't work
-
-Canopy deliberately hosts no arbitrary servers — that's what keeps a thousand
-idle projects free to run and safe to operate. Three consequences matter for
-Next.js:
-
-- **Every page is a static file.** The platform serves your deployed build
-  from storage; requests to `/`, `/about`, or any other page route never reach
-  project code (see [How static files are served](https://docs.canopy.website/guides/static-serving)).
-  Server-side rendering, React Server Components resolved per request,
-  and Incremental Static Regeneration have nowhere to run.
-- **The backend is one worker, reachable only under `/api/*`.** A project can
-  ship a single bundled module exporting `fetch()` (and optionally
-  `scheduled()`), and the platform routes `/api/*` requests to it. Server
-  actions — which POST to page routes — never reach it.
-- **Auth belongs to the platform.** Every request is already behind OneLogin
-  (or a project password) before your code runs. NextAuth, auth middleware,
-  and session handling come out of the ported app entirely.
-
-So the port is a restructure: the frontend becomes a static build, and
-whatever genuinely needs a server moves into the worker.
-
-## What a ported app looks like
-
-```
-my-app/
-├── canopy.json          ← slug, build command, dist folder, worker entry
-├── src/                 ← frontend (static build)
-├── worker/
-│   └── index.ts         ← backend: fetch handler for /api/*
-└── dist/                ← build output that gets deployed
-```
-
-```json
-{
-  "slug": "my-app",
-  "build": "npm run build",
-  "dist": "dist",
-  "worker": "worker/index.ts"
-}
-```
-
-One `canopy deploy` builds and ships both; frontend and backend always move
-together as a single version, with rollback.
-
-## Step 1 — take inventory
-
-List everything in the app that runs on the server. Each item lands in one of
-three buckets:
-
-| Next.js feature                                 | Where it goes on Canopy                                                          |
-| ----------------------------------------------- | -------------------------------------------------------------------------------- |
-| Pages, layouts, client components               | Static build (unchanged in spirit)                                               |
-| Server components fetching data at request time | Client-side fetching, or a worker endpoint                                       |
-| Route handlers (`app/api/*/route.ts`)           | Worker endpoints under `/api/*`                                                  |
-| Server actions                                  | Explicit worker endpoints, called with `fetch` from the client                   |
-| Middleware                                      | Usually deleted (auth is platform-provided); anything else moves into the worker |
-| NextAuth / auth middleware                      | Deleted — use `canopy.auth.user()` (client) or `env.USER` (worker)               |
-| Database (Prisma, Postgres, …)                  | `canopy.db` — per-project database, document API + SQL escape hatch              |
-| File uploads (S3, …)                            | `canopy.blob` — per-project file storage with signed downloads                   |
-| AI SDK / OpenAI client                          | `canopy.ai.chat()`, or point the Vercel AI SDK at `canopy.ai.endpoint()`         |
-| `NEXT_PUBLIC_*` env vars                        | Build-time env vars in your CI — the platform doesn't inject build config        |
-| Server-side env vars / secrets                  | Project secrets (dashboard Settings) — injected into the worker's `env`          |
-| Cron (`vercel.json` crons)                      | [Schedules](https://docs.canopy.website/platform/schedules) — delivered to the worker's `scheduled()`       |
-| ISR / `revalidate` / caching                    | Dropped — at internal-tool scale, fetch fresh or cache in the client             |
-| `next/image` optimization                       | Plain `<img>`, or optimize at build time                                         |
-| Custom domain                                   | Not available — projects live at `<slug>.canopy.<domain>` behind sign-in         |
-| Queues / background jobs                        | Not supported — restructure around request/response plus schedules               |
-
-If the last two rows are deal-breakers, stop here: see
-[When not to port](#when-not-to-port).
-
-## Step 2 — make the frontend static
-
-Two routes, pick one:
-
-**Static export (quickest).** Set `output: 'export'` in `next.config.js` and
-fix what breaks. You keep the App Router file layout and components, but lose
-everything request-time: no route handlers, no server actions, no dynamic
-route segments without `generateStaticParams`, no request-time server
-components (they still run — but once, at build time). `next build` writes a
-fully static site to `out/`; point `dist` at it. Set
-`images: { unoptimized: true }` since there's no image optimizer serving
-requests.
-
-**Rebuild as a Vite SPA (more idiomatic).** Canopy's templates and tooling
-assume a single-page app: one `index.html`, client-side routing, `canopy dev`
-for local development against real project data. If you're porting an app
-you'll keep evolving on Canopy — especially with an AI agent doing the work —
-converting pages to a React + Vite SPA usually pays for itself quickly, and
-agents handle this conversion well. Page routes become client routes (the
-platform serves `index.html` for unknown paths, so deep links work).
-
-Either way, data that pages used to fetch on the server now arrives one of two
-ways: fetched from the client through the SDK (`canopy.db`, `canopy.blob` —
-fine for most internal tools), or from your worker via `/api/*` when it needs
-server-side logic or secrets.
-
-## Step 3 — move the backend into a worker
-
-Route handlers and server actions become endpoints in one fetch handler.
-[Hono](https://hono.dev) is a natural fit and bundles cleanly:
-
-```ts
-// worker/index.ts
-import { createCanopy } from "@mediamonks/canopy";
-import { Hono } from "hono";
-
-type Env = {
-  CANOPY: { fetch: typeof fetch };
-  /** Signed-in monk, verified by the platform; null for cron. */
-  USER: { sub: string; email: string; name: string } | null;
-  /** Project secrets from dashboard Settings appear as plain keys. */
-  MY_API_KEY?: string;
-};
-
-const app = new Hono<{ Bindings: Env }>();
-
-// was: app/api/report/route.ts
-app.post("/api/report", async (c) => {
-  const user = c.env.USER;
-  if (!user) return c.json({ error: "unauthenticated" }, 401);
-
-  // The SDK works inside the worker through the CANOPY binding —
-  // same database and files the frontend sees, caller's identity attached.
-  const canopy = createCanopy({ fetch: c.env.CANOPY.fetch.bind(c.env.CANOPY) });
-  const rows = await canopy.db.collection("reports").find({ where: { owner: user.email } });
-  return c.json({ rows });
-});
-
-// was: a server action
-app.post("/api/submit", async (c) => {
-  const body = await c.req.json();
-  // …validate, write via canopy.db, call an external API with c.env.MY_API_KEY…
-  return c.json({ ok: true });
-});
-
-export default {
-  fetch: app.fetch.bind(app),
-  // was: vercel.json crons — configure in dashboard Settings → Schedules
-  async scheduled(event: { name: string }, env: Env) {
-    if (event.name === "nightly-report") {
-      // …
-    }
-  },
-};
-```
-
-Rules of the road for the worker:
-
-- It's **one bundled file** — dependencies are bundled in at deploy time, so
-  stick to packages that don't need Node built-ins or native modules.
-- **No filesystem, no long-lived state.** Persist through `canopy.db` and
-  `canopy.blob`.
-- **Outbound requests are controlled.** Calls to external APIs pass through a
-  per-project egress allowlist — deny-by-default, managed by you. Allow the
-  hosts your worker calls with `canopy egress allow <host>` or in dashboard
-  Settings → Outbound hosts (see [Outbound requests](https://docs.canopy.website/platform/egress)).
-- Frontend calls are plain `fetch("/api/…")` — same origin, the platform
-  session cookie rides along automatically.
-
-## Step 4 — swap the data layer
-
-Replace the ORM and connection strings with the project's own database:
-
-- The paved road is the [document API](https://docs.canopy.website/sdk/database):
-  `canopy.db.collection("todos").insert(…)` / `find(…)` — schemaless JSON, no
-  migrations. For most internal tools this replaces Prisma models outright.
-- Relational shapes port via the SQL escape hatch, `canopy.db.sql()`, against
-  the same per-project database.
-- Existing data can be imported once: export from your old database, then load
-  it through the worker or the [SQL console](https://docs.canopy.website/guides/data) in the dashboard.
-
-Files move to [`canopy.blob`](https://docs.canopy.website/sdk/files) (uploads, listings, short-lived
-signed download URLs — nothing is ever publicly readable). AI calls move to
-[`canopy.ai`](https://docs.canopy.website/sdk/ai); if the app uses the Vercel AI SDK, point it at
-`canopy.ai.endpoint()` and it keeps working, now metered and budget-capped.
-
-## Step 5 — delete the auth
-
-This is the satisfying part. OneLogin fronts every request before your code
-runs, so the ported app removes sign-in pages, session handling, and auth
-middleware entirely:
-
-- **Client:** `canopy.auth.user()` returns the signed-in monk.
-- **Worker:** `env.USER` carries the verified identity (no round-trip).
-- Client-facing access without OneLogin is a per-project
-  [password](https://docs.canopy.website/platform/client-access), configured in Settings — not code.
-
-Authorization (who may do what _inside_ the app) stays yours, but it now keys
-off a verified identity instead of a homegrown session.
-
-## When not to port
-
-Be honest about fit before starting. Dedicated hosting is the better home
-when the app:
-
-- depends on **per-request SSR** for real reasons — SEO on public pages,
-  personalization at the edge, streaming server components as a core UX;
-- is built around **server actions and RSC data flow** so thoroughly that the
-  restructure is a rewrite;
-- needs a **custom domain or anonymous public access** — nothing on Canopy is
-  reachable without OneLogin or a project password;
-- needs **queues, background jobs, or long-running work**.
-
-That's not a workaround waiting to happen — it's the platform's design. Canopy
-optimizes for small internal tools; an app that genuinely needs a server is
-past greenhouse size (see [Use cases](https://docs.canopy.website/overview/use-cases)).
-
-## Checklist
-
-- [ ] Inventory server-side surface (RSC fetching, actions, route handlers, middleware, crons)
-- [ ] Frontend: `output: 'export'` or Vite SPA; fix dynamic segments and `next/image`
-- [ ] Worker: route handlers + server actions → `/api/*` endpoints in `worker/index.ts`
-- [ ] Data: ORM → `canopy.db`; uploads → `canopy.blob`; AI clients → `canopy.ai`
-- [ ] Delete NextAuth/middleware; read identity from `canopy.auth.user()` / `env.USER`
-- [ ] Secrets into dashboard Settings; `NEXT_PUBLIC_*` into your CI build
-- [ ] Crons into Settings → Schedules, handled in `scheduled()`
-- [ ] `canopy.json` with `build`, `dist`, `worker` — then `canopy deploy`