@marver-design/marver 0.13.0 → 0.14.0

package/dist/{shot-Cyv3GN79.mjs → shot-kbR_xzJH.mjs}

@@ -1,4 +1,4 @@
-import { i as ROUTE } from "./cli.mjs";
+import { a as slideSize, i as ROUTE } from "./cli.mjs";
 import { existsSync, mkdirSync, mkdtempSync, readFileSync, rmSync, writeFileSync } from "node:fs";
 import { join } from "node:path";
 import { tmpdir } from "node:os";
@@ -38,6 +38,12 @@ const clamp = (n, lo, hi) => Math.min(hi, Math.max(lo, n));
 function planShot(frame, viewports) {
 	const cw = typeof frame.contentWidth === "number" && Number.isFinite(frame.contentWidth) && frame.contentWidth > 0 ? frame.contentWidth : void 0;
 	const vpObj = frame.viewport ? viewports[frame.viewport] : void 0;
+	const sl = slideSize(frame);
+	if (sl) return {
+		width: sl.width,
+		initialHeight: sl.height,
+		fullHeight: false
+	};
 	const fallback = viewports.mobile ?? {
 		width: 390,
 		height: 844

package/docs/live-jam.md

@@ -0,0 +1,173 @@
+# Live Jam
+
+Tag `@marver` in a canvas comment while `npx marver dev` is running. The dev server spawns
+your own coding-agent CLI headless with that one job, the frame lights up with a working
+glow, the agent edits the real frame source, and its reply lands back in the same thread.
+No round trip to the terminal. Marver ships no AI: the agent that acts is the one you
+already run and pay for.
+
+## It arms itself
+
+Live Jam is on by default (since 0.9.0). Marver speaks seven agent CLIs - `claude`,
+`codex`, `cursor`, `droid` (Factory), `opencode`, `grok`, and `pi` - which also covers the
+apps built on them: Factory drives `droid`, Cursor drives `cursor-agent`, Conductor drives
+`claude`. Marver looks for one in this order:
+
+1. **The tool running the process wins.** Most CLIs export env markers into what they spawn
+   (`CLAUDECODE` for Claude Code, `CODEX_SANDBOX` for Codex, `CURSOR_AGENT` for Cursor,
+   `OPENCODE` for opencode, `PI_CODING_AGENT` for pi), and `marver init` is usually run by
+   the agent itself. That is evidence, not a guess. droid and grok set no marker in the
+   shells they spawn, so this step cannot see them - name them in config or let PATH decide.
+2. **Otherwise, whatever is on PATH**, in the order above - `claude` first.
+
+That second step is a guess, so the answer is made visible rather than clever: `init` prints
+the agent it chose and writes it into `design/config.ts` in plain sight, and `marver dev`
+names it at boot (`jam: on (claude)`). One word to correct, once per repo.
+
+The candidate has to be executable on `PATH` under its bare name, because the daemon spawns
+it without a shell. A shell alias or function is invisible to it. Cursor is the one agent
+whose binary differs from its config name: marver spawns `cursor-agent`, never the bare
+`agent` - both Cursor and grok install an `agent` name, so the short one is a coin flip.
+
+With no agent CLI installed, jam stays off and both `init` and `marver dev` say so instead
+of going quiet. Workspaces created before 0.9.0 need no re-init; they resolve the same way
+at every dev boot.
+
+## The config block
+
+```ts
+// design/config.ts
+jam: { agent: "claude", concurrency: 6 },
+```
+
+| Key | Default | What it does |
+|---|---|---|
+| `agent` | detected | The CLI the daemon spawns: `"claude"`, `"codex"`, `"cursor"`, `"droid"`, `"opencode"`, `"grok"`, or `"pi"` |
+| `concurrency` | `6` | Frames worked on at once (1-16). The same frame never gets two agents |
+| `subagents` | `true` | Inside one job, fan out one subagent per frame |
+
+Shorthands: `jam: "codex"` names the agent and takes the rest of the defaults, `jam: true`
+is the default block, and **`jam: false` is the off switch**.
+
+A named agent is never quietly swapped for another. If `jam.agent` names something marver
+cannot spawn, or names a CLI that is not on PATH, Live Jam turns off with a printed reason
+rather than answering your comments with a tool you did not choose. A `design/config.ts`
+that fails to parse also leaves jam off, since it may have been the file that said
+`jam: false`.
+
+## What the agent may do
+
+Be clear-eyed about what this is. The real protection is not a sandbox - it is that the
+agent doing the work is **your own**, running on **your machine**, and **every change it
+makes is a diff you review** before anything is resolved. On top of that, marver removes the
+one tool that would turn a prompt-injected comment into silent damage: an unrestricted
+**shell**. Each CLI is spawned so the model can read and edit files but cannot open a shell
+(or, for Codex and Cursor, only a shell the OS sandbox contains and cuts off from the
+network):
+
+| | How it is spawned |
+|---|---|
+| **Claude Code** | `claude -p --permission-mode acceptEdits` with an allowlist of Read, Edit, Write, Glob, Grep, WebSearch, WebFetch - and `--disallowedTools Bash`, so there is no shell |
+| **Codex** | `codex exec -s workspace-write`, its own OS sandbox, which bounds what commands touch and blocks network egress, but still lets the model run shell commands |
+| **Cursor** | `cursor-agent -p --sandbox enabled --trust` - cursor's print mode carries a shell, so like Codex it runs inside the OS sandbox (verified: network egress is blocked); `--trust` only answers the workspace-trust prompt for the repo you already run `marver dev` in, and `--force` is never passed |
+| **droid** | `droid exec --auto low` for file edits, with `--disabled-tools` removing the shell (`Execute`), the delegation tools (`Task`, missions), and the Slack/connector tools |
+| **opencode** | `opencode run --pure` (no external plugins) with a per-run DEFAULT-DENY `OPENCODE_PERMISSION` grant - read/edit/search/web/task allowed by name, everything else (bash included) denied - never its all-approving `--auto` flag |
+| **grok** | `grok -p --tools read_file,search_replace,list_dir,grep,todo_write` - an ALLOWLIST of read/edit tools only, so the shell, web, and subagents are simply absent (a deny-list is a footgun: it can miss a tool's real name); `--permission-mode acceptEdits` auto-applies the edits |
+| **pi** | `pi -p --tools read,edit,write,grep,find,ls --no-extensions --no-skills` - pi has no runtime permission system, so the tool allowlist IS the jail, and bash is not on it |
+
+The honest limits: file tools that take a path (Read/Edit/Write, and their equivalents) are
+not themselves jailed to `design/` - on the CLIs without an OS sandbox they can, if a
+comment talks the model into it, touch a file elsewhere in the repo or the machine. And Web
+access, where a CLI keeps it, can carry data outward. This is the same boundary Claude Code
+has always run under, and it is why the two rules above still do the real work: it is your
+agent, and you review the diff. Do not point Live Jam at a repo, or run it on a machine, you
+would not hand that same agent directly.
+
+Web access stays on where the CLI offers it (Claude Code, Codex, opencode): reference sites
+and real brand SVGs are how a frame stops looking like a placeholder. The agent never
+resolves a thread; you do that after reviewing.
+
+The missing sense that no-shell used to cost - "does my frame actually RENDER?" - is a
+server capability instead, rendered in the machine's own headless Chrome (no bundled
+browser, CDP over Node's built-in WebSocket) and written as a PNG under
+`design/.local/shots/`. Two transports reach it, because the no-shell jail rules out the
+obvious one:
+
+- **The file-drop inbox** (works for every agent, including Claude Code, which has no shell
+  and whose WebFetch refuses localhost). The agent writes
+  `design/.local/shots/<slug>.request.json` with `{"frame":"<id>","theme":"<t>"}`; the dev
+  server renders and writes `<slug>.result.json` with the PNG path or an error, which the
+  agent Reads.
+- **`npx marver shot <frame>`** / `GET /api/shot?frame=<id>&theme=<t>` for humans and
+  shell-ful agents - the same renderer, one line.
+
+The generated jam instructions tell every agent to shoot and LOOK before replying "done".
+A frame that never mounts, or a dev server that isn't reachable, comes back as an honest
+`{"ok":false,"error":...}` carrying the real cause - never a blank that reads as success.
+
+One prerequisite marver cannot arrange: **the CLI has to be logged in** (`droid` and
+`cursor-agent login` and `grok login` each have their own flow; opencode and pi can also
+read provider API keys from the environment). An unauthenticated CLI fails the job; the
+daemon retries once, then replies that it could not finish - the dev log and
+`design/.local/jam-logs/` say why.
+
+## The trust boundary
+
+Only comments written on the owner's machine can start work. A mention becomes eligible
+solely by way of the local dev server's owner-gated endpoint (a CSRF double-submit cookie
+plus an Origin allowlist), which appends it to `design/.local/jam-ledger`. The daemon runs
+a job only for an event id that is already in that ledger, so a drive-by comment on a
+published canvas cannot trigger one, and neither can a collaborator comment that arrived
+through `marver comments sync`.
+
+The ledger and the job journal both carry a device stamp, because gitignore is a convention
+and not provenance: a repo can force-add its own `.local/`. Jam state that arrived with a
+clone is read as absent. The stamp is derived from the machine rather than stored, so
+marver still writes nothing outside `design/`.
+
+The larger caution is unchanged and worth stating plainly: `marver dev` imports and executes
+`design/config.ts`, so running a dev server in a repo you do not trust is already running
+that repo's code. Live Jam adds no new hole to that; it does not make it safe.
+
+## Provenance
+
+Every jam reply is stamped with who acted: your dev user, the harness that ran, and the
+model when the agent names one. Claude Code, Cursor, droid, grok, and pi report their model
+in the stream; `codex exec` and `opencode run` report none, so their replies carry the
+harness without a model rather than a guessed one.
+
+## Parallelism
+
+Two knobs stack, and they are not the same thing. `jam.concurrency` is how many jobs the
+daemon runs at once - different frames, different comments. `jam.subagents` is fan-out
+*inside* one job, one subagent per frame, which is what makes a five-frame ask land
+together instead of in series. Claude Code, Codex, and opencode fan out (opencode's
+subagents verifiably inherit the jail); pi has no subagent tool, and droid and grok have
+theirs removed in the spawn itself (`--disabled-tools Task`, `--no-subagents`) until a
+child is proven to inherit the parent's confinement. Their jobs simply run the frames in
+sequence - the prompt only ever says the agent MAY fan out.
+
+Two honest caveats in the same spirit as the config-execution one above: cursor's own
+permission rules (`~/.cursor/cli-config.json`, a repo's `.cursor/cli.json`) and a repo's
+own `opencode.json` agent block can widen what those CLIs allow - that is your
+configuration speaking, and marver does not override it.
+
+## When a mention does nothing
+
+- **It has to be your machine, your repo, with `marver dev` running.** That is the trust
+  boundary above, working as intended.
+- **The first boot after upgrading to 0.9.0 rebaselines the job journal**, because an
+  existing journal predates the device stamp. Any `@marver` left unprocessed while the
+  server was down is marked seen instead of run. Re-comment to pick it up.
+- **Check the boot line.** `marver dev` prints `jam: on (<agent>)` when it is armed, and
+  prints the reason when it is not.
+- **Read the raw run log.** Every job's full agent output lands in
+  `design/.local/jam-logs/` (last 10 kept) - an auth failure or permission refusal
+  explains itself there. The generated `design/instructions/jam.md` carries the full
+  troubleshooting drill, written for your agent to run: it checks the boot line, the log,
+  and the CLI's own headless auth, fixes what belongs to the workspace, and files what
+  belongs to marver at [github.com/TNEP4/marver/issues](https://github.com/TNEP4/marver/issues) -
+  with the patch, when it found one while debugging.
+
+`npx marver comments list --open --json` reads the same threads without the live loop, for
+catching up or for a one-off answer.

package/docs/publish.md

@@ -0,0 +1,270 @@
+# Publishing a Marver canvas
+
+A published canvas is a static site: `marver build` bundles the shell, the prototype
+stage, and your frames with all data inlined - it fetches nothing, saves nothing, and
+runs on any static host. `marver serve` hosts it, optionally behind a gate - a shared
+password, or Marver Sign In (see [Who can open your canvas](#who-can-open-your-canvas)).
+Give it a persistent volume (`MARVER_DATA_DIR`) and comments + viewer accounts persist
+across deploys (`MARVER_OWNER_EMAIL` bootstraps the first owner account).
+
+Publishing is default-closed: `design/publish.json` names the boards that ship and
+their rights (`"read"` or `"comment"`) - no policy and no explicit flag means no build.
+A board row can also be an object that says how the board presents - its `type`
+(`doc`, `slides`, `design`, `sketch`, `refs`, `mix`), the view visitors land in
+(`open`: `canvas`, `board`, `present`, `focus`, `slides`), `lock` to freeze them
+there, and for decks `transition` / `chrome` - the fields are spelled out in the
+[sharing guide](sharing.md#publishjson-v2---the-ceiling-and-the-boards-shape) and,
+for decks, the [slides guide](slides.md).
+
+```bash
+npx marver build                      # boards named in design/publish.json → design/.dist
+npx marver build --boards checkout    # only these boards - the frame filter is applied
+                                      # at BUILD time; excluded frames never enter the bundle
+MARVER_PASSWORD=secret npx marver serve            # a shared password, or:
+MARVER_ID_ISSUER=https://id.marver.design \
+  MARVER_PUBLIC_ORIGIN=https://your.canvas \
+  MARVER_DATA_DIR=/data npx marver serve           # accounts, one sign-in across canvases
+```
+
+Deep links work verbatim: any `#/b/...` or `#/p/...` URL copied from your dev canvas
+opens the same view on the published site, as long as its board and frame shipped.
+
+**What ships**: the boards you list, the frames they reference, and the host `public/`
+directory in full (the `--boards` filter covers frames, not public assets). A flow you
+publish must have all its `data-goto` targets on a published board.
+
+## Who can open your canvas
+
+Three choices, and the canvas is public until you make one.
+
+| | **Open** | **Password** | **Marver Sign In** |
+|---|---|---|---|
+| Set | nothing | `MARVER_PASSWORD` | `MARVER_ID_ISSUER` + `MARVER_PUBLIC_ORIGIN` |
+| People prove | nothing | they know a secret | who they are |
+| Named accounts | none | only with `MARVER_DATA_DIR` | always (needs `MARVER_DATA_DIR`) |
+| Who decides entry | - | you | you |
+| Outbound requests | none | none | public keys only |
+| Best for | a public canvas | one link to a small group | a team, across canvases |
+
+`MARVER_DATA_DIR` is what turns a gate into accounts. Without it the password gate
+is exactly one shared secret and nothing else - no per-person identity, no comments
+that persist, and nothing for `marver comments invite` to write to. Marver Sign In
+requires it outright, because identity accounts need somewhere to live.
+
+They are alternatives, not layers. Setting both `MARVER_PASSWORD` and
+`MARVER_ID_ISSUER` would weaken your invite list to "an account OR whoever has the
+password", so the identity gate replaces the password gate rather than sitting
+beside it.
+
+**Whichever you choose, the guest list stays yours.** This is the part worth
+reading twice: with Marver Sign In, the identity service proves *who somebody is*
+and has no say in *where they may go*. Your canvas decides that, from a list it
+holds. Somebody with a perfectly valid Marver account who is not on your list
+gets nothing.
+
+And the honest fine print, because this is a promise we publish rather than a
+slogan: Marver stores which canvases a person has *signed in to*, and issues
+short-lived tokens for them. What someone can **do** on your canvas is answered
+by your canvas to their own browser, cached only there, and never sent to us.
+Two things do cross the line, both disclosed and both optional: an invite email
+means the identity service learns that an address was invited to your origin
+(that is what sending the mail requires - decline it entirely with
+`share: { notify: false }` in `design/config.ts` and use the dialog's "copy
+invite message" instead), and the front door at `app.marver.design` learns
+which origins a person probes (`share: { frontDoor: false }` keeps your canvas
+silent there). The app ships no third-party analytics and no summary telemetry.
+
+**Sharing, precisely.** Sharing controls who may **comment**, and who gets in
+at all. What a person who is in can **see** is decided at build time by
+`design/publish.json` - boards you do not publish are not in the bundle. One
+canvas per audience is the read boundary today; per-person read arrives in v2,
+served rather than bundled. Managing that roster - granting people, blocking
+them, approving access requests, and reading who-sees-what from the terminal -
+is its own guide: [Sharing a Marver canvas](sharing.md).
+
+### Sovereign accounts (`MARVER_PASSWORD` + `MARVER_DATA_DIR`)
+
+```bash
+MARVER_PASSWORD=secret MARVER_DATA_DIR=/data npx marver serve
+```
+
+Everything stays here. Accounts live in `MARVER_DATA_DIR` as scrypt hashes, invites
+are minted by you, and the canvas makes no outbound request of any kind - there is
+no service to depend on and nothing to phone home to. If you want a canvas that
+still works in ten years on a disconnected network, this is it.
+
+`MARVER_PASSWORD` on its own is a simpler thing: one shared secret in front of the
+bundle, with no accounts behind it. Add the volume when you want named people.
+
+Auth is an HMAC-signed 30-day cookie with a per-boot secret (a server restart
+re-prompts), and each password attempt pays an scrypt cost. Invite people with
+`marver comments invite <email>`; they claim it in the browser and choose a
+password.
+
+**Set `MARVER_PUBLIC_ORIGIN` here too if you serve over https.** It is required for
+Marver Sign In and optional here, but it is what puts `Secure` on that 30-day
+cookie. Without it the canvas has to guess from `X-Forwarded-Proto`, and nginx's
+own documented `proxy_pass http://localhost:PORT` sends no `X-Forwarded-*` at all -
+so an https canvas behind that config drops `Secure` and the cookie will travel
+over plain http. Proxies that do set the header (Railway, Fly, Vercel, Caddy,
+nginx with `proxy_set_header`) were never affected. Fixed in 0.11.1; on 0.11.0 the
+gate cookie guessed regardless.
+
+The costs are the ordinary costs of passwords. It is one secret shared by
+everybody, so removing one person means rotating it for all of them; there is no
+password reset; and a person with five canvases keeps five passwords.
+
+### Marver Sign In (`MARVER_ID_ISSUER`) - recommended for teams
+
+```bash
+MARVER_ID_ISSUER=https://id.marver.design \
+MARVER_PUBLIC_ORIGIN=https://your.canvas \
+MARVER_DATA_DIR=/data \
+npx marver serve
+```
+
+The gate asks people who they are instead of asking for a shared secret. They sign
+in once - with Google, or a code emailed to them - and every canvas you gate this
+way opens without another password. Nobody types a canvas password, so there is
+none to leak, rotate, or forget, and revoking one person revokes them.
+
+A Marver account is **free**, and there is exactly one of it. That is the point:
+the account is not per canvas, so the second board you share with somebody costs
+them nothing - no signup, no password to store, no invite link to keep. The first
+canvas is where they pay the thirty seconds; every one after that is a click. If
+you have ever watched a review die because a reviewer could not find the link, that
+is the friction this removes.
+
+This is the better default for a team, and it is the one we run ourselves. What it
+costs you is honest to state:
+
+- **A dependency.** If the identity service is unreachable, sign-in fails closed:
+  existing sessions keep working, new ones are refused, nothing falls back to open.
+- **The service learns when somebody signs in**, and to which canvas origin. It
+  does not learn whether you let them in, what is on the canvas, or anything else.
+- **It is a hosted service**, so it is the one part of a self-hosted canvas that is
+  not self-hosted. The protocol is ordinary ES256 + JWKS and the verifying half
+  lives in this repo (`src/server/marver-id.ts`), so a different issuer is a
+  configuration change, not a fork.
+
+A canvas with no `MARVER_ID_ISSUER` set makes no outbound request at all. Opting
+out is the default, and this section is the only reason to opt in.
+
+#### Configuration
+
+`MARVER_PUBLIC_ORIGIN` is **required** - always, including in development - and the
+canvas refuses to start without it. Every assertion is bound to this exact origin
+(scheme, host and port), so one minted for one canvas is inert at another.
+
+It is configuration rather than inference on purpose, and the reason is worth
+knowing if you deploy behind a proxy. The canvas used to work this out for itself
+when the connection looked local, which is wrong in the most ordinary setup there
+is: nginx's documented `proxy_pass http://localhost:PORT` rewrites `Host` to the
+upstream and adds no `X-Forwarded-*` headers at all, so a request from the open
+internet arrives looking exactly like one from your own machine. There is no signal
+here a proxy cannot erase, so the canvas asks instead of guessing.
+
+It must be a bare origin - https anywhere, or http on loopback - with no path or
+query. Cookie security follows it, not any forwarded header:
+
+```bash
+MARVER_PUBLIC_ORIGIN=https://canvas.example.com   # deployed
+MARVER_PUBLIC_ORIGIN=http://localhost:4199        # development
+```
+
+#### Who gets in
+
+An address may enter if it already has an account on this canvas, holds an
+unexpired invite, or is `MARVER_OWNER_EMAIL` on a canvas with no accounts yet. You
+invite people exactly as before; Marver Sign In only removes the password step from
+claiming it.
+
+People are matched on the stable identity behind the address, not the address
+itself, so somebody whose email changes keeps their account and their history. Their
+other sessions are signed out when that happens - a session records the address it
+was minted for, and leaving it alive would hand it to whoever claims that address
+next. A rename onto an address someone else already holds is refused outright.
+
+> **Managing people needs `MARVER_CLI_TOKEN`.** `marver comments invite`,
+> `revoke` and `sync` authenticate the CLI with a password, and an identity
+> account has none. Set `MARVER_CLI_TOKEN` on the canvas to a generated secret of
+> 32 characters or more and hand the same value back:
+>
+> ```bash
+> # on the canvas:  MARVER_CLI_TOKEN=$(openssl rand -hex 24)
+> MARVER_CLI_TOKEN='<that same value>' marver comments connect https://canvas.example.com
+> ```
+>
+> `--token` works too, but a secret on the command line is visible to anything
+> that can list processes, so prefer the variable.
+>
+> Generate it, do not choose it: nothing rate-limits this credential and nothing
+> slows a guess down, so its entropy is the whole defence. Use hex rather than
+> base64 - an `Authorization` header carries letters, digits, `_` and `-`, and the
+> canvas refuses to start on a value it could never accept. It acts as whoever
+> owns the canvas, so let the owner sign in once first.
+>
+> `connect` trades it for an ordinary session and stores THAT in
+> `~/.marver/canvases/`, so neither the secret nor the session lands in your repo.
+>
+> **To revoke it, rotate `MARVER_CLI_TOKEN`.** Every session it ever minted stops
+> working the moment the variable changes; sessions people hold in their browsers
+> are untouched. `marver comments revoke` cannot help here - the session acts as
+> the owner, and a canvas refuses to remove its last owner - so rotation is the
+> lever, and it is the reason each device session records which secret minted it.
+> (One instance at a time, as ever: during a rolling restart an old replica still
+> honours old sessions until it drains.)
+>
+> It is a deployment variable rather than something a page hands out, and that is
+> deliberate. A browser-approved sign-in for the CLI was built for this and then
+> removed before release: authored frames run same-origin in a canvas, so frame
+> JavaScript could have driven the approval itself and walked away with a
+> long-lived credential; no header distinguishes a frame from the page around it,
+> because they are the same origin. Per-member CLI credentials still want the
+> frame isolation this release does not have, so the one credential is the
+> operator's.
+
+### The gate footer
+
+The gate footer ("Powered by Marver.design") is the honor system, not enforcement:
+Marver is free, the gate is fully personalized to your app, and that one line is how
+the tool spreads - we'd love it if you keep it. It's yours to remove, no strings:
+`share: { branding: false }` in `design/config.ts` (this also strips every Marver
+mention from the page metadata, the sign-in screens included).
+
+### Name the canvas
+
+`share: { name: "Your App" }` in `design/config.ts`. That name titles the gate,
+labels the brand pill, and becomes `utm_campaign` on every powered-by link the
+canvas emits, so site analytics can tell which canvas sent a visitor. Unset, the gate
+falls back to your `package.json` name and the canvas shell to the root
+directory name - which inside a container is usually `app`, so every unnamed
+containerised canvas reports as one campaign.
+
+## Railway (the one-pager)
+
+1. Push your repo to GitHub and create a Railway service from it.
+2. Build command: `npm ci && npx marver build`
+3. Start command: `npx marver serve`  (Railway's `$PORT` is picked up automatically)
+4. Variables: `MARVER_PASSWORD=<your password>`
+
+Deploy. The repo itself is the deployable - nothing to export, nothing to sync.
+
+## Docker (everywhere else)
+
+```dockerfile
+FROM node:22-slim
+WORKDIR /app                      # set share.name in design/config.ts - the fallback name is this directory
+COPY . .
+RUN npm ci && npx marver build
+ENV PORT=8080
+EXPOSE 8080
+CMD ["npx", "marver", "serve"]
+```
+
+## Cloudflare Pages + Access (email/domain allowlists)
+
+For teams that want per-email policies instead of one password: build in CI
+(`npx marver build`, output directory `design/.dist`), deploy to Pages, then put
+Cloudflare Access in front with your email or domain rules. Google login and audit
+logs come free; Marver ships no auth code at all in this setup.