@marver-design/marver 0.11.0 → 0.12.0

package/CHANGELOG.md

@@ -2,6 +2,81 @@
 
 Notable changes to `@marver-design/marver`. Format follows [Keep a Changelog](https://keepachangelog.com); versions follow semver.
 
+## 0.12.0 - 2026-08-31
+
+### Added
+
+- **Sharing: grant people access to a canvas, person by person, from the terminal or
+  the browser.** On a canvas with a persistent volume and an owner account, `marver share`
+  manages a roster of *people* - who may open the canvas, who may comment, and until when -
+  over the canvas's owner-only routes; the browser share dialog drives the same routes.
+  `add`, `remove`, `block`, `unblock`, `general <mode>`, `list`, `requests`, `explain`, and
+  `who` cover the whole surface. Exact-email grants work on a password canvas; domain grants
+  (`@acme.com`), refused-visitor access requests, and the front door need Marver Sign In.
+  The full guide is [docs/sharing.md](docs/sharing.md).
+
+  **One resolver, one place.** A single pure function answers "what can this person do here" -
+  blocklist first (the only deny), then the owner, then grants additive with the highest match
+  winning, then a general-access floor, all clamped by each board's published ceiling. The gate
+  and comment writes enforce from it, reading one `share.json`, so the policy is one thing in
+  one place rather than a rule re-implemented per door. `marver share explain <email>` traces
+  it for one person and `marver share who` prints the grant matrix (both convenience views -
+  the dialog is the accurate read for the owner and for domain principals).
+
+- **`design/publish.json` v2: a board can carry its artifact type and landing view, not just
+  its ceiling.** A board level may now be an object - `{ "max": "read" | "comment", "type":
+  "doc" | "slides" | "design" | "sketch" | "refs" | "mix", "open": "canvas" | "board" |
+  "present" | "focus" | "slides", "lock": true }` - where `max` is the ceiling (the only
+  field that affects access) and the rest choose how the board presents. `open` accepts all
+  five view names, but slides mode is v1.5: `open: "slides"` currently lands in `present`.
+  Every 0.11 canvas parses unchanged: a bare `"read"` or `"comment"` string is still a valid
+  row. (This is a schema version, unrelated to the read-privacy "v2" below.) Source paths
+  in a published bundle now go opaque by default (`reveal.source` defaults off) - the inlined
+  manifest used to carry every frame's repo path, which is a disclosure the moment a canvas
+  is shared beyond its own repo.
+
+- **Access requests: a refused visitor can ask, and you can approve from the terminal.** When
+  someone is turned away at the identity gate, the canvas offers a request form instead of a
+  dead end (authenticated by a short-lived, origin-bound, single-purpose token - the refused
+  visitor has no session). Requests surface in `marver share requests` and the dialog;
+  approving grants canvas-wide at the role you choose, declining resolves silently. One
+  pending row per address, swept after 30 days.
+
+- **The front door at `app.marver.design`.** A signed-in home page that lists the canvases a
+  person can reach, each row lit by a short summary the canvas itself signs and serves. The
+  front door holds no roster and makes no access decision - it asks each canvas, and each
+  canvas answers for itself, against browser-pinned keys. Keep a canvas silent there with
+  `share: { frontDoor: false }` in `design/config.ts`.
+
+### Notes
+
+- **Read privacy is still v2.** Sharing v1 controls who gets in and who may comment; every
+  admitted person can read every published board. The read boundary today is the bundle - a
+  board you do not publish is not in the build. Grants are canvas-scoped and approvals are
+  canvas-wide by design; `share.json` is already shaped for the per-board, per-person read
+  privacy that arrives in v2, served rather than bundled.
+
+- **First boot writes `share.json` from your live 0.11 state and changes nothing you did not
+  ask for.** Every existing account gets the canvas-wide `comment` grant it already had
+  (clamped per board); until that first boot, every door keeps the legacy rules. Raising a
+  board's ceiling never silently re-promotes anyone granted under the old one - the roster
+  ratchets down on every boot and only your explicit re-confirm raises an entry.
+
+## 0.11.1 - 2026-08-27
+
+### Fixed
+
+- **The password gate's cookie now gets `Secure` from the pinned origin too.** 0.11.0 fixed
+  this for the collaboration session cookie and missed the gate's own, which is set in a
+  different file and is the one most likely to be sitting behind a plain `proxy_pass` - it is
+  the door on every password-mode canvas. Same rule, same reason: `MARVER_PUBLIC_ORIGIN`
+  decides when it is set, and `X-Forwarded-Proto` is the fallback only when there is nothing
+  better. Set `MARVER_PUBLIC_ORIGIN=https://your-canvas.example.com` and the thirty-day gate
+  cookie is https-only regardless of what your proxy tells the process.
+
+  Canvases behind a proxy that does send `X-Forwarded-Proto` - Railway, Fly, Vercel, Caddy,
+  and nginx configured with `proxy_set_header` - were never affected.
+
 ## 0.11.0 - 2026-08-27
 
 ### Added
@@ -105,15 +180,18 @@ Notable changes to `@marver-design/marver`. Format follows [Keep a Changelog](ht
 
 ### Fixed
 
-- **`Secure` on the session cookie no longer depends on a header your proxy may not send.**
-  A canvas decided whether it was on https by reading `X-Forwarded-Proto`, and nginx's own
-  documented `proxy_pass http://localhost:PORT` sets no `X-Forwarded-*` at all. A canvas
-  served over https behind that configuration saw no header, concluded "not secure", and
-  issued a thirty-day session cookie the browser would happily send over plain http. Where
+- **`Secure` on the collaboration session cookie no longer depends on a header your proxy may
+  not send.** A canvas decided whether it was on https by reading `X-Forwarded-Proto`, and
+  nginx's own documented `proxy_pass http://localhost:PORT` sets no `X-Forwarded-*` at all. A
+  canvas served over https behind that configuration saw no header, concluded "not secure",
+  and issued a thirty-day session cookie the browser would happily send over plain http. Where
   `MARVER_PUBLIC_ORIGIN` is set it now decides - a deliberate statement by whoever deployed
   the canvas, rather than a guess about a proxy that may not be speaking. The header remains
   the fallback only where there is nothing better, which is development on loopback.
 
+  This release fixed the collaboration session cookie only. The password gate's own cookie
+  still guessed from the header - see 0.11.1.
+
 - **The collaboration credential has moved out of your repository, because `marver dev` was
   serving it.** It lived at `design/.local/collab.json`, and the dev server puts the repository
   on the web so frames can import from it. Authored frames run same-origin, so any frame could

package/README.md

@@ -6,7 +6,7 @@
 
 **The agent-native design canvas.** A `design/` folder in your repo, one command, and a canvas of live frames built from your app's real components and theme. Your coding agent designs by writing files; the tool ships no AI.
 
-[marver.design](https://marver.design) · [Live Jam](docs/live-jam.md) · [Deploying a canvas](docs/publish.md) · [Changelog](CHANGELOG.md) · [Contributing](CONTRIBUTING.md) · [Issues](https://github.com/TNEP4/marver/issues)
+[marver.design](https://marver.design) · [Live Jam](docs/live-jam.md) · [Deploying a canvas](docs/publish.md) · [Sharing](docs/sharing.md) · [Changelog](CHANGELOG.md) · [Contributing](CONTRIBUTING.md) · [Issues](https://github.com/TNEP4/marver/issues)
 
 ## Quickstart
 
@@ -28,6 +28,7 @@ Frames appear on the canvas the moment the files land. That's the loop.
 - **Everything hot-reloads.** The agent writes, you watch it land - live.
 - **True viewports.** Each frame is a real iframe: drag its edge and your actual breakpoints fire.
 - **Your agent answers on the canvas.** Tag `@marver` in a comment and it picks up the job, edits the real source, and replies in the thread - no wiring, on by default. See [Live Jam](#live-jam).
+- **Feedback without a signup wall.** Publish the canvas, invite people by email, and they sign in as themselves - one free Marver account, Google or an emailed code, and it opens every canvas you ever share with them. Or keep it entirely self-hosted behind a shared password. See [Collaboration](#collaboration).
 - **No AI inside.** The designer is the coding agent you already run and pay for. `init` generates the `design/AGENTS.md` contract that teaches it the whole workflow.
 
 ## The canvas
@@ -40,9 +41,21 @@ Frames appear on the canvas the moment the files land. That's the loop.
 
 ## Collaboration
 
-- **Comments.** Google-Docs-style feedback pinned to actual elements. Press `c`, click a div inside a frame, write - the thread lives on that element and survives edits via a layered anchor (source semantics → structure → fuzzy text). Viewers on a published canvas comment with real names and avatars (invite-link accounts, no email infrastructure). `marver dev` syncs the same threads into `design/comments/*.jsonl`, where your agent works the queue: `npx marver comments list --open --json` → fork a variant → `resolve --addressed-in`. Live via SSE; one deploy, no extra services.
+- **Comments.** Google-Docs-style feedback pinned to actual elements. Press `c`, click a div inside a frame, write - the thread lives on that element and survives edits via a layered anchor (source semantics → structure → fuzzy text). Viewers on a published canvas comment with real names and avatars - either a Marver account they already have, or an invite-link account on that canvas alone. `marver dev` syncs the same threads into `design/comments/*.jsonl`, where your agent works the queue: `npx marver comments list --open --json` → fork a variant → `resolve --addressed-in`. Live via SSE; one deploy, no extra services.
 - **Laser mode.** Press `l`: every element in every frame gets depth-hued outlines plus a hover label - the fastest way to see structure. Click any element to copy its full address (frame file + CSS path) for the agent.
-- **Publishing.** `npx marver build` exports a static canvas (default-closed: `design/publish.json` names what ships); `npx marver serve` hosts it with an optional password gate. One deploy on Railway, Docker, or any static host - the [publishing guide](docs/publish.md) has the one-pagers.
+- **Publishing.** `npx marver build` exports a static canvas (default-closed: `design/publish.json` names what ships, and whether each board is `read` or `comment`); `npx marver serve` hosts it. One deploy on Railway, Docker, or any static host - the [publishing guide](docs/publish.md) has the one-pagers.
+
+- **Two ways to let people in.** They are alternatives, not layers - pick one per canvas.
+
+  **Marver Sign In** (new in 0.11). Set `MARVER_ID_ISSUER=https://id.marver.design` and reviewers sign in as themselves, with Google or a six-digit code emailed to them. One free Marver account opens *every* canvas gated this way, so the second board you share costs them nothing: no new signup, no new password, no link to keep. You invite an email address and they are in.
+
+  That is the whole difference, and it is the difference between "I'll look later" and a comment actually landing on the board. It also means their real name and face ride along, so a thread is from a person rather than from an address.
+
+  **A shared password** (`MARVER_PASSWORD`). Fully self-hosted, no account anywhere but your own volume, nothing about your reviewers leaves your infrastructure - and still fully supported, not a legacy path. The trade is that every canvas is an island: reviewers claim an invite link and pick a name and password *on that canvas*, and do it again for the next one. Fine for one board, a toll on the fifth.
+
+  Either way the canvas runs on your infrastructure and stores its own comments and members. With Marver Sign In the identity service only ever tells your canvas that a verified address matched an entry on your invite list - it never sees your frames, your files, or your comments. Rights stay yours: `design/publish.json` decides which boards are readable and which are commentable, and `marver comments invite`/`revoke` decides who is on the list.
+
+  *Coming next:* one home for your account - every canvas you have been invited to, every canvas you have shared, and the access each one carries, in a single list. Today the account page at `id.marver.design` shows the canvases you have approved and lets you revoke them.
 
 ## Live Jam
 
@@ -61,7 +74,7 @@ The same glow, driven from the terminal. When your agent takes a request, it cre
 | `npx marver init` | Scaffold `design/` in this repo (safe to re-run; refreshes managed files) |
 | `npx marver dev` / `canvas` | Start the local canvas - hot reload, comments, Live Jam armed (`--port`, default 5199) |
 | `npx marver build` | Static export → `design/.dist`; what ships comes from `design/publish.json` (default-closed) |
-| `npx marver serve` | Serve the export; `MARVER_PASSWORD` gates it, `MARVER_DATA_DIR` persists comments + accounts |
+| `npx marver serve` | Serve the export; `MARVER_ID_ISSUER` or `MARVER_PASSWORD` gates it, `MARVER_DATA_DIR` persists comments + accounts |
 | `npx marver comments …` | The agent's queue: `connect <url>` · `sync` · `list` · `reply` · `resolve` · `invite <email>` · `revoke <email>` |
 | `npx marver work …` | Working glow from the terminal: `start <scene/frame …>` · `done … \| --all` · `list` |