@mediamonks/canopy-cli 0.7.31 → 0.7.33

package/dist/{deploy-B-znPE-v.mjs → deploy-Ka2lHkyy.mjs}

@@ -2,6 +2,7 @@ import { a as projectDirArgs, c as resolveProject, l as stagingUrl, n as siteCon
 import { i as apiRequest, n as apiDataRequest, o as withContext, r as apiDownload } from "./api-C4rMhE7i.mjs";
 import { a as unwrap, r as reportErrors, t as formatDateTime } from "./ui-C_jSc1Kz.mjs";
 import { n as migrateProject, r as readMigrationFiles, t as describeMigrateResult } from "./migrations-Czlcddyz.mjs";
+import { builtinModules } from "node:module";
 import { defineCommand } from "citty";
 import { mkdtempSync, readFileSync, readdirSync, rmSync, statSync, writeFileSync } from "node:fs";
 import { tmpdir } from "node:os";
@@ -27,7 +28,7 @@ async function bundleWorker(projectDir, entry) {
 			format: "esm",
 			target: "es2022",
 			packages: "bundle",
-			external: ["node:*"],
+			plugins: [nodeBuiltins],
 			logLevel: "silent"
 		});
 		return new Uint8Array(readFileSync(outfile));
@@ -38,6 +39,115 @@ async function bundleWorker(projectDir, entry) {
 		});
 	}
 }
