@mediamonks/canopy-cli 0.7.43 → 0.7.44

package/dist/{browse-dyOThTyf.mjs → browse-B8-0dweq.mjs}

@@ -15,7 +15,7 @@ var BrowseError = class extends Error {
 /** The control plane's refusal, in words that say what to do about it. */
 function explainBrowseRefusal(code, slug, detail) {
 	switch (code) {
-		case "members_only": return `${slug} is limited to its collaborators — ask the owner to add you.`;
+		case "members_only": return `${slug} is limited to its members — ask the owner to add you.`;
 		case "project_not_found": return `There is no project ${slug} on this site — check the slug and --profile.`;
 		case "project_paused": return `${slug} is paused.`;
 		case "project_moved": return `${slug} has moved${detail ? ` (${detail})` : ""}.`;

package/dist/dev-CUJKgaqJ.mjs

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

package/dist/{dev-adLLSY1F.mjs → dev-Cq98yblV.mjs}

@@ -2,7 +2,8 @@ import { a as projectDialect, f as tryReadCanopyJson, l as resolveProject, o as
 import { a as apiRequest, f as withContext, t as ApiError } from "./api-Bl6SG8Oq.mjs";
 import { r as reportErrors, t as formatDateTime } from "./ui-CLnICOne.mjs";
 import { r as readMigrationFiles } from "./migrations-D8NqjC5I.mjs";
-import { i as stampWorkerHeaders, n as WORKER_ATTEST_HEADER } from "./src-CScXotBB.mjs";
+import { i as stampWorkerHeaders, n as WORKER_ATTEST_HEADER } from "./src-8vxOBOxW.mjs";
+import { a as parseAppRoleFlag } from "./roles-UM0Iiws6.mjs";
 import { n as writeDevServerRecord } from "./dev-server-file-Dk9pk4AR.mjs";
 import { createRequire } from "node:module";
 import { defineCommand } from "citty";
@@ -10,6 +11,71 @@ import { existsSync } from "node:fs";
 import { join } from "node:path";
 import { randomBytes } from "node:crypto";
 import { pathToFileURL } from "node:url";
+//#region src/dev-roles.ts
+/** The roles a visitor holding `asRoles` carries: the default first, then theirs. */
+function overrideRoles(defaultRole, asRoles) {
+	const mine = [...new Set(asRoles)].filter((r) => r !== defaultRole);
+	return defaultRole ? [defaultRole, ...mine] : mine;
+}
+/** An /auth/me body with `roles` replaced; anything that isn't an object passes through. */
+function patchAuthMeRoles(body, roles) {
+	if (typeof body !== "object" || body === null || Array.isArray(body)) return body;
+	return {
+		...body,
+		roles
+	};
+}
+/**
+* The roles this dev session runs with, plus lines to print. `roles` is
+* undefined when nothing could be learned and nothing was asked for — the
+* worker then falls back to whatever /auth/me reports.
+*/
+async function resolveDevRoles(slug, asRoles) {
+	const notes = [];
+	const mine = await apiRequest("GET", `/projects/${slug}/me/roles`).catch(() => void 0);
+	if (!asRoles || asRoles.length === 0) {
+		if (mine && mine.roles.length > 0) notes.push(`  app roles: ${mine.roles.join(", ")}`);
+		return {
+			roles: mine?.roles,
+			override: false,
+			notes
+		};
+	}
+	const roles = overrideRoles(mine?.default ?? null, asRoles);
+	const known = await apiRequest("GET", `/projects/${slug}/roles`).then((r) => r.roles.map((role) => role.slug)).catch(() => void 0);
+	const unknown = known ? asRoles.filter((r) => !known.includes(r)) : [];
+	if (unknown.length > 0) notes.push(`  warning: ${slug} has no app role ${unknown.join(", ")} — its roles are ${known.length > 0 ? known.join(", ") : "(none yet)"}. Using it anyway.`);
+	notes.push(`  app roles: ${roles.join(", ") || "(none)"} (--as-role; the platform is unchanged)`);
+	return {
+		roles,
+		override: true,
+		notes
+	};
+}
+/**
+* Answers `/_api/data/v1/auth/me` with the platform's answer and `roles`
+* swapped, for the page and the worker alike (the worker's CANOPY.fetch goes
+* through the dev server's own `/_api`). Registered as a plain middleware so
+* it runs ahead of Vite's proxy.
+*/
+function authMeRolesPlugin(roles, upstream) {
+	return {
+		name: "canopy-dev-as-role",
+		configureServer(server) {
+			server.middlewares.use((req, res, next) => {
+				const path = (req.url ?? "").split("?")[0];
+				if (req.method !== "GET" || path !== "/_api/data/v1/auth/me") return next();
+				(async () => {
+					const response = await upstream();
+					const body = await response.json().catch(() => null);
+					res.writeHead(response.status, { "content-type": "application/json" });
+					res.end(JSON.stringify(response.ok ? patchAuthMeRoles(body, roles) : body));
+				})().catch(next);
+			});
+		}
+	};
+}
+//#endregion
 //#region src/dev.ts
 /**
 * Mirror the gateway (apps/gateway/src/index.ts): strip /_api and forward.
@@ -34,21 +100,25 @@ function workerDialect(flags) {
 * gateway serves it in production (dev-worker.ts). Returns the plugin plus
 * the notice lines to print, or undefined when the project has no worker.
 */
-async function workerPlugin(flags, slug, workerAttest, remoteUser) {
+async function workerPlugin(flags, slug, workerAttest, remoteUser, roles) {
 	const entry = tryReadCanopyJson(flags.dir)?.worker;
 	if (entry === void 0) return void 0;
 	if (!existsSync(join(flags.dir, entry))) {
 		console.log(`note: canopy.json points "worker" at ${entry}, which does not exist — skipping.`);
 		return;
 	}
-	const { missingSecretNames, readDevVars, workerDevPlugin } = await import("./dev-worker-DJekKSdb.mjs");
+	const { missingSecretNames, readDevVars, workerDevPlugin } = await import("./dev-worker-CcYwQjxz.mjs");
 	const secrets = readDevVars(flags.dir);
 	const email = siteConfig().email;
-	const user = await remoteUser?.() ?? (email ? {
+	const found = await remoteUser?.() ?? (email ? {
 		sub: "local-dev",
 		email,
 		name: "Local Dev"
 	} : null);
+	const user = found && roles ? {
+		...found,
+		roles
+	} : found;
 	const plugin = workerDevPlugin({
 		dir: flags.dir,
 		entry,
@@ -170,7 +240,8 @@ async function fetchDevUser(apiUrl, headers) {
 		return {
 			sub: me.id,
 			email: me.email ?? "",
-			name: me.name ?? ""
+			name: me.name ?? "",
+			...Array.isArray(me.roles) && { roles: me.roles }
 		};
 	} catch {
 		return;
@@ -223,14 +294,16 @@ async function bridgeToSandbox(sandbox, req, res) {
 async function devRemote(flags, slug) {
 	const { token, expires_at } = await withContext(apiRequest("POST", `/projects/${slug}/dev-token`), devTokenContext(slug));
 	const { apiUrl } = siteConfig();
-	const channel = flags.staging ? "staging" : "live";
-	const worker = await workerPlugin(flags, slug, void 0, () => fetchDevUser(apiUrl, devProxyHeaders(token, slug, channel)));
+	const proxyHeaders = devProxyHeaders(token, slug, flags.staging ? "staging" : "live");
+	const devRoles = await resolveDevRoles(slug, flags.asRoles);
+	const worker = await workerPlugin(flags, slug, void 0, () => fetchDevUser(apiUrl, proxyHeaders), devRoles.override ? devRoles.roles : void 0);
+	const asRolePlugin = devRoles.override && devRoles.roles ? [authMeRolesPlugin(devRoles.roles, () => fetch(`${apiUrl}/data/v1/auth/me`, { headers: proxyHeaders }))] : [];
 	const server = await startVite(flags, { proxy: { "/_api": {
 		target: apiUrl,
 		changeOrigin: true,
-		headers: devProxyHeaders(token, slug, channel),
+		headers: proxyHeaders,
 		rewrite: rewriteApiPath
-	} } }, worker ? [worker.plugin] : []);
+	} } }, [...asRolePlugin, ...worker ? [worker.plugin] : []]);
 	if (flags.staging) {
 		console.log(`\n  ${slug} — remote-first dev against the STAGING channel's data`);
 		console.log("  (live data is untouched; `canopy staging sync` re-clones it from live)");
@@ -244,6 +317,7 @@ async function devRemote(flags, slug) {
 		console.log("  while the schema is in flux");
 	}
 	for (const note of worker?.notes ?? []) console.log(note);
+	for (const note of devRoles.notes) console.log(note);
 	console.log("");
 	server.printUrls();
 	console.log(`\n  Dev token expires ${formatDateTime(expires_at)} — restart canopy dev after that.`);
@@ -251,7 +325,7 @@ async function devRemote(flags, slug) {
 async function devLocal(flags, slug) {
 	let dump;
 	if (flags.pull) {
-		const { fetchProjectDump } = await import("./local-2xtxtoUd.mjs");
+		const { fetchProjectDump } = await import("./local-CIkL7tXP.mjs");
 		console.log(`Pulling a fresh export of ${slug}${flags.staging ? " [staging]" : ""}…`);
 		dump = await fetchProjectDump(slug, flags.staging ? "staging" : "live");
 	}
@@ -267,11 +341,13 @@ async function devLocal(flags, slug) {
 		console.log(`Note: ai/services will be unavailable — could not reach the platform (${reason}).`);
 	}
 	const workerAttest = randomBytes(24).toString("base64url");
-	const { createSandbox } = await import("./local-2xtxtoUd.mjs");
+	const devRoles = await resolveDevRoles(slug, flags.asRoles);
+	const { createSandbox } = await import("./local-CIkL7tXP.mjs");
 	const sandbox = await createSandbox({
 		slug,
 		persistDir: join(flags.dir, ".canopy", "local"),
 		email: siteConfig().email,
+		roles: devRoles.roles ?? [],
 		dialect: flags.dialect,
 		workerAttest
 	});
@@ -304,7 +380,7 @@ async function devLocal(flags, slug) {
 		headers: { authorization: `Bearer ${remote.token}` },
 		rewrite: rewriteApiPath
 	};
-	const worker = await workerPlugin(flags, slug, workerAttest);
+	const worker = await workerPlugin(flags, slug, workerAttest, void 0, devRoles.roles ?? []);
 	const server = await startVite(flags, { proxy: {
 		...remoteEntry && {
 			"/_api/data/v1/ai": remoteEntry,
@@ -328,6 +404,7 @@ async function devLocal(flags, slug) {
 	console.log("  blobs are not pulled — the local blob store starts empty");
 	console.log(remote ? "  ai/services pass through to the platform (metered as usual)" : "  ai/services answer 501 until you log in and restart");
 	for (const note of worker?.notes ?? []) console.log(note);
+	for (const note of devRoles.notes) console.log(note);
 	console.log("");
 	server.printUrls();
 }
@@ -356,6 +433,10 @@ const devCommand = defineCommand({
 			type: "boolean",
 			default: false,
 			description: "Point remote dev at the staging channel's data (or pull the staging dump with --local --pull)"
+		},
+		"as-role": {
+			type: "string",
+			description: "Try the app as someone with this app role instead of your own (repeatable; the default role stays)"
 		}
 	},
 	run: reportErrors("dev", async ({ args }) => {
@@ -370,7 +451,8 @@ const devCommand = defineCommand({
 			local: args.local,
 			pull: args.pull,
 			staging: args.staging,
-			dialect: projectDialect(dir)
+			dialect: projectDialect(dir),
+			asRoles: parseAppRoleFlag(args["as-role"])
 		};
 		await (flags.local ? devLocal(flags, slug) : devRemote(flags, slug));
 	})

package/dist/{dev-worker-DJekKSdb.mjs → dev-worker-CcYwQjxz.mjs}

@@ -1,4 +1,4 @@
-import { i as stampWorkerHeaders, n as WORKER_ATTEST_HEADER, r as redactCanopyCredentials, t as CALLER_HEADER } from "./src-CScXotBB.mjs";
+import { i as stampWorkerHeaders, n as WORKER_ATTEST_HEADER, r as redactCanopyCredentials, t as CALLER_HEADER } from "./src-8vxOBOxW.mjs";
 import { readFileSync } from "node:fs";
 import { relative, resolve, sep } from "node:path";
 //#region src/dev-worker.ts
@@ -189,14 +189,22 @@ function createDevBlob(canopyFetch, prefix) {
 		}
 	};
 }
+/** Stamped app roles (project-roles); undefined when the request carries none. */
+function rolesFromHeaders(headers) {
+	const raw = headers.get("x-canopy-identity-roles");
+	if (raw === null) return void 0;
+	return raw.split(",").map((r) => r.trim()).filter(Boolean);
+}
 /** Gateway-stamped identity, honored in dev too so a request can pose as one. */
 function userFromHeaders(headers, fallback) {
 	const sub = (headers.get("x-canopy-user-sub") ?? "").trim();
 	if (!sub) return fallback;
+	const roles = rolesFromHeaders(headers);
 	return {
 		sub,
 		email: (headers.get("x-canopy-user-email") ?? "").trim(),
-		name: (headers.get("x-canopy-user-name") ?? "").trim()
+		name: (headers.get("x-canopy-user-name") ?? "").trim(),
+		...roles && { roles }
 	};
 }
 /**
@@ -208,20 +216,25 @@ function callerFromHeaders(headers, fallback) {
 	const kind = (headers.get("x-canopy-identity-kind") ?? "").trim();
 	const id = (headers.get("x-canopy-identity-id") ?? "").trim();
 	const agent = headers.get("x-canopy-caller") === "agent";
-	if ((kind === "monk" || kind === "external") && id) return {
-		kind,
-		id,
-		email: (headers.get("x-canopy-identity-email") ?? "").trim(),
-		name: (headers.get("x-canopy-identity-name") ?? "").trim(),
-		agent
-	};
+	if ((kind === "monk" || kind === "external") && id) {
+		const roles = rolesFromHeaders(headers);
+		return {
+			kind,
+			id,
+			email: (headers.get("x-canopy-identity-email") ?? "").trim(),
+			name: (headers.get("x-canopy-identity-name") ?? "").trim(),
+			agent,
+			...roles && { roles }
+		};
+	}
 	const user = userFromHeaders(headers, fallback);
 	return user ? {
 		kind: "monk",
 		id: user.sub,
 		email: user.email,
 		name: user.name,
-		agent
+		agent,
+		...user.roles && { roles: user.roles }
 	} : null;
 }
 /**

package/dist/docs/agent-browsing.md

@@ -16,7 +16,7 @@ It prints a one-time link. Whatever browser opens it is signed in to **my-app**,
 ## What the agent gets
 
 - **One project, one channel.** The live site, or staging with `--staging`. The browser is not signed in to your other projects, or to the dashboard.
-- **You.** The app sees you as the visitor, exactly as when you open it yourself. Your backend's `env.USER` is you, and data you can see, the agent can see. On a collaborators-only project you have to be a collaborator.
+- **You.** The app sees you as the visitor, exactly as when you open it yourself. Your backend's `env.USER` is you, and data you can see, the agent can see. On a members-only project you have to be a member.
 - **An hour.** After that the agent meets the sign-in page and can run `canopy browse` again.
 - **Marked as an agent.** Your backend can tell the request came from an agent: `mcpCaller(request, env).agent` from `@mediamonks/canopy/mcp` is `true`.
 
@@ -47,7 +47,7 @@ The agent's session ends when the hour is up. It also ends early if you:
 - revoke that CLI sign-in on your Account page in the dashboard, or
 - sign out everywhere.
 
-If you lose access to a collaborators-only project, the agent loses it too.
+If you lose access to a members-only project, the agent loses it too.
 
 ## Good to know
 

package/dist/docs/agent-tools.md

@@ -136,7 +136,7 @@ schema to decide what to send. A few habits help a lot:
 ## Connect your agent
 
 Anyone who can open the project in a browser can connect. For
-collaborators-only projects, that means collaborators only. From a terminal:
+members-only projects, that means members only. From a terminal:
 
 ```bash
 canopy mcp add <slug>
@@ -202,7 +202,7 @@ an agent (`agent`), in any route. Two limits apply to your own server:
 - They can only call your tools. They can't reach your app's pages or `/api/*`
   routes directly, the dashboard, or other projects.
 - Their access ends when the person signs out (`canopy logout`, or "sign out
-  everywhere"), or loses access to a collaborators-only project.
+  everywhere"), or loses access to a members-only project.
 - Very long tool descriptions or schemas are held back, a project shows at
   most 64 tools, results over 512 KB become an error, and a call stops after
   60 seconds.

package/dist/docs/ci.md

@@ -27,7 +27,7 @@ can deploy that one project and nothing else.
 
 ## Create a token
 
-Only the project owner can create a deploy token (any collaborator can list
+Only the project owner can create a deploy token (any editor can list
 and revoke them). From inside the project directory:
 
 ```bash

package/dist/docs/cli-browse.md

@@ -24,7 +24,7 @@ The site comes from the active profile, as for every command (`--profile staging
 
 ## How it works
 
-The command uses your `canopy login` sign-in to ask Canopy for a link to the project, under the same rules as opening it yourself. Collaborators-only projects only give links to collaborators.
+The command uses your `canopy login` sign-in to ask Canopy for a link to the project, under the same rules as opening it yourself. Members-only projects only give links to their members.
 
 - The link **works once** and **expires after a minute**. Run the command again for a new one.
 - The browser that opens it is signed in to that project and channel for an hour. After that it sees the sign-in page again.

package/dist/docs/cli-dev.md

@@ -21,6 +21,7 @@ canopy dev --local --pull       # sandbox hydrated from a fresh prod export
 - `--local` — use the local-data sandbox instead of live data. Default off.
 - `--pull` — hydrate the sandbox from a fresh export of the project's production database first. Only valid with `--local`; the command errors otherwise (remote dev already sees live data).
 - `--staging` — point remote dev at the [staging channel's](https://docs.canopy.website/guides/staging) data instead of live (the safe remote target while a schema is in flux), or, with `--local --pull`, hydrate the sandbox from the staging dump.
+- `--as-role <slug>` — run as someone with that [app role](https://docs.canopy.website/guides/roles) instead of your own (repeatable). You keep the project's default role, as a real visitor would. `auth.user()` and `env.CALLER` both report the override, and nothing changes on the platform. Without it, dev runs with your real roles.
 - `--profile <site>` / `CANOPY_PROFILE` — which site the dev token and API calls target. Projects usually pin a profile in `canopy.json`.
 
 ## How it works

package/dist/docs/cli-mcp.md

@@ -79,7 +79,7 @@ While developing: the tools from your working tree, served by `canopy dev`.
 usual cases:
 
 - **Not signed in** — run `canopy login`.
-- **Limited to its collaborators** — ask the owner to add you.
+- **Limited to its members** — ask the owner to add you.
 - **No backend, or serves no tools** — the project has no `worker/`, or it
   doesn't mount any tools yet.
 - **Redeploy required** — the backend was deployed before tools existed. Run

package/dist/docs/cli-members.md

@@ -0,0 +1,41 @@
+---
+title: canopy members
+description: See who is on the project, add people as editors or viewers, and give them app roles.
+---
+
+`canopy members` manages the project's roster from a terminal: the same as
+the **Members** card under Settings → Access. See
+[Members and access](https://docs.canopy.website/platform/members-and-access) for what editors and
+viewers can do.
+
+## Usage
+
+```bash
+canopy members list
+canopy members add jane@monks.com
+canopy members add sam@monks.com --viewer --app-role approver
+canopy members set sam@monks.com --app-role approver --app-role reviewer
+canopy members set sam@monks.com --editor
+canopy members set sam@monks.com --clear-app-roles
+canopy members remove sam@monks.com
+```
+
+## Arguments & flags
+
+All subcommands find the project the usual way (`canopy.json` in the target
+directory, or `--project <slug>`) and honor the global `--profile <site>`.
+
+- `list` prints everyone on the project and every pending invite, with their
+  Canopy role and app roles. `--json` prints the same as JSON.
+- `add <email>` adds someone as an editor, or a viewer with `--viewer`.
+  Someone who hasn't signed in to Canopy yet gets an invite and joins at their
+  first sign-in. Owner only.
+- `set <email>` changes someone. `--editor` or `--viewer` changes their Canopy
+  role (owner only). `--app-role <slug>` sets their app roles, replacing what
+  they had (repeat it, or separate slugs with commas), and `--clear-app-roles`
+  takes them all away. Editors can change app roles.
+- `remove <email>` takes someone off the project, or withdraws their invite.
+  Owner only.
+
+`--app-role` takes slugs from [`canopy roles list`](https://docs.canopy.website/cli/roles). The default
+role needs no assigning: everyone has it.

package/dist/docs/cli-roles.md

@@ -0,0 +1,39 @@
+---
+title: canopy roles
+description: Create, rename and remove the project's app roles, and pick the default.
+---
+
+`canopy roles` manages your project's [app roles](https://docs.canopy.website/guides/roles): the labels
+your app reads as `roles` on the signed-in user. It does the same job as the
+**App roles** card under Settings → Access. Owners and editors can use it.
+
+## Usage
+
+```bash
+canopy roles list
+canopy roles list --json
+canopy roles add "Approver"
+canopy roles add "Sign-off lead" --slug lead
+canopy roles rename approver "Sign-off"
+canopy roles default reader
+canopy roles remove approver
+```
+
+## Arguments & flags
+
+All subcommands find the project the usual way (`canopy.json` in the target
+directory, or `--project <slug>`) and honor the global `--profile <site>`.
+
+- `list` prints each role's slug and name, with the default marked. `--json`
+  prints the same as JSON, handy for an agent before it writes a role check.
+- `add <name>` creates a role. The slug comes from the name unless you pass
+  `--slug`. Slugs are 1–32 lowercase letters, digits and dashes, starting with
+  a letter, and never change. The first role becomes the default. A project
+  has at most 20 roles.
+- `rename <slug> <name>` changes the display name. The slug stays.
+- `default <slug>` makes that role the default, which everyone who can open
+  the app has.
+- `remove <slug>` deletes the role and takes it away from everyone. Make
+  another role the default before removing the current default.
+
+To give roles to people, use [`canopy members`](https://docs.canopy.website/cli/members).

package/dist/docs/cli-token.md

@@ -17,7 +17,7 @@ canopy token revoke <id>
 
 All subcommands resolve the project the usual way — `canopy.json` in the target directory, or `--project <slug>` to override — and honor the global `--profile <site>` / `CANOPY_PROFILE` for which site the token belongs to.
 
-- `create` — mint a new deploy token for the project. Owner only: collaborators get a clear error and should ask the owner.
+- `create` — mint a new deploy token for the project. Owner only: editors get a clear error and should ask the owner.
   - `--name <label>` — a label shown in the dashboard, e.g. `"GitHub Actions"`. Optional but recommended so you can tell tokens apart later.
 - `list` — show the project's deploy tokens: id, name, creation time, who created them, and when each was last used. Token values are never shown here.
 - `revoke <id>` — delete a token by its id (from `canopy token list`). Deploys using it stop working immediately.

package/dist/docs/index.json

@@ -52,6 +52,11 @@
           "title": "Staging & promoting",
           "summary": "Deploy to a safe copy of your project first — own database cloned from live — then promote the exact same version."
         },
+        {
+          "slug": "roles",
+          "title": "Roles and permissions",
+          "summary": "Give people different powers inside your app with app roles, and check them where it counts."
+        },
         {
           "slug": "data",
           "title": "Working with project data",
@@ -157,7 +162,7 @@
         {
           "slug": "platform-members-and-access",
           "title": "Members & access",
-          "summary": "Everything on Canopy sits behind Monks sign-in. Collaborators manage a project; other Monks can view the live app — unless you tighten it."
+          "summary": "Everything on Canopy sits behind Monks sign-in. Editors manage a project, viewers open it, and your app can hand out its own roles on top."
         },
         {
           "slug": "platform-feedback",
@@ -296,6 +301,16 @@
           "title": "canopy secrets",
           "summary": "Set, list, and remove the project's worker secrets from the terminal."
         },
+        {
+          "slug": "cli-members",
+          "title": "canopy members",
+          "summary": "See who is on the project, add people as editors or viewers, and give them app roles."
+        },
+        {
+          "slug": "cli-roles",
+          "title": "canopy roles",
+          "summary": "Create, rename and remove the project's app roles, and pick the default."
+        },
         {
           "slug": "cli-schedule",
           "title": "canopy schedule",

package/dist/docs/overview-faq.md

@@ -9,7 +9,7 @@ start with [getting started](https://docs.canopy.website/guides/getting-started)
 ## Who can see my project?
 
 By default, any Monk who signs in with OneLogin. If that's too broad, switch
-the project to **collaborators only** in Settings — then only the people you've
+the project to **members only** in Settings — then only the people you've
 invited can open the live app (it still appears in the company project list,
 and platform admins can still manage it).
 
@@ -63,9 +63,11 @@ agent so it knows how the platform works.
 
 ## Can I work on it with teammates?
 
-Yes. Invite people from the project's page in the dashboard with the people
-picker — as admins or collaborators. Combined with collaborators-only mode,
-this also controls who can open the live app.
+Yes. Add people under **Settings → Access** in the dashboard: as editors,
+who work on the project with you, or as viewers, who can only open the app.
+Combined with members-only mode, this also controls who can open the live
+app. Your app can give people its own roles too, see
+[Roles and permissions](https://docs.canopy.website/guides/roles).
 
 ## Can I bring an app I already started?
 

package/dist/docs/overview-how-it-works.md

@@ -28,7 +28,7 @@ address exists as soon as the project does.
 
 Visitors to your project's URL hit OneLogin before they see anything. By
 default any Monk can open it. From the project's Settings you can tighten that
-to collaborators only, or add a shared client password so people outside Monks
+to members only, or add a shared client password so people outside Monks
 can view it. The password stays visible in Settings, so you can look it up and
 share it again later. There is no "make it public" switch — that's by design.
 
@@ -76,7 +76,8 @@ loop gone wrong stops at the cap instead of running up a bill.
 | **Snapshot**              | A saved copy of a project's database you can restore later.                                                                                                      |
 | **Slug**                  | The project's short name — the first part of its URL.                                                                                                            |
 | **Site** (or **profile**) | An installation of the Canopy platform. Most people only ever use the main one; the CLI can point at others (like staging) and always shows which one you're on. |
-| **Collaborator**          | A teammate invited to a project through the dashboard's people picker.                                                                                           |
+| **Member**                | Someone on a project's roster: an editor, who works on the project, or a viewer, who can only open the app.                                                      |
+| **App role**              | A label your app gives people, like `approver`, read as `roles` on the signed-in user.                                                                           |
 
 - [Getting started](https://docs.canopy.website/guides/getting-started) — From nothing to a live project, step by step.
 - [Local development](https://docs.canopy.website/guides/dev) — Preview changes on your machine against your real project data.

package/dist/docs/overview-use-cases.md

@@ -40,7 +40,7 @@ content is a normal use, not an exception.
 - A strategist vibecoding a pitch prototype over a weekend, sharing it Monday
   behind a client password.
 - A producer building a tracker the whole team uses daily, with teammates
-  invited as collaborators.
+  invited as members.
 - A developer prototyping an AI-assisted workflow with a custom backend,
   scheduled jobs, and secrets — still inside platform auth and budgets.
 

package/dist/docs/overview-what-is-canopy.md

@@ -35,7 +35,7 @@ behind the scenes, so for you it looks like this:
   don't set up servers, domains, or certificates.
 - **Sign-in, always on.** Every project sits behind Monks OneLogin
   automatically. Any Monk can open it by default; you can tighten access to
-  collaborators only, or add a shared password so clients without a Monks
+  members only, or add a shared password so clients without a Monks
   account can see work-in-progress. Nothing on Canopy is ever truly public.
 - **Data and files.** Each project has its own private database and file
   storage. No tables to design, no migrations, no connection strings — and no

package/dist/docs/platform-client-access.md

@@ -57,7 +57,7 @@ route that should serve clients checks `env.CALLER`, not `env.USER`. See
 ## Playing well with other access controls
 
 Client access is independent of
-[collaborators-only mode](https://docs.canopy.website/platform/members-and-access): you can lock
+[members-only mode](https://docs.canopy.website/platform/members-and-access): you can lock
 the app down for Monks outside the team while a client with the password
 still gets in. That combination — "the client and the project team, nobody
 else" — is a common setup during a review phase.