@mediamonks/canopy-cli 0.7.19 → 0.7.21

package/dist/{dev-DtEwiNYi.mjs → dev-CNqx_53I.mjs}

@@ -37,7 +37,7 @@ async function workerPlugin(flags, slug) {
 		console.log(`note: canopy.json points "worker" at ${entry}, which does not exist — skipping.`);
 		return;
 	}
-	const { missingSecretNames, readDevVars, workerDevPlugin } = await import("./dev-worker-IWnHvQ1f.mjs");
+	const { missingSecretNames, readDevVars, workerDevPlugin } = await import("./dev-worker-Bij9OUMk.mjs");
 	const secrets = readDevVars(flags.dir);
 	const email = siteConfig().email;
 	const plugin = workerDevPlugin({
@@ -165,7 +165,7 @@ async function devRemote(flags, slug) {
 async function devLocal(flags, slug) {
 	let dump;
 	if (flags.pull) {
-		const { fetchProjectDump } = await import("./local-CKRZur_5.mjs");
+		const { fetchProjectDump } = await import("./local-CsSP4Vpt.mjs");
 		console.log(`Pulling a fresh export of ${slug}${flags.staging ? " [staging]" : ""}…`);
 		dump = await fetchProjectDump(slug, flags.staging ? "staging" : "live");
 	}
@@ -180,7 +180,7 @@ async function devLocal(flags, slug) {
 		const reason = err instanceof ApiError ? err.explain().why : String(err);
 		console.log(`Note: ai/services will be unavailable — could not reach the platform (${reason}).`);
 	}
-	const { createSandbox } = await import("./local-CKRZur_5.mjs");
+	const { createSandbox } = await import("./local-CsSP4Vpt.mjs");
 	const sandbox = await createSandbox({
 		slug,
 		persistDir: join(flags.dir, ".canopy", "local"),

package/dist/dev-D7v7WK9O.mjs

@@ -0,0 +1,2 @@
+import { t as devCommand } from "./dev-CNqx_53I.mjs";
+export { devCommand };

package/dist/{dev-worker-IWnHvQ1f.mjs → dev-worker-Bij9OUMk.mjs}

@@ -1,4 +1,4 @@
-import "./src-Bu4Ze32I.mjs";
+import "./src-BKKAEkbH.mjs";
 import { readFileSync } from "node:fs";
 import { relative, resolve, sep } from "node:path";
 //#region ../data-plane/src/worker-request.ts

package/dist/docs/cli-dev.md

@@ -29,7 +29,7 @@ canopy dev --local --pull       # sandbox hydrated from a fresh prod export
 
 **Local sandbox (`--local`).** Database, file, and auth requests are answered entirely on your machine, from a sandbox stored under `.canopy/local/` in the project directory — no database to install, and writes never reach the platform. The sandbox behaves the same as the real API, so code that works locally works deployed. Two things still go remote: `ai` and `services` calls go through to the real platform (metered as usual) when you're logged in — fully offline, they return errors until you log in and restart.
 
-**Matching your site's SQL dialect.** The document API (`canopy.db.collection(…)`) behaves identically everywhere, but raw `canopy.db.sql()` speaks the deployment target's dialect — SQLite on Cloudflare-backed sites, Postgres on GCP-backed ones (see [dialect()](https://docs.canopy.website/guides/data)). The sandbox defaults to Postgres. If your project uses raw SQL written for a SQLite site, lock the dialect in `canopy.json`:
+**Matching your site's SQL dialect.** The document API (`canopy.db.collection(…)`) behaves identically everywhere, but raw `canopy.db.sql()` speaks your site's dialect — SQLite or Postgres (see [dialect()](https://docs.canopy.website/guides/data)). The sandbox defaults to Postgres. If your project uses raw SQL written for a SQLite site, lock the dialect in `canopy.json`:
 
 ```json
 { "slug": "my-project", "dialect": "sqlite" }

package/dist/docs/cli-logs.md

@@ -5,7 +5,7 @@ description: Read your project worker's logs (console output) from the terminal
 
 `canopy logs` prints what your project's worker wrote to `console.log` / `console.error`. Reach for it when the worker misbehaves — a 500, an unexpected 403, a schedule that "did nothing" — instead of adding diagnostic endpoints and redeploying. The same output lives in the dashboard under the project's **Logs** tab.
 
-Logs are available on every site that runs workers. On a site where the platform can't read worker output, the command says so honestly instead of guessing. One caveat on Cloudflare-hosted sites: log capture starts with a project's next deploy after 2026-08-19 — a worker that hasn't been redeployed since then has nothing to show yet.
+Logs are available on every site that runs backends. On a site where the platform can't read your backend's output, the command says so honestly instead of guessing. One caveat: on some sites log capture starts with a project's next deploy after 2026-08-19, so a backend that hasn't been redeployed since then has nothing to show yet.
 
 ## Usage
 

package/dist/docs/data.md

@@ -3,8 +3,8 @@ title: Working with project data
 description: Pulling, snapshotting, and restoring your project database.
 ---
 
-Each Canopy project gets its own database and blob storage (D1 and R2 on the
-Cloudflare target; Postgres and GCS on GCP). Your app reads and writes them
+Each Canopy project gets its own database and its own file storage. Your app
+reads and writes them
 through the Canopy SDK at runtime; the CLI gives you tools to manage the data
 around it.
 

package/dist/docs/dev.md

@@ -39,7 +39,7 @@ canopy dev --local --pull
 By default the sandbox runs PGlite (embedded Postgres), so raw
 `canopy.db.sql()` speaks the postgres dialect there, while your deployed
 project speaks whatever its platform target speaks (`canopy.db.dialect()`
-tells you — sqlite on Cloudflare). Collections (`canopy.db.collection(...)`)
+tells you). Collections (`canopy.db.collection(...)`)
 behave the same in both, so this only matters for hand-written SQL — see
 `canopy docs data`. If your project's raw SQL targets a sqlite site, lock the
 dialect in `canopy.json` (`"dialect": "sqlite"`) and the sandbox runs an

package/dist/docs/developers-architecture.md

@@ -42,8 +42,8 @@ fall back to `index.html`, so client-side routes like `/settings` work on a
 hard refresh without any configuration. Rollback just repoints "live" at an
 earlier version — instant, nothing rebuilt.
 
-The full path — including caching, version-pinned `v12-dot-<slug>` preview
-hosts, and the security review — is in
+The full picture — caching rules, deploy limits, and version-pinned
+`v12-dot-<slug>` preview hosts — is in
 [How static files are served](https://docs.canopy.website/guides/static-serving).
 
 ## The optional backend worker
@@ -63,44 +63,52 @@ a backend, declared in `canopy.json`:
 ```
 
 Requests under `/api/*` reach the worker (Hono-style handlers); everything
-else is still static serving. Three things to know:
+else is still static serving. A few things to know:
 
 - **Requests arrive authenticated.** The worker sits behind the same gateway
   wall as the frontend.
-- **Platform access goes through the same SDK**, via the `CANOPY` service
-  binding — same budgets, same data isolation as the browser:
+- **The caller is already identified.** `c.env.USER` is the signed-in person
+  (`null` during a scheduled run) — no round-trip needed:
 
   ```ts
-  app.get("/api/hello", async (c) => {
-    const canopy = createCanopy({ fetch: c.env.CANOPY.fetch.bind(c.env.CANOPY) });
-    const user = await canopy.auth.user();
+  app.get("/api/hello", (c) => {
+    const user = c.env.USER;
+    if (!user) return c.json({ error: "unauthenticated" }, 401);
     return c.json({ message: `Hello, ${user.name}!` });
   });
   ```
 
+- **Platform access goes through the same SDK**, via the `CANOPY` service
+  binding — same budgets, same data isolation as the browser:
+
+  ```ts
+  const canopy = createCanopy({ fetch: c.env.CANOPY.fetch.bind(c.env.CANOPY) });
+  const notes = await canopy.db.collection("notes").find();
+  ```
+
 - **Secrets and schedules come from the dashboard.** Secrets (Settings →
   Secrets) land as Workers-shaped bindings (`c.env.MY_API_KEY`, not
   `process.env`); dashboard Schedules invoke an exported
   `scheduled(event, env)` — switch on `event.name`.
 
-> **Warning:** Backend workers are capability-gated per target: today the GCP target runs them, while on
-> Cloudflare sites a worker deploy answers a clear "not supported yet". Frontend-only projects
-> deploy everywhere.
+> **Note:** Backends run on the `main` and `gcp-pilot` sites. On a site without backend support, a deploy that
+> includes one answers with a clear "not supported here" rather than failing obscurely;
+> frontend-only projects deploy everywhere.
 
 ## Where your data lives
 
 Every project gets its own database and its own blob-storage prefix. No other
 project can read them, and deleting the project tears everything down. The
-document API is portable across targets; raw SQL speaks the target's dialect
+document API works the same on every site; raw SQL speaks your site's dialect
 (`sqlite` or `postgres` — ask `canopy.db.dialect()`). Dumps, snapshots, and
 restores are CLI commands — see the [project data guide](https://docs.canopy.website/guides/data).
 
 ## Sites
 
 A _site_ is one installation of the whole platform. The CLI ships three
-profiles — `main` (canopy.website, Cloudflare), `staging` (thanarie.dev,
-Cloudflare), and `gcp-pilot` (canopy.monks.zone, GCP) — and always shows which
-one you're on. Projects pin theirs in `canopy.json`; `--profile` or
-`CANOPY_PROFILE` overrides per command. Most projects only ever use `main`.
-Target differences (dialect, full-text search, worker support) surface as
-capabilities, not separate APIs.
+profiles — `main`, `staging`, and `gcp-pilot` — and always shows which one
+you're on. Projects pin theirs in `canopy.json`; `--profile` or
+`CANOPY_PROFILE` overrides per command. Most projects only ever use `main`;
+see [sites and profiles](https://docs.canopy.website/platform/sites-and-profiles) for what the other two
+are. Where sites differ (SQL dialect, full-text search, backend support) it
+surfaces as a capability, not a separate API.

package/dist/docs/index.json

@@ -80,17 +80,12 @@
         {
           "slug": "notifications",
           "title": "Slack notifications",
-          "summary": "Canopy DMs you about your reports and projects — replies, new reports, blocked fetches, budget hits, failing schedules."
+          "summary": "Canopy DMs you about your reports and projects — replies, new reports, blocked fetches, budget hits, failing schedules — and answers questions when you ask."
         },
         {
           "slug": "static-serving",
           "title": "How static files are served",
-          "summary": "The full path a browser request takes to a deployed file."
-        },
-        {
-          "slug": "infrastructure",
-          "title": "Infrastructure as code",
-          "summary": "Terraform for the account-level Cloudflare pieces Canopy needs."
+          "summary": "Why every page is a file, and what that means for routing, caching, and deploys."
         },
         {
           "slug": "troubleshooting",
@@ -296,7 +291,7 @@
         {
           "slug": "sdk",
           "title": "Using the SDK",
-          "summary": "One typed client for auth, data, files, AI, and services — no keys, no connection strings, the platform authenticates for you."
+          "summary": "One typed client for auth, data, files, AI, email, and services — no keys, no connection strings, the platform authenticates for you."
         },
         {
           "slug": "sdk-auth",
@@ -318,6 +313,11 @@
           "title": "AI",
           "summary": "Metered LLM access through the project's budget-capped gateway key — chat, streaming, and an OpenAI-compatible endpoint."
         },
+        {
+          "slug": "sdk-email",
+          "title": "Email",
+          "summary": "Send email from your project without a mail server or an API key — Monks recipients only, with a per-project daily quota and a sent log."
+        },
         {
           "slug": "sdk-google",
           "title": "Google",

package/dist/docs/migrations.md

@@ -65,9 +65,9 @@ data).
 
 Pin your dialect first — a Drizzle schema is written for one SQL flavor. Check
 what your project's site runs on (`await canopy.db.dialect()` or the
-[data guide](https://docs.canopy.website/guides/data)) and set `"dialect"` in `canopy.json`: `"sqlite"`
-on Cloudflare-backed sites, `"postgres"` on GCP-backed ones. That same field
-makes `canopy dev --local` run a matching local engine.
+[data guide](https://docs.canopy.website/guides/data)) and set `"dialect"` in `canopy.json` to match —
+`"sqlite"` or `"postgres"`. That same field makes `canopy dev --local` run a
+matching local engine.
 
 Install the tools and describe your schema:
 
@@ -113,24 +113,30 @@ This is fully local — it diffs your schema files and writes `.sql` into
 Canopy never hands out connection strings — Drizzle talks to your data through
 the handles Canopy already provides.
 
-**In a project worker on a Cloudflare-backed site**, `env.DB` is a real D1
-handle:
+Both handles are query functions, so both fit Drizzle's **proxy driver** —
+`drizzle-orm/sqlite-proxy` on a sqlite site, `drizzle-orm/pg-proxy` on a
+postgres one. Match it to the `"dialect"` you pinned in `canopy.json`.
+
+**In your backend**, `env.DB` takes the statement and its parameters:
 
 ```ts title="worker/index.ts"
-import { drizzle } from "drizzle-orm/d1";
+import { drizzle } from "drizzle-orm/sqlite-proxy";
 import { users } from "../src/schema.ts";
 
 export default {
   async fetch(request, env) {
-    const db = drizzle(env.DB);
-    const all = await db.select().from(users);
-    return Response.json(all);
+    const db = drizzle(async (sql, params, method) => {
+      const { rows } = await env.DB.query(sql, params);
+      const values = rows.map((row) => Object.values(row));
+      return { rows: method === "get" ? (values[0] ?? []) : values };
+    });
+    return Response.json(await db.select().from(users));
   },
 };
 ```
 
-**In the browser (or anywhere the SDK runs)**, wrap `canopy.db.sql()` with
-Drizzle's proxy driver:
+**In the browser (or anywhere the SDK runs)**, wrap `canopy.db.sql()` the same
+way:
 
 ```ts title="src/db.ts"
 import { drizzle } from "drizzle-orm/sqlite-proxy";
@@ -143,9 +149,6 @@ export const db = drizzle(async (sql, params, method) => {
 });
 ```
 
-(On a postgres site use `drizzle-orm/pg-proxy` the same way; in a GCP project
-worker, `env.DB.query(text, params)` fits `pg-proxy` directly.)
-
 ## Rehearsing on staging
 
 The safest way to try a migration is on the project's staging channel — a

package/dist/docs/notifications.md

@@ -1,6 +1,6 @@
 ---
 title: Slack notifications
-description: Canopy DMs you about your reports and projects — replies, new reports, blocked fetches, budget hits, failing schedules.
+description: Canopy DMs you about your reports and projects — replies, new reports, blocked fetches, budget hits, failing schedules — and answers questions when you ask.
 ---
 
 Canopy sends you Slack DMs when something on the platform needs your
@@ -38,6 +38,19 @@ the categories on or off. To silence one noisy project entirely, use **Mute
 project** on its Settings tab — personal to you, and your own reports
 elsewhere keep notifying.
 
+## Asking Canopy things
+
+The same bot answers questions. DM **Canopy** in Slack — or mention
+**@Canopy** in a channel — and ask in plain language: "what projects do I
+have?", "why is my fetch to that API failing?", "how do I roll back a bad
+deploy?". It looks at your projects (only the ones you can already see) and
+at these docs, and answers with links to the right guide.
+
+It can only read. It never deploys, changes settings, or touches your data —
+for that it points you at the dashboard or the CLI. In a channel that's
+linked to a project, it already knows which project you mean; replying in a
+report's notification thread, it knows which report.
+
 ## If DMs don't arrive
 
 The bot finds you by your work email. If your Slack account uses a different

package/dist/docs/platform-egress.md

@@ -13,8 +13,8 @@ That default is deliberate: a thousand idle vibecoded projects should not be
 able to call arbitrary internet hosts. When your project genuinely needs an
 external API, you allow that host yourself — no platform-team ticket.
 
-> **Note:** Enforcement applies on every target. On GCP the runtime answers the 403 itself; on Cloudflare the
-> platform vets each outbound request outside your worker. Same rule, same error, one allowlist.
+> **Note:** Enforcement happens outside your code, on every site — so the rule holds even if your project
+> tries to route around it. Same rule, same error, one allowlist.
 
 ## Allowing a host
 

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

@@ -69,8 +69,8 @@ then run `canopy dev --local --pull` for a throwaway sandbox seeded with 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.
+to the underlying database, so anything that database supports works. Which
+one your site runs — SQLite or Postgres — your code can ask with
+`canopy.db.dialect()`.
 
 - [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

@@ -100,4 +100,4 @@ stable contract between the dashboard and your handler.
 - **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.
+- [How the platform serves your project](https://docs.canopy.website/developers/architecture) — Where your backend runs, and what it can reach — the same environment a scheduled run gets.

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

@@ -15,7 +15,7 @@ the CLI targets them.
 | ----------- | --------------------- | ------------------------------------------------- |
 | `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.                  |
+| `gcp-pilot` | `*.canopy.monks.zone` | A pilot installation, used for evaluation work.   |
 
 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

package/dist/docs/sdk-email.md

@@ -0,0 +1,114 @@
+---
+title: Email
+description: Send email from your project without a mail server or an API key — Monks recipients only, with a per-project daily quota and a sent log.
+---
+
+`canopy.email` sends transactional email — a digest, a notification, a
+"your request was approved" — from your project code. There is no mail
+server to run, no provider account to open, no API key in your project, and
+no DNS to configure. The platform sends on your behalf and keeps a log of
+what went out.
+
+Two rules are enforced by the platform, not by your code:
+
+- **Monks recipients only.** Every address must be an `@monks.com` one.
+  Anything else is refused before the message is sent.
+- **A daily quota per project**, 100 emails by default. Each recipient
+  counts as one. Ask an admin if your project genuinely needs more.
+
+## email.send(options)
+
+Resolves once the platform has accepted the message:
+
+```ts
+await canopy.email.send({
+  to: "someone@monks.com",
+  subject: "Weekly digest",
+  text: "Three new entries this week.",
+});
+```
+
+**`EmailSendOptions`:**
+
+- `to` — required. One address, or an array of up to 10.
+- `subject` — required, up to 200 characters.
+- `text` — required. The plain-text body. Always sent, even alongside
+  `html`: some clients show only this, and it helps you stay out of spam
+  folders.
+- `html` — optional HTML body. `text` and `html` together are capped at
+  256 KB.
+- `replyTo` — optional. Follows the same recipient rule as `to`, so replies
+  cannot be routed off to an outside address.
+
+**Returns** `{ delivered, queued, bounced }` — three arrays of addresses.
+`delivered` is accepted for delivery, `queued` will be retried, and
+`bounced` will never arrive (a wrong address, usually).
+
+Attachments are not supported. Link to something in your app instead.
+
+## Who the email comes from
+
+Your project sends as itself: the From address is your project's slug at the
+platform's mail domain, with your project's name attached — so a recipient
+can tell at a glance which app is writing to them, and replies do not land
+in a shared inbox.
+
+Set `replyTo` when you want answers to reach a real person or team.
+
+## Sending from the backend
+
+The most useful sends have nobody signed in — a nightly digest, a
+[scheduled](https://docs.canopy.website/platform/schedules) summary. Email works there too: call it from
+a worker route or a scheduled handler and it authenticates as the project
+itself.
+
+```ts
+export default {
+  async scheduled(event, env) {
+    const canopy = createCanopy({ fetch: env.CANOPY.fetch.bind(env.CANOPY) });
+    const entries = await recentEntries(env.DB);
+
+    await canopy.email.send({
+      to: "team@monks.com",
+      subject: `Digest · ${entries.length} new entries`,
+      text: entries.map((e) => `· ${e.title}`).join("\n"),
+    });
+  },
+};
+```
+
+## Seeing what was sent
+
+Your project's **Usage** tab in the dashboard shows how much of today's
+quota you have used and the recent sends — when, to whom, the subject, and
+whether it went out. Message bodies are never stored.
+
+## When it fails
+
+Every failure is a `CanopyError` with a status you can branch on:
+
+- **400** — the recipient isn't a Monks address, or the request broke one of
+  the limits above (too many recipients, subject too long, missing `text`).
+- **429** — the project used its daily quota. It resets at UTC midnight.
+- **501** — email isn't set up on this Canopy site.
+- **502** — the platform accepted the request but the send failed downstream.
+
+```ts
+import { CanopyError } from "@mediamonks/canopy";
+
+try {
+  await canopy.email.send({ to, subject, text });
+} catch (err) {
+  if (err instanceof CanopyError && err.status === 429) {
+    // Out of quota for today — queue it, or tell the user.
+  }
+}
+```
+
+## What this is not
+
+This is transactional email for a small internal audience. It is not a
+newsletter platform: there are no mailing lists, no subscriber management,
+and no unsubscribe handling — if you send something people can opt into,
+you own that list and that opt-out inside your own app. A project that
+outgrows "email some Monks" should graduate to a dedicated email provider.

package/dist/docs/sdk-files.md

@@ -37,8 +37,9 @@ Every upload (and every `list` entry) is described by a `BlobObject`:
 const blob = await canopy.blob.get("notes.txt");
 const text = await blob?.text();
 
-// getUrl(key) → Promise<{ url: string; expiresAt: string }>
+// getUrl(key, options?) → Promise<{ url: string; expiresAt: string }>
 const { url, expiresAt } = await canopy.blob.getUrl("avatars/arjan.png");
+const long = await canopy.blob.getUrl("packs/brand.zip", { expiresIn: 3600 });
 ```
 
 `get` returns the content as a standard `Blob`, typed with the MIME type it
@@ -52,6 +53,15 @@ links, media elements — and prefer `get` when your code needs the content.
 Request a fresh URL when you render rather than storing one: it expires at
 `expiresAt`.
 
+A URL lasts **10 minutes** by default. Pass `expiresIn` (seconds) when a link
+has to outlive that — a download a person starts later, or a sync tool that
+works through a batch of files without coming back for a new link each time.
+The platform caps a lifetime at **24 hours**; ask for more and you get 24
+hours rather than an error, so trust `expiresAt` over what you asked for. A
+lifetime that isn't a whole number of seconds above zero is rejected. Keep the
+window as short as the job needs — anyone holding the URL can download the
+file until it expires.
+
 ## Listing and deleting
 
 ```ts

package/dist/docs/sdk.md

@@ -1,11 +1,11 @@
 ---
 title: Using the SDK
-description: One typed client for auth, data, files, AI, and services — no keys, no connection strings, the platform authenticates for you.
+description: One typed client for auth, data, files, AI, email, and services — no keys, no connection strings, the platform authenticates for you.
 ---
 
 `@mediamonks/canopy` is a thin, typed client over the platform's project API.
-One `createCanopy()` call gives you six modules — `auth`, `db`, `blob`, `ai`,
-`google`, and `services` — and that is the entire surface. There are no API keys,
+One `createCanopy()` call gives you seven modules — `auth`, `db`, `blob`, `ai`,
+`email`, `google`, and `services` — and that is the entire surface. There are no API keys,
 connection strings, or environment variables to manage: every call rides the
 session the platform already established before your code ran.
 
@@ -35,7 +35,7 @@ import { createCanopy } from "/_api/data/v1/sdk.js";
 import { createCanopy } from "@mediamonks/canopy";
 
 const canopy = createCanopy();
-// canopy.auth, canopy.db, canopy.blob, canopy.ai, canopy.google, canopy.services
+// canopy.auth, canopy.db, canopy.blob, canopy.ai, canopy.email, canopy.google, canopy.services
 ```
 
 | Option    | Type           | Default        | What it does                                                                                                          |