+/** Bare names Node resolves to a built-in (`fs`, `fs/promises`, …). */
+const BARE_BUILTINS = new Set(builtinModules.filter((name) => !name.startsWith("_")));
+/**
+* Built-ins both hosts provide, each with a default export: Node, and workerd
+* at the dispatch scripts' compatibility date (2026-05-01, nodejs_compat —
+* probed with a worker importing every one; several are stubs that throw only
+* when called). Missing on workerd: `sea`, `test/reporters`. Left out on
+* purpose: `sqlite` (experimental on Node) and `test`.
+*/
+const HOSTED_BUILTINS = /* @__PURE__ */ new Set([
+	"assert",
+	"assert/strict",
+	"async_hooks",
+	"buffer",
+	"child_process",
+	"cluster",
+	"console",
+	"constants",
+	"crypto",
+	"dgram",
+	"diagnostics_channel",
+	"dns",
+	"dns/promises",
+	"domain",
+	"events",
+	"fs",
+	"fs/promises",
+	"http",
+	"http2",
+	"https",
+	"inspector",
+	"inspector/promises",
+	"module",
+	"net",
+	"os",
+	"path",
+	"path/posix",
+	"path/win32",
+	"perf_hooks",
+	"process",
+	"punycode",
+	"querystring",
+	"readline",
+	"readline/promises",
+	"repl",
+	"stream",
+	"stream/consumers",
+	"stream/promises",
+	"stream/web",
+	"string_decoder",
+	"sys",
+	"timers",
+	"timers/promises",
+	"tls",
+	"trace_events",
+	"tty",
+	"url",
+	"util",
+	"util/types",
+	"v8",
+	"vm",
+	"wasi",
+	"worker_threads",
+	"zlib"
+]);
+const REQUIRE_NAMESPACE = "canopy-node-require";
+/**
+* Node built-ins are the host's, not the bundle's: the GCP runtime is Node and
+* Cloudflare dispatch scripts run with nodejs_compat. A `neutral` build cannot
+* resolve them at all, so every import of one — `node:fs` or bare `fs`, as Node
+* itself treats them — stays external under its `node:` name.
+*
+* A CommonJS `require()` of one cannot simply stay external: in an ESM bundle
+* esbuild turns it into a `__require` shim that throws "Dynamic require of …
+* is not supported" when it runs. Neither host offers a `require` to an ES
+* module, so the call is routed to a tiny ES module that re-exports the
+* built-in through a static `import`. The AI SDK needs this: `ai` reaches
+* `@vercel/oidc`, whose CommonJS build requires `fs`, `os` and `path` at load.
+*
+* That turns a lazy require — often an optional one in a try/catch — into an
+* import made at load, and Cloudflare refuses a script importing a module it
+* lacks. So only HOSTED_BUILTINS are rewritten; a require of any other
+* built-in keeps the throwing shim, which fails only if that line runs.
+*/
+const nodeBuiltins = {
+	name: "canopy-node-builtins",
+	setup(build) {
+		build.onResolve({ filter: /^(node:)?[a-z_][a-z0-9_/]*$/ }, (args) => {
+			const prefixed = args.path.startsWith("node:");
+			const name = prefixed ? args.path.slice(5) : args.path;
+			if (!prefixed && !BARE_BUILTINS.has(name)) return void 0;
+			if (args.kind === "require-call" && HOSTED_BUILTINS.has(name)) return {
+				path: name,
+				namespace: REQUIRE_NAMESPACE
+			};
+			return {
+				path: `node:${name}`,
+				external: true
+			};
+		});
+		build.onLoad({
+			filter: /.*/,
+			namespace: REQUIRE_NAMESPACE
+		}, (args) => ({
+			contents: `export * from "node:${args.path}";\nexport { default } from "node:${args.path}";\n`,
+			loader: "js"
+		}));
+	}
+};
 //#endregion
 //#region src/deploy.ts
 /**

package/dist/docs/agent-tools.md

@@ -101,7 +101,7 @@ wrote for another MCP server carry over as they are.
 A tool set you already use with the AI SDK works too. Put it in the same list:
 
 ```ts
-import { tool } from "@ai-sdk/provider-utils";
+import { tool } from "ai";
 
 const aiTools = {
   weather: tool({
@@ -114,9 +114,7 @@ const aiTools = {
 mountMcpTools(app, [...myTools, aiTools]);
 ```
 
-Import `tool` from `@ai-sdk/provider-utils` in a backend: the full `ai`
-package doesn't bundle for Canopy backends yet. Tools without `execute` (ones
-the AI provider runs itself) are left out.
+Tools without `execute` (ones the AI provider runs itself) are left out.
 
 ## Write good tools
 
@@ -210,4 +208,5 @@ an agent (`agent`), in any route. Two limits apply to your own server:
   60 seconds.
 - Agent calls show up in your backend's logs like any other request.
 
-See [canopy mcp](https://docs.canopy.website/cli/mcp) for every flag.
+See the [SDK reference](https://docs.canopy.website/sdk/mcp) for every option and [canopy mcp](https://docs.canopy.website/cli/mcp)
+for every flag.

package/dist/docs/cli-create.md

@@ -19,6 +19,7 @@ canopy create existing-app --no-scaffold  # register only, no files written
 - `--slug <slug>` — the URL slug; the project will live at `https://<slug>.<site-domain>`. Lowercase letters, digits and dashes only. Defaults to a slugified version of the name (prompted on a TTY).
 - `--template <id>` — starter to scaffold: `static` (plain HTML/CSS/JS, no build step, untyped SDK from the platform — simplest apps), `spa` (Vite + React + TypeScript with the typed SDK from npm — best for real SDK use or growth), or `worker` (`spa` plus a backend worker in `worker/` — for server-side code: secrets, schedules, calling external APIs). A picker appears when omitted on a TTY; `static` is the default otherwise.
 - `--scaffold` / `--no-scaffold` — whether to write `./<slug>/` from the template. When neither is given, the CLI scaffolds unless the current directory already has a `canopy.json` (in which case it assumes you're registering an existing app and only registers).
+- `--repo` / `--no-repo` — also create a git repository for the project on Canopy and set up the new folder to push to it (see [`canopy repo`](https://docs.canopy.website/cli/repo)). When neither is given, an interactive run asks (default no) on sites that offer repositories; non-interactive runs create none.
 - `--profile <site>` — global flag (or `CANOPY_PROFILE`): which site to create the project on. The chosen profile is pinned into the scaffolded `canopy.json`.
 
 ## How it works

package/dist/docs/cli-repo.md

@@ -0,0 +1,87 @@
+---
+title: canopy repo
+description: Create, clone and set up the project's git repository on Canopy.
+---
+
+`canopy repo` manages the project's git repository. A project has at most one: a
+Canopy repository, which Canopy keeps for it, or its own GitHub repository.
+Once a folder is set up, you use plain git. The CLI signs git in on every push
+and pull, so you never handle a password or token.
+
+## Usage
+
+```bash
+canopy repo show [--json]
+canopy repo create
+canopy repo clone <slug> [folder]
+canopy repo connect
+canopy repo delete [--yes]
+```
+
+## Arguments & flags
+
+`show`, `create`, `connect` and `delete` resolve the project the usual way:
+`canopy.json` in the target folder, or `--project <slug>`. All of them honour
+the global `--profile <site>` / `CANOPY_PROFILE`.
+
+- `show` — whether the project has a repository, and if so its remote, when it
+  was created and when it was last pushed to.
+  - `--json` — the same as JSON, for scripts and agents.
+- `create` — create the project's Canopy repository. Owners, editors and
+  platform admins can. Run it in the project's folder and the folder is set up
+  too.
+- `clone <slug> [folder]` — clone the project's repository into a new folder
+  (the slug by default), ready to push.
+- `connect` — set up an existing folder.
+  - If the folder isn't a git repository yet, it is initialised on branch `main`.
+  - If it has no `origin`, the Canopy repository becomes `origin`.
+  - If `origin` points somewhere else, the Canopy repository is added as
+    `canopy`.
+- `delete` — delete the repository and all its history. Owner only. Asks you to
+  type the slug.
+  - `--yes` — skip that question.
+
+## How it works
+
+Setting up a folder (`create`, `clone`, `connect`) does two things:
+
+1. It points a remote at the project's repository.
+2. It registers the CLI as git's credential helper for that one repository.
+
+Nothing secret is written into the folder or its git settings. On each push or
+pull, git asks the CLI for credentials. The CLI exchanges your `canopy login`
+for a short-lived token that only works for this repository, keeps it in
+`~/.canopy` for up to an hour, and gets a new one when needed. `canopy logout`
+throws them away.
+
+Pushing doesn't deploy. Run `canopy deploy` for that.
+
+## Examples
+
+```bash
+canopy repo create
+git add -A && git commit -m "First version" && git push -u origin main
+```
+
+Creates the repository for the project in this folder and pushes the code.
+
+```bash
+canopy repo clone my-tool
+```
+
+Clones a teammate's project into `./my-tool`, ready to push.
+
+```bash
+canopy repo show --json
+```
+
+```json
+{
+  "kind": "canopy",
+  "remote": "https://monks.ghe.com/canopy/my-tool.git",
+  "created_at": "2026-10-21T09:12:00Z",
+  "last_push_at": "2026-10-21T09:15:42Z"
+}
+```
+
+Read the [git guide](https://docs.canopy.website/guides/git) for the bigger picture.

package/dist/docs/getting-started.md

@@ -93,6 +93,9 @@ Then open the live site:
 canopy open
 ```
 
+Want your code in git too, without a GitHub account? `canopy repo create` gives
+the project a repository on Canopy — see [Keep your code in git](https://docs.canopy.website/guides/git).
+
 ## Where to go next
 
 Everything the CLI can do is documented and available offline. List the topics:

package/dist/docs/git.md

@@ -0,0 +1,86 @@
+---
+title: Keep your code in git
+description: Give your project a git repository on Canopy — history, backup and sharing, no GitHub account needed.
+---
+
+Every project can have one git repository. If you already use GitHub, keep using
+it. If you don't have a GitHub account, Canopy can keep a private repository for
+your project instead. Your code then has history and a backup, and teammates and
+their agents can pick it up.
+
+A Canopy repository is for storing code. Pushing to it doesn't deploy anything —
+`canopy deploy` still does that.
+
+## Create one
+
+From your project folder:
+
+```bash
+canopy repo create
+```
+
+That creates the repository and sets up the folder, so from then on it is plain
+git:
+
+```bash
+git add -A
+git commit -m "First version"
+git push -u origin main
+```
+
+New projects can get one straight away with `canopy create my-tool --repo`. You
+can also create one from the dashboard, on the project's **Deploys** tab.
+
+## Work on it from another machine (or hand it to a teammate)
+
+Anyone on the project can clone it:
+
+```bash
+canopy repo clone my-tool
+```
+
+Already have the code in a folder? Set that folder up instead:
+
+```bash
+canopy repo connect
+```
+
+If the folder already pushes somewhere else (say your own GitHub), that stays
+`origin` and the Canopy repository is added as a second remote called `canopy`.
+
+## Signing in
+
+You never type a password or paste a token. The Canopy CLI signs git in for you
+on every push and pull, using your `canopy login`. When that sign-in expires, git
+stops and tells you to run `canopy login` again.
+
+Who can do what follows the project's members:
+
+- Owners and editors can pull and push.
+- Platform admins can pull.
+- Nobody else gets in.
+
+Remove someone from the project and they can no longer push or pull, even from
+a copy they already cloned.
+
+## Git apps (GitHub Desktop, VS Code, Tower, …)
+
+Set the folder up once with `canopy repo clone` or `canopy repo connect` in a
+terminal. After that, git apps that use the git installed on your computer push
+and pull as usual. Apps that bring their own git or ask for a password can't
+sign in to a Canopy repository; use the terminal for those.
+
+## Good to know
+
+- **Keep secrets out.** Files like `.env` and `.dev.vars` are ignored by the
+  project templates; secrets belong in `canopy secrets`.
+- **There is no branch protection.** Anyone who can push can rewrite history, so
+  avoid force-pushes on `main`.
+- **Deleting is for good.** `canopy repo delete` (owner only) removes the
+  repository and all its history. Deleting the project deletes its repository
+  too.
+- **Moving to your own GitHub later** is ordinary git: create an empty
+  repository there, then `git remote add github <its url>` and
+  `git push github --all`.
+
+See the [`canopy repo` reference](https://docs.canopy.website/cli/repo) for every command and flag.

package/dist/docs/index.json

@@ -67,6 +67,11 @@
           "title": "CI and deploy tokens",
           "summary": "Push-to-main deploys using a project-scoped deploy token."
         },
+        {
+          "slug": "git",
+          "title": "Keep your code in git",
+          "summary": "Give your project a git repository on Canopy — history, backup and sharing, no GitHub account needed."
+        },
         {
           "slug": "agent-tools",
           "title": "Agent tools (MCP)",
@@ -251,6 +256,11 @@
           "title": "canopy token",
           "summary": "Create, list, and revoke project-scoped deploy tokens for CI and push-to-main deploys."
         },
+        {
+          "slug": "cli-repo",
+          "title": "canopy repo",
+          "summary": "Create, clone and set up the project's git repository on Canopy."
+        },
         {
           "slug": "cli-egress",
           "title": "canopy egress",
@@ -363,6 +373,11 @@
           "title": "Realtime",
           "summary": "Live updates between the people using your app — subscribe to a topic, publish to it, no backend needed."
         },
+        {
+          "slug": "sdk-mcp",
+          "title": "Agent tools (MCP)",
+          "summary": "\"@mediamonks/canopy/mcp — serve your backend's tools to AI agents: mountMcpTools, createMcpToolsHandler, MCP_PATH and mcpCaller.\""
+        },
         {
           "slug": "sdk-google",
           "title": "Google",

package/dist/docs/sdk-mcp.md

@@ -0,0 +1,222 @@
+---
+title: Agent tools (MCP)
+description: "@mediamonks/canopy/mcp — serve your backend's tools to AI agents: mountMcpTools, createMcpToolsHandler, MCP_PATH and mcpCaller."
+---
+
+`@mediamonks/canopy/mcp` turns your backend into a set of MCP tools that AI
+agents call through `canopy mcp serve`, always as the signed-in Monk running
+them. It is a separate entry of the SDK, for backend code only: browser
+bundles never include it.
+
+```ts
+import { createMcpToolsHandler, MCP_PATH, mcpCaller, mountMcpTools } from "@mediamonks/canopy/mcp";
+```
+
+For the why and the how-to, read the [Agent tools guide](https://docs.canopy.website/guides/agent-tools).
+This page lists the exports and what they accept.
+
+## mountMcpTools(app, tools, options?)
+
+Serves `tools` at `MCP_PATH` on a Hono app. Route tools run this same app's
+routes.
+
+```ts
+import { mountMcpTools } from "@mediamonks/canopy/mcp";
+import { z } from "zod";
+
+mountMcpTools(app, [
+  {
+    name: "list_notes",
+    description: "List the current user's notes, newest first",
+    route: "GET /api/notes",
+    annotations: { readOnlyHint: true },
+  },
+  {
+    name: "summarise",
+    description: "Summarise a note",
+    inputSchema: z.object({ id: z.string() }),
+    handler: async ({ id }, ctx) => summarise(ctx.env, id),
+  },
+]);
+```
+
+- `app` — your Hono app, or anything with `all(path, handler)` and
+  `fetch(request, env, ctx)`.
+- `tools` — a list of [tool definitions](#tool-definitions) and
+  [AI SDK tool sets](#vercel-ai-sdk-tool-sets), mixed.
+- `options` — optional `{ name?, version? }`: the server name and version MCP
+  clients see. The name defaults to your project's slug.
+
+## createMcpToolsHandler(tools, options?)
+
+The same thing without Hono: returns a handler you route `MCP_PATH` to
+yourself.
+
+```ts
+import { createMcpToolsHandler, MCP_PATH } from "@mediamonks/canopy/mcp";
+
+const tools = createMcpToolsHandler(myTools, { app });
+
+export default {
+  fetch(request, env, ctx) {
+    if (new URL(request.url).pathname === MCP_PATH) return tools(request, env, ctx);
+    return app.fetch(request, env, ctx);
+  },
+};
+```
+
+**Returns** `(request, env?, executionCtx?) => Promise<Response>`. Pass the
+backend's `env` so handlers and route tools see `env.USER`, `env.CANOPY` and
+your secrets.
+
+**Options:** `{ app?, name?, version? }`. `app` is required when the list has
+route tools: they run its routes.
+
+Each request gets a fresh, stateless MCP server built on the official
+`@modelcontextprotocol/server`. It speaks both the current MCP protocol and
+the 2025 revision, so older clients work too.
+
+## Tool definitions
+
+A tool is an object in the MCP specification's shape, plus either a `handler`
+or a `route`:
+
+| Field          | Type                           |                                                                                       |
+| -------------- | ------------------------------ | ------------------------------------------------------------------------------------- |
+| `name`         | `string`                       | Required. Unique; letters, digits, `_`, `-` and `.`, at most 128.                     |
+| `description`  | `string`                       | What it does and when to use it. The agent reads this.                                |
+| `title`        | `string`                       | A display name.                                                                       |
+| `inputSchema`  | JSON Schema or Standard Schema | The arguments. Defaults to "no arguments".                                            |
+| `outputSchema` | JSON Schema or Standard Schema | Shape of the structured result, if you want clients to rely on it.                    |
+| `annotations`  | `McpToolAnnotations`           | Hints: `readOnlyHint`, `destructiveHint`, `idempotentHint`, `openWorldHint`, `title`. |
+| `handler`      | `(args, ctx) => unknown`       | Runs the tool.                                                                        |
+| `route`        | `"<METHOD> /path"`             | Runs one of your routes instead.                                                      |
+
+**Schemas** can be plain JSON Schema or any schema that implements Standard
+Schema with JSON Schema output: Zod 4, Valibot (with `toStandardJsonSchema`),
+ArkType. Arguments are validated against `inputSchema` before your handler or
+route runs. Invalid arguments come back to the agent as an error naming the
+field.
+
+**Annotations** matter to agents. Mark tools that change nothing with
+`readOnlyHint: true`. Unmarked tools are treated as possibly destructive, and
+clients usually ask the user before calling them.
+
+### Handler tools
+
+```ts
+{
+  name: "add_comment",
+  inputSchema: z.object({ noteId: z.string(), text: z.string().max(2000) }),
+  handler: async ({ noteId, text }, ctx) => {
+    const env = ctx.env as Env; // your backend's Env type
+    const canopy = createCanopy({ fetch: env.CANOPY.fetch.bind(env.CANOPY) });
+    return canopy.db.collection("comments").insert({ noteId, text, by: ctx.user?.email });
+  },
+}
+```
+
+What the handler returns becomes the result:
+
+- an object — sent as structured content, with a JSON text copy;
+- a string — sent as text;
+- an MCP `CallToolResult` (`{ content, structuredContent?, isError? }`) —
+  sent as is;
+- nothing — an empty result.
+
+Throw to report a failure. The agent gets a tool error with your message.
+
+**`ctx`** (`McpToolContext`):
+
+- `user` — the signed-in Monk (`{ sub, email, name }`), or `null`.
+- `agent` — `true` when an AI agent made the call through `canopy mcp`.
+- `toolCallId` — this call's id, for logs.
+- `signal` — an `AbortSignal`, aborted when the agent cancels.
+- `request` — the HTTP request the call arrived on, without platform
+  credentials.
+- `env` — your backend's env, as routes get it. Typed `unknown`: cast it to
+  your `Env`.
+
+`canopy.*` calls from a handler act as the user, as they would for that
+person's browser.
+
+### Route tools
+
+```ts
+{ name: "get_note", route: "GET /api/notes/:id", inputSchema: z.object({ id: z.string() }) }
+```
+
+The route runs in-process, with the same `env` and identity:
+
+- `:name` segments of the path are filled from the argument of that name. A
+  missing one is a tool error.
+- `GET` and `DELETE`: the other arguments become the query string (arrays
+  repeat the key, objects are sent as JSON).
+- `POST`, `PUT`, `PATCH`: the other arguments become a JSON body.
+- A 2xx JSON response becomes the result (structured when it's an object).
+  Other 2xx bodies become text.
+- Any other status becomes a tool error: `HTTP 403: {"error":"not_owner"}`.
+
+### Vercel AI SDK tool sets
+
+Put a tool set in the list as it is. Each key becomes a tool name:
+
+```ts
+import { tool } from "ai";
+
+const aiTools = {
+  weather: tool({
+    description: "Weather in a city",
+    inputSchema: z.object({ city: z.string() }),
+    execute: async ({ city }) => ({ city, tempC: 21 }),
+  }),
+};
+
+mountMcpTools(app, [...myTools, aiTools]);
+```
+
+`execute` gets the arguments and `{ toolCallId, abortSignal, messages: [] }`.
+Tools without `execute` are skipped. If the result is a stream, its last value
+is the answer.
+
+## MCP_PATH
+
+`"/__canopy/mcp"` — the one path on your backend that agents reach. Mount your
+own MCP server there if you don't use `mountMcpTools`. It must answer on that
+single URL with MCP's streamable HTTP transport.
+
+## mcpCaller(request, env?)
+
+Who is calling, in any route or in your own MCP server:
+
+```ts
+app.get("/api/notes", (c) => {
+  const { user, agent } = mcpCaller(c.req.raw, c.env);
+  // agent is true for a tools call that ran this route
+});
+```
+
+**Returns** `McpCaller`: `{ user: McpUser | null, agent: boolean }`.
+`user` comes from `env.USER`. Without `env`, it falls back to the identity the
+platform attached to the request.
+
+## When the tool list is wrong
+
+The list is checked on the first request. A duplicate or invalid name, a tool
+with neither or both of `handler` and `route`, a route tool without `app`, or
+a schema that can't describe itself as JSON Schema makes the tools endpoint
+answer `500 invalid_tools`, naming the tool. `canopy mcp add` shows that
+message. The rest of your backend keeps working.
+
+## Limits
+
+`canopy mcp serve` holds back tools whose description is over 2,048
+characters or whose input schema is over 16 KB, shows at most 64 tools, turns
+results over 512 KB into an error, and stops a call after 60 seconds.
+
+## Types
+
+All exported from `@mediamonks/canopy/mcp`: `McpTool`, `McpHandlerTool`,
+`McpRouteTool`, `McpToolAnnotations`, `McpToolContext`, `McpToolsInput`,
+`McpToolsOptions`, `McpCaller`, `McpUser`, `AiSdkToolSet`, `ToolSchema`,
+`JsonSchema`, `StandardSchemaLike`, `FetchApp`, `HttpMethod`.

package/dist/{docs-YD4z70gq.mjs → docs-BP5jmD10.mjs}

@@ -1,4 +1,4 @@
-import { t as version } from "./package-CiKTWo0_.mjs";
+import { t as version } from "./package-CQIPmdcO.mjs";
 import { n as siteConfig } from "./site-DM2J10CB.mjs";
 import { i as latestKnownVersion, r as compareSemver } from "./version-check-CcsA1QjI.mjs";
 import { r as reportErrors } from "./ui-C_jSc1Kz.mjs";

package/dist/{feedback-Cd7Rvg9a.mjs → feedback-5oPSxAz0.mjs}

@@ -1,4 +1,4 @@
-import { t as version } from "./package-CiKTWo0_.mjs";
+import { t as version } from "./package-CQIPmdcO.mjs";
 import { a as projectDirArgs, c as resolveProject, d as tryResolveProject, n as siteConfig, u as tryReadCanopyJson } from "./site-DM2J10CB.mjs";
 import { a as apiUpload, i as apiRequest, r as apiDownload } from "./api-C4rMhE7i.mjs";
 import { r as reportErrors, t as formatDateTime } from "./ui-C_jSc1Kz.mjs";